Ansibleの「脱・依存関係地獄」：Execution EnvironmentとBuilderで実現する、堅牢なIaC基盤の設計術
「Ansibleのバージョンが開発者間でバラバラ」「特定のコレクションが足りずに本番デプロイでコケる」「コントロールノードのPython環境が汚染されていく」……。
もし君が今、そんな「Ansibleあるある」に頭を抱えているのなら、それは「Ansible 2.9以前の古い常識」に縛られている証拠だ。現代のSREにとって、Ansibleの実行環境をホストOSに直接構築するのは、もはやアンチパターンと言わざるを得ない。
本稿では、Ansible BuilderとAWX（またはAutomation Controller）を組み合わせ、実行環境を完全にコンテナ化（Execution Environment: EE）して「再現性」と「可搬性」を極限まで高めるプロの戦術を伝授する。
—
1. なぜ今、Execution Environment (EE) なのか？
かつてのAnsible運用では、`requirements.yml`を適用し、システムPythonのモジュールをインストールしていた。しかし、これでは「環境のドリフト」を避けられない。
EEの真の価値は、「プレイブックの実行に必要なすべての依存関係（Ansible Core, Collections, Pythonライブラリ, OS依存のバイナリ）を、ひとつのOCIコンテナイメージに固める」ことにある。これにより、「私の環境では動くのに」という言い訳を、歴史の彼方に追いやることができる。
2. Ansible Builder: 職人による「イメージビルド」の神髄
Ansible Builderは、単なるDockerビルドのラッパーではない。依存関係の解決を自動化し、最適なレイヤー構成でイメージを生成するための魔法の杖だ。
実践：`execution-environment.yml` のベストプラクティス
まずは、プロジェクトのルートに配置する構成ファイルだ。
—
version: 3
依存するコレクションの定義（galaxy.yml形式）
dependencies:
galaxy: requirements.yml
python: requirements.txt
system: bindep.txt # OSパッケージの依存解決用
ベースイメージは公式の最小限かつ堅牢なものを選ぶ
images:
base_image:
name: registry.redhat.io/ansible-automation-platform-24/ee-minimal-rhel8:latest
ビルドのカスタマイズ（ここでは追加のツールを入れる）
additional_build_steps:
prepend:
# 現場で必須のデバッグツールを追加
- RUN dnf install -y iputils procps-ng
append:
# 独自スクリプトの配置など
- COPY scripts/pre-run.sh /usr/local/bin/pre-run.sh
現場で震えるほど役立つTips
- `bindep.txt`を使い倒せ: Ansibleモジュールが依存する`libssl-dev`や`gcc`などを、OSレベルで明示的に管理せよ。これを怠ると、コンテナ起動時にライブラリ不足で即死する。
- キャッシュ戦略: `ansible-builder build –build-arg BUILDKIT_INLINE_CACHE=1` を活用し、CI/CDパイプラインでのビルド速度を劇的に向上させよ。
—
3. AWX/Automation Controllerへの統合
EEを構築したら、次はAWXへ登録する。
1. レジストリ登録: `docker push`でプライベートコンテナレジストリ（HarborやECRなど）へプッシュ。
2. Credential設定: AWX上で「Container Registry」の認証情報を設定。
3. EEの追加: AWXの「Execution Environments」メニューから、イメージのURLを指定して登録。
これにより、AWXのジョブテンプレートで「どの環境（EE）で実行するか」をUIから選択可能になる。プロジェクトごとにEEを分ければ、Pythonのバージョン依存やコレクションの競合を一切気にせず、独立した実行環境を担保できる。
—
4. 生産性を最大化する「プロの作法」
必須の神プラグイン（VS Code）
- Ansible (Red Hat): これを入れない選択肢はない。`ansible-lint`との統合が必須だ。
- YAML (Red Hat): スキーマ検証を強制し、インデントミスによる絶望を未然に防ぐ。
隠れた生産性ハック
- キーボードショートカット: VS Codeで `Ctrl + Shift + P` -> `Ansible: Run at Cursor` を設定せよ。巨大なプレイブック全体を回すのではなく、タスク単位で高速検証する。
- Linterの厳格化: `.ansible-lint` ファイルをプロジェクトルートに置き、以下の設定を強制せよ。
.ansible-lint
profile: production
skip_list:
- ‘no-handler’ # ハンドラの不使用を許容する場合のみ
rules:
no-same-owner: false # 厳格にチェックする
—
5. 結論：IaCの先にある「運用の自動化」
Ansible Builderで環境をコード化し、EEとしてパッケージングする。これは単なる技術選定ではなく、「インフラをソフトウェア開発の作法に合わせる」というパラダイムシフトだ。
君のチームが次に構築すべきは、複雑なシェルスクリプトの塊ではない。CI/CDパイプラインを通り、ビルドされたコンテナイメージが検証環境から本番環境まで一貫して動く「美しい自動化フロー」だ。
さあ、古い資産は捨てろ。今日からEEによるクリーンな自動化を始めよう。君のインフラは、もっと強くなれる。