第3章 ブループリントとブループリントイメージを作成する
イメージブループリントとは、必要なイメージカスタマイズを永続的に定義したものです。これによって複数のビルドを作成できますが、イメージビルドごとにブループリントを設定する必要はありません。
ブループリントを編集、再構築、削除し、保存して、そこからイメージを再構築し続けることができます。ブループリントを編集または削除して定義および管理し、再構築し続けることで、毎回ビルドを設定する必要がなくなります。ブループリントを再構築すると、ブループリントで指定されたすべてのターゲットが再構築されます。ブループリントは、そこから構築されたイメージをグループ化するため、大量のイメージを処理するときに、関連するすべてのイメージにアクセスできるようになります。
ブループリントは永続的であり、カスタマイズを管理することができます。結果として得られるビルドや、それらのビルドからのイメージのコンテンツバージョンが異なる場合でも、そのブループリントに保存されているカスタマイズは、このブループリントから得られるすべてのビルドに常に適用されます。
ブループリントからイメージを作成する場合は、イメージに名前を定義しない限り、親ブループリントの名前が使用されます。
3.1. Red Hat Lightspeed イメージのパッケージモードとイメージモードについて理解する リンクのコピーリンクがクリップボードにコピーされました!
RHEL Lightspeed イメージビルダーを使用して、従来のパッケージモードまたはコンテナーネイティブイメージモードでイメージを作成できます。これら 2 つのモードの違いを理解することで、パブリッククラウドや仮想化プラットフォーム全体でオペレーティングシステムを管理、更新、展開する方法が決まります。
RHEL イメージをビルドする際、イメージタイプの選択によって、デプロイされたインスタンスのライフサイクルにおけるソフトウェアの配信および保守方法の基盤となるアーキテクチャーが決まります。
- パッケージモード (従来型)
パッケージモードでは、個々の RPM パッケージで設定される標準的な RHEL オペレーティングシステムが構築されます。
-
仕組み: イメージビルダーは依存関係を解決し、RPM パッケージをディスクイメージにインストールします。イメージをデプロイした後、
dnfなどのパッケージマネージャーを使用してシステムを管理できます。 - ライフサイクル: アップデートはパッケージごとに適用されます。これは、同じオリジナルイメージからデプロイした 2 つのシステムでも、異なるパッケージが更新されたり、設定ファイルが個別に変更されたりすることで、時間の経過とともに差異が生じる可能性があることを意味します。
-
仕組み: イメージビルダーは依存関係を解決し、RPM パッケージをディスクイメージにインストールします。イメージをデプロイした後、
- イメージモード (コンテナーネイティブ)
イメージモードでは、オペレーティングシステム全体を単一の不変のコンテナーイメージとして扱います。
-
仕組みとしては、ライブシステム上で個々の RPM を管理する代わりに、オペレーティングシステムは標準的な Open Container Initiative (OCI) コンテナーイメージとしてパッケージ化されます。これは
bootcテクノロジーを使用して、ベアメタル環境または仮想マシン上でコンテナーイメージを直接起動します。 - ライフサイクル: オペレーティングシステムは、コンテナーイメージの新しいバージョンをプルすることで、単一のユニットとしてアトミックに更新されます。アップデートが失敗した場合、システムは以前の安定版にロールバックし、設定のずれを解消します。
-
仕組みとしては、ライブシステム上で個々の RPM を管理する代わりに、オペレーティングシステムは標準的な Open Container Initiative (OCI) コンテナーイメージとしてパッケージ化されます。これは
| 機能 | パッケージモード | イメージモード |
|---|---|---|
| 管理ユニット |
個別の RPM パッケージ ( | オペレーティングシステム全体をコンテナーイメージ (OCI 形式) として保存 |
| 不変性 | 変更可能: パッケージを追加または削除できます (デプロイ後でも変更可能)。 | 不変: 読み取り専用のルートファイルシステム、再起動時に変更は消去されます |
| 更新メカニズム |
| コンテナータグをプルして切り替えることで、アトミックな更新を実現します。 |
| ドリフトリスク | システムは時間とともに分岐する可能性があるため、高い。 | ゼロ。なぜなら、同じタグを実行しているすべてのノードは同一だからである。 |
- 対象環境とデプロイメントユースケース
使用目的に応じて、両方のモードをさまざまなターゲット環境にコンパイルできます。それらをどこに、どのように配備するかを決定する際には、以下のガイドラインを参考にしてください。
パブリッククラウド:AWS、Google Cloud、Microsoft Azure
どちらのモードも主要なクラウドプロバイダーに直接提供できますが、運用上のユースケースは異なります。
- 従来のマルチテナントワークロード、標準ファイルシステムを前提とするレガシーエンタープライズソフトウェアをデプロイする場合、または起動後に標準ディレクトリーにコードを挿入する必要のあるサードパーティー製エージェントに依存する場合は、パッケージモードを使用してください。
- クラウドネイティブで自動スケーリングに対応したアプリケーションを構築する場合は、イメージモードを使用してください。このようなアプリケーションでは、インスタンスが迅速に起動され、同一状態を維持し、パッチを適用するのではなく置き換えられます。
仮想化 - ゲストイメージ (
.qcow2)プライベートクラウドや、QEMU、KVM、Red Hat OpenShift Virtualization、Nutanix などのハイパーバイザーには
、.qcow2形式を使用してください。- 社内 IT チームが Red Hat Satellite を使用して毎月パッチを適用する、社内仮想マシン用のゴールデンプライマリーイメージが必要な場合は、パッケージモードを使用してください。
- GitOps パイプラインを使用して仮想化インフラストラクチャーを管理する場合は、イメージモードを使用してください。CI/CD パイプラインを使用してオペレーティングシステムのコンテナーイメージを再構築し、ハイパーバイザーがプルできるようにプライベートレジストリーにプッシュします。
コンテナーインストーラー (
.isoファイル)ベアメタルデプロイメント、エッジコンピューティング、または非接続環境には、
.isoターゲット形式を使用してください。- パッケージモードを使用して、従来のネットワークインストールまたはキックスタートインストールをローカルディスクに実行します。これは、マシンが初日から永続的で独自にカスタマイズされた設定を必要とする場合です。
-
イメージモードを使用してエッジロケーションに展開します。コンテナーインストーラーの
.isoファイルは、最小限のブートローダーでハードウェアをプロビジョニングし、それがすぐに変更不可能なオペレーティングシステムコンテナーイメージに接続することで、ゼロタッチメンテナンスと信頼性の高いリモートロールバックを保証します。