Ansible（構成管理ツール）

Red Hatが開発するPython製の構成管理ツール。最大の特徴はagentless(エージェントレス)な設計で、管理対象ノードに常駐エージェントを一切インストールせず、SSH(Linux/Unix)やWinRM(Windows)経由で設定を「push」する。

実行モデル

agentlessといっても、対象ノードで何も動かないわけではない。実際には次の流れで動く。

  1. コントロールノード側でPlaybookを解釈し、実行すべきタスクを決める。
  2. SSHで対象ノードに接続し、そのタスクに対応するモジュール(Pythonスクリプト)を一時ディレクトリへ転送する。
  3. 対象ノードのPythonインタプリタでモジュールを実行し、結果をJSONで受け取る。
  4. 転送した一時ファイルを削除して接続を閉じる。

つまり「常駐エージェントは不要だが、対象ノードにPythonは必要」という構成になっている。ansible-core 2.21の場合、コントロールノード側はPython 3.12〜3.14、管理対象ノード側はPython 3.9〜3.14をサポートする(WindowsはPowerShell 5.1〜7)。

冪等性はAnsible本体が保証するのではなく、個々のモジュールが「現在の状態を調べ、必要なときだけ変更する」ように実装されていることで成り立つ。実行結果がokかchangedかはモジュールが自己申告している。逆に言うと、command/shellのような素のコマンド実行モジュールは何もしなければ常にchangedになるため、creates/removesやchanged_whenで書き手が冪等性を与えてやる必要がある。

構成要素

  • Inventory — 管理対象ホストの一覧。INI形式かYAMLで静的に書くほか、クラウドAPIを叩いて動的にホストを列挙するdynamic inventoryプラグインもある。ホストは任意のグループに束ねられ、グループ単位で変数を与えられる。
  • Playbook — YAMLで書く、ホスト(のグループ)に対するtasksの並び。各taskは1つのモジュール呼び出しに対応する。宣言的というより「あるべき状態を作る手続き」の記述に近い。
  • Role — Playbookの断片(tasks/, handlers/, templates/, defaults/, vars/など)を決まったディレクトリ構造にまとめ、再利用可能にしたもの。
  • Collection — Role・モジュール・プラグイン・Playbookをまとめて配布する単位。Ansible Galaxyやansible-galaxyコマンドで配布・導入する。
  • Facts — 実行開始時にsetupモジュールが対象ノードから収集するOS・ネットワーク・ハードウェア情報。ansible_factsとして変数から参照できる。収集にコストがかかるためgather_facts: falseで無効化することもある。
  • Handler — taskがchangedになったときだけ末尾でまとめて走る処理。設定ファイル更新時のサービス再起動などに使う。

Playbookの中の変数展開・条件分岐にはJinja2テンプレートを使う。JSON構造の絞り込みにはjson_queryフィルタ経由でJMESPathも使える。

ansible-core と community package

配布物が2つに分かれている点は最初に混乱しやすいところ。

  • ansible-core — 実行エンジン本体とコマンド群(ansible, ansible-playbook, ansible-galaxyなど)、およびansible.builtinコレクションのみを含む最小構成。バージョンは2.x系で、年2回程度のペースでminorが上がる。2026年8月時点の最新は2.21(2026年5月リリース)で、2.19/2.20/2.21の3世代が保守対象。
  • ansible (community package) — ansible-coreに、キュレーションされた多数のコレクションを同梱した「全部入り」パッケージ。かつてのAnsible 2.9以前の姿を引き継いだもの。バージョンは12, 13のような単独の整数で、ansible-coreのminorリリースに追随して上がる(例: Ansible 12.0.0はansible-core 2.19.1に依存)。

コレクション側は「新しいansible-coreでテストが通ること」が同梱の条件で、追随できないコレクションはcommunity packageから外される。

ansible-core 2.19 のテンプレート刷新

2.19ではテンプレート処理系が大きく作り直され、Data Taggingという仕組みが入った。変数の値に「どこから来たか」の来歴(provenance)タグを付けて回ることで、エラーメッセージにファイルパス・行・列を出せるようになり、非推奨要素にタグを付けて警告を出すこともできるようになった。

同時に「テンプレートとして評価してよい文字列」の扱いが厳格化され、Playbookやvarsファイル由来の文字列は信頼済みとして扱う一方、プラグインがテンプレートを埋め込んだ文字列を新たに作る場合はansible.templateのtrust_as_templateを通す必要が生じた。従来は見逃されていた曖昧なJinja/JMESPathの書き方が顕在化するため、移行時はporting guideを参照するのが前提になる。

周辺ツール

  • ansible-lint — Playbook/Roleの書き方をチェックするlinter。
  • Molecule — Roleやコレクションのテストフレームワーク。シナリオごとにコンテナ等の環境を作り、収束(converge)させ、もう一度流してchangedが出ないことで冪等性を検証し、最後に状態を検証する。
  • ansible-navigator / Execution Environment — 実行に必要なansible-core・コレクション・Python依存をコンテナイメージ(EE)に固め、その中でPlaybookを流す方式。手元と本番で実行環境を揃えられる。
  • AWX — Web UI・REST API・ジョブ実行エンジンをAnsibleの上に載せたOSSプロジェクト(Red Hatがスポンサー)。商用版がAnsible Automation Platform (AAP)。
  • Semaphore UI — AWXより軽量な、Goの単一バイナリで動くWeb UI。Terraform/OpenTofuやシェルスクリプトも同列に扱う。
  • LC4RI — ツールではなく方法論。Jupyter NotebookからAnsibleを実行し、Notebookを実行可能な手順書兼作業証跡にする(NIIクラウド運用チーム)。

dry-runと安全側の実行

--syntax-check(構文検証のみ)と--check --diff(dry-run + 変更差分表示)という2段階のフラグがあり、実行前の確認を段階化するCLI設計の実例としても参照できる。ただし--checkが意味を持つのはモジュールがcheck modeに対応している場合で、素のcommand/shellはスキップされる。

構成管理ツールの中での位置づけ

Chef・Puppetがagent常駐・pull型なのに対し、Ansibleはagentless・push型という対照的な設計を取る。DSLもRuby系の内部DSLではなくYAML + Jinja2ベース。同じくagentlessなItamaeのitamae sshと比べると、Ansibleはモジュールを転送して対象ノード側のPythonで実行するのに対し、Itamaeは1操作ごとにSSH越しのコマンド実行を積み重ねる点が異なる。

#infrastructure-as-code #python

出典

🔗 リンクされているノート

作成日時: 2026-08-19 15:26 / 更新日時: 2026-09-26 05:57