はじめに
信頼できるファイル自動化では、コントローラーのソース、管理対象のコピー、調査のために回収した成果物を区別します。ファイル名が正しいだけでは、内容の完全性、権限、ホストの識別は確認できません。
バナーを配置し、stat と register で実際の SHA-256 メタデータを調べ、ホスト別の運用レポートを生成して、コントローラーの別々のパスに fetch で回収します。準備済みの 2 ホストの SSH 環境と権限モデルは、以前に練習したものと同じです。
管理対象の権限を明示してファイルを配布する
このステップでは、コントローラーの非公開ソースを保護された管理対象ディレクトリにコピーし、リモートの所有者と権限を明示的に選択します。
ターミナルを開き、プロジェクトに移動します。
cd /home/labex/project
末尾の改行を含めて、再利用可能なコントローラーのソースを作成します。
printf 'Managed service banner\n' > site-banner.txt
chmod はローカルファイルの権限を変更します。モード 0600 は所有者に読み書きを許可し、グループとその他にはアクセスを許可しません。コントローラーのソースは非公開に保ちながら、管理対象には意図的に異なる権限を選びます。
chmod 0600 site-banner.txt
配布用の Playbook を記述します。
cat > deploy-banner.yml <<'EOF'
- name: Distribute the managed banner
hosts: all
gather_facts: false
become: true
tasks:
- name: Prepare the managed site directory
ansible.builtin.file:
path: /srv/ansible-site
state: directory
owner: root
group: automation
mode: "0750"
- name: Copy the controller banner with explicit managed permissions
ansible.builtin.copy:
src: /home/labex/project/site-banner.txt
dest: /srv/ansible-site/banner.txt
owner: root
group: automation
mode: "0640"
EOF
Play レベルの become は、管理対象ノードでの権限昇格を要求します。/srv 以下への書き込みと root 所有権の割り当てには、それが必要です。コントローラーでソースを読み込むプロセスを、root ログインに変えるわけではありません。
ディレクトリの所有者は root、グループは automation、モードは 0750 です。バナーの所有者は root、グループは automation、モードは 0640 です。これにより、一般アカウント automation は書き込み権限を与えられずに、ディレクトリを通過してバナーを読めます。明示した管理対象のモードは、コントローラーのソースの 0600 モードとは独立しています。
Playbook をチェックし、適用します。
ansible-playbook deploy-banner.yml --syntax-check
ansible-playbook deploy-banner.yml
両ホストが失敗なしで完了するはずです。become なしで、通常の読み取りアクセスをテストします。
ansible all -m ansible.builtin.command -a 'cat /srv/ansible-site/banner.txt'
各ホストに Managed service banner と表示されるはずです。ソースと管理対象コピーを別ファイルとして維持しながら、意図したリモートのグループ読み取りアクセスを実証できます。
構造化されたファイルメタデータを登録して利用する
このステップでは、実際の管理対象バナーを調べ、そのメタデータからホスト別の運用レポートを記述します。
stat モジュールは、ファイルをコピーせず、ファイル情報を返します。checksum_algorithm: sha256 は、内容検証に SHA-256 を選択します。register は、そのタスクの結果を同じホスト上の後続タスク用に保存します。stat フィールドにファイルのメタデータが含まれます。
調査用 Playbook を作成します。
cat > inspect-and-collect.yml <<'EOF'
- name: Inspect the banner and prepare host reports
hosts: all
gather_facts: true
tasks:
- name: Inspect managed content and permissions
ansible.builtin.stat:
path: /srv/ansible-site/banner.txt
checksum_algorithm: sha256
register: banner_info
- name: Display the structured file metadata
ansible.builtin.debug:
var: banner_info.stat
- name: Write the per-host report from real metadata
become: true
ansible.builtin.copy:
dest: /srv/ansible-site/node-report.txt
content: |
host={{ inventory_hostname }}
distribution={{ ansible_facts.distribution }}
banner_sha256={{ banner_info.stat.checksum }}
owner: root
group: automation
mode: "0640"
EOF
debug モジュールは var で既存の変数を表示するため、banner_info.stat から exists、mode、所有者とグループ名、size、checksum などの項目がわかります。メタデータを表示しても、ファイルが作成されたり、その後の操作が成功した証明になったりはしません。
copy タスクは、inventory_hostname とディストリビューションのファクトに加え、banner_info.stat.checksum を利用します。そのタスクレベルの become は、root 所有のレポートを書くために必要です。調査タスク自体は、通常の読み取りアクセスを使用します。
調査とレポート生成を実行します。
ansible-playbook inspect-and-collect.yml
メタデータは、モード 0640、所有者 root、グループ automation の通常ファイルを示すはずです。各レポートには自身のホスト名と、実際のリモートバナーから得られた SHA-256 値が含まれます。
sha256sum はローカルファイルの SHA-256 ダイジェストを計算し、ダイジェストとそれに続く名前を表示します。コントローラーのソースのダイジェストを、メタデータとレポートの値と比較してください。
sha256sum site-banner.txt
両方のリモートレポートを読みます。
ansible all -m ansible.builtin.command -a 'cat /srv/ansible-site/node-report.txt'
各結果には host=web1 または host=web2、distribution=Ubuntu、banner_sha256 とそれに続く一致した 64 文字のダイジェストが含まれるはずです。固定の debug メッセージで置き換えず、観察結果を各実ホストに結び付けてください。
別々のレポートをコントローラーに回収する
このステップでは、一方のホストの結果を他方で上書きせずに、両方の管理対象レポートを収集します。
copy は通常、コントローラーのソースを管理対象のコピー先に送ります。fetch は逆方向に動作します。src は管理対象ノード上、dest はコントローラーのディレクトリです。flat が false の場合、fetch は dest 以下にインベントリのホスト名とリモートパスを含めます。
既存の調査用 Playbook に、次のタスクを追記します。他のタスク項目とインデントをそろえてください。>> は、それまでの stat、register、レポートのタスクを置き換えずに追記します。
cat >> inspect-and-collect.yml <<'EOF'
- name: Collect each managed report without flattening host paths
ansible.builtin.fetch:
src: /srv/ansible-site/node-report.txt
dest: /home/labex/project/reports/
flat: false
EOF
調査と収集の完全な手順を実行します。
ansible-playbook inspect-and-collect.yml
最初の fetch は、コントローラーに 2 つのコピーを作成するはずです。レポートのグループ権限ですでに読み取りが許可されているため、各対象では一般アカウント automation として実行されます。
収集した各成果物をローカルで調べます。
cat reports/web1/srv/ansible-site/node-report.txt
cat reports/web2/srv/ansible-site/node-report.txt
これらのパスは、独立したホストの識別を維持します。各レポートの host フィールドはそのパスと一致し、両方の checksum フィールドは配置したソースと一致するはずです。両結果を 1 つの共有ファイル名に平坦化すると、片方のホストの成果物が失われます。
完全な手順を繰り返します。
ansible-playbook inspect-and-collect.yml
ソース、ファクト、ファイル状態が変わらなければ、両ホストが changed=0、失敗と到達不能の結果なしを報告するはずです。実際の管理対象メタデータに裏付けられた、別々に収集したレポートが得られました。
まとめ
コントローラーと管理対象のファイル状態を区別し、リモートの所有者と権限を宣言して、単なる成功メッセージの表示ではなく、登録した stat メタデータを利用しました。ホスト別のレポートは実際の SHA-256 による完全性情報を記録し、fetch は、安定した繰り返し実行とともに、両ホストの成果物をコントローラーの別々のパスに保持しました。
