Ansible の概要（ad-hoc と playbook）
複数台のサーバへ同じ設定を一斉に適用したいときは Ansible が便利です。Ansible は管理対象にエージェントを常駐させず、SSH 経由で処理を流すしくみで、1回限りの単発操作は ad-hoc コマンド（ansible）、手順をまとめて再利用する場合は YAML で書いた playbook（ansible-playbook）を使います。各処理は冪等に設計されており、既に望む状態なら何もしないため、同じ playbook を何度流しても安全です。
ここまでは主に1台のマシンの中で処理を自動化する話だった。だが、運用するサーバが2台、10台、100台と増えてきたら、どうなるだろう。
「全台に同じ設定を入れたい」「全台のパッケージをそろえて更新したい」「新しいサーバを既存と同じ構成で立ち上げたい」。こうした作業を、サーバの台数だけ手作業で繰り返すのは現実的ではない。
手作業だと、手順の抜けや台ごとのばらつき（構成のずれ、いわゆる構成ドリフト）も生まれる。
この複数台の構成管理・一斉操作を自動化するための代表的な道具が Ansible（アンシブル）だ。
設定やインストールといった作業を、人間がSSHで1台ずつログインして手で行う代わりに、Ansible に手順を記述して一括で流す。このスタイルに置き換える。
手作業をコードに置き換えることで、規模が増えても運用の手間が比例して増えないようにするのが狙いだ。
🪶 管理される側に、なぜ何も入れなくていいのか
Ansible の大きな特徴は、エージェントレスである点だ。多くの構成管理ツールは、管理される側のサーバに専用の常駐プログラム（エージェント）を入れる必要がある。Ansible はそれを必要としない。
では何を頼りに動くのか。管理用のマシン（コントロールノード）から、操作対象（管理対象ノード）へ SSH で接続し、その場で処理を実行して結果を受け取る、というしくみで動く。
対象側に追加で必要なのは、SSH で入れることと Python が使えることくらいだ。エージェントの導入・更新・維持といった手間がない分、導入の敷居が低く、管理対象を増やしやすいのが利点になる。
どのサーバを管理するかは「インベントリ」と呼ばれる一覧ファイルに書いておく。ホスト名やIPアドレスを web や db といったグループに分けて記述する。
Ansible はこのインベントリを見て、どの対象群へ処理を流すかを決める。SSH 鍵による認証を整えておけば、毎回パスワードを打たずに全台へ一斉に処理を届けられる。
⚡ まず1行で、全台を触ってみるには
Ansible の使い方は大きく2つに分かれる。
1つ目は ad-hoc（アドホック）コマンドで、その場限りの単発操作を1行で実行する方法だ。ansible コマンドを使う。
たとえば ansible all -m ping とすると、インベントリに登録した全ホストへ疎通確認（ping モジュール）を一斉に投げ、各ホストがちゃんと応答するかを確かめられる。
ansible web -m command -a \"uptime\" のようにすれば、web グループの全台で uptime を実行してそれぞれの稼働時間をまとめて集めてくる。こうしたことが1行ででき、Ansible の手始めとして分かりやすい使い方だ。
-m はモジュール（実行する機能）の指定、-a はそのモジュールへ渡す引数を表す。パッケージを一斉に入れたいなら ansible web -m dnf -a \"name=httpd state=present\" のように書くこともできる。
「いま全台の状態をさっと確認したい」「全台で1つコマンドを叩きたい」ときに向く、手軽な入り口だ。
📖 その場の一手を、再現可能な手順書にするには
2つ目が、本格的な自動化の中心となる playbook（プレイブック）だ。これは実行したい手順を YAML 形式のファイルに記述し、ansible-playbook コマンドで実行する。
playbook には、どのホスト群を対象に（hosts）、どんな作業を順に行うか（tasks）を、人が読める形で並べて書く。
たとえば「web グループに対して、httpd パッケージを入れ、設定ファイルを配り、サービスを起動して有効化する」といった一連の構築手順を1つのファイルにまとめておく。すると ansible-playbook site.yml の一発で対象の全台に同じ構成を再現できる。
手順がファイルとして残るので、いいことが多い。構成の意図がそのまま文書になる。誰が実行しても同じ結果になる。git などのバージョン管理にも乗せられる。
これがいわゆる Infrastructure as Code（コードとしてのインフラ）の考え方だ。ad-hoc が「その場の一手」なら、playbook は「再現可能な手順書であり、同時に実行ファイルでもあるもの」にあたる。
設定値をまとめた変数や、繰り返し使う部品をまとめたロール（role）といったしくみで、規模が大きくなっても整理して書き続けられる。
🔄 何度流しても安全、とはどういうことか
Ansible を理解するうえで欠かせないのが、冪等性（idempotency）だ。
Ansible の各モジュール（タスク）は冪等に設計されている。「どう操作するか」ではなく「どうあってほしいか（望ましい状態）」を宣言する形で書く。
たとえば「httpd がインストールされていること」「この設定ファイルがこの内容であること」「サービスが起動していること」を記述する。すると Ansible は実行時に各ホストの現在の状態を調べ、すでにその状態になっていれば何もせず、なっていなければ足りない分だけを変更する。
そのため、同じ playbook を何度流しても無駄な変更や害が起きず、安心して繰り返せる。
これは cron 用のスクリプトを冪等に作るのと同じ発想を、複数台のサーバ構成に広げたものだと捉えると腑に落ちる。
実行結果には、各タスクが ok（既に望む状態で変更なし）・changed（変更を加えた）・failed（失敗）のいずれだったかが集計表示される。「2回目以降は changed が0になる」ことが、冪等に書けているかどうかの実用的な目安になる。
🧱 時間で回す道具と、台数を捌く道具
整理しよう。cron や systemd timer は「1台の中で、時間をきっかけに処理を回す」道具だ。これに対し、Ansible は「多数のマシンへ同じ構成を行き渡らせ、再現可能な手順として管理する」道具だ。
両者は競合するものではない。たとえば Ansible を使って全台に同じ cron 設定や systemd timer を配って回る、といった形で組み合わせて使われる。
最初の一歩としては、まずインベントリを1つ書き、ansible all -m ping で全台に届くことを確かめ、次に簡単な playbook を1本書いて ansible-playbook で流してみる。
この流れをたどると、エージェントレス・ad-hoc と playbook・冪等性という Ansible の核がひととおり腑に落ちる。
台数が増えても手作業を増やさずに済む、というスケールのさせ方を体感できれば、自動化の視野が1台から複数台へと自然に広がっていくはずだ。