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 鍵による認証を整えておけば、毎回パスワードを打たずに全台へ一斉に処理を届けられます。
ad-hoc コマンド — その場の単発操作
Ansible の使い方は大きく2つに分かれます。1つ目は ad-hoc（アドホック）コマンドで、その場限りの単発操作を1行で実行する方法です。ansible コマンドを使い、たとえば ansible all -m ping とすると、インベントリに登録した全ホストへ疎通確認（ping モジュール）を一斉に投げ、各ホストがちゃんと応答するかを確かめられます。ansible web -m command -a "uptime" のようにすれば、web グループの全台で uptime を実行してそれぞれの稼働時間をまとめて集めてくる、といったことが1行ででき、auto-ansible の手始めとして分かりやすい使い方です。-m はモジュール（実行する機能）の指定、-a はそのモジュールへ渡す引数を表します。パッケージを一斉に入れたいなら ansible web -m dnf -a "name=httpd state=present" のように書くこともできます。「いま全台の状態をさっと確認したい」「全台で1つコマンドを叩きたい」ときに向く、手軽な入り口です。
playbook — 手順をまとめて再利用する
2つ目が、本格的な自動化の中心となる playbook（プレイブック）です。これは実行したい手順を YAML 形式のファイルに記述し、ansible-playbook コマンドで実行します。auto-playbook には、どのホスト群を対象に（hosts）、どんな作業を順に行うか（tasks）を、人が読める形で並べて書きます。たとえば「web グループに対して、httpd パッケージを入れ、設定ファイルを配り、サービスを起動して有効化する」といった一連の構築手順を1つのファイルにまとめておけば、ansible-playbook site.yml の一発で対象の全台に同じ構成を再現できます。手順がファイルとして残るので、構成の意図がそのまま文書になり、誰が実行しても同じ結果になり、git などのバージョン管理にも乗せられます。これがいわゆる Infrastructure as Code（コードとしてのインフラ）の考え方で、ad-hoc が「その場の一手」なら、playbook は「再現可能な手順書であり、同時に実行ファイルでもあるもの」にあたります。設定値をまとめた変数や、繰り返し使う部品をまとめたロール（role）といったしくみで、規模が大きくなっても整理して書き続けられます。
冪等性 — 何度流しても安全
Ansible を理解するうえで欠かせないのが、冪等性（idempotency）です。Ansible の各モジュール（タスク）は auto-idempotent に設計されており、「どう操作するか」ではなく「どうあってほしいか（望ましい状態）」を宣言する形で書きます。たとえば「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台から複数台へと自然に広がっていくはずです。