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 では、複数の自動化ジョブをワークフローに連結することができます。ワークフローは、複雑なパッチ適用シナリオで複数のステップを調整するために使用できます。

次の複雑なパッチ適用シナリオの例では、仮想マシンのスナップショットを取得し、仮想マシンにパッチを適用し、ワークフローでエラーが発生したときにチケットを作成する方法を示します。

  1. プロジェクトの同期を実行して、最新の Playbook が利用可能であることを確認します。並行して、インベントリー同期を実行し、ターゲットホストの最新リストが利用可能であることを確認します。
  2. 各ターゲットホストのスナップショットを取得します。

    1. スナップショットタスクが失敗した場合は、関連情報を記載したチケットを送信します。
  3. 各ターゲットホストにパッチを適用します。

    1. パッチ適用タスクが失敗した場合は、スナップショットを復元し、関連情報を記載したチケットを送信します。
  4. パッチ適用タスクが成功した各スナップショットを削除します。

次のワークフロー図は、複雑なパッチ適用シナリオの例のコンポーネントがどのように実行されるかを示しています。

Workflow representation

関連情報

ワークフローの詳細は、Automation Controller のワークフロー を参照してください。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.