はじめに
Playbook の実行は Ansible の作業の一部に過ぎません。タスクの出力を調査し、実行結果の要約（recap）を理解し、最終的な管理対象ノードの状態を検証することも重要です。
この実験では、ansible-navigator を使用して Playbook を実行し、管理対象ファイルを作成します。その後、再度 Playbook を実行して、目的の状態が維持されていることを確認します。
プロジェクト設定の準備
このステップでは、追加のコマンドラインオプションなしで navigator が実行できるプロジェクトを作成します。設定は前回の実験と同様ですが、今回は複数のファイルを管理する Playbook を扱います。
プロジェクトを作成し、ディレクトリに移動します。
cd /home/labex/project
mkdir -p rhce-ansible/{inventory/group_vars,playbooks,files}
cd rhce-ansible
インベントリファイルと設定ファイルを作成します。
cat > inventory/hosts <<'EOF'
[managed]
node1 ansible_connection=local
EOF
cat > ansible.cfg <<'EOF'
[defaults]
inventory = ./inventory/hosts
retry_files_enabled = False
interpreter_python = auto_silent
EOF
インベントリには、ローカルホストのエイリアスを持つ managed グループを作成しました。ansible.cfg ファイルでこのインベントリをデフォルトに設定したため、navigator は追加のインベントリフラグなしでプロジェクトディレクトリから Playbook を実行できます。
cat > ansible-navigator.yml <<'EOF'
---
ansible-navigator:
mode: stdout
execution-environment:
enabled: false
playbook-artifact:
enable: false
EOF
navigator の設定により、この実験はターミナルベースで行われます。mode: stdout はタスクの出力を直接表示し、ローカル実行によってコンテナのセットアップを回避します。また、アーティファクトを無効にすることで、プロジェクトディレクトリ内に作成したファイルのみが表示されるようにしています。
Playbook 用のソースコンテンツの作成
このステップでは、Playbook がデプロイするソースコンテンツを作成します。ソースファイルをプロジェクト内に保持することで、Ansible が何を管理しているのかが明確になります。
このステップのコマンドを実行する前に、プロジェクトディレクトリに戻り、相対パスが Ansible プロジェクトを指すようにします。
cd /home/labex/project/rhce-ansible
ソースファイルを作成します。
cat > files/motd.txt <<'EOF'
RHCE Ansible navigator practice host
EOF
これはソースコンテンツです。Ansible がデプロイする対象であり、最終的な管理対象のコピーではありません。ソースファイルと生成された出力を分離しておくことで、Playbook が何を管理しているのかを把握しやすくなります。
インベントリのグループ変数ファイルに、ターゲットディレクトリのパス変数を設定します。このファイルを inventory/group_vars に配置することで、Playbook がサブディレクトリに保存されていても一貫して読み込まれるようになります。
mkdir -p inventory/group_vars
cat > inventory/group_vars/all.yml <<'EOF'
managed_dir: /home/labex/project/rhce-ansible/managed-state
EOF
managed_dir はプロジェクト固有の変数です。これを inventory/group_vars/all.yml で定義することで、Playbook 内で毎回絶対パスを繰り返す代わりに、変数名で参照できるようになります。
管理状態を定義する Playbook の作成
このステップでは、ディレクトリを作成し、その中にファイルをコピーする Playbook を作成します。file モジュールでディレクトリと権限を管理し、copy モジュールでファイルの内容をデプロイします。この Playbook は playbooks ディレクトリに配置されるため、ソースパス ../files/motd.txt はプロジェクトレベルの files ディレクトリを指すことになります。
このステップのコマンドを実行する前に、プロジェクトディレクトリに戻ります。
cd /home/labex/project/rhce-ansible
playbooks/manage-state.yml を作成します。
cat > playbooks/manage-state.yml <<'EOF'
---
- name: Manage local state with navigator
hosts: managed
gather_facts: false
tasks:
- name: Create managed state directory
ansible.builtin.file:
path: "{{ managed_dir }}"
state: directory
mode: '0755'
- name: Deploy managed message
ansible.builtin.copy:
src: ../files/motd.txt
dest: "{{ managed_dir }}/motd.txt"
mode: '0644'
EOF
Playbook の内容を確認してください。最初のタスクで宛先ディレクトリが存在することを確認し、2 番目のタスクでソースファイルをそのディレクトリにコピーします。{{ managed_dir }} は inventory/group_vars/all.yml から読み込まれた値に置き換えられます。
システムを変更する前に、構文チェックを実行します。
ansible-playbook playbooks/manage-state.yml --syntax-check
navigator を使用して Playbook を実行する場合でも、このチェックは有効です。navigator は Playbook を Ansible に渡すため、通常の構文解析で失敗する Playbook は navigator を通じても失敗します。
Navigator を使用した Playbook の実行
このステップでは、Playbook を実行します。要約（recap）行は重要です。ok は目的の状態に達したタスクの数、changed は変更が行われたタスクの数、failed=0 は実行が正常に完了したことを示します。
このステップのコマンドを実行する前に、プロジェクトディレクトリに戻ります。
cd /home/labex/project/rhce-ansible
Playbook を実行します。
ansible-navigator run playbooks/manage-state.yml
管理対象の出力ファイルを直接確認します。
要約によって実行が完了したかどうかは分かりますが、管理対象ファイルが存在することで、要求された状態が実際に構築されたことが証明されます。files/motd.txt に記述した内容と同じテキストが表示されるはずです。
cat managed-state/motd.txt
再実行による冪等性の確認
このステップでは、同じ Playbook を再度実行します。適切に作成された Playbook は、何度実行しても安全であるべきです。ファイルがすでに要求された内容と権限を持っている場合、Ansible は再度変更を行う必要はありません。
このステップのコマンドを実行する前に、プロジェクトディレクトリに戻ります。
cd /home/labex/project/rhce-ansible
Playbook を 2 回目に実行し、出力を保存します。
ansible-navigator run playbooks/manage-state.yml | tee navigator-second-run.txt
要約を確認します。正確なスペースは異なる場合がありますが、要約には失敗がないことが示されているはずです。
2 回目の実行は再現性の確認です。failed=0 でクリーンに実行されることは、Playbook が管理状態を壊すことなく再適用可能であることを証明しています。また、changed=0 が表示されれば、タスクがすでに満たされている（冪等性が保たれている）ことも示されます。
grep -E 'failed=0' navigator-second-run.txt
まとめ
ansible-navigator を使用して Playbook を実行し、作成された管理対象ファイルを調査し、Playbook を再実行してクリーンに動作することを確認しました。これは、Ansible 自動化作業全体を通じて使用される「実行・調査・検証」の基本的なループです。
