Ansible Collectionは「資産」だ。秘伝のタレを脱却し、組織のインフラをコードで統治せよ
現場で「またこのRoleをコピペして修正しているのか？」と絶望したことはないか。特定の環境に向けたニッチな共通処理が、プロジェクトごとに散逸し、技術負債として積み上がる。
SREとして、我々は「再利用可能なユニット」を武器に戦わねばならない。本稿では、Ansible Collectionを単なるディレクトリ構造ではなく、「組織のインフラ資産」としてパッケージングし、Private Automation Hubで流通させるための深淵なる実践フローを伝授する。
—
1. なぜ「Collection」なのか？
Role単体の管理は、依存関係の解決において脆すぎる。Collectionは、Role、Module、Plugin、ドキュメントを一つの名前空間に封じ込める「カプセル化」を実現する。
開発を加速させる神セットアップ
VS Codeで開発するなら、以下のプラグインは必須だ。
- Ansible (Red Hat公式): 言語サーバーによる補完とLint。
- YAML (Red Hat): `ansible.builtin` などのスキーマを自動適用。
- Todo Tree: 開発中の「あとで直す」を可視化する。
隠れたキーボードショートカット:
`Ctrl + Space` (補完) は当然だが、`F12` (定義へ移動) を使いこなせ。Collection間の参照を飛び回る時、これがないと指が死ぬ。
—
2. Collection開発の黄金律：初期化とディレクトリ戦略
まずは `ansible-galaxy collection init` で雛形を作る。
名前空間は組織名（例: acme）とコレクション名（例: infra）
ansible-galaxy collection init acme.infra
実践的ディレクトリ構成のベストプラクティス
acme.infra/
├── galaxy.yml # 魂。バージョン管理の起点
├── plugins/ # 独自Module/Lookupなど
├── roles/ # 共通処理のRole
│ └── hardened_ssh/ # セキュリティ基準を満たしたSSH Role
├── tests/ # moleculeによる統合テスト
└── README.md # チームへの「仕様書」
ポイント: `galaxy.yml` の `version` は、`semantic versioning` を厳守せよ。ここを適当に扱うチームは、将来的に必ず「どのバージョンが安全かわからない」という泥沼にハマる。
—
3. 「壊れない」ためのテストとビルド
Ansibleのコードをデプロイする際、テストがないのはブレーキのない車で公道を走るのと同じだ。Molecule を使い、Dockerコンテナ上で `idempotency`（冪等性）を強制的に検証する。
molecule.yml の極意
molecule/default/molecule.yml
verifier:
name: ansible
platforms:
- name: instance
image: geerlingguy/docker-ubuntu2204-ansible:latest
pre_build_image: true
provisioner:
name: ansible
playbooks:
converge: converge.yml
`molecule verify` をCIパイプラインに組み込み、冪等性が担保されていないコードはマージを拒否するルールを敷け。
—
4. Private Automation Hub への配信フロー
ビルドした成果物を社内インフラに届ける。これが最後のピースだ。
ビルドコマンド
ansible-galaxy collection build
これで acme-infra-1.0.0.tar.gz が生成される
Automation Hubへのアップロード（自動化せよ）
手動アップロードは悪だ。`ansible-galaxy` コマンドでAPI経由で流し込む。
認証トークンを環境変数に設定し、自動デプロイ
ansible-galaxy collection publish ./acme-infra-1.0.0.tar.gz \
–api-key $AUTOMATION_HUB_TOKEN \
–server https://automation-hub.example.com/api/galaxy/
—
5. チーム共有のルール：ここが「差」を生む
Collectionを開発しただけで満足してはいけない。チームが使いこなせる環境を整備せよ。
1. `requirements.yml` の強制: 開発する全てのPlaybookにおいて、`requirements.yml` でバージョン指定を行うこと。「最新版」という甘えは許さない。
collections:
- name: acme.infra
version: “1.2.0”
source: “https://automation-hub.example.com/”
2. Lintの統一: プロジェクトルートに `.ansible-lint` を置き、警告を `error` として扱う。
# .ansible-lint の極意
skip_list:
- ‘no-handler’ # ハンドラーを使わない例外的なケースのみ
profile: min # 徐々に厳しくして ‘production’ へ移行
—
最後に：技術は「仕組み」に宿る
Ansible Collectionは、単なるコードの集まりではない。「組織のベストプラクティスを強制する規律」そのものだ。
あなたが作ったCollectionが、後輩の手を煩わせず、数行のYAMLで完璧なインフラを構築した時、初めてそのツールは「エンジニアの武器」となる。今日から、コピペを捨て、パッケージングを始めよう。
コードは嘘をつかない。だが、仕組みがなければ人は必ずサボる。さあ、自動化のその先へ。