【Ansible応用講座 最終回】新時代の実行環境。Ansible Builder/RunnerによるExecution Environment (EE) 完全ガイド

「私のPCでは動いたんですけど…」は、もう通用しない。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
全16回（入門8回＋応用8回）にわたるAnsible講座、ついにグランドフィナーレです。

これまでの講座で、あなたのAnsibleスキルは飛躍的に向上しました。
しかし、チームで開発を進めると、最後の最後に立ちふさがる壁があります。
それは「実行環境の差異（依存関係地獄）」です。

本記事では、Ansibleの最新アーキテクチャである Execution Environment (EE) の概念と、自分専用の実行環境を作る Ansible Builder、そしてそれを実行する Ansible Runner (Navigator) の使い方を徹底解説します。

---

第1章：なぜ今、コンテナ化なのか？ (What is EE?)

これまで私たちは、yum install ansible や pip install ansible で、OS上に直接Ansibleをインストールしてきました。
しかし、この方法には限界があります。

従来の問題点（Dependency Hell）

• Pythonライブラリの競合: 「AWSモジュールを使いたいから boto3 を入れたら、Azureモジュールの依存関係が壊れた」。
• OS依存: 「開発者のMacでは動くけど、CIサーバーのRed Hat Enterprise Linuxでは libxml が古くて動かない」。
• Ansibleバージョンの違い: 「AさんはAnsible 2.9、BさんはCore 2.14を使っているため、挙動が違う」。

解決策：Execution Environment (EE)

Execution Environment (EE) とは、「Ansibleを実行するために必要なすべてを詰め込んだコンテナイメージ」のことです。

• Ansible Core 本体
• Python (3.9など)
• 必要なPythonライブラリ (boto3, pywinrmなど)
• 必要なAnsible Collection (amazon.aws, cisco.iosなど)
• 必要なシステムパッケージ (git, opensshなど)

これらを1つのDockerイメージに固めてしまいます。
実行時は、このイメージを使ってコンテナを立ち上げ、その中でPlaybookを実行します。
これにより、どこで動かしても100%同じ環境が保証されます。

---

第2章：環境定義ツール「Ansible Builder」

EEを作るためには、Dockerfileを手書きする必要はありません。
Ansible Builder というツールを使えば、設定ファイルから自動的に最適なDockerfileを生成し、イメージをビルドしてくれます。

1. Ansible Builderのインストール

作業用の端末（コントロールノード）にインストールします。
※DockerまたはPodmanが動く環境が必要です。

pip install ansible-builder

2. 定義ファイルの作成

作業ディレクトリを作り、以下のファイルを用意します。

execution-environment.yml (メイン設定):

---
version: 3

images:
  base_image:
    name: quay.io/centos/centos:stream9  # ベースOS

dependencies:
  galaxy: requirements.yml       # コレクション
  python: requirements.txt       # Pythonライブラリ
  system: bindep.txt             # OSパッケージ

additional_build_steps:
  prepend_base:
    - RUN pip install --upgrade pip setuptools

requirements.yml (Ansible Collections):

---
collections:
  - name: amazon.aws
  - name: cisco.ios
  - name: community.general

requirements.txt (Python Libraries):

boto3>=1.26.0
botocore>=1.29.0
pywinrm>=0.4.3

bindep.txt (System Packages):

git [platform:rpm]
gcc [platform:rpm]
python3-devel [platform:rpm]

3. イメージのビルド

以下のコマンドで、Dockerイメージを作成します。

ansible-builder build --tag my-custom-ee:1.0

裏側でDockerfileが生成され、docker build が走り、必要なものが全て入った my-custom-ee:1.0 というイメージが完成します。

---

第3章：新しい実行CLI「ansible-navigator」

EEを作ったら、どうやってPlaybookを実行するのでしょうか？
従来の ansible-playbook コマンドは、ローカル環境のAnsibleを使おうとするため、EEを使ってくれません。

そこで登場するのが、ansible-navigator です。
これは、TUI（テキストユーザーインターフェース）を備えた新しいCLIツールで、裏側でコンテナ技術を使ってEEを起動し、Playbookを実行してくれます。

1. インストール

pip install ansible-navigator

2. 実行 (TUIモード)

ansible-navigator run site.yml --execution-environment-image my-custom-ee:1.0 --mode interactive

実行すると、画面が切り替わり、リッチなUIで実行ログが表示されます。
エラーが出たタスクの詳細をドリルダウンして確認したり、変数の値を見たりすることができます。

※Dockerが入っていない環境では動きません（Podman等が必要）。

3. 実行 (標準出力モード)

従来のようにテキストログだけを出したい場合（CI環境など）は、--mode stdout を使います。

ansible-navigator run site.yml \
  --execution-environment-image my-custom-ee:1.0 \
  --mode stdout \
  --pull-policy missing

