Ansibleの実行環境を「コンテナ」に閉じ込める：Execution Environment（EE）の深淵と実践
こんにちは。現場でIaCと向き合い続けていると、「ローカル環境では動くのに、CI/CDサーバーや他のメンバーのPCではコケる」という、あの忌々しい「環境依存」の呪いに何度も遭遇しますよね。
Ansibleも例外ではありません。Pythonのバージョン違い、ライブラリの衝突、依存関係の地獄……。これらを一撃で解決し、AWXやAutomation Controllerでモダンに運用するための答えが「Ansible Execution Environment（EE）」です。
今回は、Ansible Builderを使ってこの「クリーンな実行環境」を構築する極意を、現場の視点から伝授します。
—
1. なぜ「Execution Environment」が必要なのか？
かつてのAnsibleは、実行端末にPython環境やモジュールを直接インストールする必要がありました。しかし、プロジェクトごとに必要なコレクションやライブラリが異なると、環境はすぐにスパゲッティ状態になります。
Execution Environment (EE) は、Ansibleの実行に必要なすべて（OS, Python, Ansible Core, Collections, System Packages）を一つのコンテナイメージにパッケージングする技術です。
- 冪等性の担保: 誰がどこで実行しても、全く同じコンテナが立ち上がるため、環境差異による失敗がゼロになります。
- AWXとの親和性: AWXはEEをネイティブにサポートしており、ジョブごとに異なるEEを割り当てることが可能です。
—
2. 準備：Ansible Builderをインストールする
まずは、このEEをビルドするためのツール「Ansible Builder」を導入します。Python環境が整っている前提で進めます。
仮想環境を作成してクリーンに導入するのが鉄則です
python3 -m venv venv
source venv/bin/activate
Ansible Builderのインストール
pip install ansible-builder
—
3. EE作成の設計図「execution-environment.yml」を書く
EEの構築は、このYAMLファイルを書くことから始まります。これが今回の心臓部です。
—
version: 3
images:
base_image:
name: registry.redhat.io/ansible-automation-platform-24/ee-minimal-rhel9:latest
dependencies:
# Ansible Galaxyから必要なコレクションを指定
galaxy:
requirements: requirements.yml
# OSレベルで必要なシステムパッケージ（例: git, iprouteなど）
system: bindep.txt
# Pythonライブラリの依存関係
python: requirements.txt
options:
package_manager_path: /usr/bin/dnf
現場のヒント：
- base_image: `ee-minimal`から始めるのが鉄則です。余計なプリインストールパッケージがないため、サイズが小さく、セキュリティリスクも低減できます。
- bindep.txt: システムレベルの依存関係（SSHクライアントや特定のバイナリ）を記述します。
—
4. 依存関係の定義（requirements.yml & requirements.txt）
次に、Ansibleのタスクに必要な中身を記述します。
requirements.yml (コレクション)
collections:
- name: community.general
- name: ansible.posix
requirements.txt (Python依存)
jmespath>=0.10.0
requests
—
5. ビルドとHelloWorld（動作確認）
設定が整ったら、魔法のコマンドを叩きます。
コンテナイメージをビルド
ansible-builder build -t my-ansible-ee:1.0
ビルドが完了したら、生成されたイメージを使って「HelloWorld」を試しましょう。AWXを通さずとも、ローカルのコンテナとして即座にテスト可能です。
コンテナを立ち上げてAnsibleバージョンを確認
podman run –rm my-ansible-ee:1.0 ansible –version
精度高い動作確認のコツ：
単にコマンドが通るだけでなく、以下のコマンドで、自分が定義したコレクションが正しくインストールされているかを確認してください。
podman run –rm my-ansible-ee:1.0 ansible-galaxy collection list
これで、自分の意図した構成がコンテナに封じ込められていることが証明されました。
—
6. AWX/Automation Controllerへの橋渡し
ここからがSREの腕の見せ所です。ビルドしたイメージは、社内のプライベートレジストリ（HarborやQuayなど）にプッシュします。
1. イメージをレジストリへプッシュ: `podman push my-registry.example.com/my-ansible-ee:1.0`
2. AWXの設定: 「Execution Environments」メニューから、上記レジストリのURLを登録。
3. ジョブテンプレートへの適用: ジョブテンプレート作成時に、作成したEEを選択するだけ。
これで、あなたのAnsibleコードは「どこでも同じように動く」強力な自動化資産へと昇華しました。
—
最後に：先輩からのアドバイス
初心者のうちは、「なぜわざわざコンテナに？」と思うかもしれません。しかし、運用規模が拡大し、管理するサーバーが10台、100台と増えたとき、この「実行環境の分離」があなたを救う唯一の砦になります。
最初は小さなPlaybookからで構いません。まずは自分専用の「鉄壁のEE」を作ってみてください。それが、モダンなIaCエンジニアへの第一歩です。
何か詰まったら、いつでも聞いてくださいね。現場の壁は、一緒に突破しましょう。