ハンドラートリガー
これはトリガーに似ています。たとえば、このようなシナリオでは、nginx conf構成ファイルをターゲットマシンにコピーし、構成ファイルが更新されたら、nginxを再起動する必要があります。同様の要件については、Ansibleハンドラーを使用します。すること
- name: Copy configuration files
copy:
src: xtest1.conf
dest: /etc/nginx/conf.d/xtest1.conf
notify:
- restart_nginx
handlers:
- name: restart_nginx
service:
name: nginx
state: restarted
完全な例
https://gitee.com/as4k/ysansible/blob/master/handlers/main.yml
環境変数の増加と変更
多くのシナリオがあり、selinuxをオフにするなど、ターゲットマシンのいくつかの変数(または構成)を変更する必要があります。この操作がシェルスクリプトとして記述されている場合、次のようになります。
sed 's#^SELINUX=.*#SELINUX=disabled#g' /etc/selinux/config
以下に示すように、Ansibleも同様の使用法を提供します
- name: Ensure SELinux is set to disabled mode
lineinfile:
path: /etc/selinux/config
regexp: '^SELINUX='
line: SELINUX=disabled
テキストファイルの行を変更したり、行を追加したりする必要がある場合は、基本的にlineinfile
モジュールを使用します
たとえば~/.bash_profile
、次のような環境変数を追加しています
- name: Add an environment variable to the remote user's shell.
lineinfile:
path: "~/.bash_profile"
regexp: "^ENV_VAR="
line: "ENV_VAR=value_helloworld"
上記のモジュールの意味は、~/.bash_profile
この行がありENV_VAR=value_helloworld
、一部は変更されておらず、増加がないことを確認することです。
もう1つ言及すべきことは、さまざまな環境変数を別のファイルに配置するのが最適であるため、メンテナンスに最も便利です。たとえば、環境変数をCenOS7/etc/profile.d
に配置できるため、ファイルをコピーするだけで読みやすくなります。と維持します。
- name: Copy java_env
copy:
src: java_env.sh
dest: /etc/profile.d/java_env.sh
Ansibleには多くの高度ですばらしい使用法がありますが、実稼働環境でAnsibleを使用しても、スキルを誇示することはできません。単純なモジュールを使用して問題を解決できる場合は、単純なモジュールを使用してください。
完全な例
https://gitee.com/as4k/ysansible/blob/master/env_variables/main.yml
スクリプトで変数を使用する
プログラミング言語であろうとAnsibleであろうと、繰り返し使用する必要のあるものが常にいくつかあります。現時点では、メンテナンスと変更を容易にするために、これらを変数に入れる必要があります。たとえば、ブログソフトウェアのスクリプトを記述します。 PHPで記述されている場合)、ソフトウェアのバージョン番号は変数として適しているため、将来的にスクリプトをアップグレードするか、スクリプトを他の人に渡す必要があります。バージョン番号を変更するだけで、対応するバージョンに移動する必要はありません。スクリプト内のスクリプト場所を手動で変更する
通常、スクリプトを入手するときは、最初に使用可能な変数を確認する必要があります。これらの変数は、外部アクセスインターフェイスと同等です。ソフトウェアのバージョン番号やソフトウェアのデータストレージディレクトリなどの場合、これらは明らかに次のことを行う必要があります。さまざまなシナリオに従って使用する。、通常、コミッション変数を使用することをお勧めします。
可変命名規則
开头是 [A-Za-z]
其它地方可以包含 下划线_ 数字[0-9]
合法的变量示例:foo, foo_bar, foo_bar_5
不合法的变量示例:_foo, foo-bar, 5_foo_bar, foo.bar
スクリプトに埋め込まれた変数
vars:
http_port: 80
https://gitee.com/as4k/ysansible/blob/master/variables/playbook_var_in_file.yml
YAMLファイルに個別に書き込まれる変数
vars_files:
- vars.yml
https://gitee.com/as4k/ysansible/blob/master/variables/playbook_var_file.yml
コマンドラインで直接追加された変数
# ansible-playbook playbook_var_cmd.yml --extra-vars "foo=bar" --limit 192.168.31.100
# ansible-playbook playbook_var_cmd.yml --extra-vars "@vars.yml" --limit 192.168.31.100
https://gitee.com/as4k/ysansible/blob/master/variables/playbook_var_cmd.yml
これらの方法での変数の使用には優先順位の違いがあります。コマンドラインで使用される変数の優先順位が最も高くなります。詳細については、次のドキュメントを参照してください。
https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable
スクリプトを使用してAnsibleを整理する場合(より基本的な、後で役割を紹介します)、プレイブックに埋め込まれる変数が少なくなり、1つ以上のファイルから独立している変数が多くなります。それ以外の場合は、使用する--extra-vars
フォームを少なくすることをお勧めします。このフォームは追跡が容易ではないため、テストに使用されますが、ファイルに書き込まれ、gitなどのコード管理ツールを使用して追跡できます。
コマンド出力をキャプチャするためのレジスタ変数レジスタ
たとえば、一部のシナリオでは、ターゲットマシンにソフトウェアをインストールする必要がありますが、インストールする前に、コマンドを実行してターゲットマシンの状態を動的に判断する必要があります。A、B、およびの3つの状態があると想定します。 C、および各状態で実行する必要があるもの同じではないため、以下に示すように、後で使用するために、最初に状態(つまり変数)を保存する必要があります。
- name: Register the output of the 'uptime' command.
command: uptime
register: system_uptime
- name: Print a simple message if a command resulted in a change.
debug: msg="Command resulted in a change!"
when: system_uptime.changed
https://gitee.com/as4k/ysansible/blob/master/registered_var/main1.yml
変数の種類と変数へのアクセス
Ansibleの主な開発言語はpythonであり、配列や辞書など、多くのpythonデータ型もAnsibleで利用できます。Ansibleはテンプレート変数の置換にjinjia構文を使用します。
最も基本的な
- name: test1
debug:
msg: "{
{ foo }}"
不加双引号会报错
アレイ
foo3_list:
- one
- two
- three
==========
- name: test3
debug:
msg: "{
{ foo3_list[1] }}"
- name: test4
debug:
msg: "{
{ foo3_list|first }}"
数组从0开始
{
{ foo3_list|first }} 与 {
{ foo3_list[1] }} 等价, |first 是jinjia过滤器的语法
辞書
foo4_dict:
xiaoming: 186
xiaowang: 187
xiaoli: 188
============
- name: test4
debug:
msg: "{
{ foo4_dict.xiaoming }}"
- name: test5
debug:
msg: "{
{ foo4_dict['xiaoli'] }}"
- name: test6
debug:
msg: "{
{ ansible_eth0['ipv4']['address'] }}"
{
{ foo4_dict.xiaoming }} 与 {
{ foo4_dict['xiaoli'] }} 等价
如果字典的key有些什么特殊符号之类,用第2种
変数型は複雑にネストすることもできますが、必要がない場合は、単純なデータ型を使用してみてください
完全な例
https://gitee.com/as4k/ysansible/blob/master/acccessing_var/main1.yml
ホストリストのインベントリ変数
フォームは次のとおりです
cat /etc/ansible/hosts
[allservers]
192.168.31.106
192.168.31.100
192.168.31.101
192.168.31.102
192.168.31.103
192.168.31.104
192.168.31.105
192.168.31.107
192.168.31.108
[webservers]
192.168.31.100 os=centos73 admin_user=jane
192.168.31.101 os=centos77 admin_user=jack
192.168.31.102 os=centos78
[webservers:vars]
dns1=223.5.5.5
dns2=8.8.8.8
admin_user=admin
ここで定義されている変数とスクリプトで定義されている変数に大きな違いはなく、スクリプトで使用できます。通常、指定されたマシンまたは指定されたマシングループ(NTPなど)に強く関連する変数のみがあります。マシンのグループによって使用されるタイムサーバー。すべて中国にありますが、マシンの1つは特殊で、外部のタイムサーバーを使用するため、変数を使用してホストリストでそれを識別できます。
ただし、ホストリストに書き込まれる変数が多すぎると、面倒になります。より適切な解決策は、それらを分離すること、つまり「ホスト変数とグループ変数」です。
ホスト変数とグループ変数
次のディレクトリ構造を確認してください
[root@192_168_31_106 /data/ysansible]# tree host_and_group_variables/
host_and_group_variables/
├── group_vars
│ └── webservers
├── hosts
├── host_vars
│ ├── 192.168.31.100
│ ├── 192.168.31.101
│ └── 192.168.31.102
├── main1.yml
└── README.md
# 对应线上代码在 https://gitee.com/as4k/ysansible/tree/master/host_and_group_variables
hostsはホストリストファイルです。実際に実行されると、現在のディレクトリに移動し、-i
パラメータを使用して次のようなホストリストを指定します。
ansible-playbook main1.yml -i hosts
group_vars
andhost_vars
フォルダーは固定ディレクトリであり、ホストリストと同じレベルのディレクトリにある必要があります。group_varsの下のファイル名はホストリスト内のグループ名に対応し、host_varsの下のファイル名はホストリスト内のホストに対応します。 (IPまたはIPの場合があります。ドメイン名の場合があります)。これらはそれぞれ、マシンのグループによって共有される変数と単一のマシンによって所有される変数を表します。hosts_varsはgroup_varsよりも優先度が高くなります。
さらに、all
すべてのマシン(グループ)で使用できる変数を表す特別なグループ名(ファイル名)があります。
事実システム変数の収集
Linuxオペレーティングシステムには、メモリ、CPU、オペレーティングシステムのバージョン、イントラネットIPアドレスなど、多くの基本情報があります。この情報は、サービスを展開するときによく使用されます。Ansibleはこれらを事実と呼び、この機能が有効になっています。デフォルトでは、直接使用できます
---
- hosts: all
gather_facts: yes
# gather_facts: no
#默认是yes
#关掉信息收集可以提升性能,但不能再使用相关变量
tasks:
- name: get ip address
debug:
msg: "{
{ ansible_eth0['ipv4']['address'] }}"
使用できるすべての事実を確認したい場合は、次のコマンドを使用できます
ansible 192.168.31.100 -m setup > ansible_setup.json
CentOS7によって収集されるすべてのシステム変数については、以下を参照してください。
https://gitee.com/as4k/ysansible/blob/master/facts/ansible_setup.json
参照例:https://gitee.com/as4k/ysansible/blob/master/facts/main.yml
自分でシステム変数を手動で追加することもできます。以下は、シェルコマンドを使用してIPアドレスを取得する例です。
- name: Get host IP address.
shell: >
prefix=`/sbin/ip route | awk '/default/ { print $3 }' | sed -r 's#\.[0-9]+$##g'`;
hostname -I | egrep -o "$prefix\.[0-9]+"
register: host_ip
changed_when: false
- name: Set host_ip_address variable.
set_fact:
host_ip_address: "{
{ host_ip.stdout }}"
参照例:https://gitee.com/as4k/ysansible/blob/master/facts/set_fact.yml
組み込みのホストインベントリ変数
この点で、ansible_hostを紹介します
- name: ansible_host
debug:
msg: "echo {
{ ansible_host }}"
この組み込み変数は、ホストリスト内のIPアドレスを取得するために特に使用されます(もちろん、ドメイン名でもかまいません)。実稼働環境では、通常、マシンには複数のネットワークカードがあり、複数の内部ネットワークIPアドレスですが、通常は主にイントラネットIPアドレスとして使用されます。このとき、前節の事実を利用してIPアドレスを収集すると、複数になります。どのIPがメインIPアドレスであるかを区別する方法少し面倒です。したがって、ansible_host
この組み込みのホストクリア変数を直接使用するため、メインIPアドレスをホストリストに自分で入力するだけで済みます。
参照例:https://gitee.com/as4k/ysansible/blob/master/centos7_init/centos7_init.yml
Vaultの安全な暗号化
プレイブックには、データベースのルートパスワードなど、機密情報が含まれている場合があります。他の人に見られたり、gitリポジトリに直接同期されたりしたくない場合は、現時点では、次のような機密情報を分離する方が簡単です。現在のプロジェクトの外部に直接配置し、使用時にターゲットマシンにコピーするなど、関連するパスワードとして。ただし、この方法は管理が簡単で面倒で、元のプレイブックの整合性が損なわれます。この場合、AnsibleVault暗号化機能の使用を検討できます。
簡単な例を見てください
cat vars.yml
my_password: hello123456
=============
#执行加密指令
ansible-vault encrypt vars.yml #系统会要求输入密码,需要记住这个密码
New Vault password: 123456
Confirm New Vault password: 123456
Encryption successful
=============
cat vars.yml
$ANSIBLE_VAULT;1.1;AES256
37613864313965393631653339356633376666386537353338613865373863316562396461303366
3161643662343963316534396365643265383562303862360a363662636437313033646333363339
30333232656361363233626436383434386234646361303130353662633566373231333934656535
6561373861346434650a303635333632616263373631393566666363373334303162363161386338
39646333353137396133363831663166633366323731646339396261623432336361303039643164
34393365383932393236653733366362303766663833376433633864343638346338646430326664
35396630663162313238396262616539376361663534623132346634613865386135643335636138
34346431636430383366323235346662653337633739366564643637313164326662633933346236
32636538646537663933373836386234366337363661323334313635346633313266643365653165
6437643437666365363830353162666163643365313366353937
ご覧のとおり、元のテキストは直接変更および暗号化されています。使用方法を見てみましょう。
パスワードをインタラクティブに入力して実行
[root@192-168-31-106 /data/ysansible/vault]# ansible-playbook main1.yml --limit 192.168.31.100 --ask-vault-pass
Vault password: 123456 (这个是我们执行ansible-vault encrypt vars.yml命令要求输入的密码,不是vars.yml里面记录的内容)
....
非対話型の直接操作
touch ~/.ansible/vault_pass.txt
echo "123456" > ~/.ansible/vault_pass.txt
chmod 0600 ~/.ansible/vault_pass.txt
ansible-playbook main1.yml --limit 192.168.31.100 --vault-password-file ~/.ansible/vault_pass.txt
他のボールトで一般的に使用されるコマンド
解密成原始文本,需要输入密码
ansible-vault decrypt vars.yml
编辑原始文件,需要输入密码
ansible-vault edit vars.yml
查看原始的文本
ansible-vault view vars.yml
要約すると、Ansibleを使用して情報を暗号化するには、次のことを行う必要があります。
- テキストを暗号化します(テキストの内容を変更する必要はありません)
- 暗号化パスワードを適切に保持する
- コマンド実行時に
--vault-password-file
パラメータを追加する
暗号化の導入には、まだ追加のメンテナンスコストが必要です。暗号化されたテキストだけでは基本的に意味がありません。状況に応じて選択できます。
参照例:https://gitee.com/as4k/ysansible/blob/master/vault/main1.yml
レジスタ変数レジスタ
場合によっては、ターゲット構成ファイルから変数を読み取り、後で使用するために記録する必要があります。たとえば、register
以下に示すように、実装可能なターゲットマシンのコンピュータールーム情報を読み取ります。
# ignore_errors 用来防止playbook被打断
- name: Run a shell command and register its output as a variable
shell: cat /etc/redhat-release
register: foo_result
ignore_errors: true
- name: Run a shell command using output of the previous task
shell: echo "ok" > /tmp/tmp.txt
when: foo_result.rc == 0
参照例:https://gitee.com/as4k/ysansible/blob/master/env_variables/main.yml
参照
https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#registering-variables
https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html#playbooks-conditionals