はじめに
単発の Ansible コマンドでは、複数ホストを調査したり、小さく明示的な設定状態を適用したりできます。適切なモジュールを選ぶと、その動作と返される結果を理解しやすくなります。
2 つの Linux 対象を調査し、管理対象ディレクトリを準備して、コントローラーのソースファイルを配布します。コマンド実行と、要求された状態に実際に変更が必要だったかを報告するモジュールを比較します。インベントリと SSH 接続は準備済みです。
モジュールでホストグループを調査する
このステップでは、単発の Ansible モジュールを選び、準備済みの 2 つの管理対象ノードを調査します。
ターミナルを開き、作業スペースに移動します。
cd /home/labex/project
アドホックコマンドは、Playbook を使わず、選択したインベントリのホストに対して 1 つのモジュールを直接実行します。基本形は ansible PATTERN -m MODULE -a ARGUMENTS です。この実習には、両方の SSH 対象を含む webservers グループが用意されています。そのグループをプレビューします。
ansible webservers --list-hosts
web1 と web2 だけが表示されるはずです。前の実習の command モジュールを使い、オペレーティングシステムのカーネル名を表示する uname -s を実行します。
ansible webservers -m ansible.builtin.command -a 'uname -s'
各ホストが Linux と表示するはずです。command モジュールは、読み取り専用の問い合わせでも通常 CHANGED を報告します。この表示を設定変更として解釈せず、標準出力と終了ステータスを調べてください。
setup モジュールは、管理対象ノードで検出された構造化情報であるファクトを収集します。モジュールの filter 引数は、返されるファクトを絞り込みます。ディストリビューション名を調べます。
ansible webservers -m ansible.builtin.setup -a 'filter=ansible_distribution'
各成功結果には、"ansible_distribution": "Ubuntu" を持つ ansible_facts オブジェクトが含まれるはずです。この調査では setup は通常 changed: false を報告します。ファクトが記述するのはコントローラーではなく対象です。今後の実習では、自動化にファクトを利用します。
タスクの結果がゼロ以外なら失敗であり、UNREACHABLE は接続の問題を示します。2 ホストを想定している場合、成功結果も 2 つ必要です。空の選択を、調査完了と取り違えないでください。
管理対象ディレクトリを宣言する
このステップでは、状態を扱うモジュールを使い、両方の対象に同じディレクトリを準備します。
file モジュールはファイルシステムの状態を管理します。path は対象パスを指定し、state=directory は空のファイルではなくディレクトリを要求します。mode=0750 は所有者に全アクセス、グループに読み取りと検索のアクセスを与え、その他のユーザーにはアクセスを許可しません。先頭のゼロは、8 進数の権限値であることを表します。
通常のタスクは、準備済みの automation アカウントとして実行されます。そのユーザーのホーム内にディレクトリを作成するので、become は不要です。
ansible webservers -m ansible.builtin.file -a 'path=/home/automation/ops state=directory mode=0750'
最初にディレクトリを作成したときは、両ホストが changed: true を報告し、path または dest フィールドが /home/automation/ops を示すはずです。automation アカウントが作成するため、ディレクトリの所有者は automation です。
同じ宣言をもう一度実行します。
ansible webservers -m ansible.builtin.file -a 'path=/home/automation/ops state=directory mode=0750'
今度は、要求された状態がすでに存在するため、両ホストが changed: false を返すはずです。これは、タイムスタンプを引き続き更新する可能性がある touch のような汎用コマンドを繰り返す場合とは異なります。
コントローラーのファイルを両方の対象にコピーする
このステップでは、コントローラー上に小さなソースファイルを作成し、対象の権限を明示して、その内容を正確に配置します。
printf はテキストと末尾の改行を書き出します。> は現在のプロジェクトにソースを作成するか、置き換えます。引用符で囲んだ書式はメッセージをまとめて保持し、\n は改行を要求します。
printf 'Managed by Ansible\n' > message.txt
copy モジュールは、コントローラーのソースを管理対象のコピー先に転送します。src はコントローラー上、dest は各対象上のパスです。通常ファイルでは、mode=0640 は所有者に読み書き、グループに読み取りを許可し、その他のユーザーにはアクセスを許可しません。
ansible webservers -m ansible.builtin.copy -a 'src=/home/labex/project/message.txt dest=/home/automation/ops/message.txt mode=0640'
初回のコピーでは、各対象が changed: true を報告するはずです。同じ転送をもう一度実行します。
ansible webservers -m ansible.builtin.copy -a 'src=/home/labex/project/message.txt dest=/home/automation/ops/message.txt mode=0640'
バイト列と要求された権限がすでに一致していれば、changed: false になるはずです。親ディレクトリは file モジュールで準備しました。ファイルのコピーは、そのディレクトリ作成のステップの代わりにはなりません。
command モジュールで、実際のリモートの内容を読みます。
ansible webservers -m ansible.builtin.command -a 'cat /home/automation/ops/message.txt'
両方の標準出力に Managed by Ansible と表示されるはずです。このコマンドによる問い合わせは CHANGED を報告することがありますが、それ以前の copy モジュールの changed:false という結果は、管理対象ファイルがすでに一致していることを示します。コントローラーのソースは、両方のリモートコピーとは別のものとして維持されます。
まとめ
実際の 2 ホストのグループに対してアドホックモジュールを実行し、コマンド出力を解釈して、ディストリビューションのファクトを取得しました。ディレクトリを宣言し、独立したコントローラーのソースを明示的な権限でコピーしました。また、繰り返し実行時に、状態を扱うモジュールが一致する状態を検出すると変更なしになることを観察しました。
