【メモ】Ansibleパッチ適用自動化
要旨
Ansible でパッチ適用を自動化するときに効くのは、Playbook そのものよりも「パッチ管理プロセス」「実行基盤」「証跡」を一体で設計する考え方です。NIST のパッチ管理ガイドが示すように、パッチ管理は識別、優先度付け、取得、適用、適用確認までを含む運用プロセスです。Ansible はその実行を大きく効率化できますが、企業運用では ansible-playbook が動くだけでは足りず、権限分離、承認、監査、段階展開、失敗時復旧まで含めて設計したほうが事故率を下げやすくなります。12
結論を先に置くと、選び方の目安は次の 3 段階です。
| 規模・要件 | 向く形 |
|---|---|
| 数十〜数百ノード / 統制が軽い | CLI + Git + Vault で始め、serial と失敗率制御、証跡保管を先に固める |
| 数百〜数千ノード / 部門分掌と監査が必要 | AWX または Automation Controller を中核に置き、RBAC、スケジュール、Workflow、監査ログ、メトリクスを標準化する |
| 数千〜数万ノード / 多拠点・分離ネットワーク | 実行プレーンを分散し、ホップノードと実行ノードを組み合わせて中央統制と拠点内実行を両立する |
本稿では、前提が明示されていないため、Linux、Windows、ネットワーク機器の更新を対象にします。ミドルウェア更新も、変更管理、検証、段階展開、ロールバックという枠組み自体は同じです。
前提として押さえるべき Ansible 側の論点
いまの Ansible は ansible-core と Collection の組み合わせで使う前提が強く、Windows やネットワーク機器のパッチ適用ではこの点を外しにくいです。Collection はモジュール、プラグイン、ロールの配布単位で、ansible-core だけでは足りない機能が多くあります。たとえば Windows Update を扱う ansible.windows.win_updates は ansible.windows collection に含まれ、ansible-core には含まれません。ネットワーク機器向けの ansible.netcommon.network_cli も同様です。3456
実務上の落とし穴は、ansible-core と Collection の対応関係がずれることです。ansible.windows collection の現行ドキュメントでも、対応 ansible-core は 2.16.0 以降とされています。加えて、Ansible community package と ansible-core は別のリリース体系で保守されるため、ローカル開発環境、CI、Automation Controller 上の実行環境がばらけると再現性が崩れます。47
この問題に対する基本解は、Execution Environment で依存関係を固定することです。Execution Environment は、従来の仮想環境の代わりに使うコンテナイメージで、ansible-core、Collections、Python 依存、システム依存をまとめて同梱できます。パッチ適用のように OS 別、接続方式別の差が大きい運用では、EE を使うかどうかで「開発では動くが本番では失敗する」の頻度が大きく変わります。8
公開事例から読めること
公開情報で追える事例だけを並べても、共通するのは「標準化された実行基盤」と「人手前提の手順からの脱却」です。
| 組織 | 業界 | 公開された規模感 | 採用形態 | 読み取れるポイント |
|---|---|---|---|---|
| Emory University | 教育 | RHEL サーバー 500 台超 | Ansible Automation Platform でパッチ適用を自動化 | 手動なら 2 週間かかる修復を 4 時間で完了。パッチ自動化は速度よりも復旧可能な標準手順化が効いている。9 |
| Asian Development Bank | 金融 | 職員 3,500 人 + 3,000 人規模 | マネージドクラウド上の Ansible Automation Platform | パッチ、DB クローン、復旧を自動化し、月 20 人日規模の削減を公開。運用の中央化と既存ツール連携が主眼。10 |
| ABB | 製造・テクノロジー | 32 チームが利用 | グローバル標準の Ansible Automation Platform | チームごとに別の自動化手段を使う分散状態から、マルチテナンシー前提の共通基盤へ寄せている。11 |
| Swisscom | 通信 | 約 15,000〜20,000 の IT / ネットワーク構成要素 | Ansible Tower / Automation Platform を中央基盤化 | 自動化対象は OS だけでなく firewall、network、storage を含む。年間約 3,000 時間削減と、セルフサービス・RBAC の強化を前面に出している。1213 |
ここから読めるのは、パッチ適用だけを局所最適化しても効果は限定的で、結局は「誰が、どの権限で、どのテンプレートを、どの順序で実行するか」を共通化した組織のほうが伸びるということです。
実装形態の比較
パッチ適用を継続運用として回す前提で見ると、実装形態ごとの違いはかなりはっきりしています。
| 形態 | 代表例 | 強み | 弱み | 向く場面 |
|---|---|---|---|---|
| コマンドライン中心 | ansible-playbook、Git、CI、Vault | 最小構成で始めやすい。Playbook の自由度が高い。 | 承認、監査、権限分離、再実行統制を外部設計に頼りやすい。 | 小規模、少人数、まず標準ロールを固めたい段階 |
| Web 実行基盤 | AWX、Automation Controller | GUI/API、Job Template、Workflow、スケジュール、Activity Stream、メトリクスを持てる。 | 基盤運用が増える。AWX は商用 SLA やサポート付きアップグレードを前提にしにくい。 | 部門分掌、監査、セルフサービス運用が必要な段階 |
| 配布基盤込みの統合型 | Satellite + Ansible、WSUS + Ansible、機器ごとのイメージ配布基盤 | 配布元、ライフサイクル、承認、検証済みコンテンツ管理を寄せやすい。 | 設計対象が増える。製品ごとの差分吸収が必要。 | 配布元を統制したい環境、本番前検証を厳密に回したい環境 |
| マネージド / SaaS | AAP Service on AWS など | コントロールプレーン運用を減らしやすい。分散実行と親和性が高い。 | 接続モデルやサポート範囲の理解が必要。ベンダー依存も増える。 | 多拠点・分離ネットワーク・少人数運用 |
AWX / Automation Controller の価値は、ジョブを GUI から起動できること自体よりも、Workflow、Activity Stream、認証連携、メトリクス、資格情報の集約をセットで持てる点にあります。逆に AWX を選ぶなら、SLA やアップグレード互換性の責任を自前で持つ前提で判断したほうが安全です。14151617
代表構成パターン
小規模: CLI + Git + Vault
運用者 / CI
├─ Git pull → Playbook / Role リポジトリ
├─ Vault → 秘密情報
└─ ansible-playbook 実行
├─ SSH → Linux
├─ WinRM / PSRP → Windows
└─ network_cli / httpapi → ネットワーク機器
この構成の利点は、最短で始められることです。まずは serial と max_fail_percentage で段階展開を入れ、ログと実行結果を保管し、誰がいつどの Playbook を回したかが追えるようにします。小規模ではこれだけで十分なこともあります。1819
ただし、この構成は拡大すると急に脆くなります。承認フロー、権限分離、作業委譲、再実行統制、証跡の改ざん耐性を後付けで足すことになりやすいからです。
中規模: Automation Controller 中心
運用者 / 申請者
↓ Web UI / API
Automation Controller
├─ SCM 連携
├─ Job Template / Workflow
├─ 資格情報 / RBAC
├─ Activity Stream
├─ Metrics Endpoint
└─ 実行ノード
├─ SSH → Linux
├─ WinRM / PSRP → Windows
└─ network_cli → ネットワーク機器
実務で効くのは Workflow です。Red Hat のパッチ自動化ガイドでも、スナップショット取得、パッチ適用、失敗時復元、成功時クリーンアップという複数ジョブ連鎖が例示されています。これをテンプレート化しておけば、「作業者が上手いから事故が少ない」状態から抜けやすくなります。2
加えて、Activity Stream で変更履歴を追え、認証は LDAP や SAML などと統合でき、メトリクスは Prometheus 系に載せられます。UI があること自体より、統制と観測が一段上がることのほうが価値です。141516
大規模: 分散実行プレーン
ポータル / ITSM / 申請
↓
Controller Cluster
├─ DB / 実行制御
├─ Automation Hub / EE Registry
└─ Automation Mesh
├─ Hop Node（中継）
├─ 拠点 A 実行ノード → 拠点 A の Linux / Windows / NW
└─ 拠点 B 実行ノード → 拠点 B の Linux / Windows / NW
多拠点や分離ネットワークでは、制御プレーンと実行プレーンを分けないと苦しくなります。Automation Mesh では、hop ノードがトラフィック中継だけを担い、execution ノードが実際のジョブを実行します。この役割分離があると、中央から直接到達しづらいセグメントでも現実的な設計になります。20
さらにマネージドサービスを使う場合、AAP Service on AWS は PULL モデルを推奨しており、実行ノード側から WebSocket を張る形なので企業ネットワーク側で Ingress を開けずに済みます。mTLS で保護される一方、TLS 終端プロキシは非サポートなので、ネットワーク設計時の前提条件として確認が必要です。21
運用設計で外しにくい論点
段階展開を最初から入れる
Ansible では serial によってホストをバッチ単位で処理でき、max_fail_percentage と組み合わせることで失敗率しきい値を超えた時点で停止できます。パッチ適用で重要なのは、全台一斉に成功することではなく、失敗の影響範囲を小さく閉じ込めることです。18
- hosts: linux_targets
become: true
serial: "10%"
max_fail_percentage: 10
tasks:
- name: Apply security patches
ansible.builtin.dnf:
name: "*"
security: true
state: latest
- name: Reboot hosts
ansible.builtin.reboot:
reboot_timeout: 1800
- name: Wait until hosts are reachable again
ansible.builtin.wait_for_connection:
timeout: 600
wait_for_connection は Windows も含めて使えるため、再起動後の復帰待ちを標準化しやすいです。22
ロールバックを「人が判断する作業」にしない
ロールバックを Runbook の末尾に文章で書くだけだと、失敗時に一番忙しい人へ判断が集中します。スナップショット取得、パッチ適用、失敗時復元、チケット作成、成功時スナップショット削除までを Workflow にしておくほうが、復旧時間も説明責任も安定します。2
ネットワーク機器では、変更前バックアップを必須にするだけでも事故率が下がります。ansible.netcommon.cli_config は変更前に running-config のフルバックアップを取れます。23
Windows は接続方式と更新方式の差分を先に潰す
Windows 更新では、ansible.windows.win_updates を中心に考えるのが素直です。カテゴリ指定、再起動、ログ出力をまとめて扱えます。接続は WinRM でも PSRP でもよいですが、Ansible の現行 Windows ガイドでは PSRP は WinRM よりやや高速で、負荷時のタイムアウトに強いことがあると説明されています。524
- hosts: windows_targets
tasks:
- name: Install Windows updates with reboot
ansible.windows.win_updates:
category_names:
- SecurityUpdates
- CriticalUpdates
reboot: true
log_path: C:\ansible_wu.log
Windows では、更新直後にサービスが完全復帰していない状態を織り込んで、疎通確認と業務アプリ確認を別タスクに分けたほうが安全です。
認証、権限、秘密情報は実行基盤に寄せる
Linux は SSH、Windows は WinRM または PSRP、ネットワーク機器は network_cli が基本線です。CLI 運用なら Ansible Vault で秘密情報を暗号化し、Controller 運用なら資格情報と RBAC を中央化します。運用者に鍵やパスワードを直接見せず、実行権限だけを委譲できる設計のほうが長期運用に向きます。19615
監査とメトリクスを「後から考える項目」にしない
AWX の Activity Stream は、どのオブジェクトに対して、誰が、いつ、何をしたかを追う起点になります。Automation Controller には Prometheus 等で取得できるメトリクスエンドポイントもあります。バージョンによってパス表記は差がありますが、少なくとも現行系ドキュメントではメトリクス公開が標準機能です。1416
ここで見るべきは、ジョブ成功率だけではありません。適用率、再実行率、失敗率、平均復旧時間、対象別の滞留件数を持っておくと、月次パッチ運用の品質が数字で話せるようになります。
多拠点や分断ネットワークでは「実行ノードを近づける」
到達不能ホストが多い環境で中央から直接流すだけだと、再試行とタイムアウトで全体が不安定になります。Hop node と execution node を使って実行位置を拠点側へ寄せるほうが現実的です。AWS の PULL モデルはその設計と相性がよく、アウトバウンド接続だけで済ませたい環境で特に有効です。2021
並列性は上げるより制御する
大規模では「もっと並列に流す」よりも「どこまで並列に流してよいか」を定義するほうが重要です。Automation Controller では instance group ごとに max_concurrent_jobs と max_forks を設定できるため、組織や拠点単位で消費上限を決められます。25
導入コストと運用工数の見方
ここは製品価格よりも、何が工数を押し上げるかで見るほうが実務的です。支配要因は、対象の多様性、統制要件、ロールバックの深さ、拠点分散、EE の有無です。特に Linux、Windows、ネットワーク機器が混在すると、接続、再起動、確認項目が一気に増えます。
以下は標準的な企業システムを想定した筆者試算のレンジです。金額ではなく、人日と月次運用工数の目安として見てください。
| 規模レンジ | 推奨実装形態 | 初期導入の目安 | 運用の目安 | インフラの見方 |
|---|---|---|---|---|
| 数十〜200 ノード | CLI + Git/CI + Vault | 20〜60 人日 | 2〜6 人日 / 月 | 実行ホスト、ログ保管、最低限の検証環境 |
| 200〜2,000 ノード | AWX / Automation Controller | 60〜140 人日 | 6〜15 人日 / 月 | DB、実行ノード、監視、証跡保管 |
| 2,000〜10,000 ノード | Controller + 分散実行 + Workflow 標準化 | 140〜260 人日 | 15〜35 人日 / 月 | 実行プレーン分散、容量制御、拠点接続設計 |
| 10,000 ノード超 | 大規模分散 + HA またはマネージド | 260〜500 人日 | 35〜80 人日 / 月 | HA、複数拠点、接続モデル、実行ノード最適化 |
運用工数は、Playbook を書く時間より、例外処理、証跡保管、失敗調査、再実行判断、メンテナンスウィンドウ調整で膨らみます。ここを減らしたいなら、Workflow と定常 SOP を先に作るほうが効きます。
導入ロードマップ
12 週間で立ち上げるなら、最初に大規模 HA を作るより、標準ロール、段階展開、証跡、復旧手順を先に固めたほうが成功しやすいです。
-
週 1-2: 資産棚卸しと方針整理
Linux、Windows、ネットワーク機器を分け、接続方式、再起動要否、検証観点、パッチ期限、例外条件を決める。 -
週 3-4: 実行基盤の最小構築
まず CLI で始めるか、最初から AWX / Controller を入れるかを決める。認証連携、ログ保管先、証跡の残し方まで合わせて決める。 -
週 5-6: 標準 Playbook / Role 整備
serial、max_fail_percentage、再起動、wait_for_connection、Windows Update、ネットワーク機器バックアップを骨格として揃える。 -
週 7-8: テストと依存固定
ansible-lintと Molecule を CI に入れ、Execution Environment で依存を固定する。26278 -
週 9-10: パイロット運用
Canary、段階拡大、復元、通知、レポートを含めて本番相当で回す。ここで SOP と障害時判断基準を確定させる。 -
週 11-12: 本番移行と横展開
定期パッチと緊急パッチの 2 本立てで運用を始め、適用率、失敗率、平均復旧時間を KPI として定着させる。
まとめ
Ansible のパッチ適用自動化を企業運用として成立させるには、Playbook の巧拙よりも、段階展開、ロールバック、認証、証跡、分散実行の設計が効きます。小規模では CLI から始めてよいですが、運用を人に依存させないなら、どこかの段階で Web 実行基盤と Workflow に寄せるほうが安定します。
特に、Linux、Windows、ネットワーク機器を横断して扱う場合は、Collection と Execution Environment の整備を後回しにしないほうが安全です。パッチ適用を「月次作業」ではなく「標準化された変更管理プロセス」として扱えるかどうかが、最終的な差になります。