これで、「ローカルにAnsibleが入っていなくても、DockerさえあればAnsibleが実行できる」状態になりました。

---

第4章：プログラムから実行する「Ansible Runner」

ansible-navigator は人間が使うツールですが、システム（WebアプリやCIツール）からAnsibleを呼び出したい場合は Ansible Runner を使います。
これは AWX (Ansible Tower) のバックエンドでも使われている、Ansible実行エンジンのコアです。

Ansible Runnerの特徴

• Python API: Pythonプログラムの中からAnsibleを実行し、結果をオブジェクトとして受け取れる。
• ディレクトリ構造による入力: 引数ではなく、所定のディレクトリ（env/, inventory/, project/）にファイルを置くことでパラメータを渡す。
• コンテナネイティブ: process_isolation=true にすると、自動的にコンテナ（EE）の中で実行してくれる。

Pythonからの実行例

import ansible_runner

r = ansible_runner.run(
    private_data_dir='/path/to/my/project',
    playbook='site.yml',
    process_isolation=True,
    process_isolation_executable='docker',
    container_image='my-custom-ee:1.0'
)

print("{}: {}".format(r.status, r.rc))
for each_host_event in r.events:
    print(each_host_event['event'])

これを使えば、「自社の管理画面ボタンを押したら、裏でAnsible RunnerがEEコンテナを立ち上げて処理を実行し、結果をDBに保存する」といったシステムが簡単に作れます。

---

第5章：移行ガイド（venv から EE へ）

多くの現場では、まだ virtualenv (venv) でAnsibleを動かしていると思います。
どうやってEEへ移行すべきでしょうか？

Step 1: 依存関係の洗い出し

まず、現在の環境に入っているものをリストアップします。

pip freeze > current_requirements.txt
ansible-galaxy collection list > current_collections.txt

Step 2: Builder定義ファイルの作成

洗い出したリストを元に、第2章の手順で requirements.txt と requirements.yml を作ります。
この時、不要なものは削ぎ落とし、本当に必要なものだけを定義するのがコツです。

Step 3: CI/CDパイプラインの更新

JenkinsやGitHub Actionsで pip install ansible している部分を、docker pull my-registry/my-custom-ee:1.0 に置き換えます。
そして実行コマンドを ansible-playbook から ansible-navigator (または docker run ...) に変更します。

---

第6章：Ansible講座 総まとめ

全16回、本当にお疲れ様でした！
入門編から応用編まで、私たちが歩んできた道のりを振り返りましょう。

入門編（基礎力の習得）

1. 構成管理の概念: エージェントレス、冪等性。
2. 環境構築: インベントリとansible.cfg。
3. Playbook: YAMLの書き方と基本モジュール。
4. 変数とテンプレート: 環境ごとの設定切り替え。
5. Role: コードの部品化と整理。
6. VaultとHandlers: セキュリティと効率化。
7. 実践演習: LAMP環境構築。
8. GUI管理: AWXとCI/CD。

応用編（プロフェッショナルへの道）

1. Dynamic Inventory: クラウド環境への追従。
2. 高度なロジック: Loop制御とJinja2フィルタ。
3. チューニング: Mitogenによる爆速化。
4. カスタムモジュール: Pythonによる拡張。
5. 自動テスト: Moleculeによる品質保証。
6. Windows管理: WinRMとPowerShell。
7. ネットワーク管理: Cisco/Juniperの自動化。
8. 実行環境 (EE): コンテナによる環境のポータビリティ。

これからの学習指針

Ansibleの学習に「終わり」はありませんが、「基礎」はこれで完璧です。
今後は以下の分野に挑戦してみてください。

• Event-Driven Ansible (EDA): 「アラート検知 → 自動復旧」をイベント駆動で実現する最新技術。
• Ansible Automation Platform (AAP): エンタープライズ向けの商用機能（Meshネットワークなど）。
• Kubernetes Operator: k8sのリソースをAnsibleで管理する。

---

おわりに：自動化エンジニアとしての未来

あなたがこの講座で手に入れたのは、単なるツールの使い方ではありません。
「繰り返しの苦痛から自分とチームを解放する力」です。

手動作業は、いつか必ずミスを生みます。そして何より、エンジニアの貴重な時間を奪います。
Ansibleを使って作業をコード化し、テストし、コンテナ化することで、あなたは「オペレーター」から「アーキテクト」へと進化しました。

エラーが出ても恐れないでください。ログを読み（-vvv）、仮説を立て、修正する。
そのサイクルの数だけ、あなたは強くなります。

長期間のお付き合い、本当にありがとうございました。
あなたの作ったPlaybookが、世界のどこかで誰かの助けになることを願っています。
Happy Automating!