エンジニアの皆さん、こんにちは。インフラの自動化を極めようとすると、必ず「なぜこの処理は、このサーバーではなく別の場所で動いてほしいのか？」という壁にぶつかります。
Ansibleは非常に強力ですが、その本質は「どの場所で、どのコンテキストを持って実行するか」の制御にあります。今日は、Ansible中級者への登竜門であり、IaCの設計思想を根本から変える`local_action`と`delegate_to`の使い分けについて、現場の「生きた知見」を共有します。
—
1. なぜ「実行場所」の制御が重要なのか？
通常、Ansibleのタスクは`hosts`で指定したターゲットノードで実行されます。しかし、以下のようなケースではどうでしょうか？
- 外部APIを叩く: ターゲットノードにcurlを入れたくない、あるいはファイアウォールで外部通信が制限されている。
- 負荷分散の切り離し: ロードバランサー（LB）の設定を、LB自身ではなく管理ノードから操作したい。
- デプロイのトリガー: 全サーバーの更新が終わった後に、監視ツール（Datadogなど）へ通知を送る。
これらを解決するのが「コンテキスト制御」です。
—
2. local_action：管理ノードの力を借りる
`local_action`は、タスクをAnsibleを実行しているマシン（管理ノード/コントロールノード）で強制的に実行させる魔法です。
基本の書き方
- name: ローカルでAPIを叩いてステータスを確認する
local_action:
module: uri
url: “https://api.monitoring.com/v1/status”
method: GET
# 実行場所は常に「管理ノード」
極意: `local_action`は「ターゲットノードに依存しない処理」に使うのが鉄則です。例えば、デプロイ完了をSlackへ通知したり、クラウドのDBインスタンス（RDSなど）の設定を変更したりする際、ターゲットノードが何であるかは関係ありませんよね。そういう時に使います。
—
3. delegate_to：特定の「第三者」に仕事を投げる
`delegate_to`は、ターゲットノードではなく「指定した別ホスト」に処理を委譲します。これができると、インフラのオーケストレーションが劇的に進化します。
基本の書き方
- name: ロードバランサーからサーバーを切り離す
command: /usr/bin/lb_tool –remove {{ inventory_hostname }}
delegate_to: lb-server-01 # このタスクだけは「lb-server-01」で実行する
極意: これを使うと、複数のサーバーが連動する高度な処理が可能になります。
- Blue/Greenデプロイ: サーバーをローリングアップデートする際、LBに「今からこいつをメンテナンスにするぞ」と教えるために使います。
- DBマイグレーション: アプリサーバーを停止する前に、踏み台サーバーからDBのバックアップを取る、といった前後処理の制御に必須です。
—
4. 比較で理解する：どちらを使うべきか？
| 特徴 | local_action | delegate_to |
| :— | :— | :— |
| 実行先 | 常に管理ノード（自分自身） | 指定したインベントリ内のホスト |
| 主な用途 | 通知、クラウドAPI操作、ファイル集計 | LB制御、DB操作、他サーバー連携 |
| 汎用性 | 限定的（管理ノード固定） | 高い（どのホストも指定可能） |
現場の判断基準: 「自分自身のPCや管理サーバーで完結するか（local_action）」か、「特定の役割を持つ別のサーバーに指示を飛ばす必要があるか（delegate_to）」で決めてください。
—
5. 実践：HelloWorld的な動作確認
それでは、管理ノードの時刻を記録しつつ、ターゲットノードが生きているかを確認するプレイブックで、この感覚を掴んでみましょう。
—
- name: コンテキスト制御の練習
hosts: webservers
tasks:
# 管理ノードでログを残す
- name: 処理開始時間を管理ノードに記録
local_action:
module: shell
cmd: date >> /tmp/deploy.log
# ターゲットノードの動作確認（これは通常実行）
- name: ターゲットノードの疎通確認
ping:
# 監視サーバーに通知を飛ばす（delegate_toの例）
- name: 監視サーバーへ通知
uri:
url: “http://monitoring-server/api/notify”
method: POST
delegate_to: monitoring-server
# このタスクだけは、webserversではなくmonitoring-serverが実行する
—
最後に：自動化の深淵へ
`local_action`と`delegate_to`を使いこなせると、Ansibleは単なる「設定管理ツール」から、「インフラ全体の指揮官」に姿を変えます。
初心者のうちは、「とりあえずターゲットノードで全部実行しよう」としがちです。しかし、それでは複雑な構成を制御できません。「どの作業をどこで行うのが最も安全で効率的か？」を常に考えること。その設計思想こそが、あなたが一流のSREになるための最短ルートです。
毎日の作業が劇的に楽になる感覚、ぜひ体感してください。応援しています！