Ansible playbookを書く
Ansible の ad-hoc コマンドは単発の作業には便利ですが、手順が増えると1行では収まりません。そこで登場するのが playbook です。playbook は「どのサーバーに・何を・どういう順で行うか」を YAML というテキスト形式でまとめた手順書です。この回では playbook の基本構造（hosts・tasks・module）、相手を並べるインベントリ、そして何度流しても同じ結果になる冪等性という考え方を学びます。小さく書いて少しずつ育てるのがコツです。
Ansible の ad-hoc コマンドは、1つの作業をその場でサッと流すのに向いている。だが実際の構築は「パッケージを入れて、設定ファイルを置いて、サービスを起動する」のように手順が連なる。これを毎回1行ずつ手で打つのは、つらいし間違える。
そこで手順そのものをテキストファイルに書き出して、まとめて実行できるようにする。この手順書が playbook（プレイブック）だ。一度書けば、同じ手順を何台のサーバーにも、何度でも、同じ順序で流せる。
📖 playbook の中身は YAML
playbook は YAML（ヤムル）という形式で書く。YAML はインデント（行頭の空白）で親子関係を表すテキスト形式で、人が読みやすいのが特徴だ。だからこそ空白の数がずれると意味が変わるので、そこだけは神経を使う。
中身は大きく3階層でできている。どの相手に流すかを表す hosts、やることの列である tasks、そして各 task が呼び出す部品である module（モジュール）だ。
module は「パッケージを入れる」「ファイルをコピーする」「サービスを操る」といった具体的な仕事を1つずつ受け持つ既製部品で、Ansible に最初から山ほど付いてくる。自分でシェルを書く代わりに、この部品を組み合わせて手順を作る。
つまり playbook を読むと、上から順に「この相手に、この仕事を、この部品で」と書いてあることになる。英語の手順書のように、素直に上から下へ読めるのがねらいだ。
name は各 task に付ける説明ラベルで、実行時にそのまま画面に表示される。become: true は「管理者権限（sudo）で行う」という意味だ。パッケージ導入のような特権が要る作業では、この一行が効いてくる。
📇 相手を並べるインベントリ
playbook の hosts に webservers と書いたが、では webservers とは具体的にどのマシンなのか。それを決めるのが インベントリ（inventory）だ。インベントリは操作対象のホスト（サーバー）を並べたリストで、名前でグループにまとめられる。
角かっこの中がグループ名で、その下にそのグループに属するホストを並べる。playbook 側で hosts: webservers と書けば、上の2台にだけ手順が流れる。相手を増やしたければ、この行を足すだけでいい。
🔁 何度流しても同じになる冪等性
Ansible を語るうえで欠かせない考え方が 冪等性（べきとうせい・idempotency）だ。難しそうな言葉だが、意味は「同じ操作を何度繰り返しても、結果が1回だけ行ったのと同じ状態になる」こと、それだけだ。
ふつうのシェルスクリプトは命令の羅列なので、2回流せば2回動く。mkdir を2回書けば、2回目は「もうある」と怒られる。これに対して Ansible の module は「あるべき状態」を宣言する形になっている。
だから先ほどの playbook を2回流しても、1回目は nginx を入れて「changed（変えた）」、2回目はもう入っているので「ok（変更なし）」になる。壊れないから、不安なときは気軽にもう一度流せる。これが自動化を安心して回せる土台になる。
▶️ 流す前に確かめる
書けたら、いよいよ実行だ。ansible-playbook コマンドに、インベントリ（-i）と playbook のファイル名を渡す。
最後の PLAY RECAP が成績表だ。changed は実際に変えた数、ok は既に望む状態で何もしなかった数、failed は失敗の数を表す。failed が0なら、その回は無事に通ったということになる。
本番でいきなり流すのが怖いときは、--check を付ける。これは dry-run（ドライラン＝リハーサル）モードで、実際には変更せず「もし流したら何が changed になるか」だけを見せてくれる。
🧭 ここまでの地図
playbook は手順書、インベントリは相手のリスト、module は仕事の部品、冪等性はその全体を支える性質、と役割で覚えると混乱しない。
この4つが手に入れば、手作業だった構築を「読めて・履歴に残せて・何度でも再現できる」ものに変えられる。次はこの playbook を、通知やログ管理といった日々の運用と組み合わせていくことになる。