Ansibleの「実行コンテキスト」を極める：local_actionとdelegate_toの深淵
Ansibleをただの「SSH経由のコマンド実行ツール」だと思っているなら、それはまだ入り口に過ぎない。大規模なインフラを自動化する際、最も障壁となるのは「どこで」「どのコンテキストで」処理を実行するかという制御だ。
今日は、Ansibleのタスク実行を自在に操るための二大巨頭、`local_action`と`delegate_to`の本質的な違いと、現場でプロが使う「コンテキスト制御の極意」を伝授する。
—
1. local_action vs delegate_to：本質的な違い
この二つは「タスクをターゲットホスト以外で実行する」という目的は同じだが、適用されるコンテキスト（変数や接続情報）に決定的な違いがある。
local_action: 「管理ノード」という閉じた世界
`local_action`（または `connection: local`）は、タスクをAnsibleを実行しているマシン（管理ノード）で動かすためのものだ。
- 用途: API操作（AWS/GCP/Azureのリソース作成）、ローカルファイルの生成、デプロイ前のバリデーション。
- 特徴: ターゲットホストのインベントリ情報は無視される。ローカルのShell環境やPythonライブラリに依存する。
delegate_to: 「指定したホスト」への権限委譲
`delegate_to`は、タスクの実行対象を特定のホストに一時的に変更する。
- 用途: ロードバランサーからの切り離し（LBサーバーへ指示）、DBのバックアップ取得（DBサーバーへ指示）、監視サーバーへのステータス通知。
- 特徴: 指定したホストの接続情報（ansible_user, ansible_ssh_private_key_file等）と、そのホスト特有の変数が引き継がれる。
—
2. 現場で使える「コンテキスト制御」の極意
実践：LBからの切り離しと復帰（Rolling Updateの裏側）
多くのエンジニアが陥る罠は、`delegate_to`使用時にホストのファクト情報がズレることだ。
- name: ロードバランサーからサーバーを切り離す
command: /usr/local/bin/lb_remove.sh {{ inventory_hostname }}
delegate_to: “{{ groups[‘lb_servers’][0] }}”
# ここが重要：delegate_to先でも、元のホストの情報を扱いたい場合は
# delegate_facts: true を付与する
delegate_facts: true
プロの教訓: `delegate_facts: true`を忘れると、委譲先で実行されたタスクの結果が、元のターゲットホストの変数として保存されず、冪等性が崩壊する。マルチノードデプロイでは必須のオプションだ。
—
3. 生産性を極限まで高めるベストプラクティス
チーム開発の生産性を底上げする「神設定」
`ansible.cfg`は、プロジェクトごとに最適化しろ。特に以下の設定は、大規模環境でのレスポンスを劇的に変える。
[defaults]
実行結果の可読性を上げるための必須設定
stdout_callback = yaml
冪等性を確保しつつ、並列数を最適化する（環境に合わせて調整）
forks = 20
キャッシュを有効化して、インベントリ取得時間を短縮
gathering = smart
fact_caching = jsonfile
fact_caching_connection = ./.ansible/facts
fact_caching_timeout = 86400
必須のVS Codeプラグイン
- Ansible (Red Hat公式): 言語サーバーによる補完と構文チェック。これがないと始まらない。
- YAML (Red Hat公式): 構造的バリデーションの要。
- Error Lens: エラーをファイル行末にインライン表示し、デバッグ時間を数秒単位で短縮する。
隠れたキーボードショートカット（VS Code）
- `Ctrl + Shift + P` -> `Ansible: Run Ansible Lint`: 修正前に必ず実行せよ。
- `Alt + Up/Down`: タスクの順序を瞬時に入れ替える。冪等性の検証時に不可欠だ。
—
4. 冪等性を担保する「神構成」のテンプレート
単なるYAMLの羅列ではなく、「クリーンで再利用可能な構造」を意識せよ。
roles/deploy/tasks/main.yml
- name: デプロイ準備（ローカルで作業）
local_action:
module: template
src: config.j2
dest: ./build/config.json
become: false # ローカル実行時は権限を絞る
- name: サーバーへ転送
copy:
src: ./build/config.json
dest: /etc/app/config.json
notify: restart_service
処理完了を監視サーバーへ通知（委譲）
- name: 通知を送る
uri:
url: “http://monitor.local/api/deploy”
method: POST
body: {“status”: “success”, “host”: “{{ inventory_hostname }}”}
body_format: json
delegate_to: localhost # 明示的にローカルから叩く
run_once: true # 全台で実行せず、一度だけ実行
—
最後に：なぜ「コンテキスト」を理解すべきか
Ansibleの真価は、インフラを「個別のサーバー」としてではなく、「全体としてのシステム」として制御できる点にある。`delegate_to`と`local_action`を使い分ける力は、まさにその境界線を自在にコントロールする力だ。
ツールに使われるのではなく、ツールを操り、インフラという巨大なシステムに「意図」を書き込む。それこそが、SREとして目指すべき高みである。
コードは嘘をつかない。だが、コンテキストを見失ったコードは必ず裏切る。常に「今、誰が、どこで、何をしているのか」を意識して、コードを叩け。