3.2. Ansible Automation Platform によるパッチ適用の自動化
ソフトウェアのパッチ適用は、あらゆる場所のセキュリティーおよび IT 運用チームにとって基本的な活動です。パッチを最新の状態に保つことは、ソフトウェアの脆弱性を修正し、コンプライアンス要件を満たすうえで重要です。しかし、大規模なシステムに手動でパッチを適用すると、時間がかかり、ミスが発生しやすくなります。組織は、セキュリティー、コンプライアンス、ビジネス目標を満たすパッチ管理戦略を検討し、企業全体で利用可能な IT 資産に対して適用するパッチの種類 (既知のエクスプロイト、重大な脆弱性、最適化、定期的な更新、新機能など) の優先順位を付ける必要があります。ポリシーと優先順位を定義し、パッチ適用計画を確立したら、Red Hat Ansible Automation Platform を使用してパッチ管理に関連する手動タスクを自動化し、パッチのデプロイの速度と精度を向上させ、ヒューマンエラを減らし、ダウンタイムを抑えることができます。
3.2.1. パッチ適用の自動化の利点
パッチ適用プロセスを自動化すると、次のような多くの利点が得られます。
- ミスが発生しやすい手作業が削減されます。
- 大規模にパッチをデプロイする時間が短縮されます。
- 類似するシステム間でパッチの一貫性が確保されます。類似するシステムに手動でパッチを適用すると、ヒューマンエラー (1 つまたは複数のパッチの適用を忘れる、異なるバージョンを使用してパッチを適用する) が発生し、一貫性に影響が出る可能性があります。
- 更新時にパッチを適用する前にシステムのスナップショットを取得する必要がある場合や、パッチを適用するときに追加の設定変更が必要な場合に、複雑なパッチ適用シナリオのオーケストレーションが可能です。
3.2.2. パッチ適用の例
以下の Playbook は、パッチ適用の例として示しています。実稼働環境で使用する前に、ターゲット環境に合わせて変更し、十分にテストしてください。以下の例では、RHEL および dnf
パッケージマネージャーを使用するその他のオペレーティングシステム上のパッケージを管理するために ansible.builtin.dnf
モジュールを使用します。他の Linux オペレーティングシステム、Microsoft Windows、およびさまざまなネットワークデバイスにパッチを適用するためのモジュールも利用できます。
3.2.2.1. すべてを最新の状態に保つ
ラボやその他の非実稼働システムなど、一部の Red Hat Enterprise Linux サーバーでは、利用可能なすべてのパッチを定期的にインストールする必要がある場合があります。次の Playbook の例は、毎週実行するようにスケジュールされ、最新の RPM すべてを使用してシステムを更新するジョブテンプレートで使用できます。
- name: Install all available RPM updates hosts: target_hosts become: true tasks: - name: Install latest RPMs ansible.builtin.dnf: name: '*' state: latest
3.2.2.2. セキュリティー更新のみをインストールする
セキュリティーエラータを含むすべての RPM を最新の状態に保つことを要求するポリシーを採用している組織では、定期的に実行されるジョブテンプレートで次の Playbook を使用できます。
- name: Install all security-related RPM updates hosts: target_hosts become: true tasks: - name: Install latest RPMs with security errata ansible.builtin.dnf: name: '*' security: true state: latest
3.2.2.3. パッケージバージョンを指定する
実稼働システムについては、確立された設定管理プラクティスとして、システムを正しく設定して期待どおりに動作させるために、テスト済みの既知のソフトウェアの組み合わせだけをデプロイするというプラクティスがあります。これには、システムの更新によって運用アプリケーションに問題が発生しないように、既知のバージョンのオペレーティングシステムソフトウェアとパッチのみをデプロイすることも含まれます。
次のサンプル Playbook では、ターゲットホストが RHEL 9 オペレーティングシステムを使用する場合に、特定のバージョンの httpd
RPM とその依存関係をインストールします。指定したバージョンがすでに存在している場合、または別のバージョンの RHEL がインストールされている場合、この Playbook はアクションを実行しません。
- name: Install specific RPM versions hosts: target_hosts gather_facts: true become: true vars: httpd_packages_rhel9: - httpd-2.4.53-11.el9_2.5 - httpd-core-2.4.53-11.el9_2.5 - httpd-filesystem-2.4.53-11.el9_2.5 - httpd-tools-2.4.53-11.el9_2.5 - mod_http2-1.15.19-4.el9_2.4 - mod_lua-2.4.53-11.el9_2.5 tasks: - name: Install httpd and dependencies ansible.builtin.dnf: name: '{{ httpd_packages_rhel9 }}' state: present allow_downgrade: true when: - ansible_distribution == "RedHat" - ansible_distribution_major_version == "9"
allow_downgrade: true
を設定すると、定義されたパッケージの新しいバージョンがシステムにインストールされている場合、代わりに指定したバージョンにダウングレードされます。
3.2.3. 複雑なパッチ適用シナリオ
Ansible Automation Platform では、複数の自動化ジョブをワークフローに連結することができます。ワークフローは、複雑なパッチ適用シナリオで複数のステップを調整するために使用できます。
次の複雑なパッチ適用シナリオの例では、仮想マシンのスナップショットを取得し、仮想マシンにパッチを適用し、ワークフローでエラーが発生したときにチケットを作成する方法を示します。
- プロジェクトの同期を実行して、最新の Playbook が利用可能であることを確認します。並行して、インベントリー同期を実行し、ターゲットホストの最新リストが利用可能であることを確認します。
各ターゲットホストのスナップショットを取得します。
- スナップショットタスクが失敗した場合は、関連情報を記載したチケットを送信します。
各ターゲットホストにパッチを適用します。
- パッチ適用タスクが失敗した場合は、スナップショットを復元し、関連情報を記載したチケットを送信します。
- パッチ適用タスクが成功した各スナップショットを削除します。
次のワークフロー図は、複雑なパッチ適用シナリオの例のコンポーネントがどのように実行されるかを示しています。
関連情報
ワークフローの詳細は、Automation Controller のワークフロー を参照してください。