こんにちは。Red Hat ソリューションアーキテクトの清水です。RHEL9からImage Mode for RHELという新しいオペレーティングシステムのデプロイメント方式が導入されていますが、皆さん触ってみたことはありますか？本ブログ記事では、このImage Mode for RHELを使った仮想マシン(VM)を、Ansibleを使ってデプロイからアップデートを自動化する方法についてご紹介してきたいと思います。
Image Mode for RHEL とは
最初に少しおさらいをしておきましょう。Image Mode for RHELは、元々bootcというプロジェクトに端を発しており、RHEL bootc イメージを使って、ブート可能なRHELのコンテナイメージをビルドし、デプロイすることが可能となります。さらに、デプロイしたオペレーティングシステムは、コンテナイメージを通じてアップデートすることも可能です。これにより、既存のコンテナネイティブのツールや手法を使って、アプリケーションから基盤となるオペレーティングシステムまで、全てを一貫してGitOpsで管理し、既存の継続的インテグレーション/継続的デリバリー(CI/CD)に組み込むことも可能となります。
bootc について書き出すとそれだけでシリーズものが出来そうなので、詳細については、公式ドキュメントを参照してみてください。
Image Mode for RHEL におけるワークフロー
前述の通り、Image Modeを使った場合、通常のアプリケーションコンテナと同様に、オペレーティングシステムをビルド、テスト、デプロイすることができます。こうした運用ワークフローは、最初にシステムとしてデプロイするまでのワークフロー (Day1 オペレーション) とデプロイしたシステムのアップデート (Day2 オペレーション) に大別できます。
デプロイまでのワークフロー (Day1 オペレーション)
先ず、registry.redhat.io/rhel9/rhel-bootc イメージをベースイメージとして、固有の設定やアプリケーションを追加し、コンテナイメージをビルドします。次に、ビルドしたコンテナイメージからコンテナを実行し、必要なテストを実行後、OKであればコンテナイメージをレジストリーにプッシュします。そして、コンテナイメージから仮想マシンまたはサーバーを実行するためのディスクイメージを作成します。ディスクイメージの形式は、QCOW2、AMI、VMDK、ISOなどがサポートされます。最終的には、作成したディスクイメージから、コンテナイメージを仮想マシンやベアメタルシステムにデプロイした後、必要なテストを実行します。
- Containerfile (Dockerfile) からコンテナイメージをビルド
- コンテナイメージのテスト
- コンテナイメージのレジストリーへのプッシュ
- コンテナイメージからベースディスクイメージの作成
- コンテナイメージのデプロイ
- システムのテスト
RHEL Bootc ベースイメージは、Red Hat Ecosystem Catalog から入手できます。
オペレーティングシステムのアップデート (Day2 オペレーション)
Day1 オペレーションのワークフローの実行は最初の一度きりですが、Day2 オペレーションは、コンテナイメージの変更の都度実行されることになります。それぞれのタスクは、Day1 オペレーションとほぼ同じですが、一つ大きな違いは、4．コンテナイメージの切り替えとシステムの再起動です。コンテナイメージはイミュータブルですので、一度デプロイされたオペレーティングシステムへの変更は、従来のようにdnf パッケージマネージャーを使いません。Image Modeでは、コンテナイメージを変更した上で、新しいオペレーティングシステムの更新をコンテナレジストリーから取得して、システムを再起動させることになります。
- Containerfile (Dockerfile) からコンテナイメージをビルド
- コンテナイメージのテスト
- コンテナイメージのレジストリへのプッシュ
- コンテナイメージの切り替えとシステムの再起動
- システムのテスト
それでは上記のワークフローを、例としてAWS上でAnsible Automation Platform(AAP)を活用して、自動化してみましょう。
想定環境
ここでは、AAPのControllerが稼働するaac01があり、コンテナのビルド用にbuilder01が稼働しています。Image Mode for RHELのVMはbootc01で、アプリケーションとしてhttpdが稼働します。また、イメージレジストリとしてquay.io、GitリポジトリとしてGitHubを想定します。
Ansible Automation Platform (AAP)
Ansible Automation Platform(AAP)では、Workflow Jobという形で自動化されたそれぞれのJobを、ワークフロー形式で実行することができます。
こちらは、Day1 オペレーションのワークフローの例です。
| Job | やっていること |
|---|---|
Build Bootc Image |
コンテナイメージのビルドとテスト、レジストリーへのプッシュ |
Deregister Bootc AMI |
Amazon EC2 AMIの登録解除 |
Create Bootc AMI |
bootc-image-builderを使ったコンテナイメージからAMIイメージの作成と登録 |
Deploy Bootc VM |
作成したAMIからAWSインスタンスのデプロイ |
Test Bootc App |
AWSインスタンス上のアプリケーション(httpd)のテスト |
そして次に示すのは、システムのアップデート用のいわゆるDay2 オペレーションのワークフローの例です。
| Job | やっていること |
|---|---|
Build Bootc Image |
コンテナイメージのビルドとテスト、レジストリーへのプッシュ |
Update Bootc VM |
bootcコマンドを使ったコンテナイメージへの参照の切り替えとインスタンスの再起動 |
Test Bootc App |
AWSインスタンス上のアプリケーション(httpd)のテスト |
Day2 オペレーションのワークフローについては、AAP上でGitHub Webhookの設定をすることで、GitHub上のContainerfileの変更をトリガーにワークフローを起動させ、GitOpsのアプローチを実現することができます。また、例示はしていませんが、テストが失敗した場合に即座に再度bootcコマンドを使い、コンテナイメージを切り替えてロールバックするようなJobを起動することも可能です。
まとめ
ここでは、Image Mode for RHELを使った仮想マシン(VM)を、Ansibleを使ってデプロイからアップデートを自動化する方法について、AWSの環境を例にしてご紹介しました。Image Modeについては、これまでのコンテナ化されたアプリケーションと同じように、GitOpsや継続的インテグレーション/継続的デリバリー(CI/CD)などのコンセプトを適用し、オペレーティングシステム全体を管理できるものとして各所で期待されています。例ではAnsibleを使いましたが、コンテナのビルド自体は様々な3rd Partyのサービスで実行してもよいですし、アプリケーションのビルドプロセスと統合することもできるかと思います。今回は、サーバーサイドのlong-lived processをImage Mode for RHELで動作させるアプリケーションとして例示しましたが、実は先日GAした Red Hat Enterprise Linux AI もImage Modeをベースとしています。今後ますますユースケースが増えそうなImage Modeを、皆さんも一度試してみてはいかがでしょうか？
ちなみに、ここで説明したサンプルは、以下のGithubリポジトリから取得して、簡単に再現することが可能です。興味を持たれた方は、ぜひCloneしてトライしてみてください。
