Ansibleカスタムモジュール：既存の限界を突破し、IaCの聖域へ踏み込む技術
Ansibleは強力だが、実務の現場では「既存モジュールを組み合わせるだけでは、どうしても抽象化しきれない複雑なドメインロジック」に直面する。その時、多くのエンジニアは「Shellモジュールで力技」という逃げ道を選ぶ。だが、それは技術的負債の始まりだ。
真のSREは、ここでPythonによる「カスタムモジュール」を実装する。冪等性を担保し、エラーハンドリングを標準化されたJSON APIとして定義することで、インフラを「プログラム可能な資産」へと昇華させるのだ。
—
1. なぜカスタムモジュールが必要なのか？
Ansibleの標準モジュールは「冪等性」が保証されている。これこそがAnsibleの本質だ。しかし、社内独自のレガシーAPIや、複雑なビジネス要件を伴うリソース管理を行う際、既存モジュールでは「状態の判定」が困難になる。
カスタムモジュールを実装することは、「Ansibleの制御フローの中に、独自の冪等性ロジックを注入する」ことを意味する。これにより、Playbookの可読性は維持されたまま、内部で複雑なステート管理が可能になる。
—
2. 実装の神髄：`AnsibleModule` の流儀
カスタムモジュール開発の心臓部は `ansible.module_utils.basic` にある `AnsibleModule` クラスだ。これを使わずに標準入出力を自作するのは、車輪の再発明であり、脆弱性の温床となる。
実践：冪等性を担保するカスタムモジュール
以下は、ある特定の設定値をセキュアに更新するカスタムモジュールの雛形だ。
!/usr/bin/python
— coding: utf-8 —
from ansible.module_utils.basic import AnsibleModule
def run_module():
# 1. 入力値の定義とバリデーション
argument_spec = dict(
name=dict(type=’str’, required=True),
state=dict(type=’str’, default=’present’, choices=[‘present’, ‘absent’]),
value=dict(type=’int’, required=False)
)
module = AnsibleModule(
argument_spec=argument_spec,
supports_check_mode=True # ドライラン対応はSREの必須マナー
)
result = dict(changed=False, original_message=”, message=”)
# 2. 現在の状態を取得 (ここで冪等性を判定)
current_state = get_current_state(module.params[‘name’])
if module.params[‘state’] == ‘present’:
if current_state != module.params[‘value’]:
if module.check_mode:
module.exit_json(changed=True)
# 3. 処理の実行
perform_update(module.params[‘name’], module.params[‘value’])
result[‘changed’] = True
result[‘message’] = ‘Value updated successfully.’
# 4. 結果の返却
module.exit_json(result)
if __name__ == ‘__main__’:
run_module()
現場で震えるためのポイント
- `supports_check_mode=True`: これを忘れると、チームメンバーから「ドライランが効かない」と突き返される。
- `exit_json` と `fail_json`: これらを使って終了することで、Ansibleのタスク実行結果として正しくステータスが記録される。
—
3. 生産性を極限まで高める「隠れたエコシステム」
カスタムモジュールを書く際、IDEの設定が生産性を左右する。
おすすめの神プラグイン（VS Code）
- Ansible (Red Hat公式): YAMLのバリデーションとドキュメント参照に不可欠。
- Python (Microsoft): 型ヒント（Type Hinting）をフル活用し、開発時のバグを静的解析で叩き潰す。
- Indent-rainbow: 複雑なYAML構造のインデント視覚化には必須。
隠れたキーボードショートカット
- `Ctrl + Shift + P` -> `Ansible: Lint`: 思考停止でこれを叩く。Lintエラーを放置するエンジニアにIaCを語る資格はない。
—
4. チーム開発で生き残るための「共通ルール」
Ansibleプロジェクトがカオス化する原因の9割は「構造化の甘さ」にある。以下の構成をテンプレートとして採用せよ。
.
├── library/ # 自作モジュールはここ
├── module_utils/ # 複数のモジュールで共通利用するPythonコード
├── roles/ # ドメインロジック単位で分割
├── group_vars/ # 環境ごとの秘匿情報はansible-vaultで暗号化
└── ansible.cfg # 以下設定を必ず含める
`ansible.cfg` のベストプラクティス
[defaults]
実行速度を劇的に改善するSSHパイプライン
pipelining = True
カスタムモジュールのパスを指定
library = ./library
ログ出力の最小化（CI環境で重要）
stdout_callback = yaml
—
5. 最後に：伝説的SREへの道
カスタムモジュールを作るということは、Ansibleというフレームワークの内部構造を理解するということだ。最初は面倒に感じるかもしれない。しかし、一度この「型」を習得すれば、インフラのあらゆる挙動をコードで完璧に制御できるようになる。
「自動化できないものはない。ただ、適切な抽象化レイヤーがまだ見つかっていないだけだ。」
このマインドセットで、今日から君のインフラをコードの海へ導いてほしい。健闘を祈る。