Ansible コントロール端と inventory 設計
制御端は本番扱いにし、Python・Ansible・コレクションの版を固定し、inventory と play を単一 Git にまとめます。MeshMac 型プールでは ロール（CI／対話／GPU 等）と メンテ窓 でグループ化し、フラット一覧の「全台一括」事故を防ぎます。秘密は静的 inventory に直書きせず Vault、接続は短命証明書またはオペレータ鍵、期限付きブレークグラスは文書化します。変更系 play は --limit や tag でゲートし、監視のホスト名と揃えてログ相関を取ります。
ssh_args と証明書ローテーション手順表
OpenSSH ユーザー証明書は通常の ssh と同じく、制御端の CertificateFile と鍵を Ansible が継承します。Jump 付きホストだけ別引数なら ansible_ssh_common_args で局所化します。
| 手順 | 作業 | Ansible／SSH メモ |
|---|---|---|
| 1 | 旧 TTL が play 所要を下回る前に新ユーザー証明書を発行 | 制御端の CertificateFile を新 -cert.pub に向ける |
| 2 | カナリア：1 台 SSH の後 ansible -m ping --limit |
一度 -vvv で提示 identity／cert を確認 |
| 3 | CA フィンガプリントや ProxyJump 変更なら inventory を更新 | StrictHostKeyChecking=accept-new または版管理 known_hosts |
| 4 | 変更系 play は並列を下げて実行 | サービス再起動には serial: や throttle: |
| 5 | メトリクスが静まってから旧証明書失効／旧 CA 信頼削除 | 重複窓は Runbook に「長い play 用に数時間単位」と明記 |
コピー用 ansible.cfg と CLI パラメータ
inventory 隣に置くか ANSIBLE_CONFIG で指します。証明書パスと Jump は環境に合わせて調整してください。
[defaults]
inventory = ./inventory/hosts.yml
forks = 5
host_key_checking = True
timeout = 30
retry_files_enabled = False
interpreter_python = auto_silent
[ssh_connection]
pipelining = True
ssh_args = -o CertificateFile=~/.ssh/mac_automation-cert.pub -o IdentityFile=~/.ssh/mac_automation -o IdentitiesOnly=yes -o StrictHostKeyChecking=accept-new
control_master = auto
control_persist = 120sCLI 上書き例
ansible-playbook site.yml -f 3… 一時的な forks 上限ansible-playbook site.yml --limit 'ci_macs:&east'… グループ積集合ansible-playbook site.yml --check --diff… ドライ確認ANSIBLE_SSH_ARGS='-o ProxyJump=bastion.example'… 一時 Jump
play 内は serial: "25%" や serial: 2、レート制 API には throttle: 1 など。
forks／serial とノード安定性の閾値
forks は同時 SSH 本数の上限です。共有 Mac では Spotlight・セキュリティスキャン・ビルド I/O が既に競合します。目安：読み取り中心の fact 取得で対象の 1 分負荷平均 が概ね コア数×0.7 未満なら forks を慎重に上げる。対話ユーザーから遅延報告や MaxStartups 落ちが出たら下げるか Jump 側で多重化制限を見直します。serial やバッチ率は、Homebrew 大量更新・Xcode セレクタ・LaunchDaemon 再読込など破壊的作業向け。throttle: は同一 API／ディスクを叩くタスクに。
冪等 play 判断マトリクス
冪等とは「2 回目以降は実質的な状態差が出ない」ことです。定期推送を許可する前のレビュー用の簡易表です。
| 状況 | 推奨 | 理由 |
|---|---|---|
| 明確な期待状態の設定ファイル | copy／template＋checksum、notify |
ハンドラで再起動を束ね、fork 横断の再起動嵐を防ぐ |
| パッケージ／cask 更新 | 版ピン＋serial または小バッチ |
パッケージマネージャは単一ライタになりやすい |
| アドホック shell の「なんとかして」 | モジュール化または creates／fact ガード |
生 shell は冪等と監査の両方が壊れやすい |
| ドリフト検知 | --check、--diff、読み取り専用 play |
観測と変更を分離し CI 隣接でも安全 |
| 一時的な API／ネットワークエラー | block/rescue、バックオフ付き retry、until |
一部 fork だけ速攻失敗する半端状態を減らす |
FAQ
Q: 証明書ローテと Vault／inventory 更新を同時にやっていい？
A: 先に CA 信頼と証明書、カナリア検証、その後 inventory。盲信併用は実行中断の元です。
Q: forks の現実的な初値は？
A: 小プールでは 3～8 から。負荷・MaxStartups・体感遅延を見て調整。破壊系は serial。
Q: CI と Ansible の共存は？
A: 窓・ユーザー・ワークスペース分離、ロック／キュー合意、変更前 check／diff。
Q: serial と forks 全低下の使い分けは？
A: 単一ライタ経路・再起動嵐は serial／throttle。制御端・Jump が詰まるなら forks 全体を下げる。
inventory 分割、証明書ローテ、forks／serial、共有ビルド とのレーン分け、冪等 の型で、共有 Mac プールへの Ansible を再現可能にします。