はじめに
自動化が安全なのは、意図したホストに処理が届く場合だけです。1 台のマシンに 2 つの別名がある場合、ホストが欠けている場合、選択範囲が広すぎる場合は、コマンドが成功しても誤解を招くことがあります。
この実習では、異なる 2 つの SSH 対象を canary と stable のグループに整理し、親グループを調べ、ホストパターンをプレビューして、canary だけにマーカーを作成します。Ansible と練習用の接続は準備済みです。インベントリとコマンドの対象範囲を扱います。
ホストをグループに整理する
このステップでは、既存の 2 つの SSH ホストを、識別名やアドレスを重複させずにグループ化します。
ターミナルを開き、プロジェクトに移動します。
cd /home/labex/project
編集する前に、用意されたインベントリを読んでください。
cat inventory.ini
異なる ansible_host の値を持つ web1 と web2 が定義されています。これらの行と [all:vars] の接続設定を維持してください。インベントリ名はホストを識別します。同じ名前を複数のグループに配置しても、別のサーバーは作成されません。
グループはホストの集合を表します。最初のホストには canary、2 番目には stable、両グループを含む親には webservers を使用します。次のセクションを追記してください。>> は既存のファイルを維持し、引用符で囲まれたヒアドキュメントの区切り文字は貼り付けたテキストをそのまま保持します。
cat >> inventory.ini <<'EOF'
[canary]
web1
[stable]
web2
[webservers:children]
canary
stable
EOF
[canary] と [stable] にはホスト名を記述します。:children で終わるセクションにはグループ名を記述するので、webservers は canary と stable に属するホストを引き継ぎます。これらのグループの下に新しい接続先アドレスを記述しないでください。
ansible-inventory --graph は、解決済みの所属関係を描画します。
ansible-inventory --graph
canary の下に web1、stable の下に web2 が表示され、両グループが webservers の下にあるはずです。特殊な all と ungrouped の項目も表示される場合があります。ホストはグラフの複数の枝に現れても、インベントリ上は 1 ホストのままです。
ホストパターンは、コマンドの対象を選択します。モジュールを実行せずに親グループをプレビューします。
ansible webservers --list-hosts
web1 と web2 だけが表示されるはずです。パターンの :& は共通部分、つまり両方に属するホストを選択することを意味します。シェルが & を解釈しないよう、引用符で囲んでください。
ansible 'webservers:&canary' --list-hosts
web1 だけが表示されるはずです。このプレビューにより、ホストを変更する前に選択ミスを発見できます。
変更を Canary に限定する
このステップでは、stable ホストとコントローラーを維持しながら、canary に小さな変更を加えます。
コマンドの最初のパターンが初期集合を選択します。--limit はそれをさらに絞り込み、その集合の外のホストは追加しません。使用前に、限定した選択内容をプレビューしてください。
ansible webservers --limit canary --list-hosts
1 ホスト、web1 が表示されるはずです。何にも一致しない limit では、モジュールの失敗なしにコマンドが終了しても、変更の成功を証明できません。
前の実習の command モジュールで touch を実行します。この Linux コマンドは、ファイルが存在しなければ空のファイルを作成し、存在すればタイムスタンプを更新します。マーカーは管理対象の automation ユーザーのホームに置きます。-a の値を引用符で囲むと、実行ファイルとパスをまとめて渡せます。
ansible webservers --limit canary -m ansible.builtin.command -a 'touch /home/automation/canary-ready'
web1 だけにコマンドの成功結果が表示されるはずです。この操作は、あえて単純な対象範囲の練習にしています。touch は繰り返すたびにタイムスタンプを更新できるので、その CHANGED ステータスは冪等性の実証にはなりません。
各管理対象ユーザーのホームにある、隠しファイル以外のファイルを調べます。ls は Ansible の command モジュールで実行されるため、各対象のディレクトリを一覧表示します。
ansible webservers -m ansible.builtin.command -a 'ls /home/automation'
web1 の結果には canary-ready が含まれるはずです。web2 の結果にはその名前が含まれず、標準出力が空の場合もあります。これらはリモートのディレクトリであり、コントローラーの作業スペースとは別のものです。
最後に、コントローラーの現在のディレクトリを調べます。
ls
プロジェクト設定とインベントリが表示され、ローカルの canary-ready マーカーはないはずです。コントローラーを変更したのではなく、実際の管理対象ホストを選択しました。今後の実習では、ファイルの状態を直接宣言するモジュールを使用し、冪等性を検証します。
まとめ
異なる 2 つのインベントリ上の識別名を維持し、ホストと子グループを整理して、引用符で囲まれた共通部分のパターンをプレビューし、--limit でコマンドの対象を絞りました。対象の実際の状態から、マーカーが canary だけに存在し、stable ホストとコントローラーは変更の範囲外に保たれたことを確認しました。
