Ansible × Docker：開発速度を「異常値」まで引き上げる極限のインフラコード術
開発環境の構築に何時間も費やしているチームは、今すぐその手を止めてほしい。
「Dockerコンテナを立ち上げて、中に入ってコマンドを叩く」――この手作業こそが、現代のエンジニアリングにおける最大の負債だ。
私はこれまで数々の大規模インフラを設計してきたが、「AnsibleでDockerを制御する」というアプローチを極めたチームだけが、開発環境の冪等性と再現性を完全にコントロールできている。
今日は、ただのツール紹介ではない。現場の生産性を極限まで高めるための「Ansible × Docker」の深淵に触れる。
—
1. なぜDocker管理にAnsibleを持ち込むのか？
Docker Composeだけでも環境は作れる。だが、それだけでは「OSレベルの複雑な依存関係」や「セキュアなプロビジョニング」を管理できない。
AnsibleをDockerのプロビジョナーとして使う最大のメリットは、「ホストOSのセットアップ」から「コンテナ内のアプリケーション構成」までを、単一の冪等なコードベースで完結できる点にある。これにより、開発者のPCが変わっても、CI/CDで動くコンテナと完全に同じ環境が1分で立ち上がる。
必須の「神」プラグイン＆環境設定
まずは生産性を底上げする武器を揃えよ。
- VS Code拡張機能: `Red Hat Ansible`
- これなしでAnsibleを書くのは、地図なしで密林を歩くようなものだ。YAMLのバリデーション、変数補完、ドキュメント参照が飛躍的に向上する。
- `.ansible-lint` による強制力:
- チーム開発では、書き方の揺れは「悪」だ。プロジェクトルートに以下の設定を置き、CIで強制的にチェックをかけること。
.ansible-lint
profile: production
rules:
# 冪等性を損なう危険なコマンドを排除
skip_list:
- ‘no-handler’
—
2. 現場で震えるほど役立つ「Docker × Ansible」ベストプラクティス
多くのエンジニアは `shell` モジュールで力技のスクリプトを書きがちだが、それは初心者のやることだ。`community.docker` コレクションを使い倒せ。
実践的なタスク構成例
Dockerコンテナを「単なるプロセス」ではなく「管理されたインフラ」として扱うコード例だ。
roles/dev_container/tasks/main.yml
- name: コンテナ用のネットワークを作成
community.docker.docker_network:
name: dev_bridge
- name: 開発コンテナのプロビジョニング
community.docker.docker_container:
name: app_server
image: my-app:latest
state: started
restart_policy: always
networks:
- name: dev_bridge
volumes:
- /sys/fs/cgroup:/sys/fs/cgroup:ro # Systemdをコンテナで動かすための魔法のパス
env:
DB_HOST: “db_container”
極限のTips: `volumes` にホストのコードをマウントする際、`delegated` または `cached` オプションを付けろ。OSX/Windows環境でのファイルIO性能が劇的に向上する。
—
3. Moleculeで始める「インフラのTDD」
「動いたから良し」とする文化を捨てろ。インフラコードもテスト駆動開発（TDD）の対象だ。Moleculeを使えば、Dockerコンテナを使い捨てて、プロビジョニングの成功を自動検証できる。
Moleculeによる検証フロー
1. `molecule init` でプロジェクト生成
2. `molecule test` でコンテナ起動 → Ansible実行 → 成功確認 → コンテナ破棄 を自動実行。
これをCIに組み込めば、「設定ミスによる環境構築失敗」はチームから撲滅される。 開発者がコードをプッシュした瞬間、Moleculeがその環境の健全性を担保するのだ。
—
4. チームで共有すべき「設定ファイル」の美学
チーム開発で「俺の環境では動く」という言い訳を許してはならない。以下のディレクトリ構成を標準とせよ。
.
├── inventory/ # 環境ごとの接続先定義（開発用ローカル、ステージングなど）
├── roles/ # 再利用可能なプロビジョニング単位
├── group_vars/ # 環境ごとの変数定義（ここを分けるのが肝）
├── molecule/ # 各ロールのテスト用設定
└── ansible.cfg # チーム共通の実行パラメータ
ansible.cfgの最適化設定:
[defaults]
実行速度を極限まで高める
pipelining = True
forks = 20
ログ出力を綺麗にする
stdout_callback = yaml
—
最後に：エンジニアとしての矜持
Ansibleを単なる「コマンド実行ツール」として使うのは、フェラーリで近所のスーパーに買い物に行くようなものだ。
真のSREは、Ansibleを使って「環境そのものを宣言的に定義」する。
今日伝えた手法を取り入れれば、環境構築のストレスはゼロになる。自動化に費やした時間は、必ず数倍の「創造的な時間」として君に返ってくるはずだ。
さあ、エディタを開け。君のインフラをコードという芸術に昇華させる時が来た。