こんにちは。Red Hat ソリューションアーキテクトの清水です。RHEL7のELSも開始となり、RHELのライフサイクル管理の重要性に改めて認識された方も多いのではないでしょうか？さて、本ブログ記事では、RHELのパッチ適用をAnsibleとSatelliteを使って自動化する方法についてご紹介していきたいと思います。
実は、RHELのパッチ適用を含むライフサイクル管理と言うと、幾つかの製品が登場してきて使い方も様々ですので、ちょっとわかりにくかったりします。代表的な製品としては、以下のようなものが挙げられます。
- Red Hat Insights
- Red Hat Satellite
- Red Hat Ansible Automation Platform (AAP)
これらの組み合わせパターンとしては、大きく以下の4パターンあり、いずれもInsightsやSatelliteといった中央のマネジメントプレーンからパッチ適用をトリガーする、言わば「プッシュモデル」となります。
- Insgiths → RHEL
- Insights → Cloud Connector (Satellite) → RHEL
- Insights → AAP → RHEL
- Ansible in Satellite → RHEL
これから紹介していく方法は、上記の「プッシュモデル」とは異なり、Satelliteをリポジトリセットとして使い、RHELのパッチ適用を「プルモデル」で行い、関連する一連の作業を、例えば、事前のバックアップやパッチ適用後のテストなども含めて、AAPのワークフローによって自動化する、という方法になります。具体的なイメージがあった方が理解がしやすいと思いますので、以下のAWS上の環境を一例として説明をしていきたいと思います。
想定環境
ここでは、管理対象のRHELサーバとして、Development環境のmanaged-dev、そしてProduction環境のmanaged-prodの2台があります（通常の環境では、もっと多数のサーバがあると思いますが、話をシンプルにするためにそれぞれ1台という想定にしています）。それぞれRHEL9で稼働しており、アプリケーションとしてWordPressと、そのDBとしてMySQLが稼働しています。そして、これらのRHELサーバのパッチを管理する機能としてsatellite01、さらにAAPのControllerが稼働するaac01があります。
どのように動くのか？
Satellite
Satelliteでは、Organization（組織） という論理グループを作成することで、1つのSatelliteシステムで複数の組織を管理することができます。ここでは、My_Organizationという組織を1つ作成しています。さらに、Satelliteでは、アプリケーションのライフサイクルの各ステージに対応する ライフサイクル環境 というものを定義します。Libraryというのはスタートポイントとして必須になりますが、ここではDevelopmentやProductionという２つのライフサイクルを定義しています。これは、ユーザー環境によって自由に定義することができ、例えば、Dev/Staging/Productionや、もっと複雑なものも定義可能です。
そして、Satelliteには、コンテンツビュー というSatelliteが管理対象ホストに配信するもの全般を指す概念があります。具体的には、ソフトウェアパッケージ、RPMやDockerイメージが含まれます。
最初にこのコンテンツビューをLibraryに置くことをPublishと言います。まず、Ver1.0をLibraryにPublishするところから始まり、さらにこのVer1.0のコンテンツビューをDevelopment環境に置くことをPromoteと言います。つまり、次のライフサイクルのステージにPromote(昇進)させるもの、と考えると良いでしょう。
Development環境でテストされたコンテンツビューは、最終的にProduction環境にPromoteされます。ここでは、Ver1.0のコンテンツビューには、2023/7/31以前にリリースされた、Bugfix、Security Updates、Enhancementsが全て含まれます。この条件は、Content View Filtersと呼ばれ、もっと複雑な条件を設定することも可能です。上記の例では、Errataのタイプと公開日付でフィルターしていますが、RPM、Package Group、Container image tag、Module Streaｍなどでフィルターすることが可能です。
例えばこのコンテンツビューを月次で更新することを想定してみましょう。翌月になったら、2023/8/31までのBugfix、Security Updates、Enhancementsを含むVer2.0をPublishして、Development環境にPromoteします。同様に、その翌月になったら、9月末までのコンテンツビューとしてVer3.0をPublishするという流れになります。
ここでは、管理対象のRHELサーバは、このSatelliteのライフサイクルにマッピングされます。従って、Development環境のmanaged-devサーバは、Ver2.0の8月末までのコンテンツビューしか参照できないようになっており、またProduction環境のmanaged-prodサーバも同様にVer1.0の7月末までのコンテンツビューしか参照できないようになっています。さらに言えば、このVer1.0のコンテンツビューは、Development環境でテスト済みということになります。このようにそれぞれの管理対象サーバは、紐づいているライフサイクルのコンテンツビューを参照することで、限られたスコープのコンテンツビューでRHELのアップデート、つまりパッチ適用を「プルモデル」で行うことができるわけです。
例えば、Ver2.0(2023/8/31まで)のコンテンツビューを適用したサーバの適用可能なErrataを、Satelliteのコンソールから確認してみると、全て2023/9月以降のものになっていることがわかります。当該サーバでは、8月末までのErrataは全て適用済みということになります。
そして、この全体の流れを制御し、自動化するのがAnsible Automation Platform(AAP)です。
Ansible Automation Platform (AAP)
Ansible Automation Platform(AAP)では、Workflow Jobという形で自動化されたそれぞれのJobを、ワークフロー形式で実行することができます。
こちらは、Development環境におけるパッチ適用のワークフローの例です。
最初に、コンテンツビューをPublishして、Development環境にPromote、さらに管理対象VMであるmanaged-devサーバのバックアップを行い、Update Dev VMでパッチを適用します。その後、VMをリスタートして、インフラレベルのテストを行い、最後に稼働しているWordPressのアプリケーションレベルのテストを行って終了です。
| Job | やっていること |
|---|---|
Content View Publish |
構成したコンテンツビューの新バージョンをPublish |
Promote To Dev |
コンテンツビューをDevelopmentライフサイクル環境にPromote |
Backup Dev VM |
managed-vmのディスクのSnapshotを取得 |
Update Dev VM |
構成されたコンテンツビューに従い全てのパッケージをUpdate |
Restart Dev VM |
managed-vmをリスタート |
Test Dev VM |
再起動したmanaged-vmのインフラレベルのテスト |
Test Dev App |
再起動したmanaged-vmのアプリレベルのテスト |
ちなみに、Content View PublishやPromote To DevのJobでは、Satelliteの操作を行うため、Playbook内でredhat.satelliteのAnsible collectionを使って連携させることができます。
そして次に示すのは、Devlopement環境のパッチ適用後に流す、Production環境用のワークフローの例です。Development環境との相違点は、最初のところでコンテンツビューのPublishがなく、Development環境のパッチ適用がうまくいった前提でコンテンツビューをProductionにPromoteするところから始まる点で、それ以外のJobは同様の流れになっています。
まとめ
ここでは、RHELのパッチ適用に関する一連の作業を、AAPとSatelliteを使って自動化する方法を、AWS上のRHEL環境を例にしてご紹介しました。最初に挙げた通り、Satelliteを使ったRHELのパッチ適用については、他にも幾つかの方法があり、例えば、Satelliteから管理対象サーバの特定のErrataやパッケージを「プッシュモデル」でアップデートすることもできます。この「プッシュモデル」の方法は、「緊急パッチの適用」といった、どちらかと言うとセキュリティユースケースで使われる場合が多いようです。このあたりは、ユースケースに応じて適切な方法を見極めていく必要があります。いずれにせよ、RHELのパッチ適用の自動化については、やり方がわかってしまえば、実はそんなに難しいものでもありません。これを機に、RHELのライフサイクル管理を自動化することを考えてみてはいかがでしょうか。
ちなみに、ここで説明したサンプルは、以下のGithubリポジトリから取得して、簡単に再現することが可能です。興味を持たれた方は、ぜひCloneしてトライしてみてください。
