Ansible Execution Environment (EE) の深淵：コンテナによる「環境の不一致」という悪夢からの解放
「私の環境では動くのですが…」
この言葉がチームから聞こえた瞬間、SREの夜は終わる。Ansibleのバージョン、Pythonの依存ライブラリ、インストールされたCollectionの差異。これらは構成管理ツールを使っているはずの我々を、皮肉にも「環境依存の地獄」へと突き落とす。
Ansible Automation Platform 2以降、我々はExecution Environment (EE)という強力な武器を手に入れた。これは単なるコンテナ化ではない。Ansibleの実行環境をImmutable（不変）なアーティファクトとして定義する、現代的なDevOpsの到達点だ。
本稿では、EEを駆使して「環境のゆらぎ」を完全に排除し、開発速度を極限まで引き上げるための実践テクニックを伝授する。
—
1. EEの核心：なぜ「ポータブルな実行環境」が必要か
従来のAnsibleは、実行ノードのOS環境に深く依存していた。`ansible-galaxy`で入れたCollectionが別環境で壊れる、Pythonの依存ライブラリが競合する。これらは全て「実行環境が動的であること」が原因だ。
EEは、Ansible本体、コレクション、Pythonパッケージ、OSライブラリを一つのコンテナイメージにパッケージングする。
- 冪等性の担保: どの環境で実行しても、必ず同じバイナリ・ライブラリセットが使用される。
- CI/CDとの親和性: `ansible-navigator`を導入すれば、ローカル開発環境とCIパイプラインで全く同じ実行コンテキストを即座に再現できる。
—
2. ansible-builder による「環境のコード化」
`ansible-builder`を用いて、環境を定義する。ここでのポイントは、「最小構成の追求」と「依存関係の明示」だ。
実践的な `execution-environment.yml`
version: 3
images:
base_image: ‘registry.redhat.io/ansible-automation-platform-24/ee-minimal-rhel9:latest’
dependencies:
# Python依存関係を固定する（Pipfile/requirements.txtのベストプラクティス）
python: requirements.txt
# 必要なAnsibleコレクション
galaxy: requirements.yml
additional_build_steps:
prepend:
# 必要なOSパッケージをインストール（Podmanビルド時に実行）
- RUN dnf install -y gcc libffi-devel
append:
# セキュリティリスク低減のため、不要な権限を剥奪する設定など
- RUN whoami
—
3. プロの現場で差がつく：Podman × Navigator の神運用
`ansible-playbook`を直接叩く時代は終わった。これからは `ansible-navigator` 一択だ。
隠れた神ショートカットとTips
`ansible-navigator`を実行中、以下のキー操作を脳に叩き込んでおけ。
- `Ctrl + w`: ウィンドウの分割切り替え。出力結果とタスクリストを同時に俯瞰する。
- `:stdout`: タスク実行中の標準出力をフル表示する。デバッグのスピードが倍になる。
- `:doc
` : コンテナ内で有効なモジュールのドキュメントを即座に引く。ブラウザを開く時間は無駄だ。
`ansible.cfg` のベストプラクティス
チーム開発において、`ansible.cfg`はリポジトリのルートに置き、EEとの連携を自動化せよ。
[defaults]
実行環境の自動認識
interpreter_python = /usr/bin/python3
コンテナ実行時のパフォーマンス最適化
pipelining = True
ログの標準化
log_path = ./ansible.log
[navigator]
Podmanをバックエンドに指定
execution-environment = true
container-engine = podman
—
4. トラブルシューティング：コンテナの闇に光を当てる
EE内で発生するエラーの多くは、ホストとの権限不一致や、コンテナ内へのパスの不整合に起因する。
1. コンテナ内シェルへの侵入:
うまく動かないときは、迷わずコンテナ内に入る。
ansible-navigator run site.yml –mode interactive
# インタラクティブモードに入ったら、モジュールの動作確認を行う
2. マウントエラー:
Podmanのボリュームマウントで権限エラーが出る場合は、`–userns=keep-id`オプションを検討せよ。これにより、ホスト側のユーザーIDとコンテナ内のIDを一致させることができる。
—
5. チーム生産性を最大化する「共有化ルール」
EEの導入は、ツールそのものよりも「開発プロセスの統一」にこそ価値がある。
- イメージのレジストリ集約: 自作EEイメージは必ず社内のプライベートレジストリ（Harbor等）で管理し、タグは `latest` ではなく `git commit hash` を付与せよ。
- Pre-commit hookの導入: `ansible-lint`をEE経由で実行する `pre-commit` フックを作成し、リポジトリに含める。これにより、汚いコードはマージ前に物理的に排除される。
- READMEへの明記: 開発開始時に `ansible-builder build -t my-ee:v1` を叩くだけで環境が整う状態を「Done」と定義せよ。
—
最後に：エンジニアとしての矜持
EEは単なるコンテナではない。それは、あなたが書いたコードが、「どこでも、いつまでも、誰が実行しても同じ結果をもたらす」という、インフラエンジニアとしての究極の約束だ。
「環境依存」という言葉を、君たちの辞書から消し去れ。
今日から、Ansibleの実行環境をコードとして管理し、より高次元の自動化へ突き進もう。
現場からは以上だ。さあ、次はどのインフラを自動化する？