Image Mode for RHEL を使用したオペレーティングシステムの構築、デプロイ、管理
Red Hat Enterprise Linux 9 での RHEL bootc イメージの使用
概要
Red Hat ドキュメントへのフィードバック (英語のみ) リンクのコピーリンクがクリップボードにコピーされました!
Red Hat ドキュメントに関するご意見やご感想をお寄せください。また、改善点があればお知らせください。
Jira からのフィードバック送信 (アカウントが必要)
- Jira の Web サイトにログインします。
- 上部のナビゲーションバーで Create をクリックします。
- Summary フィールドにわかりやすいタイトルを入力します。
- Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも追加してください。
- ダイアログの下部にある Create をクリックします。
第1章 Image Mode for RHEL の概要 リンクのコピーリンクがクリップボードにコピーされました!
Image Mode for RHEL を使用すると、アプリケーションコンテナーと同じツールと手法を使用して、オペレーティングシステムを構築、テスト、およびデプロイできます。Image Mode for RHEL は、registry.redhat.io/rhel9/rhel-bootc bootc イメージを使用することで利用できます。RHEL bootc イメージは、従来は除外されていた起動に必要な追加コンポーネント (カーネル、initrd、ブートローダー、ファームウェアなど) が含まれている点で、既存のアプリケーションの Universal Base Images (UBI) とは異なります。
rhel-bootc コンテナーイメージに基づく rhel-bootc およびユーザーが作成したコンテナーは、Red Hat Enterprise Linux エンドユーザーライセンス契約 (EULA) に従います。これらのイメージを公開して再配布することはできません。
Red Hat は、次のコンピューターアーキテクチャー用の bootc イメージを提供します。
- AMD および Intel 64 ビットアーキテクチャー (x86-64-v2)
- 64 ビット ARM アーキテクチャー (ARMv8.0-A)
- IBM Power Systems 64 ビットリトルエンディアンアーキテクチャー (ppc64le)
- IBM Z 64 ビットアーキテクチャー (s390x)
Bootc は、次のコンテナーイメージ形式とディスクイメージ形式をサポートします。
| イメージタイプ | ターゲット環境 |
|---|---|
|
| 物理環境、仮想化環境、クラウド環境、およびエッジ環境。 |
|
| Amazon Machine Image。 |
|
| QEMU (Red Hat OpenStack、Red Hat OpenStack services for OpenShift、OpenShift Virtualization などの環境を対象)、Libvirt (RHEL)。 |
|
| VMDK for vSphere。 |
|
| 最初に見つかったディスクにインストールする無人 Anaconda インストーラー。 |
|
| フォーマットされていない raw ディスク。QEMU および Libvirt でもサポートされる。 |
|
| 仮想 PC 用の VHD など。 |
|
| Google Compute Engine (GCE) 環境。 |
コンテナーは、以下の手段を提供することで、RHEL システムのライフサイクルを合理化します。
- コンテナーイメージのビルド
-
Containerfile を変更することで、ビルド時にオペレーティングシステムを設定できます。Image Mode for RHEL は、コンテナーイメージ
registry.redhat.io/rhel9/rhel-bootcを使用することで利用できます。Podman、OpenShift Container Platform、またはその他の標準のコンテナービルドツールを使用して、コンテナーとコンテナーイメージを管理できます。CI/CD パイプラインを使用してビルドプロセスを自動化できます。 - コンテナーイメージのバージョン管理、ミラーリング、テスト
- Podman や OpenShift Container Platform などのコンテナーツールを使用して、派生した bootc イメージのバージョン管理、ミラーリング、イントロスペクション、署名を行うことができます。
- コンテナーイメージのターゲット環境へのデプロイ
イメージをデプロイする方法はいくつか存在します。
- Anaconda: RHEL で使用されるインストールプログラムです。Anaconda とキックスタートを使用してインストールプロセスを自動化することで、すべてのイメージタイプをターゲット環境にデプロイできます。
-
bootc-image-builder: コンテナーイメージをさまざまな種類のディスクイメージに変換し、必要に応じてイメージレジストリーまたはオブジェクトストレージにアップロードする、コンテナー化されたツールです。 -
bootc: コンテナーレジストリーからコンテナーイメージを取得してシステムにインストールしたり、オペレーティングシステムを更新したり、既存の ostree ベースのシステムから切り替えたりするツールです。RHEL bootc イメージは、デフォルトでbootcユーティリティーを含んでおり、すべてのイメージタイプに対応しています。ただし、rpm-ostreeはサポートされていないため、変更を加えるために使用してはならないことに注意してください。
- オペレーティングシステムの更新
-
システムは、デプロイメント後にロールバックが可能なインプレーストランザクション更新をサポートします。自動更新はデフォルトでオンになっています。systemd サービスユニットと systemd タイマーユニットファイルがコンテナーレジストリーの更新をチェックし、システムに適用します。更新はトランザクショナルであるため、再起動が必要です。より高度なロールアウトやスケジュールされたロールアウトが必要な環境では、自動更新を無効にし、
bootcユーティリティーを使用してオペレーティングシステムを更新してください。
RHEL には 2 つのデプロイメントモードがあります。どちらも、デプロイメント時の安定性、信頼性、パフォーマンスは同様です。相違点を参照してください。
-
パッケージモード: RHEL Image Builder を使用してパッケージベースのイメージと OSTree イメージをビルドできます。
composer-cliまたは Web コンソールを使用してパッケージモードのイメージを管理できます。オペレーティングシステムは RPM パッケージを使用し、dnfパッケージマネージャーを使用して更新されます。ルートファイルシステムはミュータブルです。ただし、オペレーティングシステムをコンテナー化されたアプリケーションとして管理することはできません。RHEL システムイメージのカスタマイズ を参照してください。 -
イメージモード: RHEL をビルド、デプロイ、管理するためのコンテナーネイティブなアプローチです。同じ RPM パッケージがベースイメージとして配信され、更新はコンテナーイメージとしてデプロイされます。ルートファイルシステムは、
/etcと/varを除きデフォルトではイミュータブルであり、ほとんどのコンテンツはコンテナーイメージから取得されます。
イメージモード または パッケージモード のデプロイメントのいずれかを使用して、オペレーティングシステムを構築、テスト、および共有できます。また、イメージモード を使用すると、他のコンテナー化されたアプリケーションと同じ方法でオペレーティングシステムを管理できます。
1.1. RHEL のイメージモードの利点 リンクのコピーリンクがクリップボードにコピーされました!
Image Mode for RHEL の利点は、システムのライフサイクル全体にわたって得られます。次のリストには、いくつかの最も重要な利点が含まれます。
- コンテナーイメージは他のイメージ形式よりも簡単に理解して使用でき、ビルドが高速
- Containerfile (Dockerfile とも呼ばれます) は、イメージのコンテンツとビルド手順を定義する単純なアプローチを提供します。コンテナーイメージは、しばしば他のイメージ作成ツールよりもビルドとイテレートが非常に高速です。
- プロセス、インフラストラクチャー、リリースアーティファクトを統合
- アプリケーションをコンテナーとして配布すると、同じインフラストラクチャーとプロセスを使用して、基盤となるオペレーティングシステムを管理できます。
- イミュータブルな更新
-
Image Mode for RHEL では、コンテナー化されたアプリケーションがイミュータブルな方法で更新されるのと同様に、オペレーティングシステムもイミュータブルな方法で更新されます。
rpm-ostreeシステムを使用する場合と同じように、更新を起動し、必要に応じてロールバックできます。
rpm-ostree を使用して変更を加えたり、コンテンツをインストールしたりすることはサポートされていません。
- ハイブリッドクラウド環境間での移植性
- bootc イメージは、物理環境、仮想化環境、クラウド環境、エッジ環境全体で使用できます。
コンテナーはイメージをビルド、転送、実行するための基盤となります。ただし、これらの bootc イメージを、インストールメカニズムを使用してデプロイするか、ディスクイメージに変換した後は、システムがコンテナーとして実行されないことを理解することが重要です。
1.2. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- RHEL 9 システムをサブスクライブしている。詳細は、RHEL システム登録のスタートガイド ドキュメントを参照してください。
- コンテナーレジストリーがある。レジストリーをローカルに作成することも、Quay.io サービスで無料アカウントを作成することもできます。Quay.io アカウントを作成するには、Red Hat Quay.io ページを参照してください。
- 実稼働用または開発者サブスクリプションを持つ Red Hat アカウントがある。無料の開発者サブスクリプションは、Red Hat Enterprise Linux Overview ページで入手できます。
- registry.redhat.io に対して認証済みである。詳細は、Red Hat Container Registry Authentication 記事を参照してください。
第2章 RHEL bootc イメージのビルドとテスト リンクのコピーリンクがクリップボードにコピーされました!
Podman と Containerfile を使用して RHEL コンテナーイメージをビルドおよびテストし、複数の環境でブート可能な RHEL システムイメージを効率的に作成、カスタマイズ、共有できます。OpenShift Container Platform などの他のツールを使用することもできます。コンテナーを使用して RHEL システムを設定する例は、rhel-bootc-examples リポジトリーを参照してください。
2.1. Containerfile から bootc ベースのイメージをビルドおよび設定する リンクのコピーリンクがクリップボードにコピーされました!
Containerfile を使用すると、必要なツール、設定、アプリケーションを使用して独自の bootc ベースのイメージをビルドおよびカスタマイズできます。ほとんどの標準命令は機能しますが、イメージがシステムにインストールされるときに一部は無視されます。
図2.1 Containerfile からの指示を使用してイメージを構築し、コンテナーをテストし、イメージをレジストリーにプッシュして他のユーザーと共有する
一般的な Containerfile の構造は次のとおりです。
Containerfile および Dockerfile 内で使用できる利用可能なコマンドは同じです。
ただし、rhel-10-bootc イメージのシステムへのインストール時には、Containerfile 内の以下のコマンドは無視されます。
-
ENTRYPOINTおよびCMD(OCI:Entrypoint/Cmd): 代わりにCMD /sbin/initを設定できます。 -
ENV(OCI:Env):systemd設定を変更して、グローバルシステム環境を設定します。 -
EXPOSE(OCI:exposedPorts): ランタイム時にシステムのファイアウォールやネットワークがどのように機能するかとは無関係です。 -
USER(OCI:User): RHEL bootc 内の個々のサービスを、権限のないユーザーとして実行するように設定します。
rhel-10-bootc コンテナーイメージは OCI イメージ形式を再利用します。
-
rhel-10-bootcコンテナーイメージは、システムへのインストール時にはコンテナー設定セクション (Config) を無視します。 -
rhel-10-bootcコンテナーイメージは、podmanやdockerなどのコンテナーランタイムを使用してこのイメージを実行するときには、コンテナー設定セクション (Config) を無視しません。
2.2. コンテナーツールを使用した再現可能なコンテナーイメージのビルド リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Enterprise Linux (RHEL)は、Podman および Buildah を使用した再現可能なコンテナービルドをサポートするようになりました。これにより、時間の経過とともに一貫した入力によるイメージの変更が削減されました。この新機能は、イメージを更新するときにレジストリーからプルされるデータを減らします。これは、サプライチェーンのセキュリティー、信頼できるソフトウェアデプロイメント、および効果的なデバッグに不可欠です。RHEL コンテナーの再現可能なビルドにより、レジストリーストレージを削減し、小規模な更新ペイロードを作成し、イメージ層の一貫性を確保してダウンロードを高速化します。以前は、tarball の作成やコンテナーイメージサイズのエスカレートによる課題により、基盤となるデータが変更されていない場合でも、ストレージの負荷と不要なレイヤープルが増加し、rhel-bootc や RHEL AI などの環境での更新が高速化されていました。
2.3. コンテナーイメージのビルド リンクのコピーリンクがクリップボードにコピーされました!
Containerfile からの指示を使用してイメージを構築するには、podman build コマンドを使用します。
前提条件
-
container-toolsメタパッケージがインストールされている。
手順
Containerfileを作成します。cat Containerfile FROM registry.redhat.io/rhel9/rhel-bootc:latest RUN dnf -y install cloud-init && \ ln -s ../cloud-init.target /usr/lib/systemd/system/default.target.wants && \ ln -s ../cloud-init.target /usr/lib/systemd/system/default.target.wants && \ dnf clean all dnf clean all$ cat Containerfile FROM registry.redhat.io/rhel9/rhel-bootc:latest RUN dnf -y install cloud-init && \ ln -s ../cloud-init.target /usr/lib/systemd/system/default.target.wants && \ dnf clean allCopy to Clipboard Copied! Toggle word wrap Toggle overflow この
Containerfileの例では、cloud-initツールが追加されています。そのため、SSH 鍵を自動的に取得し、インフラストラクチャーからスクリプトを実行できるほか、インスタンスメタデータから設定とシークレットを収集することもできます。たとえば、このコンテナーイメージを、事前に生成した AWS または KVM ゲストシステムに使用できます。現在のディレクトリーの
Containerfileを使用して、<image>イメージをビルドします。podman build -t quay.io/<namespace>/<image>:<tag> .
$ podman build -t quay.io/<namespace>/<image>:<tag> .Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
すべてのイメージをリスト表示します。
podman images
$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/<image> latest b28cd00741b3 About a minute ago 2.1 GBCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4. マルチステージビルドによるカスタムブート可能イメージの利点 リンクのコピーリンクがクリップボードにコピーされました!
デプロイメントイメージには、ビルドツールや不要なライブラリーを追加せずに、アプリケーションと必要なランタイムのみを含める必要があります。これを実現するには、2 つのステージで構成される Containerfile を使用します。1 つのステージはアーティファクトをビルドするためのもので、もう 1 つのステージはアプリケーションをホストするためのものです。
マルチステージビルドでは、Containerfile で複数の FROM 命令を使用します。FROM 命令は、それぞれ異なるベースを使用でき、ビルドの新しいステージを開始します。あるステージから別のステージにアーティファクトを選択的にコピーし、最終イメージに必要のないものをすべて除外することができます。
マルチステージビルドにはいくつかの利点があります。
- イメージサイズの削減
- ビルド環境をランタイム環境から分離することで、最終イメージに必要なファイルと依存関係のみが含まれ、サイズが大幅に削減されます。
- セキュリティーの向上
- 最終イメージからビルドツールと不要なライブラリーが取り除かれるため、攻撃対象領域が縮小され、よりセキュアなコンテナーが実現します。
- パフォーマンスの最適化
- イメージサイズが削減されるため、ダウンロード、デプロイ、起動の時間が短縮し、コンテナー化されたアプリケーションの全体的な効率が向上します。
- メンテナンスの簡素化
- ビルド環境とランタイム環境が分離されるため、アプリケーションの実行に必要なものだけが最終イメージに取り込まれ、イメージがよりクリーンになり、保守が容易になります。
- よりクリーンなビルド
- マルチステージビルドによって、ビルドプロセス中に蓄積される中間ファイルによる混乱を回避し、重要なアーティファクトだけを最終イメージに取り込むことができます。
- リソース効率
- 1 つのステージでビルドし、不要な部分を破棄できるため、デプロイ時のストレージと帯域幅の使用が最小限に抑えられます。
- レイヤーキャッシュの改善
- ステージを明確に定義し、将来のビルドを高速化することにより、Podman が前のステージの結果を効率的にキャッシュできるようになります。
次の Containerfile は 2 つのステージで構成されています。最初のステージは、通常 builder と呼ばれ、golang バイナリーをコンパイルします。2 番目のステージでは、最初のステージからバイナリーをコピーします。go-toolset ビルダーのデフォルトの作業ディレクトリーは opt/ap-root/src です。
結果として、最終的なコンテナーイメージには helloworld バイナリーが含まれますが、前のステージのデータは含まれません。
また、マルチステージビルドを使用すると、次のシナリオを実行できます。
- 特定のビルドステージで停止する
- イメージをビルドするときに、指定したビルドステージで停止できます。以下に例を示します。
podman build --target build -t hello .
$ podman build --target build -t hello .
たとえば、この方法を使用して特定のビルドステージをデバッグできます。
- 外部のイメージをステージとして使用する
-
COPY --from命令を使用すると、ローカルイメージ名、ローカルまたはコンテナーレジストリーで使用可能なタグ、またはタグ ID を使用して、別のイメージからコピーできます。以下に例を示します。
COPY --from=<image> <source_path> <destination_path>
COPY --from=<image> <source_path> <destination_path>
- 前のステージを新しいステージとして使用する
-
FROM命令を使用すると、前のステージが終了したところから続行できます。以下に例を示します。
2.5. コンテナーイメージの実行 リンクのコピーリンクがクリップボードにコピーされました!
コンテナーを実行してテストするには、podman run コマンドを使用します。
前提条件
-
container-toolsメタパッケージがインストールされている。
手順
適切なオプションを指定した
podman runコマンドを使用してコンテナーを実行します。たとえば、quay.io/<namespace>/<image>:<tag>コンテナーイメージに基づいてmybootcという名前のコンテナーを実行するには、以下を実行します。podman run -it --rm --name mybootc quay.io/<namespace>/<image>:<tag> /bin/bash
$ podman run -it --rm --name mybootc quay.io/<namespace>/<image>:<tag> /bin/bashCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
-iオプションは対話式のセッションを作成します。-i オプションを指定しないと、シェルが開き、終了します。 -
-tオプションは、端末セッションを開きます。the-iオプションを指定しないと、開いたままになりますが、シェルには何も入力できません。 -
--rmオプションは、コンテナーの終了後にquay.io/<namespace>/<image>:<tag>コンテナーイメージを削除します。
-
検証
実行中のすべてのコンテナーをリスト表示します。
podman ps
$ podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 7ccd6001166e quay.io/<namespace>/<image>:<tag> /sbin/init 6 seconds ago Up 5 seconds ago mybootcCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.6. コンテナーイメージのレジストリーへのプッシュ リンクのコピーリンクがクリップボードにコピーされました!
イメージを独自のレジストリーまたはサードパーティーのレジストリーにプッシュして他のユーザーと共有するには、podman push コマンドを使用します。次の手順では、Red Hat Quay レジストリーを例として使用します。
前提条件
-
container-toolsメタパッケージがインストールされている。 - イメージがビルドされ、ローカルシステムで使用できる。
- Red Hat Quay レジストリーを作成した。詳細は、概念実証 - Red Hat Quay のデプロイ を参照してください。
手順
ローカルストレージからレジストリーに
quay.io/<namespace>/<image>:<tag>コンテナーイメージをプッシュします。podman push quay.io/<namespace>/<image>:<tag>
$ podman push quay.io/<namespace>/<image>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第3章 論理的にバインドされたイメージのビルドと管理 リンクのコピーリンクがクリップボードにコピーされました!
論理的にバインドされたイメージを使用すると、ベース bootc イメージのライフサイクルにバインドされたコンテナーイメージを扱うことができます。これにより、アプリケーションとオペレーティングシステムのさまざまな運用プロセスを組み合わせることができます。コンテナーアプリケーションイメージは、イメージファイルまたは同等のものとしてベースイメージから参照されます。したがって、システムインストール用の複数のコンテナーイメージを管理できます。
セキュリティーエージェントや監視ツールなど、ライフサイクルにバインドされたワークロードにコンテナーを使用できます。このようなワークロードは、bootc upgrade コマンドを使用してアップグレードすることもできます。
3.1. 論理的にバインドされたイメージの概要 リンクのコピーリンクがクリップボードにコピーされました!
論理的にバインドされたイメージを使用することで、コンテナーアプリケーションイメージをベース bootc システムイメージに関連付けることができます。デフォルトでは、podman などによって実行されるアプリケーションコンテナーには、ホストのアップグレードに依存しないライフサイクルがあります。これらのコンテナーはいつでも追加または削除でき、コンテナーイメージが存在しない場合は通常、起動後にオンデマンドで取得されます。
論理的にバインドされたイメージの主な利点は、この方法でバインドされたアプリケーションコンテナーのライフサイクルがホストのアップグレードと連動し、ホストが新しいオペレーティングシステムで再起動する 前に コンテナーが利用可能になる点です。このようにバインドされたコンテナーイメージは、bootc コンテナーが参照している限り存在します。
以下は、通常はホスト外部では更新されない、ライフサイクルにバインドされたワークロードの例です。
- ロギング (例: journald → リモートログフォワーダーコンテナー)
- 監視 (例: Prometheus node_exporter)
- 設定管理エージェント
- セキュリティーエージェント
このようなタイプのワークロードでは通常、ネットワークが利用可能になる前に、ブートプロセスの非常に早い段階からコンテナーを起動することが重要です。論理的にバインドされたイメージを使用すると、ベース bootc イメージ内のバイナリーの ExecStart= を使用するのと同じ信頼性でコンテナーを起動できます (多くの場合、systemd 経由)。
論理的にバインド という用語は、アプリケーションコンテナーのコンテンツが bootc コンテナーイメージに物理的に保存される、物理的にバインドされたイメージの別のモデルと対比されることもあります。物理的ではなく、論理的にバインドする利点として主に、変更なしのアプリケーションコンテナーイメージをダウンロードし直すことなく、bootc システムを更新できる点が挙げられます。
論理的にバインドされたイメージを使用する場合、システムが論理的にバインドされたイメージをインストールできるように、複数のコンテナーイメージを管理する必要があります。これは利点であると同時に欠点でもあります。たとえば、非接続インストールまたはオフラインインストールの場合は、1 つのコンテナーだけでなく、すべてのコンテナーをミラーリングする必要があります。アプリケーションイメージは、.image ファイルまたは同等のファイルとしてベースイメージからのみ参照されます。
- 論理的にバインドされたイメージのインストール
-
bootc installを実行するときに、論理的にバインドされたイメージがデフォルトの/var/lib/containersコンテナーストアに存在している必要があります。イメージはターゲットシステムにコピーされ、bootc ベースイメージとともに起動時に直接表示されます。 - 論理的にバインドされたイメージのライフサイクル
-
論理的にバインドされたイメージは、ブート可能なコンテナーによって参照され、bootc ベースのサーバーの起動時に可用性が保証されます。イメージは常に
bootc upgradeを使用してアップグレードされます。Podman などの他のプロセスでは、イメージをread-onlyとして使用できます。 - アップグレード、ロールバック、ガベージコレクションにおける論理的にバインドされたイメージの管理
- アップグレード中、論理的にバインドされたイメージは bootc によって排他的に管理されます。
- ロールバック中は、ロールバックデプロイメントに対応する論理的にバインドされたイメージが保持されます。
- bootc が、未使用のバインドされたイメージのガベージコレクションを実行します。
3.2. 論理的にバインドされたイメージの作成 リンクのコピーリンクがクリップボードにコピーされました!
論理的にバインドされたイメージは、Podman Quadlet の .image または .container ファイルを使用して作成できます。
前提条件
-
container-toolsメタパッケージがインストールされている。
手順
- 論理的にバインドするイメージを選択します。
Containerfileを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow .container定義で、以下を使用します。GlobalArgs=--storage-opt=additionalimagestore=/usr/lib/bootc/storage
GlobalArgs=--storage-opt=additionalimagestore=/usr/lib/bootc/storageCopy to Clipboard Copied! Toggle word wrap Toggle overflow この
Containerfileの例では、/usr/lib/bootc/bound-images.dディレクトリーに、.imageファイルまたは.containerファイルを参照するシンボリックリンクを作成することにより、論理的にバインドされるイメージが選択されます。bootc upgradeコマンドを実行します。bootc upgrade
$ bootc upgradeCopy to Clipboard Copied! Toggle word wrap Toggle overflow bootc upgrade では、次の主な手順が実行されます。
- イメージリポジトリーから新しいベースイメージを取得します。「コンテナープルシークレットの設定」を参照してください。
- 新しいベースイメージのルートファイルシステムを読み取り、論理的にバインドされたイメージを検出します。
-
新しい bootc イメージで定義されている、検出された論理的にバインドされたイメージを、bootc が所有する
/usr/lib/bootc/storageイメージストレージに自動的にプルします。
バインドされたイメージを Podman などのコンテナーランタイムで使用できるようにします。そのためには、バインドされたイメージが "追加のイメージストア" として bootc ストレージを参照するように明示的に設定する必要があります。以下に例を示します。
podman --storage-opt=additionalimagestore=/usr/lib/bootc/storage run <image>
podman --storage-opt=additionalimagestore=/usr/lib/bootc/storage run <image>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要/etc/containers/storage.confで/usr/lib/bootc/storageイメージストレージをグローバルに有効にしないでください。論理的にバインドされたイメージには bootc ストレージだけを使用してください。
bootc image store は bootc が所有します。論理的にバインドされたイメージは、/usr/lib/bootc/bound-images.d ディレクトリー内のファイルによって参照されなくなると、ガベージコレクションされます。
第4章 bootc-image-builder を使用した bootc 互換ベースディスクイメージの作成 リンクのコピーリンクがクリップボードにコピーされました!
テクノロジープレビューとして利用可能な bootc-image-builder は、bootc イメージからディスクイメージを作成するためのコンテナー化されたツールです。ビルドしたイメージを使用して、エッジ、サーバー、クラウドなどのさまざまな環境にディスクイメージをデプロイできます。
4.1. bootc-image-builder の Image Mode for RHEL の概要 リンクのコピーリンクがクリップボードにコピーされました!
bootc-image-builder ツールを使用すると、bootc イメージをさまざまなプラットフォームや形式のディスクイメージに変換できます。bootc イメージのディスクイメージへの変換は、bootc イメージのインストールと同じです。これらのディスクイメージは、ターゲット環境にデプロイした後、コンテナーレジストリーから直接更新できます。
以下のいずれかの方法を使用して、ベースイメージを構築できます。
- ローカルの RHEL システムを使用し、Podman ツールをインストールして、ローカルでイメージをビルドします。その後、イメージをプライベートレジストリーにプッシュできます。
- CI/CD パイプラインを使用します。RHEL ベースのシステムを使用してイメージをビルドし、プライベートレジストリーにプッシュする CI/CD パイプラインを作成します。
bootc-image-builder ツールは、次のイメージタイプの生成をサポートしています。
- 非接続インストールに適したディスクイメージ形式 (ISO など)
以下のような仮想ディスクイメージ形式:
- QEMU copy-on-write (QCOW2)
- Amazon Machine Image (AMI)
- 未フォーマットの raw ディスク (Raw)
- 仮想マシンイメージ (VMI)
bootc-image-builder は、デフォルトでローカルコンテナーストレージを使用します。このツールは、リモートレジストリーからコンテナーイメージをプルできません。ディスクイメージをビルドするには、システムのローカルコンテナーレジストリーでベースの bootc コンテナーイメージを利用可能にして、システムのコンテナーストレージを bootc-image-builder コンテナーにマウントし、システムストレージからのコンテナーを使用できるようにする必要があります。
コンテナーイメージからデプロイすると同じインストール結果を得られるため、仮想マシンまたはサーバーを実行するときに便利です。同じコンテナーイメージからビルドする場合、当該一貫性は複数の異なるイメージタイプとプラットフォームにわたって保持されます。その結果、プラットフォーム間でオペレーティングシステムイメージを維持するための労力を最小限に抑えることができます。また、bootc-image-builder を使用して新しいディスクイメージを再作成およびアップロードする代わりに、bootc ツールを使用して、これらのディスクイメージからデプロイしたシステムを更新することもできます。
rhel-9-bootc イメージを直接デプロイすることもできますが、この bootc イメージから派生した独自のカスタムイメージを作成することもできます。bootc-image-builder ツールは、rhel-9-bootc OCI コンテナーイメージを入力として受け取ります。
汎用ベースコンテナーイメージには、デフォルトのパスワードや SSH 鍵は含まれません。また、bootc-image-builder ツールを使用して作成したディスクイメージには、cloud-init などの一般的なディスクイメージで使用できるツールは含まれません。そのようなディスクイメージは、変換されたコンテナーイメージだけです。
4.2. bootc-image-builder のインストール リンクのコピーリンクがクリップボードにコピーされました!
bootc-image-builder はコンテナーとしての使用が意図されており、RHEL で RPM パッケージとして利用することはできません。アクセスするには、以下の手順に従います。
前提条件
-
container-toolsメタパッケージがインストールされている。メタパッケージには、Podman、Buildah、Skopeo などのすべてのコンテナーツールが含まれます。 -
registry.redhat.ioに対して認証されている。詳細は、Red Hat コンテナーレジストリーの認証 を参照してください。
手順
ログインして、
registry.redhat.ioに対する認証を行います。sudo podman login registry.redhat.io
$ sudo podman login registry.redhat.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow bootc-image-builderツールをインストールします。sudo podman pull registry.redhat.io/rhel9/bootc-image-builder
$ sudo podman pull registry.redhat.io/rhel9/bootc-image-builderCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
ローカルシステムにプルしたすべてのイメージをリスト表示します。
sudo podman images
$ sudo podman images REPOSITORY TAG IMAGE ID CREATED SIZE registry.redhat.io/rhel9/bootc-image-builder latest b361f3e845ea 24 hours ago 676 MBCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3. 設定ファイルでサポートされているイメージのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
TOML または JSON 形式のビルド設定ファイルを使用して、作成するディスクイメージにカスタマイズを追加できます。
コンテナー内のディレクトリーでは、設定ファイルが /config.toml にマッピングされます。カスタマイズオブジェクトにより、イメージの変更を定義します。また、ビルド設定ファイルを config.json または config.toml として /usr/lib/bootc-image-builder ディレクトリーに埋め込むこともできます。デフォルトでは、システムはこのディレクトリーにあるファイルシステムまたはディスクのカスタマイズを自動的に使用します。別のカスタマイズを明示的に指定すると、この動作をオーバーライドできます。
JSON 形式の場合、--config 引数を使用するときに stdin を使用して設定を渡すこともできます。
- ユーザーのカスタマイズ
ディスクイメージにユーザーを追加し、必要に応じて SSH 鍵を設定します。このセクションのフィールドは、
nameを除いてすべてオプションです。Expand TOML JSON [[customizations.user]] name = "user" password = "password" key = "ssh-rsa AAA ... user@email.com" groups = ["wheel"]
[[customizations.user]] name = "user" password = "password" key = "ssh-rsa AAA ... user@email.com" groups = ["wheel"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow - カーネルの設定
設定ファイルでカーネルブートパラメーターをカスタマイズできます。
Expand TOML JSON [customizations.kernel] name = "kernel-debug" append = "nosmt=force"
[customizations.kernel] name = "kernel-debug" append = "nosmt=force"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow - ファイルシステムの設定
カスタマイズのファイルシステムセクションを使用して、
/や/bootなどのベースパーティションの最小サイズを設定したり、/varの下にマウントポイントを持つ追加のパーティションを作成したりできます。Expand TOML JSON Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow - ファイルシステムタイプと rootfs の相互作用
ルートファイルシステムタイプ (
--rootfs) 引数は、ソースコンテナーのデフォルト値をオーバーライドします。また、ext4、xfs、およびbtrfsタイプのすべての追加マウントポイントのファイルシステムタイプも設定します。サポートされているマウントポイントとサイズには、
rootfsがbtrfsでない限り、次の制限とルールが適用されます。-
/を指定すると、ルートファイルシステムの最小サイズを設定できます。起動したシステムの/sysrootにマウントされるファイルシステムの最終的なサイズは、この設定で指定した値、またはベースコンテナーのサイズを 2 倍にした値のうち、どちらか大きい方になります。 -
/bootを指定すると、ブートパーティションの最小サイズを設定できます。/varのサブディレクトリーも指定できますが、/var内のシンボリックリンクは指定できません。たとえば、/var/homeと/var/runはシンボリックリンクであり、それ自体ではファイルシステムにはなりません。 -
/var自体はマウントポイントにはなりません。rootfsオプションは、ルートファイルシステムのファイルシステムタイプを定義します。 -
現在、ビルド時に
btrfsサブボリュームを作成することはサポートされていません。したがって、rootfsがbtrfsの場合、/var配下にカスタムマウントポイントを作成することはサポートされていません。/と/bootのみを設定できます。
-
- Anaconda ISO (インストーラー) の設定オプション
任意のインストールコマンドを含むキックスタートファイルを作成します。その後、ISO ビルドにキックスタートファイルを追加して、フルカスタマイズおよび自動化されたインストールメディアを作成します。
注記[customizations.user]と[customizations.installer.kickstart]を組み合わせたカスタマイズはサポートされていません。キックスタートを追加するときは、TOML形式の設定ファイルを使用してください。複数行の文字列ではエラーが発生しやすいためです。Expand TOML JSON Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow 警告bootc-image-builderは、システムがコンテナーイメージに自動的に追加するコマンド以外に、キックスタートコマンドを追加することはありません。詳細は、キックスタートファイルの作成 を参照してください。
4.4. bootc-image-builder を使用した QCOW2 イメージの作成 リンクのコピーリンクがクリップボードにコピーされました!
RHEL bootc イメージを、コマンドを実行しているアーキテクチャー用の QEMU (QCOW2) イメージにビルドします。
RHEL ベースイメージにはデフォルトのユーザーは含まれません。必要に応じて、--config オプションを使用してユーザー設定を注入し、bootc-image-builder コンテナーを実行できます。または、cloud-init を使用してベースイメージを設定し、初回起動時にユーザーと SSH 鍵を注入することもできます。ユーザーとグループの設定 - cloud-init を使用したユーザーと SSH 鍵の注入 を参照してください。
前提条件
- ホストマシンに Podman がインストールされている。
-
ホストマシンに
virt-installがインストールされている。 -
bootc-image-builderツールを実行し、コンテナーを--privilegedモードで実行して、イメージをビルドするための root アクセスがある。
手順
オプション: ユーザーアクセスを設定するための
config.tomlを作成します。次に例を示します。[[customizations.user]] name = "user" password = "pass" key = "ssh-rsa AAA ... user@email.com" groups = ["wheel"]
[[customizations.user]] name = "user" password = "pass" key = "ssh-rsa AAA ... user@email.com" groups = ["wheel"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow bootc-image-builderを実行します。必要に応じて、ユーザーアクセス設定を使用する場合は、config.tomlを引数として渡します。注記コンテナーストレージマウントがない場合は、イメージがパブリックである必要があります。
- 以下は、パブリック QCOW2 イメージを作成する例です。
次の例では、パブリックな QCOW2 イメージを作成します。このイメージは、
registry.redhat.io/rhel10/bootc-image-builder:latestなどのレジストリーからアクセスできる必要があります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 以下は、プライベート QCOW2 イメージを作成する例です。
この例では、ローカルコンテナーからプライベートな QCOW2 イメージを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow .qcow2イメージは出力フォルダーにあります。
4.5. bootc-image-builder を使用した VMDK イメージの作成 リンクのコピーリンクがクリップボードにコピーされました!
bootc イメージから仮想マシンディスク (VMDK) を作成し、それを vSphere などの VMware の仮想化プラットフォーム内か、Oracle VirtualBox で使用します。
前提条件
- ホストマシンに Podman がインストールされている。
-
podman login registry.redhat.io使用して Red Hat Registry に認証した。 -
rhel10/bootc-image-builderコンテナーイメージをプルした。
手順
次の内容の
Containerfileを作成します。FROM registry.redhat.io/rhel10/rhel-bootc:latest RUN dnf -y install cloud-init open-vm-tools && \ ln -s ../cloud-init.target /usr/lib/systemd/system/default.target.wants && \ rm -rf /var/{cache,log} /var/lib/{dnf,rhsm} && \ systemctl enable vmtoolsd.serviceFROM registry.redhat.io/rhel10/rhel-bootc:latest RUN dnf -y install cloud-init open-vm-tools && \ ln -s ../cloud-init.target /usr/lib/systemd/system/default.target.wants && \ rm -rf /var/{cache,log} /var/lib/{dnf,rhsm} && \ systemctl enable vmtoolsd.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow bootc イメージをビルドします。
podman build . -t localhost/rhel-bootc-vmdk
# podman build . -t localhost/rhel-bootc-vmdkCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 以前に作成した bootc イメージから VMDK ファイルを作成します。
以前に作成した bootc イメージから VMDK ファイルを作成します。このイメージは、
registry.redhat.io/rhel10/bootc-image-builder:latestなどのレジストリーからアクセスできる必要があります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow bootc イメージの VMDK ディスクファイルは、
output/vmdkディレクトリーに保存されます。
4.6. bootc-image-builder を使用した GCE イメージの作成 リンクのコピーリンクがクリップボードにコピーされました!
RHEL bootc イメージを、コマンドを実行しているアーキテクチャー用の GCE イメージにビルドします。RHEL ベースイメージにはデフォルトのユーザーは含まれません。必要に応じて、--config オプションを使用してユーザー設定を注入し、bootc-image-builder コンテナーを実行できます。または、cloud-init を使用してベースイメージを設定し、初回起動時にユーザーと SSH 鍵を注入することもできます。ユーザーとグループの設定 - cloud-init を使用したユーザーと SSH 鍵の注入 を参照してください。
前提条件
- ホストマシンに Podman がインストールされている。
-
bootc-image-builderツールを実行し、コンテナーを--privilegedモードで実行して、イメージをビルドするための root アクセスがある。
手順
オプション: ユーザーアクセスを設定するための
config.tomlを作成します。次に例を示します。[[customizations.user]] name = "user" password = "pass" key = "ssh-rsa AAA ... user@email.com" groups = ["wheel"]
[[customizations.user]] name = "user" password = "pass" key = "ssh-rsa AAA ... user@email.com" groups = ["wheel"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow bootc-image-builderを実行します。必要に応じて、ユーザーアクセス設定を使用する場合は、config.tomlを引数として渡します。注記コンテナーストレージマウントがない場合は、イメージがパブリックである必要があります。
bootc-image-builderを実行します。必要に応じて、ユーザーアクセス設定を使用する場合は、config.tomlを引数として渡します。このイメージは、registry.redhat.io/rhel10/bootc-image-builder:latestなどのレジストリーからアクセスできる必要があります。以下は
gceイメージを作成する例です。Copy to Clipboard Copied! Toggle word wrap Toggle overflow gceイメージは出力フォルダーにあります。
4.7. bootc-image-builder を使用した AMI イメージの作成および AWS へのアップロード リンクのコピーリンクがクリップボードにコピーされました!
bootc イメージから Amazon Machine Image (AMI) を作成し、それを使用して Amazon Web Services (AWS) Amazon Elastic Compute Cloud (EC2) インスタンスを起動します。
前提条件
- ホストマシンに Podman がインストールされている。
-
AWS アカウント内に既存の
AWS S3バケットがある。 -
bootc-image-builderツールを実行し、コンテナーを--privilegedモードで実行して、イメージをビルドするための root アクセスがある。 -
AMI を AWS アカウントにインポートするために、アカウントに
vmimportサービスロールが設定されている。
手順
bootc イメージからディスクイメージを作成します。
- Containerfile でユーザーの詳細を設定します。必ず sudo アクセスを割り当ててください。
- Containerfile で設定したユーザーを使用して、カスタマイズされたオペレーティングシステムイメージをビルドします。これにより、パスワードなしの sudo アクセスを持つデフォルトのユーザーが作成されます。
オプション:
cloud-initを使用してマシンイメージを設定します。ユーザーとグループの設定 - cloud-init を使用したユーザーと SSH 鍵の注入 を参照してください。以下に例を示します。FROM registry.redhat.io/rhel10/rhel-bootc:latest RUN dnf -y install cloud-init && \ ln -s ../cloud-init.target /usr/lib/systemd/system/default.target.wants && \ rm -rf /var/{cache,log} /var/lib/{dnf,rhsm}FROM registry.redhat.io/rhel10/rhel-bootc:latest RUN dnf -y install cloud-init && \ ln -s ../cloud-init.target /usr/lib/systemd/system/default.target.wants && \ rm -rf /var/{cache,log} /var/lib/{dnf,rhsm}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記cloud-initにより、インスタンスメタデータを使用してユーザーや設定を追加することもできます。bootc イメージをビルドします。たとえば、イメージを
x86_64AWS マシンにデプロイするには、次のコマンドを使用します。podman build -t quay.io/<namespace>/<image>:<tag> . podman push quay.io/<namespace>/<image>:<tag> .
$ podman build -t quay.io/<namespace>/<image>:<tag> . $ podman push quay.io/<namespace>/<image>:<tag> .Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
bootc-image-builderツールを使用して、bootc コンテナーイメージから AMI を作成します。 bootc-image-builderツールを使用して、bootc コンテナーイメージからパブリックな AMI イメージを作成します。このイメージは、registry.redhat.io/rhel10/bootc-image-builder:latestなどのレジストリーからアクセスできる必要があります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記以下のフラグはすべてまとめて指定する必要があります。フラグを指定しない場合、AMI は出力ディレクトリーにエクスポートされます。
-
--aws-ami-name- AWS の AMI イメージの名前 -
--aws-bucket- AMI を作成する際の中間ストレージのターゲット S3 バケット名 --aws-region- AWS アップロードのターゲットリージョンbootc-image-builderツールは AMI イメージをビルドし、ビルド後に AWS 認証情報を使用して AMI イメージをプッシュおよび登録することで、AWS s3 バケットにアップロードします。bootc-image-builderツールは、AMI イメージをビルドし、ビルド後に AWS 認証情報を使用して AMI イメージをプッシュおよび登録することで、AWS S3 bucketにアップロードします。
-
次のステップ
- イメージをデプロイできます。AMI ディスクイメージを使用したコンテナーイメージの AWS へのデプロイ を参照してください。
イメージを更新し、変更をレジストリーにプッシュできます。RHEL bootc イメージの管理 を参照してください。
- AWS イメージの要件の設定に問題がある場合は、次のドキュメントを参照してください。
- AWS IAM account manager
- Using high-level (s3) commands with the AWS CLI
- S3 buckets
- Regions and Zones
- カスタマイズした RHEL イメージの AWS での起動
- カスタマイズした RHEL イメージの AWS での起動
ユーザー、グループ、SSH 鍵、シークレットの詳細は、Image Mode for RHEL でのユーザー、グループ、SSH 鍵、シークレットの管理 を参照してください。ユーザー、グループ、SSH 鍵、シークレットの詳細は、Image Mode for RHEL でのユーザー、グループ、SSH 鍵、シークレットの管理 を参照してください。
4.8. bootc-image-builder を使用した raw ディスクイメージの作成 リンクのコピーリンクがクリップボードにコピーされました!
bootc-image-builder を使用すると、bootc イメージを MBR または GPT パーティションテーブルを持つ raw イメージに変換できます。
RHEL ベースイメージにはデフォルトのユーザーは含まれません。そのため、必要に応じて --config オプションを使用してユーザー設定を注入し、bootc-image-builder コンテナーを実行することもできます。または、cloud-init を使用してベースイメージを設定し、初回起動時にユーザーと SSH 鍵を注入することもできます。ユーザーとグループの設定 - cloud-init を使用したユーザーと SSH 鍵の注入 を参照してください。
前提条件
- ホストマシンに Podman がインストールされている。
-
bootc-image-builderツールを実行し、コンテナーを--privilegedモードで実行して、イメージをビルドするための root アクセスがある。 - コンテナーストレージにターゲットコンテナーイメージをプルした。
手順
オプション: ユーザーアクセスを設定するための
config.tomlを作成します。次に例を示します。[[customizations.user]] name = "user" password = "pass" key = "ssh-rsa AAA ... user@email.com" groups = ["wheel"]
[[customizations.user]] name = "user" password = "pass" key = "ssh-rsa AAA ... user@email.com" groups = ["wheel"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
bootc-image-builderを実行します。ユーザーアクセス設定を使用する場合は、config.tomlを引数として渡します。 bootc-image-builderを実行します。ユーザーアクセス設定を使用する場合は、config.tomlを引数として渡します。このイメージは、registry.redhat.io/rhel10/bootc-image-builder:latestなどのレジストリーからアクセスできる必要があります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow .rawイメージは出力フォルダーにあります。
4.9. bootc-image-builder を使用した ISO イメージの作成 リンクのコピーリンクがクリップボードにコピーされました!
bootc-image-builder を使用して ISO を作成し、この ISO からブート可能なコンテナーをオフラインでデプロイできます。
前提条件
- ホストマシンに Podman がインストールされている。
- ホストシステムがサブスクライブされているか、またはバインドマウントを使用してリポジトリー設定を注入して、イメージビルドプロセスが RPM を取得できるようにする。
-
bootc-image-builderツールを実行し、コンテナーを--privilegedモードで実行して、イメージをビルドするための root アクセスがある。
手順
オプション: 自動インストールを実行するデフォルトの埋め込みキックスタートをオーバーライドする
config.tomlを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
bootc-image-builderを実行します。設定を追加しない場合は、-v $(pwd)/config.toml:/config.toml引数を省略します。 bootc-image-builderを実行してパブリックな ISO イメージを作成します。設定を追加しない場合は、-v $(pwd)/config.toml:/config.toml引数を省略します。このイメージは、registry.redhat.io/rhel10/bootc-image-builder:latestなどのレジストリーからアクセスできる必要があります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow .isoイメージは出力フォルダーにあります。
次のステップ
ISO イメージは、USB スティックや Install-on-boot などの無人インストール方法で使用できます。インストール可能なブート ISO には、設定済みのキックスタートファイルが含まれます。Anaconda とキックスタートを使用してコンテナーイメージをデプロイする を参照してください。
警告キックスタートはシステム上の最初のディスクを自動的に再フォーマットするように設定されています。そのため、既存のオペレーティングシステムまたはデータを有するマシンで ISO を起動すると、破壊的な結果を招く可能性があります。
- イメージを更新し、変更をレジストリーにプッシュできます。RHEL ブート可能イメージの管理 を参照してください。
4.10. bootc-image-builder を使用したキックスタートファイルを含む ISO イメージのビルド リンクのコピーリンクがクリップボードにコピーされました!
キックスタートファイルを使用すると、ユーザーの設定、パーティションのカスタマイズ、SSH キーの追加など、インストールプロセスのさまざまな部分を設定できます。ISO ビルドにキックスタートファイルを含めることで、ベースイメージのデプロイメントを除くインストールプロセスの任意の部分を設定できます。bootc コンテナーベースイメージを含む ISO の場合、キックスタートファイルを使用して、ostreecontainer コマンド以外のすべての設定を行うことができます。
たとえば、キックスタートを使用して、部分的なインストールやフルインストールを実行できます。ユーザーの作成を省略することもできます。bootc-image-builder を使用して、インストールプロセスを設定するためのカスタムキックスタートを含む ISO イメージをビルドします。
前提条件
- ホストマシンに Podman がインストールされている。
-
bootc-image-builderツールを実行し、コンテナーを--privilegedモードで実行して、イメージをビルドするための root アクセスがある。
手順
キックスタートファイルを作成します。次のキックスタートファイルは、ユーザーの作成とパーティションの指示を含む、完全に自動のキックスタートファイル設定の例です。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
キックスタートコンテンツを注入するために、キックスタート設定を
toml形式で保存します。たとえば、config.tomlです。 bootc-image-builderを実行し、ISO ビルドに追加するキックスタートファイル設定を含めます。bootc-image-builderによって、コンテナーイメージをインストールするostreecontainerコマンドが自動的に追加されます。注記コンテナーストレージマウントおよび
--localイメージオプションがない場合は、イメージをパブリックにする必要があります。以下はパブリック ISO イメージを作成する例です。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下はプライベート ISO イメージを作成する例です。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow .isoイメージは出力フォルダーにあります。
4.11. 検証とトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
- AWS イメージの要件の設定に問題がある場合は、次のドキュメントを参照してください。
- ユーザー、グループ、SSH キー、シークレットの詳細は、以下を参照してください。
第5章 高度なパーティションを使用した RHEL イメージモードのディスクイメージのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
以下の方法を使用して高度なパーティションをカスタマイズし、RHEL システムをコンテナーイメージとして構築およびデプロイする際にディスクおよびファイルシステムのレイアウトを細かく制御できます。
- ディスクのカスタマイズ
- ファイルシステムのカスタマイズ
ただし、この 2 つのカスタマイズは互いに互換性がありません。カスタム RHEL システムイメージの仕様および設定を定義する TOML 形式のテキストファイルである同じブループリントで両方のカスタマイズを使用することはできません。
5.1. パーティションについて リンクのコピーリンクがクリップボードにコピーされました!
パーティションに関する一般的な原則を以下に示します。
- ディスクイメージ全体のサイズは、ヘッダーとメタデータの要件により、常にパーティションの合計サイズよりも大きくなります。したがって、特定のファイルシステム、パーティション、論理ボリューム、イメージ自体などを問わず、サイズはすべて最小要件として扱われます。
- パーティションが自動的に追加されると、ルートファイルシステムを含むパーティションが、常にパーティションテーブルレイアウトの最後に配置されます。これは、プレーン形式でフォーマットされたパーティション、LVM ボリュームグループ、または Btrfs パーティションで有効です。ディスクのカスタマイズでは、ユーザーが定義した順序が適用されます。
-
raw パーティションを設定する場合、つまり LVM を使用しない場合、ルートファイルシステムを含むパーティションが、パーティションテーブル上の残りの領域を埋めるために拡張されます。論理ボリュームがボリュームグループ内の領域を埋めるために拡張されることはありません。論理ボリュームはライブシステム上で簡単に拡張できるためです。一部のディレクトリーには、オーバーライドできないハードコードされた最小サイズがあります。
/の場合は 1 GiB、/usrの場合は 2 GiB です。そのため、/usrが別のパーティションにない場合、ルートファイルシステムのサイズは少なくとも 3 GiB になります。
5.2. RHEL イメージモードでのディスクのカスタマイズの利点 リンクのコピーリンクがクリップボードにコピーされました!
ディスクのカスタマイズにより、イメージのパーティションレイアウト全体を制御するより強力なインターフェイスが提供されます。
- 許可されているマウントポイント
bootc-image-builderを使用する場合、カスタマイズできるのは次のディレクトリーだけです。-
/(ルート) ディレクトリー。 -
/varの下のカスタムディレクトリー (/var自体ではありません)。
-
- 許可されていないマウントポイント
/varの下にある次のマウントポイントはカスタマイズできません。-
/var/home -
/var/lock -
/var/mail -
/var/mnt -
/var/roothome -
/var/run -
/var/srv -
/var/usrlocal
-
5.3. ブループリントのディスクのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
ディスクのカスタマイズを使用すると、ブループリントでパーティションテーブルをほぼ完全に定義できます。カスタマイズの構造は次のとおりです。
パーティション: 最上位レベルはパーティションのリストです。
type: 各パーティションにはタイプがあります。タイプはplainまたはlvmのいずれかです。タイプが設定されていない場合は、デフォルトでplainになります。パーティションのその他の必須および任意のプロパティーは、タイプによって異なります。plain: プレーンパーティションは、ファイルシステムを持つパーティションです。次のプロパティーがサポートされています。-
fs_type: ファイルシステムのタイプ。xfs、ext4、vfat、またはswapのいずれかです。swapに設定すると、スワップパーティションが作成されます。スワップパーティションの場合、マウントポイントが空である必要があります。 -
minsize: パーティションの最小サイズ。整数 (バイト単位) またはデータ単位付きの文字列 (例: 3 GiB) で指定します。特定のマウントポイントでは、イメージ内のパーティションの最終的なサイズがより大きくなる場合があります。パーティションについて セクションを参照してください。 -
mountpoint: ファイルシステムのマウントポイント。スワップパーティションの場合、これは空である必要があります。 -
label: ファイルシステムのラベル (任意)。
-
lvm: lvm パーティションは、LVM ボリュームグループを持つパーティションです。単一の永続ボリュームグループのみがサポートされています。次のプロパティーがサポートされています。-
name: ボリュームグループの名前(任意。設定されていない場合、システムは自動的に名前を生成します)。 -
minsize: ボリュームグループの最小サイズ。整数 (バイト単位) またはデータ単位付きの文字列 (例: 3 GiB) で指定します。この値が、イメージに含まれる論理ボリュームの合計よりも小さい場合、イメージ内のパーティションとボリュームグループの最終的なサイズがより大きくなる場合があります。 logical_volumes: ボリュームグループの 1 つ以上の論理ボリューム。各ボリュームグループは次のプロパティーをサポートしています。-
name: 論理ボリュームの名前 (任意。設定されていない場合は、マウントポイントに基づいて名前が自動的に生成されます)。 -
minsize: 論理ボリュームの最小サイズ。整数 (バイト単位) またはデータ単位付きの文字列 (例: 3 GiB) で指定します。特定のマウントポイントでは、イメージ内の論理ボリュームの最終的なサイズがより大きくなる場合があります。 -
label: ファイルシステムのラベル (任意)。 -
fs_type: ファイルシステムのタイプ。xfs、ext4、vfat、またはswapのいずれかです。swap に設定すると、スワップ論理ボリュームが作成されます。スワップ論理ボリュームの場合、マウントポイントが空である必要があります。 -
マウントポイント: 論理ボリュームのファイルシステムのマウントポイント。スワップ論理ボリュームの場合、これは空である必要があります。
-
-
- 順序:
パーティションテーブルの作成時に、リスト内の各要素の順序が適用されます。パーティションは、そのタイプに関係なく、定義された順序で作成されます。
- 不完全なパーティションテーブル:
不完全なパーティションの記述も有効です。パーティション (LVM 論理ボリューム) が自動的に追加され、有効なパーティションテーブルが作成されます。以下のルールが適用されます。
-
ルートファイルシステムが定義されていない場合は追加されます。これは、マウントポイント
/で識別されます。LVM ボリュームグループが定義されている場合、ルートファイルシステムは論理ボリュームとして作成されます。定義されていない場合、ルートファイルシステムはファイルシステムを持つプレーンパーティションとして作成されます。プレーンおよび LVM の場合、ファイルシステムのタイプは、ディストリビューションによって異なります (RHEL および CentOS の場合は xfs、Fedora の場合は ext4)。ルートパーティションのサイズと順序については、パーティションについて セクションを参照してください。 -
ブートパーティションが定義されていない場合は必要に応じて作成されます。これはマウントポイント
/bootによって識別されます。ルートパーティション (マウントポイント /) が LVM 論理ボリューム上にある場合は、ブートパーティションが必要です。これは、ESP の後に続く最初のパーティションとして作成されます (次の項目を参照)。 -
EFI システムパーティション (ESP) が必要に応じて作成されます。これは、マウントポイント
/boot/efiで識別されます。イメージが UEFI で起動するように設定されている場合は、ESP が必要です。これはイメージ定義によって定義され、イメージの種類、ディストリビューション、およびアーキテクチャーによって異なります。ファイルシステムのタイプは常にvfatです。デフォルトでは、ESP は 200 MiB で、BIOS ブート後の最初のパーティションになります (次の項目を参照)。 - イメージが BIOS で起動するように設定されている場合、パーティションテーブルの先頭に 1 MiB の未フォーマットの BIOS ブートパーティションが作成されます。これはイメージ定義によって定義され、イメージの種類、ディストリビューション、およびアーキテクチャーによって異なります。ハイブリッドブート用に設定されたイメージの場合、BIOS ブートパーティションと ESP の両方が作成されます。
- パーティションタイプの組み合わせ:
複数のパーティションを定義できます。次のパーティションタイプの組み合わせが有効です。
-
plainおよびlvm: プレーンパーティションは、LVM ボリュームグループと一緒に作成できます。ただし、定義できる LVM ボリュームグループは 1 つだけです。 - 例: 2 つのパーティションを定義するためのブループリント
次のブループリントは 2 つのパーティションを定義します。1 つ目は、/data にマウントされる ext4 ファイルシステムを持つ 50 GiB パーティションです。2 つ目は、ルート / 用、ホームディレクトリー /home 用、swap 領域用の 3 つの論理ボリュームを持つ LVM ボリュームグループです。LVM ボリュームグループには 15 GiB の未割り当て領域があります。
5.4. RHEL イメージモードでのファイルシステムのカスタマイズの利点 リンクのコピーリンクがクリップボードにコピーされました!
ファイルシステムのカスタマイズオプションは、Image Builder でビルドしたイメージの最終的なパーティションテーブルを指定するものです。このカスタマイズオプションは、次の要素の組み合わせによって決定されます。
- 特定のイメージタイプの基本パーティションテーブル。
関連するブループリントのカスタマイズ:
- パーティションモード。
- ファイルシステムのカスタマイズ。
ビルド要求のイメージサイズパラメーター:
-
コマンドラインでは、これは
composer-cli compose startコマンドの--sizeオプションです。
-
コマンドラインでは、これは
以下では、これらの要素がパーティションテーブルの最終的なレイアウトにどのように影響するかについて説明します。
- パーティションテーブルの変更
次の点を考慮してパーティションテーブルを変更できます。
- パーティションモード
パーティションモードは、イメージタイプのデフォルトレイアウトからパーティションテーブルをどのように変更するかを制御するものです。
-
rawパーティションタイプは、どのパーティションも LVM に変換しません。 -
lvmパーティションタイプは、常に/ルートマウントポイントを含むパーティションを LVM ボリュームグループに変換し、ルート論理ボリュームを作成します。/bootを除き、追加のマウントポイントは新しい論理ボリュームとしてボリュームグループに追加されます。 auto-lvmモードはデフォルトのモードです。ファイルシステムのカスタマイズで新しいマウントポイントが定義されている場合にのみ、raw パーティションテーブルを LVM ベースのものに変換します。詳細は、マウントポイント の項目を参照してください。- マウントポイント
ブループリントのファイルシステムのカスタマイズを使用して、新しいファイルシステムと最小パーティションサイズを定義できます。デフォルトでは、新しいマウントポイントが作成されると、パーティションテーブルが自動的に LVM に変換されます。詳細は、パーティションモード の項目を参照してください。
- イメージサイズ: パーティションテーブルの最小サイズは、ディスクイメージのサイズです。イメージの最終的なサイズは、サイズパラメーターの値か、すべてのパーティションとそれに関連付けられたメタデータの合計のうち、どちらか大きいほうによって決まります。
5.5. ファイルシステムカスタマイズでの特定のサイズでのイメージの作成 リンクのコピーリンクがクリップボードにコピーされました!
RHEL イメージモードで特定のサイズでイメージを作成する場合(特に bootc および bootc-image-builder を使用する場合)、イメージビルドプロセスに必要なディスクサイズを定義します。オーバーヘッドにより正確なサイズが困難な場合がありますが、最小要件を指定することができます。
前提条件
-
ビルド要求で正確な
[Image size]を指定する必要があります。 - 合計サイズよりもサイズが合計より小さいカスタマイズとしてマウントポイントを指定する必要があります。これは、パーティションテーブル、パーティション、およびその他のエンティティーにメタデータとヘッダー用に追加のスペースが必要なことが多いためです。したがって、すべてのマウントポイントに適合する領域は常に、パーティションサイズの合計よりも大きくなります。ただし、余分なスペースの正確なサイズは、イメージの種類などの多くの要因によって異なります。
手順
TOML ファイルで特定サイズのディスクイメージを作成する手順の概要は次のとおりです。
config.tomlファイルの [disk] セクション内でimage_sizeパラメーターを定義します。[disk] image_size = 10737418240 # Example: 10GB in bytes
[disk] image_size = 10737418240 # Example: 10GB in bytesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
マウントポイントの必要な最小サイズを指定してマウントポイントを追加します。/usr マウントポイントが存在しない場合は、サイズの合計がイメージサイズよりも小さくし、存在しない場合は 1.01 GiB 以上が 1.01 GiB であることを確認してください。0.01 MiB の余裕があれば、ヘッダーとメタデータ用に予約される可能性がある追加の領域にも十分に対応できます。/ マウントポイントのサイズは指定しないでください。
これにより、必要なサイズのパーティションテーブルを持つディスクが作成され、必要なマウントポイントに合わせて各パーティションのサイズが設定されます。ルートパーティション (ルート LVM 論理ボリューム) は少なくとも 3 GiB になります (/usr が指定されている場合は 1 GiB)。詳細は、パーティションについて を参照してください。
- パーティションテーブルに LVM ボリュームグループ (VG) がない場合、残りの領域を埋めるためにルートパーティションが拡張されます。
- パーティションテーブルに LVM ボリュームグループ (VG) が含まれている場合、その VG には、任意の論理ボリュームを拡張するために使用できる未割り当てのエクステントが存在します。
5.6. bootc-image-builder を使用したイメージモードのディスクイメージへの高度なパーティション設定の追加 リンクのコピーリンクがクリップボードにコピーされました!
bootc-image-builder のブループリントをカスタマイズして、osbuild-composer の高度なパーティション分割を実装できます。考えられるカスタムマウントポイントは次のとおりです。
-
LVM ベースのイメージは、
/bootおよび/boot/efiを除くすべてのパーティションの下に作成できます。 - LV ベースのスワップを作成できます。
- VG および LV のカスタム名を指定できます。
bootc-image-builder が読み取るベースイメージにパーティショニング設定を追加してパーティショニングレイアウトを作成し、コンテナー自体がパーティションテーブルの 信頼できるソース となります。パーティションおよび論理ボリュームのマウントポイントは、ディスクの構築に使用する基本コンテナーイメージに作成する必要があります。これは、/app マウントポイントなどのトップレベルのマウントポイントで特に重要です。bootc-image-builder は、起動不可能なイメージを作成しないように、ビルド前に bootc コンテナーに対して設定を検証します。
前提条件
- ホストマシンに Podman がインストールされている。
-
bootc-image-builderツールを実行し、コンテナーを--privilegedモードで実行して、イメージをビルドするための root アクセスがある。 - QEMU がインストールされている。
手順
以下の内容で
config.tomファイルを作成します。ユーザーをイメージに追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
bootc-image-builderを実行します。必要に応じて、ユーザーアクセス設定を使用する場合は、config.tomlを引数として渡します。以下は、パブリック QCOW2 イメージを作成する例です。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
.qcow2 イメージは出力フォルダーにあります。
検証
作成された QCOW2 ファイルを仮想マシンで実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow SSH で起動した仮想マシンのシステムにアクセスします。
ssh -i /<path_to_private_ssh-key> <user1>@<ip-address>
# ssh -i /<path_to_private_ssh-key> <user1>@<ip-address>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- イメージをデプロイできます。QCOW2 ディスクイメージを使用した KVM でのコンテナーイメージのデプロイ を参照してください。
- イメージを更新し、変更をレジストリーにプッシュできます。RHEL bootc イメージの管理 を参照してください。
5.7. 高度なパーティションを使用したイメージモード RHEL のディスクイメージのビルド リンクのコピーリンクがクリップボードにコピーされました!
bootc-image-builder を使用して、高度なパーティションを使用したイメージモードのディスクイメージを作成します。カスタムマウントポイントを使用してイメージモード RHEL から作成するイメージモードのディスクイメージには、カスタムマウントオプション、LVM ベースのパーティション、および LVM ベースの SWAP が含まれます。これにより、たとえば、config.toml ファイルを使用して / および /boot ディレクトリーのサイズを変更できます。ベアメタルマシンに RHEL Image Mode をインストールすると、Anaconda で利用可能なすべてのパーティション機能を活用できます。
前提条件
- ホストマシンに Podman がインストールされている。
-
ホストマシンに
virt-installがインストールされている。 -
bootc-image-builderツールを実行し、コンテナーを--privilegedモードで実行して、イメージをビルドするための root アクセスがある。
手順
config.tomlを作成してカスタムマウントオプションを設定します。次に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow config.tomlを引数として渡して、bootc-image-builderを実行します。注記コンテナーストレージマウントおよび --local イメージオプションがない場合は、イメージをパブリックにする必要があります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow カスタマイズした高度なパーティションを使用したイメージが、出力フォルダーに保存されます。
第6章 ローカルソースを使用したコンテナー実行に関するベストプラクティス リンクのコピーリンクがクリップボードにコピーされました!
RHEL bootc イメージを実行する場合、カスタムの Transport Layer Security (TLS) ルート証明書を必要とする内部レジストリーでホストされているコンテンツにアクセスできます。
ローカルリソースのみを使用してコンテナーにコンテンツをインストールするには、次のいずれかの方法を使用できます。
- バインドマウント: コンテナーのストアをホストのストアでオーバーライドします。
-
派生イメージ:
Containerfileを使用して、カスタム証明書を含む新しいコンテナーイメージをビルドして作成します。
必要に応じて、同じ手法を使用して bootc-image-builder` コンテナーまたは bootc コンテナーを実行することもできます。
6.1. バインドマウントを使用してコンテナーにカスタム証明書をインポートする リンクのコピーリンクがクリップボードにコピーされました!
バインドされたマウントを使用して、コンテナーのストアをホストのストアでオーバーライドします。
手順
RHEL bootc イメージを実行し、バインドマウント (例:
-v /etc/pki:/etc/pki) を使用して、コンテナーのストアをホストのストアでオーバーライドします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
- ディスクイメージのビルドプロセスで内部証明書にアクセスできるようになります。
6.2. Containerfile を使用してコンテナーにカスタム証明書をインポートする リンクのコピーリンクがクリップボードにコピーされました!
Containerfile を使用して、カスタム証明書を含む新しいコンテナーイメージをビルドして作成します。
手順
Containerfileを作成します。FROM <internal_repository>/<image> RUN mkdir -p /etc/pki/ca-trust/extracted/pem/ COPY tls-ca-bundle.pem /etc/pki/ca-trust/extracted/pem/ RUN rm -rf /etc/yum.repos.d/* COPY echo-rhel9_4.repo /etc/yum.repos.d/
FROM <internal_repository>/<image> RUN mkdir -p /etc/pki/ca-trust/extracted/pem/ COPY tls-ca-bundle.pem /etc/pki/ca-trust/extracted/pem/ RUN rm -rf /etc/yum.repos.d/* COPY echo-rhel9_4.repo /etc/yum.repos.d/Copy to Clipboard Copied! Toggle word wrap Toggle overflow カスタムイメージをビルドします。
podman build -t <your_image> .
# podman build -t <your_image> .Copy to Clipboard Copied! Toggle word wrap Toggle overflow <your_image>を実行します。podman run -it --rm <your_image>
# podman run -it --rm <your_image>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
コンテナー内の証明書をリスト表示します。
ls -l /etc/pki/ca-trust/extracted/pem/
# ls -l /etc/pki/ca-trust/extracted/pem/ tls-ca-bundle.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第7章 RHEL bootc イメージのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
ターゲット環境、インストール方法、自動化の要件に応じて、さまざまな方法で RHEL bootc イメージをデプロイできます。
7.1. RHEL bootc イメージのデプロイに使用できる方法 リンクのコピーリンクがクリップボードにコピーされました!
* Anaconda * bootc-image-builder * bootc installのメカニズムを使用して、rhel-bootc コンテナーイメージをデプロイできます。
使用可能な bootc イメージタイプは次のとおりです。
次のような
bootc-image-builderを使用して生成したディスクイメージ:- QCOW2 (QEMU copy-on-write、仮想ディスク)
- Raw (Mac 形式)
- AMI (Amazon Cloud)
- ISO: USB スティックまたは Install-on-boot を使用した無人インストール方法
デプロイ可能なレイヤーイメージを作成した後に、そのイメージをホストにインストールする方法はいくつかあります。
次のメカニズムを使用することで、RHEL インストーラーとキックスタートを使用してレイヤーイメージをベアメタルシステムにインストールできます。
- USB を使用したデプロイ
- PXE
-
bootc-image-builderを使用してコンテナーイメージを bootc イメージに変換し、ベアメタルまたはクラウド環境にデプロイすることもできます。
インストール方法は 1 回だけ実行されます。イメージをデプロイすると、その後の更新は、更新の公開時にコンテナーレジストリーから直接適用されます。
図7.1 基本ビルドインストーラー bootc install を使用して bootc イメージをデプロイするか、Anaconda とキックスタートを使用してコンテナーイメージをデプロイする
図7.2 bootc-image-builder を使用して bootc イメージからディスクイメージを作成し、Anaconda、bootc-image-builder、または bootc install を使用してエッジ、サーバー、クラウドなどのさまざまな環境にディスクイメージをデプロイする
7.2. QCOW2 ディスクイメージを使用した KVM でのコンテナーイメージのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
bootc-image-builder ツールを使用して RHEL bootc イメージから QCOW2 イメージを作成したら、仮想化ソフトウェアを使用してそのイメージを起動できます。
前提条件
- コンテナーイメージを作成した。
- コンテナーイメージをアクセス可能なリポジトリーにプッシュした。
-
bootc-image-builderを使用して QCOW2 イメージを作成している。手順は、bootc-image-builder を使用して QCOW2 イメージを作成する を参照してください。
手順
libvirtを使用して、コンテナーイメージから以前に作成したディスクイメージで仮想マシン (VM) を作成します。詳細は、コマンドラインを使用した仮想マシンの作成 を参照してください。次の例では、
virt-installを使用して仮想マシンを作成します。<qcow2/disk.qcow2>は、QCOW2 ファイルへのパスに置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
- コンテナーイメージを実行している仮想マシンに接続します。詳細は、仮想マシンをネットワークに接続するためにネットワークボンディングにブリッジを設定する を参照してください。
次のステップ
- イメージを更新し、変更をレジストリーにプッシュできます。RHEL bootc イメージの管理 を参照してください。
7.3. AMI ディスクイメージで AWS を使用したコンテナーイメージのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
bootc-image-builder ツールを使用して bootc イメージから AMI を作成し、それを AWS s3 バケットにアップロードしたら、AMI ディスクイメージを使用してコンテナーイメージを AWS にデプロイできます。
前提条件
- bootc イメージから Amazon Machine Image (AMI) を作成した。bootc-image-builder を使用した AMI イメージの作成および AWS へのアップロード を参照してください。
-
以前に作成した Containerfile で
cloud-initが使用でき、ユースケースに合わせたレイヤーイメージを作成できる。
手順
- ブラウザーで Service→EC2 にアクセスし、ログインします。
- AWS コンソールのダッシュボードメニューで、正しいリージョンを選択します。イメージが正常にアップロードされたことを示すには、イメージが Available ステータスになっている必要があります。
- AWS ダッシュボードでイメージを選択し、 をクリックします。
- 新しく開いたウィンドウで、イメージを起動するために必要なリソースに応じて、インスタンスタイプを選択します。 をクリックします。
- インスタンスの詳細を確認します。変更が必要な場合は、各セクションを編集できます。 をクリックします。
- インスタンスを起動する前に、インスタンスにアクセスするための公開鍵を選択します。既存のキーペアを使用するか、キーペアーを新規作成します。
インスタンスを起動するには、 をクリックします。Initializing と表示されるインスタンスのステータスを確認できます。
インスタンスのステータスが Running になると、 ボタンが有効になります。
- をクリックします。ウィンドウが表示され、SSH を使用して接続する方法の説明が表示されます。
次のコマンドを実行して、自分だけが読み取れるように秘密鍵ファイルのパーミッションを設定します。Connect to your Linux instance を参照してください。
chmod 400 <your-instance-name.pem>
$ chmod 400 <your-instance-name.pem>Copy to Clipboard Copied! Toggle word wrap Toggle overflow パブリック DNS を使用してインスタンスに接続します。
ssh -i <your-instance-name.pem>ec2-user@<your-instance-IP-address>
$ ssh -i <your-instance-name.pem>ec2-user@<your-instance-IP-address>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
インスタンスは停止しない限り実行され続けます。
検証
イメージを起動した後、次の操作を実行できます。
- ブラウザーで http://<your_instance_ip_address> への接続を試行します。
- SSH でインスタンスに接続している間にアクションが実行できるかどうかを確認します。
次のステップ
- イメージをデプロイした後、イメージを更新し、変更をレジストリーにプッシュできます。RHEL bootc イメージの管理 を参照してください。
7.4. Anaconda とキックスタートを使用したネットワークからのコンテナーイメージのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
コンテナーイメージをインストールするために、Anaconda とキックスタートを使用して ISO イメージをデプロイできます。インストール可能なブート ISO には、設定済みの ostreecontainer キックスタートファイルがすでに含まれています。このファイルは、カスタムコンテナーイメージのプロビジョニングに使用できます。
前提条件
- Red Hat から、アーキテクチャー用の 9.4 Boot ISO をダウンロードした。RH ブートイメージのダウンロード を参照してください。
手順
ネットワークからイメージを取得するための
ostreecontainerキックスタートファイルを作成します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 9.4 Boot ISO インストールメディアを使用してシステムを起動します。
カーネル引数に、次の内容のキックスタートファイルを追加します。
inst.ks=http://<path_to_your_kickstart>
inst.ks=http://<path_to_your_kickstart>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- CTRL+X を押してシステムを起動します。
次のステップ
- コンテナーイメージをデプロイした後、イメージを更新し、変更をレジストリーにプッシュできます。RHEL bootc イメージの管理 を参照してください。
7.5. 非接続環境でのカスタム ISO コンテナーイメージのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
bootc-image-builder を使用して bootc イメージを ISO イメージに変換すると、コンテナーイメージの内容が ISO ディスクイメージに埋め込まれる点を除き、ダウンロード可能な RHEL ISO に似たシステムが作成されます。インストール中にネットワークにアクセスする必要はありません。bootc-image-builder から作成した ISO ディスクイメージは、ベアメタルシステムにインストールできます。
前提条件
- bootc イメージが埋め込まれた ISO イメージを作成した。
手順
- ISO ディスクイメージを USB フラッシュドライブにコピーします。
- USB スティック内のコンテンツを使用して、非接続環境でベアメタルインストールを実行します。
次のステップ
- このコンテナーイメージの更新されたバージョンをレジストリーにプッシュして、OS の更新を稼働中のシステムに配信できます。RHEL bootc イメージの管理 を参照してください。
7.6. PXE ブートでの ISO bootc イメージのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
ISO ブートイメージを実行するには、ネットワークインストールを使用して、PXE を介して RHEL ISO イメージをデプロイできます。前提条件
- Red Hat から、アーキテクチャー用の 9.4 Boot ISO をダウンロードした。RH ブートイメージのダウンロード を参照してください。
サーバーが PXE ブート用に設定されている。以下のいずれかのオプションを選択します。
- HTTP クライアントの場合は、HTTP ブートおよび PXE ブート用の DHCPv4 サーバーの設定 を参照してください。
- UEFI ベースのクライアントの場合は、UEFI ベースのクライアント向けに TFTP サーバーを設定する を参照してください。
- BIOS ベースのクライアントの場合は、BIOS ベースのクライアント向けに TFTP サーバーを設定する を参照してください。
- クライアント (ISO イメージをインストールするシステムとも呼ばれる) がある。
手順
- RHEL インストール ISO イメージを、HTTP サーバーにエクスポートします。これにより、PXE ブートサーバーでは、PXE クライアントにサービスを提供する準備が整いました。
- クライアントを起動して、インストールを開始します。
- ブートソースを指定するよう求められたら、PXE ブートを選択します。ブートオプションが表示されない場合は、キーボードの Enter キーを押すか、起動画面が開くまで待ちます。
- Red Hat Enterprise Linux の起動画面で、必要なブートオプションを選択し、Enter キーを押します。
- ネットワークインストールを開始します。
次のステップ
- イメージを更新し、変更をレジストリーにプッシュできます。RHEL bootc イメージの管理 を参照してください。
7.7. bootc-image-builder を使用して作成するディスクイメージへの設定の注入 リンクのコピーリンクがクリップボードにコピーされました!
build config、つまり作成するイメージのカスタマイズを含む .toml または .json ファイルを使用すると、カスタムイメージに設定を注入できます。`build config ファイルは、コンテナーディレクトリーの /config.toml にマップされます。次の例は、作成するディスクイメージにユーザーを追加する方法を示しています。
手順
./config.tomlを作成します。次の例は、ディスクイメージにユーザーを追加する方法を示しています。[[customizations.user]] name = "user" password = "pass" key = "ssh-rsa AAA ... user@email.com" groups = ["wheel"]
[[customizations.user]] name = "user" password = "pass" key = "ssh-rsa AAA ... user@email.com" groups = ["wheel"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
name- 必須。ユーザーの名前です。 -
password- 必須ではありません。暗号化されていないパスワードです。 -
key- 必須ではありません。SSH 公開鍵の内容です。 -
groups- 必須ではありません。ユーザーの追加先グループの配列です。
-
bootc-image-builderを実行します。./config.tomlを含む次の引数を渡します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、
virt-installを使用して仮想マシンを起動します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
SSH でシステムにアクセスします。
ssh -i /<path_to_private_ssh-key> <user1>_@_<ip-address>
# ssh -i /<path_to_private_ssh-key> <user1>_@_<ip-address>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- コンテナーイメージをデプロイした後、イメージを更新し、変更をレジストリーにプッシュできます。RHEL のブート可能なイメージの管理 を参照してください。
7.8. bootc install を使用したベアメタルへのコンテナーイメージのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
RHEL ISO イメージを使用して、デバイスへのベアメタルインストールを実行できます。bootc には基本的なビルドインストーラーが含まれています。このインストーラーは、bootc install to-disk または bootc install to-filesystem で使用できます。
-
bootc install to-disk: この方法を使用すると、コンテナーイメージをデプロイするために追加の手順を実行する必要がなくなります。コンテナーイメージに基本的なインストーラーが含まれているためです。 -
bootc install to-filesystem: この方法を使用すると、LVM などの任意のツールを使用して、ターゲットデバイスとルートファイルシステムを設定できます。
前提条件
- ご使用のアーキテクチャー用の RHEL 10 ブート ISO を Red Hat からダウンロードした。RHEL ブートイメージのダウンロード を参照してください。
- 設定ファイルが作成されている。
手順
実行中の ISO イメージに設定を注入します。
bootc install to-diskを使用する場合:Copy to Clipboard Copied! Toggle word wrap Toggle overflow bootc install to-filesystemを使用する場合:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- コンテナーイメージをベアメタル環境にデプロイした後、イメージを更新し、変更をレジストリーにプッシュできます。RHEL ブート可能イメージの管理 を参照してください。
7.9. 1 つのコマンドを使用したコンテナーイメージのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
system-reinstall-bootc コマンドは bootc install to-existing root コマンドをラップする対話型 CLI を提供します。単一のコマンドを使用して、コンテナーイメージを RHEL クラウドインスタンスにデプロイできます。system-reinstall-bootc コマンドは次のアクションを実行します。
- 提供されたイメージをプルして、SSH 鍵をセットアップしたり、システムにアクセスしたりする。
-
すべてのバインドマウントおよび SSH 鍵を設定して、
bootc install to-existing-rootコマンドを実行する。
次の手順では、AWS 上の新しい RHEL 10 インスタンスに bootc イメージをデプロイします。インスタンスを起動する場合は、必ず SSH 鍵を選択するか、新しい鍵を作成してください。それ以外の場合は、デフォルトのインスタンス設定を使用できます。
前提条件
- Red Hat アカウントまたは Red Hat RPMS へのアクセス。
- AWS 環境で実行されるパッケージベースの RHEL (9.6/10.0 以上) 仮想システム。
- パッケージシステムに SSH で接続し、「破壊的な変更」を行う機能と権限。
手順
インスタンスが起動したら、インスタンスの作成時に選択したキーを使用して SSH でインスタンスに接続します。
ssh -i <ssh-key-file> <cloud-user@ip>
$ ssh -i <ssh-key-file> <cloud-user@ip>Copy to Clipboard Copied! Toggle word wrap Toggle overflow system-reinstall-bootcサブパッケージがインストールされていることを確認します。rpm -q system-reinstall-bootc
# rpm -q system-reinstall-bootcCopy to Clipboard Copied! Toggle word wrap Toggle overflow そうでない場合は、
system-reinstall-bootcサブパッケージをインストールします。dnf -y install system-reinstall-bootc
# dnf -y install system-reinstall-bootcCopy to Clipboard Copied! Toggle word wrap Toggle overflow bootc イメージを使用するようにシステムを変換します。
system-reinstall-bootc <image>
# system-reinstall-bootc <image>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Red Hat Ecosystem Catalog のコンテナーイメージ、または Containerfile から構築された bootc カスタマイズイメージを使用できます。
- "a" キーを押して、bootc イメージにインポートするユーザーを選択します。
- 選択内容を 2 回確認し、イメージがダウンロードされるまで待ちます。
システムを再起動します。
reboot
# rebootCopy to Clipboard Copied! Toggle word wrap Toggle overflow 指定された
<ip>の保存されている SSH ホストキーを/.ssh/known_hostsファイルから削除します。ssh-keygen -R <ip>
# ssh-keygen -R <ip>Copy to Clipboard Copied! Toggle word wrap Toggle overflow bootc システムは現在、新しい公開 SSH ホストキーを使用しています。ローカルに保存されているキーとは異なるキーを使用して同じ IP アドレスに接続しようとすると、SSH は警告を発するか、ホストキーの不一致により接続を拒否します。この変更は想定されているため、次のコマンドを使用して、既存のホストキーエントリーを
~/.ssh/known_hostsファイルから安全に削除できます。bootc システムに接続します。
ssh -i <ssh-key-file> root@<ip>
# ssh -i <ssh-key-file> root@<ip>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
システム OS が変更されたことを確認します。
bootc status
# bootc statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.10. to-filesystem を使用した高度なインストール リンクのコピーリンクがクリップボードにコピーされました!
bootc install コマンドには、bootc install to-disk と bootc install to-filesystem という 2 つのサブコマンドが含まれています。
-
bootc-install-to-filesystemは、ターゲットファイルシステムへのインストールを実行します。 bootc install to-diskサブコマンドは、独自の低レベルツールのセットで構成されます。これらのツールは独立して呼び出すこともできます。コマンドを構成するツールは次のとおりです。-
mkfs.$fs /dev/disk -
mount /dev/disk /mnt -
bootc install to-filesystem --karg=root=UUID=<uuid of /mnt> --imgref $self /mnt
-
bootc install to-existing-root は install to-filesystem のバリアントです。これを使用して、既存のシステムをターゲットコンテナーイメージに変換できます。
この変換により、/boot および /boot/efi パーティションが削除され、既存の Linux インストールが削除される可能性があります。変換プロセスではファイルシステムが再利用されます。ユーザーデータは保持されますが、システムはパッケージモードで起動しなくなります。
前提条件
- 手順を完了するには、root 権限が必要です。
-
ホスト環境とターゲットコンテナーのバージョンを一致させる必要があります。たとえば、ホストが RHEL 9 ホストの場合は、RHEL 9 コンテナーが必要です。RHEL カーネルとして
btrfsを使用して Fedora ホストに RHEL コンテナーをインストールすると、そのファイルシステムはサポートされません。
手順
既存のシステムをターゲットコンテナーイメージに変換するには、次のコマンドを実行します。
-v/:/targetオプションを使用して、ターゲットのrootfsを渡します。podman run --rm --privileged -v /dev:/dev -v /var/lib/containers:/var/lib/containers -v /:/target \ --pid=host --security-opt label=type:unconfined_t \ <image> \ bootc install to-existing-root# podman run --rm --privileged -v /dev:/dev -v /var/lib/containers:/var/lib/containers -v /:/target \ --pid=host --security-opt label=type:unconfined_t \ <image> \ bootc install to-existing-rootCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドにより
/boot内のデータは削除されますが、既存のオペレーティングシステム内にある他のすべてのデータは自動的に削除されません。これにより、新しいイメージが以前のホストシステムからデータを自動的にインポートできるため便利です。したがって、コンテナーイメージ、データベース、ユーザーホームディレクトリーデータ、/etc内の設定ファイルはすべて、その後の再起動後に/sysrootで使用できるようになります。--root-ssh-authorized-keys /target/root/.ssh/authorized_keysを追加することで、--root-ssh-authorized-keysフラグを使用して root ユーザーの SSH キーを継承することもできます。以下に例を示します。podman run --rm --privileged -v /dev:/dev -v /var/lib/containers:/var/lib/containers -v /:/target \ --pid=host --security-opt label=type:unconfined_t \ <image> \ bootc install to-existing-root --root-ssh-authorized-keys /target/root/.ssh/authorized_keys# podman run --rm --privileged -v /dev:/dev -v /var/lib/containers:/var/lib/containers -v /:/target \ --pid=host --security-opt label=type:unconfined_t \ <image> \ bootc install to-existing-root --root-ssh-authorized-keys /target/root/.ssh/authorized_keysCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第8章 bootc イメージをゼロから作成する リンクのコピーリンクがクリップボードにコピーされました!
bootc イメージをゼロから作成することで、基盤となるイメージコンテンツを制御し、システム環境を要件に合わせてカスタマイズできます。
bootc-base-imagectl コマンドを使用すると、既存の bootc ベースイメージをビルド環境として使用して bootc イメージをゼロから作成することができ、ビルドプロセスに含まれるコンテンツをより細かく制御できるようになります。このプロセスではユーザー RPM が入力として使用されるので、RPM が変更された場合はイメージを再ビルドする必要があります。
カスタムベースはベースコンテナーから派生していますが、コンテナーパイプラインに組み込まない限り、デフォルトのベースイメージに加えられた変更を自動的には取り込みません。
任意の bootc コンテナーイメージで bootc-base-imagectl rechunk サブコマンドを使用できます。
カーネル管理を実行する場合は、bootc イメージをゼロから作成する必要はありません。bootc システムでのカーネル引数の管理 を参照してください。
8.1. ピン留めされたコンテンツを使用してイメージをビルドする リンクのコピーリンクがクリップボードにコピーされました!
ベースイメージバージョンに、ロックファイルや rpm-md または yum repository などで定義された特定のバージョンのパッケージセットが含まれていることを確認するには、rpm-md または yum repository リポジトリーのスナップショットを管理するいくつかのツールを使用できます。
bootc image from scratch 機能を使用すると、ミラーリング、ピン留め、またはスナップショットされたリポジトリーコンテンツを参照しながら、ソース RPM リポジトリー内のパッケージ情報を設定およびオーバーライドできます。その結果、パッケージのバージョンとその依存関係を制御できるようになります。
たとえば、次のような状況では、パッケージのバージョンとその依存関係を制御する必要が出てくる場合があります。
- 厳格な認証およびコンプライアンス要件があるため、特定のパッケージバージョンを使用する必要がある。
- 重要な依存関係をサポートするために、特定のソフトウェアバージョンを使用する必要がある。
前提条件
- 標準の bootc ベースイメージ。
手順
次の例では、ピン留めされたコンテンツを含む bootc イメージをゼロから作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証手順
イメージを保存してビルドします。
podman build -t quay.io/<namespace>/<image>:<tag> . --cap-add=all --security-opt=label=type:container_runtime_t --device /dev/fuse
$ podman build -t quay.io/<namespace>/<image>:<tag> . --cap-add=all --security-opt=label=type:container_runtime_t --device /dev/fuseCopy to Clipboard Copied! Toggle word wrap Toggle overflow カレントディレクトリーにある
Containerfileを使用して <_image_> イメージをビルドします。podman build -t quay.io/<namespace>/<image>:<tag> .
$ podman build -t quay.io/<namespace>/<image>:<tag> .Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.2. 最小限からベースイメージをビルドする リンクのコピーリンクがクリップボードにコピーされました!
以前は、Image Mode for RHEL を使用して標準イメージのみをビルドできました。標準イメージはおおむねヘッドレスのサーバー指向のインストールですが、デスクトップでも使用可能です。また、ネットワーク、CLI ツールなど、多くの独自のパッケージが含まれています。
標準イメージから、bootc、カーネル、dnf のみから始まる新しい最小限のイメージを生成するオプションが追加されました。このイメージは、マルチステージビルドでさらに拡張できます。現時点では、最小限のイメージはレジストリーに事前に組み込まれた状態で出荷されていません。
ベースイメージには、カスタムベースイメージを生成できる /usr/libexec/bootc-base-imagectl ツールが含まれています。このツールを使用すると、ベースイメージで選択した RPM パッケージに基づいたルートファイルシステムを構築できます。
前提条件
- 標準の bootc ベースイメージ。
手順
次の例では、カスタムの最小ベースイメージを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.3. 必要な権限の構築 リンクのコピーリンクがクリップボードにコピーされました!
新しいルートファイルシステムを生成し、既存のコンテナーを変更しない場合は、多くのコンテナービルド環境ではデフォルトで有効になっていないマウント namespace などのコンテナー機能を使用して、ビルドに必要な権限を取得できます。
前提条件
-
container-toolsメタパッケージがインストールされている。
手順
podman buildに少なくとも以下の引数を指定して、新しいルートファイルシステムを生成します。--cap-add=all --security-opt=label=type:container_runtime_t --device /dev/fuse
--cap-add=all --security-opt=label=type:container_runtime_t --device /dev/fuseCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.4. bootc イメージをゼロから生成する リンクのコピーリンクがクリップボードにコピーされました!
カスタム RHEL bootc デフォルトベースコンテナーイメージから bootc イメージをゼロから作成し、小さなルートコンテンツセットを取得します。
前提条件
-
container-toolsメタパッケージがインストールされている。
手順
Containerfileを作成します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
-
Containerfileを作成すると、単一の tar ファイルの大きなレイヤーを持つイメージが取得されます。レジストリーへのプッシュ、クライアントへのプルなどのすべての変更により、単一の大きな tar ファイルがコピーされ、コンテナーイメージのサイズが増加します。作成したコンテナーイメージを小さいバージョンに最適化できます。
必要に応じて、RHEL 9.6 システムでは、rpm-ostree を使用して大規模なイメージを取得し、小さいバージョンにサイズを変更できます。
8.5. コンテナーイメージを小さいバージョンに最適化する リンクのコピーリンクがクリップボードにコピーされました!
bootc-base-imagectl rechunk サブコマンドを使用して rpm-ostree と対話し、イメージの再チャンク化を実行できます。
rpm-ostree は大きなイメージを取得し、それを再チャンク化できます。このプロセスにより、インストールされたパッケージの順序付けとグループ化が最終イメージ内の多くのレイヤーに最適化され、転送を必要とせずに複数のレイヤーを再利用できるため、ネットワーク効率が向上します。
スクラッチビルドの出力は、単一の大きなレイヤー (tar) を持つイメージです。カーネルの更新など、入力に対して行うすべての変更により、bootc イメージの内容全体を含む新しいレイヤーが作成されます。この新しいレイヤーは、プッシュされ、レジストリーに保存され、クライアントによってプルされる必要があります。
bootc-base-imagectl は、bootc イメージの一部として同梱されます。ホストコンテナーストレージをコンテナーにマッピングし、その中で bootc-base-imagectl を実行して再チャンク化操作を行うことで、既存のイメージを使用してカスタムベースイメージを再チャンク化できます。
前提条件
- 以前にビルドされたベースイメージがある。
手順
ベースイメージを再チャンク化するには、次のコマンドを実行します。
sudo podman run --rm --privileged -v /var/lib/containers:/var/lib/containers \ registry.redhat.io/rhel10/rhel-bootc:latest \ /usr/libexec/bootc-base-imagectl rechunk \ quay.io/exampleos/rhel-bootc:single \ quay.io/exampleos/rhel-bootc:chunked$ sudo podman run --rm --privileged -v /var/lib/containers:/var/lib/containers \ registry.redhat.io/rhel10/rhel-bootc:latest \ /usr/libexec/bootc-base-imagectl rechunk \ quay.io/exampleos/rhel-bootc:single \ quay.io/exampleos/rhel-bootc:chunkedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第9章 bootc イメージビルド時の FIPS モードの有効化 リンクのコピーリンクがクリップボードにコピーされました!
FIPS (Federal Information Processing Standards)には、暗号化操作の標準が含まれています。bootc イメージの構築時に FIPS モードを有効にして、FIPS 承認済みモジュールのみを使用するようにシステムを設定できます。以下のオプションを使用して、FIPS モードを有効にできます。
-
bootc-image-builderツールの使用:Containerfile で FIPS のシステム全体の暗号化ポリシーを有効にする必要があります。 -
Anaconda インストールを実行する場合:Containerfile で FIPS システム全体の暗号化ポリシーを有効にし、起動時に
fips=1カーネル引数を追加する必要もあります。
FIPS dracut モジュールがベースイメージに組み込まれています。このモジュールのデフォルトは、bootc install-to-filesystem の boot=UUID= karg です。
9.1. bootc-image-builder を使用して FIPS モードを有効にする リンクのコピーリンクがクリップボードにコピーされました!
bootc-image-builder または bootc install to-disk を使用してディスクイメージを作成し、イメージビルド時にカスタムの Containerfile を引数として渡すことで FIPS モードを有効にします。
前提条件
- Podman がホストマシンにインストールされている。
-
virt-installがホストマシンにインストールされている。 -
bootc-image-builderツールを実行し、コンテナーを--privilegedモードで実行して、イメージをビルドするための root アクセスがある。
手順
01-fips.tomlを作成して FIPS の有効化を設定します。次に例を示します。Enable FIPS
# Enable FIPS kargs = ["fips=1"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の手順で Containerfile を作成して、
fips=1カーネル引数を有効にします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow カレントディレクトリーの
Containerfileを使用して、bootc<image>と互換性のあるベースディスクイメージを作成します。podman build -t quay.io/<namespace>/<image>:<tag> .
$ podman build -t quay.io/<namespace>/<image>:<tag> .Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
システムにログインした後、FIPS モードが有効になっていることを確認します。
cat /proc/sys/crypto/fips_enabled 1 $ update-crypto-policies --show FIPS
$ cat /proc/sys/crypto/fips_enabled 1 $ update-crypto-policies --show FIPSCopy to Clipboard Copied! Toggle word wrap Toggle overflow
9.2. FIPS モードを有効にして Anaconda インストールを実行する リンクのコピーリンクがクリップボードにコピーされました!
Anaconda インストールの実行時にディスクイメージを作成し、FIPS モードを有効にするには、以下の手順に従います。
前提条件
- Podman がホストマシンにインストールされている。
-
virt-installがホストマシンにインストールされている。 -
bootc-image-builderツールを実行し、コンテナーを--privilegedモードで実行して、イメージをビルドするための root アクセスがある。
手順
01-fips.tomlを作成して FIPS の有効化を設定します。次に例を示します。Enable FIPS
# Enable FIPS kargs = ["fips=1"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の手順で Containerfile を作成して、
fips=1カーネル引数を有効にします。FROM registry.redhat.io/rhel9/rhel-bootc:latest # Enable fips=1 kernel argument: https://bootc-dev.github.io/bootc/building/kernel-arguments.html COPY 01-fips.toml /usr/lib/bootc/kargs.d/ # Install and enable the FIPS system-wide cryptographic policy RUN dnf install -y crypto-policies-scripts && update-crypto-policies --no-reload --set FIPS
FROM registry.redhat.io/rhel9/rhel-bootc:latest # Enable fips=1 kernel argument: https://bootc-dev.github.io/bootc/building/kernel-arguments.html COPY 01-fips.toml /usr/lib/bootc/kargs.d/ # Install and enable the FIPS system-wide cryptographic policy RUN dnf install -y crypto-policies-scripts && update-crypto-policies --no-reload --set FIPSCopy to Clipboard Copied! Toggle word wrap Toggle overflow カレントディレクトリーの
Containerfileを使用して、bootc<image>と互換性のあるベースディスクイメージを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow システムのインストール中に FIPS モードを有効にします。
RHEL Anaconda インストーラーを起動するときに、インストール画面で TAB キーを押して、
fips=1カーネル引数を追加します。インストール後に、システムは FIPS モードで自動的に起動します。
検証
システムにログインした後、FIPS モードが有効になっていることを確認します。
cat /proc/sys/crypto/fips_enabled 1 $ update-crypto-policies --show FIPS
$ cat /proc/sys/crypto/fips_enabled 1 $ update-crypto-policies --show FIPSCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第10章 ブート可能なイメージのセキュリティー強化とコンプライアンス リンクのコピーリンクがクリップボードにコピーされました!
Image Mode for RHEL は、セキュリティーコンプライアンス機能を提供し、準拠した設定を必要とするワークロードをサポートします。ただし、システムを強化し、コンプライアンスステータスを検証するプロセスは、パッケージモードの場合とは異なります。
Image Mode for RHEL を使用する際の重要な部分は、ブート可能なコンテナーイメージを作成することです。デプロイされたシステムはイメージをミラーリングします。したがって、ビルドされたイメージには、セキュリティーポリシーに必要なすべてのパッケージと設定が含まれている必要があります。
ブート可能なイメージをコンテナーとして実行すると、一部の強化設定は有効になりません。セキュリティープロファイルに従って完全に設定されたシステムを取得するには、コンテナーとして実行するのではなく、ベアメタルまたは仮想マシンでイメージを起動する必要があります。コンテナーデプロイメントの主な違いは次のとおりです。
- コンテナー内で systemd が実行されていないため、セキュリティープロファイルに必要な systemd サービスはコンテナー上で実行されません。したがって、コンテナーは関連するポリシー要件に準拠できません。
-
その他のサービスは、正しく設定されていても、コンテナー内で実行できません。つまり、
oscapは、実行されていない場合でも、正しく設定されていると報告します。 - コンプライアンスプロファイルによって定義された設定は強制されません。他のパッケージやインストール時のプリスクリプトからの要求によって、コンプライアンス状態が変更される可能性があります。インストールされた製品のコンプライアンスを常に確認し、要件に合わせて Containerfile を変更します。
10.1. 強化されたブート可能なイメージのビルド リンクのコピーリンクがクリップボードにコピーされました!
ブート可能なコンテナーイメージのビルドに使用する Containerfile に oscap-im ツールを含めることで、強化されたブート可能なイメージをより簡単にビルドできます。
oscap-im は任意の SCAP コンテンツを使用できますが、scap-security-guide に同梱されている SCAP ソースデータストリームは、ブート可能なコンテナーと互換性があるように特別に調整およびテストされています。
前提条件
-
container-toolsメタパッケージがインストールされている。 - システムが準拠する必要があるベースライン内のプロファイルの ID を知っている必要があります。ID を見つけるには、設定コンプライアンスのプロファイルの表示 セクションを参照してください。
手順
Containerfileを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow この
Containerfileは次のタスクを実行します。-
oscap-imツールを提供するopenscap-utilsパッケージと、Security Content Automation Protocol (SCAP) コンテンツを含むデータストリームを提供するscap-security-guideパッケージをインストールします。 -
SSH ルートログインを阻止するプロファイルに
sudoer権限を持つユーザーを追加します。 - 選択されたプロファイルに準拠して、イメージのスキャンと修復を行います。
-
カレントディレクトリーにある
Containerfileを使用してイメージをビルドします。podman build -t quay.io/<namespace>/<image>:<tag> .
$ podman build -t quay.io/<namespace>/<image>:<tag> .Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
すべてのイメージをリスト表示します。
podman images
$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE quay.io/<namespace>/<image> <tag> b28cd00741b3 About a minute ago 2.1 GBCopy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
通常のブート可能イメージのデプロイメント方法のいずれかを使用して、強化されたブート可能イメージをデプロイできます。詳細は、RHEL bootc イメージのデプロイ を参照してください。
ただし、デプロイメント方法は、対象システムのコンプライアンス状態に影響を与える可能性があります。
-
パッケージモード RHEL と同じ構文と使用法で
oscapツールを使用して、Image Mode RHEL で実行中のシステムのコンプライアンスを検証できます。詳細は、設定コンプライアンススキャン を参照してください。
10.2. 強化されたブート可能イメージのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
oscap-im ツールを使用して、カスタマイズされたプロファイルをブート可能なイメージに適用できます。セキュリティープロファイルをカスタマイズするには、特定のルール (パスワードの最小長など) のパラメーターを変更し、別の方法で対象とするルールを削除し、追加のルールを選択して内部ポリシーを実装できます。プロファイルをカスタマイズして新しいルールの定義はできません。
前提条件
-
container-toolsメタパッケージがインストールされている。 - プロファイルのカスタマイズファイルがある。詳細は、SCAP Workbench を使用したセキュリティープロファイルのカスタマイズ を 参照してください。
手順
Containerfileを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
この Containerfile は次のタスクを実行します。
- イメージにテーラリングファイルを注入します。
-
oscap-imツールを提供するopenscap-utilsパッケージと、Security Content Automation Protocol (SCAP) コンテンツを含むデータストリームを提供するscap-security-guideパッケージをインストールします。 -
SSH ルートログインを阻止するプロファイルに
sudoer権限を持つユーザーを追加します。 選択されたプロファイルに準拠して、イメージのスキャンと修復を行います。
カレントディレクトリーにある
Containerfileを使用してイメージをビルドします。podman build -t quay.io/<namespace>/<image>:<tag> .
$ podman build -t quay.io/<namespace>/<image>:<tag> .Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
すべてのイメージをリスト表示します。
podman images
$ podman images REPOSITORY TAG IMAGE ID CREATED SIZE quay.io/<namespace>/<image> <tag> b28cd00741b3 About a minute ago 2.1 GBCopy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
通常のブート可能イメージのデプロイメント方法のいずれかを使用して、強化されたブート可能イメージをデプロイできます。詳細は、RHEL bootc イメージのデプロイ を参照してください。
ただし、デプロイメント方法は、対象システムのコンプライアンス状態に影響を与える可能性があります。
注記bootc-image-builderのブループリントや Anaconda のキックスタートでデプロイメント時に行われた一部のカスタマイズは、コンテナーイメージに含まれる設定と干渉する可能性があります。セキュリティーポリシーの要件と競合するカスタマイズは使用しないでください。-
パッケージモード RHEL と同じ構文と使用法で
oscapツールを使用して、Image Mode RHEL で実行中のシステムのコンプライアンスを検証できます。詳細は、設定コンプライアンススキャン を参照してください。
第11章 RHEL bootc イメージの管理 リンクのコピーリンクがクリップボードにコピーされました!
RHEL bootc イメージをインストールしてデプロイした後、システムの変更や更新などの管理操作をコンテナーイメージに対して実行できます。システムは、デプロイメント後にロールバックが可能なインプレーストランザクション更新をサポートします。
この種の管理は Day 2 管理ベースラインとも呼ばれ、コンテナーレジストリーから新しいオペレーティングシステムの更新をトランザクショナルに取得して、システムを起動します。同時に、障害発生時には手動または自動のロールバックをサポートします。
デフォルトで有効になっている自動更新を利用することもできます。systemd service unit と systemd timer unit ファイルがコンテナーレジストリーの更新をチェックし、システムに適用します。アプリケーションの更新など、さまざまなイベントで更新プロセスをトリガーできます。これらの更新を監視し、CI/CD パイプラインをトリガーする自動化ツールがあります。更新はトランザクションであるため、再起動が必要です。より高度なロールアウトやスケジュールされたロールアウトが必要な環境では、自動更新を無効にし、bootc ユーティリティーを使用してオペレーティングシステムを更新する必要があります。
詳細は、Day 2 operations support を参照してください。
rhel-bootc イメージは、RPM パッケージなどの基礎となる入力が更新されるたびに再ビルドされます。これらの再ビルドは少なくとも毎月実行されますが、重要な更新がリリースされた場合はより頻繁に実行されます。ユーザーは、更新イメージをプッシュするタイミングを完全に制御できます。新しく公開されたベースイメージでは、カスタムイメージの自動再ビルドまたは再デプロイメントはトリガーされません。更新の頻度を設定し、必要な場合にのみ変更をプッシュします。
図11.1 インストールされたオペレーティングシステムを手動で更新し、必要に応じて変更をコンテナーイメージの参照を変更したり、ロールバックしたりする
11.1. コンテナーイメージ参照の切り替え リンクのコピーリンクがクリップボードにコピーされました!
bootc switch コマンドを使用して、アップグレードに使用するコンテナーイメージ参照を変更できます。たとえば、ステージタグから実稼働タグに切り替えることができます。既存の ostree-based コンテナーイメージ参照を手動で切り替えるには、bootc switch コマンドを使用します。
rpm-ostree を使用して変更を加えたり、コンテンツをインストールしたりすることはサポートされていません。
前提条件
-
bootcを使用して起動したシステム。
手順
以下のコマンドを実行します。
sudo bootc switch [--apply] quay.io/<namespace>/<image>:<tag>
$ sudo bootc switch [--apply] quay.io/<namespace>/<image>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow システム変更時に再起動などのアクションを自動的に実行する場合は、必要に応じて
--applyオプションを使用できます。
bootc switch コマンドは bootc upgrade と同じ効果があります。唯一の違いは、コンテナーイメージ参照が変更されることです。これにより、ホストの SSH 鍵やホームディレクトリーなど、/etc および /var 内の既存の状態を保持することが可能になります。
オプションで、非接続環境で、またはレジストリーに依存しない場合は、the- transport オプションを使用して、起動をローカルストレージメディアにポイントできます。この- transport オプションは、bootc スイッチ の実行時にシステムイメージをソースする方法を指定します。リモートレジストリーまたはローカルファイルに関係なく、異なるストレージバックエンドからのイメージに切り換えることができます。ローカルストレージの場合は、oci トランスポートを使用してください。これは通常推奨されます。単一のアーカイブファイルが必要な場合は oci-archive を使用します。the- transport オプションを使用してシステムイメージを入手する主な方法は、以下のとおりです。
OCI: ローカルの OCI レイアウトディレクトリーをイメージソースとして使用します。1 つのアーカイブファイルを作成せずに、事前にプルまたはエクスポートしたイメージに便利です。bootc switch --transport oci ./<image-directory>
$ bootc switch --transport oci ./<image-directory>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Registry (デフォルト): リモートコンテナーレジストリーからイメージをプルします。
以下に例を示します。bootc switch <image>
$ bootc switch <image>Copy to Clipboard Copied! Toggle word wrap Toggle overflow containers-storage: Podman などのツールによってローカルに保存されたイメージを使用します。これは、イメージをローカルにプルまたはビルドしている場合に役立ちます。以下に例を示します。bootc switch --transport containers-storage <image>
$ bootc switch --transport containers-storage <image>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.2. bootc イメージ initramfs へのモジュールの追加 リンクのコピーリンクがクリップボードにコピーされました!
rhel9/rhel-bootc イメージは、dracut インフラストラクチャーを使用して、イメージのビルド中に初期 RAM ディスク (initrd) を構築します。initrd は、コンテナー内の /usr/lib/modules/$kver/initramfs.img の場所に構築および追加されます。
ドロップイン設定ファイルを使用すると、dracut の設定をオーバーライドできます。ファイルは /usr/lib/dracut/dracut.conf.d/<50-custom-added-modules.conf> に配置できます。これにより、追加する必要があるモジュールを使用して initrd を再作成できます。
前提条件
- bootc を使用して起動したシステム。
手順
コンテナービルドの一部として
initrdを再作成します。FROM <baseimage> COPY <50-custom-added-modules>.conf /usr/lib/dracut/dracut.conf.d RUN set -x; kver=$(cd /usr/lib/modules && echo *); dracut -vf /usr/lib/modules/$kver/initramfs.img $kver
FROM <baseimage> COPY <50-custom-added-modules>.conf /usr/lib/dracut/dracut.conf.d RUN set -x; kver=$(cd /usr/lib/modules && echo *); dracut -vf /usr/lib/modules/$kver/initramfs.img $kverCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記デフォルトでは、このコマンドは実行中のカーネルバージョンをプルしようとするため、エラーが発生します。エラーを回避するために、ターゲットのカーネルバージョンを
dracutに明示的に渡してくだし。
11.3. initrd の変更と再生成 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトのコンテナーイメージには、/usr/lib/modules/$kver/initramfs.img に事前に生成された初期 RAM ディスク (initrd) が含まれています。たとえば、dracut モジュールを追加するために initrd を再生成するには、次の手順に従います。
手順
ドロップイン設定ファイルを作成します。以下に例を示します。
dracutmodules = "module"
dracutmodules = "module"Copy to Clipboard Copied! Toggle word wrap Toggle overflow ドロップイン設定ファイルを、
dracutが通常使用する場所 (/usr) に配置します。以下に例を示します。/usr/lib/dracut/dracut.conf.d/50-custom-added-modules.conf
/usr/lib/dracut/dracut.conf.d/50-custom-added-modules.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow コンテナービルドの一部として
initrdを再生成します。ターゲットのカーネルバージョンをdracutに明示的に渡す必要があります。dracut が実行中のカーネルバージョンをプルしようとしたときに、エラーが発生する可能性があるためです。以下に例を示します。FROM <baseimage> COPY 50-custom-added-modules.conf /usr/lib/dracut/dracut.conf.d RUN set -x; kver=$(cd /usr/lib/modules && echo *); dracut -vf /usr/lib/modules/$kver/initramfs.img $kver
FROM <baseimage> COPY 50-custom-added-modules.conf /usr/lib/dracut/dracut.conf.d RUN set -x; kver=$(cd /usr/lib/modules && echo *); dracut -vf /usr/lib/modules/$kver/initramfs.img $kverCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.4. インストールされたオペレーティングシステムからの更新の手動実行 リンクのコピーリンクがクリップボードにコピーされました!
Image Mode for RHEL のインストールは 1 回限りのタスクです。システムの変更や更新などのその他の管理タスクは、変更をコンテナーレジストリーにプッシュすることで実行できます。
Image Mode for RHEL を使用する場合、システムを手動で更新することを選択できます。手動更新は、Ansible などを使用して更新を自動的に実行できる場合でも便利です。自動更新はデフォルトで有効になっているため、手動更新を実行するには自動更新をオフにする必要があります。これは、次のいずれかの方法を選択して実行できます。
-
bootc upgradeコマンドの実行 -
systemdタイマーファイルの変更
11.5. 自動更新の無効化 リンクのコピーリンクがクリップボードにコピーされました!
手動更新を実行するには、自動更新をオフにする必要があります。これは、以下の手順に記載のいずれかの方法を選択して実行できます。
手順
コンテナービルドのタイマーを無効にします。
systemctl maskコマンドを実行します。systemctl mask bootc-fetch-apply-updates.timer
$ systemctl mask bootc-fetch-apply-updates.timerCopy to Clipboard Copied! Toggle word wrap Toggle overflow systemdタイマーファイルを変更します。systemdの "ドロップイン" を使用して、タイマーをオーバーライドします。次の例では、更新は週に 1 回スケジュールされています。次の内容で
updates.confファイルを作成します。[Timer] # Clear previous timers OnBootSec= OnBootSec=1w OnUnitInactiveSec=1w
[Timer] # Clear previous timers OnBootSec= OnBootSec=1w OnUnitInactiveSec=1wCopy to Clipboard Copied! Toggle word wrap Toggle overflow 作成したディレクトリーにファイルを追加します。
mkdir -p /usr/lib/systemd/system/bootc-fetch-apply-updates.timer.d cp updates.conf /usr/lib/systemd/system/bootc-fetch-apply-updates.timer.d
$ mkdir -p /usr/lib/systemd/system/bootc-fetch-apply-updates.timer.d $ cp updates.conf /usr/lib/systemd/system/bootc-fetch-apply-updates.timer.dCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.6. インストールされたオペレーティングシステムの手動更新 リンクのコピーリンクがクリップボードにコピーされました!
レジストリーから手動で更新を取得し、新しい更新でシステムを起動するには、bootc upgrade を使用します。このコマンドは、インストールされたオペレーティングシステムからコンテナーイメージレジストリーへの、トランザクショナルなインプレース更新を取得します。このコマンドはレジストリーを照会し、次回の起動のために更新されたコンテナーイメージをキューに追加します。デフォルトでは実行中のシステムを変更せずに、ベースイメージへの変更をステージングします。
手順
以下のコマンドを実行します。
bootc upgrade [--apply]
$ bootc upgrade [--apply]Copy to Clipboard Copied! Toggle word wrap Toggle overflow apply引数はオプションです。システム変更時に再起動などのアクションを自動的に実行する場合は、この引数を使用できます。
bootc upgrade および bootc update コマンドはエイリアスです。
11.7. 更新されたオペレーティングシステムからのロールバックの実行 リンクのコピーリンクがクリップボードにコピーされました!
bootc rollback コマンドを使用すると、以前のブートエントリーにロールバックして変更を元に戻すことができます。このコマンドは、rollback 対象のデプロイメントを次回の起動のキューに追加することで、ブートローダーエントリーの順序を変更します。現在のデプロイメントはロールバックになります。キュー内の適用されなかったアップグレードなどのステージングされた変更は、すべて破棄されます。
ロールバックが完了すると、システムが再起動し、更新タイマーが 1 - 3 時間以内に実行され、ロールバックしたイメージにシステムが自動的に更新されて再起動されます。
ロールバックを実行すると、自動更新をオフにしない限り、システムは自動的に再度更新されます。自動更新の無効化 を参照してください。
たとえば、bootc rollback コマンドを使用してロールバックを実行すると、/etc ディレクトリー内のファイルに加えられた変更は、ロールバックされたデプロイメントには引き継がれません。代わりに、/etc ディレクトリー内のファイルは、以前のデプロイメント時の状態に戻ります。
bootc rollback コマンドは既存のデプロイメントの順序を変更しますが、新しいデプロイメントは作成しません。新しいデプロイメントが作成されると、/etc ディレクトリーがマージされます。
ロールバック後に使用できるように、変更された /etc ファイルを保持するには、/var (特定の <user> の /var/home/<user> など) または root ユーザーの /var/root/ のディレクトリーに /etc の内容をコピーします。これらのディレクトリーにはユーザーコンテンツが保存されるため、ロールバックの影響を受けません。
一時的なロールバックまたは別の bootc ロールバックによって元の状態に戻ると、/etc ディレクトリーは元のデプロイメントの状態に戻ります。
または、ロールバックする問題が /etc ディレクトリー内の設定ファイルに関係しておらず、古いデプロイメントに戻す場合は、bootc switch コマンドを使用します。このコマンドは、必要な /etc マージを実行し、ソフトウェアの以前のバージョンをデプロイします。
前提条件
- システムの更新を実行した。
手順
以下のコマンドを実行します。
bootc rollback [-h|--help] [-V|--version]
$ bootc rollback [-h|--help] [-V|--version]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
systemd journalを使用して、検出されたロールバック呼び出しに関するログに記録されたメッセージを確認します。journalctl -b
$ journalctl -bCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のようなログが表示されます。
MESSAGE_ID=26f3b1eb24464d12aa5e7b544a6b5468
MESSAGE_ID=26f3b1eb24464d12aa5e7b544a6b5468Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.8. システムグループへの更新のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
Containerfile を変更することで、オペレーティングシステムの設定を変更できます。その後、コンテナーイメージをビルドして、レジストリーにプッシュできます。次回のオペレーティングシステムの起動時に、更新が適用されます。
bootc switch コマンドを使用して、コンテナーイメージソースを変更することもできます。コンテナーレジストリーは信頼できるソースです。コンテナーイメージ参照の切り替え を参照してください。
通常、システムグループに更新をデプロイする場合、セントラル管理サービスを使用できます。これにより、各システムにインストールされ、セントラルサービスに接続するクライアントを提供できます。多くの場合、管理サービスでは、クライアントが 1 回限りの登録を実行する必要があります。以下は、システムグループに更新をデプロイする方法の例です。必要に応じて、これを変更して永続的な systemd サービスを作成できます。
理解しやすいように、以下の例の Containerfile は最適化されていません。たとえば、イメージ内に複数のレイヤーが作成されないように最適化するには、RUN を 1 回呼び出します。
Image Mode for RHEL イメージにクライアントをインストールし、起動時にクライアントを実行してシステムを登録できます。
前提条件
-
管理クライアントが、
cronジョブまたは別のsystemdサービスを使用して、今後のサーバーへの接続を処理する。
手順
次の特徴を持つ管理サービスを作成します。管理サービスは、システムをいつアップグレードするかを決定します。
-
ベースイメージに
bootc-fetch-apply-updates.timerが含まれている場合は無効にします。 -
dnfを使用するか、クライアントに適用される他の方法を使用してクライアントをインストールします。 - 管理サービスの認証情報をイメージに注入します。
-
ベースイメージに
11.9. インベントリーの健全性の確認 リンクのコピーリンクがクリップボードにコピーされました!
ヘルスチェックは Day 2 操作の 1 つです。コンテナーイメージとコンテナー内で実行中のイベントのシステム健全性を、手動で確認できます。
コマンドラインでコンテナーを作成することにより、ヘルスチェックを設定できます。podman inspect または podman ps コマンドを使用して、コンテナーのヘルスチェックのステータスを表示できます。
podman events コマンドを使用して、Podman で発生するイベントを監視および出力できます。各イベントには、タイムスタンプ、タイプ、ステータス、名前 (該当する場合)、およびイメージ (該当する場合) が含まれます。
ヘルスチェックとイベントの詳細は、コンテナーの監視 の章を参照してください。
11.10. 自動化と GitOps リンクのコピーリンクがクリップボードにコピーされました!
CI/CD (継続的インテグレーションと継続的デリバリー) パイプラインを使用してビルドプロセスを自動化し、アプリケーションの更新などのイベントによって更新プロセスをトリガーできるようにします。これらの更新を追跡し、CI/CD パイプラインをトリガーする自動化ツールを使用できます。パイプラインは、トランザクショナルなバックグラウンドのオペレーティングシステム更新を使用して、システムを最新の状態に保ちます。
Image Mode for RHEL の作成リソースに関する詳細は、Image Mode for RHEL の作成に使用できる特定の実装 (RHEL Image Mode CI/CD) を確認してください。
11.11. Toolbx を使用した bootc コンテナーの検査 リンクのコピーリンクがクリップボードにコピーされました!
システムにソフトウェアをインストールすると、システムの動作が変更したり、不要になったファイルやディレクトリーが残されたりするなど、一定のリスクが生じます。このようなリスクは、RHEL bootc に含まれる Toolbx ユーティリティーに、好みの開発およびデバッグツール、エディター、ソフトウェア開発キット (SDK) をインストールすることで回避できます。RHEL bootc は、ベースオペレーティングシステムに影響を与えずに完全に変更できるコンテナーのイメージです。less、lsof、rsync、ssh、sudo、unzip などのコマンドを使用して、ホストシステム上で変更を実行できます。
Toolbx ユーティリティーは次のアクションを実行します。
-
registry.access.redhat.com/ubi9/toolbox:latestイメージをローカルシステムにプルする - イメージからコンテナーを起動する
- コンテナー内でシェルを実行し、そこからホストシステムにアクセスできる
Toolbx は、Toolbx コンテナーを作成したユーザーの権限に応じて、ルートコンテナーまたはルートレスコンテナーを実行できます。ホストシステムでルート権限を必要とするユーティリティーも、ルートコンテナーで実行する必要があります。
デフォルトのコンテナー名は rhel-toolbox です。bootc コンテナーを検査するには、次の手順に従います。
手順
toolbox createコマンドを使用して Toolbx コンテナーを起動し、toolbox enterコマンドを使用してコンテナーに入ります。ルートレスユーザーとして:
toolbox create <mytoolbox>
$ toolbox create <mytoolbox>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ルートユーザーとして:
sudo toolbox create <mytoolbox>
$ sudo toolbox create <mytoolbox> Created container: <mytoolbox> Enter with: toolbox enterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 正しいイメージを取得したことを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Toolbx コンテナーに入ります。
toolbox enter <mytoolbox>
[user@toolbox ~]$ toolbox enter <mytoolbox>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - オプション: 正しいイメージを取得したことを確認します。
<mytoolbox>コンテナー内でコマンドを実行し、コンテナーの名前とイメージを表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Toolbx を使用して開発ツールをインストールします。
Emacs テキストエディター、GCC コンパイラー、GNU デバッガー (GDB) など、選択したツールをインストールします。
⬢[user@toolbox ~]$ sudo dnf install emacs gcc gdb
⬢[user@toolbox ~]$ sudo dnf install emacs gcc gdbCopy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: ツールがインストールされていることを確認します。
⬢[user@toolbox ~]$ dnf repoquery --info --installed <package_name>
⬢[user@toolbox ~]$ dnf repoquery --info --installed <package_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow インストール後、ルートレスユーザーとしてこれらのツールを引き続き使用できます。
Toolbx を使用して、ツールをホストシステムにインストールせずに、ホストシステムのトラブルシューティングを行います。
journalctlコマンドを実行できるようにするには、systemdスイートをインストールします。⬢[root@toolbox ~]# dnf install systemd
⬢[root@toolbox ~]# dnf install systemdCopy to Clipboard Copied! Toggle word wrap Toggle overflow ホスト上で実行しているすべてのプロセスのログメッセージを表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow カーネルのログメッセージを表示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow nmapネットワークスキャンツールをインストールします。⬢[root@toolbox ~]# dnf install nmap
⬢[root@toolbox ~]# dnf install nmapCopy to Clipboard Copied! Toggle word wrap Toggle overflow ネットワーク内の IP アドレスとポートをスキャンします。
⬢[root@toolbox ~]# nmap -sS scanme.nmap.org Starting Nmap 7.93 ( https://nmap.org ) at 2024-01-02 10:39 CET Stats: 0:01:01 elapsed; 0 hosts completed (0 up), 256 undergoing Ping Scan Ping Scan Timing: About 29.79% done; ETC: 10:43 (0:02:24 remaining) Nmap done: 256 IP addresses (0 hosts up) scanned in 206.45 seconds
⬢[root@toolbox ~]# nmap -sS scanme.nmap.org Starting Nmap 7.93 ( https://nmap.org ) at 2024-01-02 10:39 CET Stats: 0:01:01 elapsed; 0 hosts completed (0 up), 256 undergoing Ping Scan Ping Scan Timing: About 29.79% done; ETC: 10:43 (0:02:24 remaining) Nmap done: 256 IP addresses (0 hosts up) scanned in 206.45 secondsCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
-sSオプションは TCP SYN スキャンを実行します。Nmap のスキャンタイプのほとんどは、生のパケットを送受信するため、特権ユーザーのみが使用できます。UNIX システムではルートアクセスが必要です。
-
Toolbx bootc コンテナーを停止します。
コンテナーを離れてホストに戻ります。
⬢ [user@toolbox ~]$ exit
⬢ [user@toolbox ~]$ exitCopy to Clipboard Copied! Toggle word wrap Toggle overflow ツールボックスコンテナーを停止します。
⬢ [user@toolbox ~]$ podman stop <mytoolbox>
⬢ [user@toolbox ~]$ podman stop <mytoolbox>Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション: ツールボックスコンテナーを削除します。
⬢ [user@toolbox ~]$ toolbox rm <mytoolbox>
⬢ [user@toolbox ~]$ toolbox rm <mytoolbox>Copy to Clipboard Copied! Toggle word wrap Toggle overflow または、
podman rmコマンドを使用して bootc コンテナーを削除することもできます。
第12章 bootc システムでのカーネル引数の管理 リンクのコピーリンクがクリップボードにコピーされました!
bootc を使用すると、カーネル引数を設定できます。bootc は、デフォルトで /boot/loader/entries に保存されているブートローダー設定ファイルを使用します。このディレクトリーは、Linux カーネルに提供される引数を定義します。このカーネル引数のセットは、マシン固有の状態ですが、カーネル引数はコンテナー更新を使用して管理することもできます。ブートローダーメニューのエントリーは、複数のオペレーティングシステム間で共有されます。ブートローダーは、1 つのデバイスにインストールされます。
現在、ブートローダーエントリーは OSTree バックエンドによって書き込まれます。
12.1. bootc でカーネル引数を注入するためのサポートを追加する方法 リンクのコピーリンクがクリップボードにコピーされました!
bootc ツールは、汎用のオペレーティングシステムカーネルを使用します。/usr/lib/bootc/kargs.d に TOML 形式のカスタム設定を追加することで、カーネル引数を注入するサポートを追加できます。以下に例を示します。
/usr/lib/bootc/kargs.d/10-example.toml
# /usr/lib/bootc/kargs.d/10-example.toml
kargs = ["mitigations=auto,nosmt"]
match-architectures キーを使用して、これらのカーネル引数をアーキテクチャー固有にすることもできます。以下に例を示します。
/usr/lib/bootc/kargs.d/00-console.toml
# /usr/lib/bootc/kargs.d/00-console.toml
kargs = ["console=ttyS0,114800n8"]
match-architectures = ["x86_64"]
12.2. bootc インストール設定を使用してカーネル引数を変更する方法 リンクのコピーリンクがクリップボードにコピーされました!
bootc install を使用すると、インストール時に次の方法でカーネル引数を追加できます。
- コンテナーイメージにカーネル引数を追加する。
-
bootc install --kargコマンドを使用してカーネル引数を追加する。
カーネル引数を追加して、切り替え、アップグレード、または編集時に適用することで、Day 2 運用時にカーネル引数を使用できます。カーネル引数を追加して Day 2 運用に使用するには、次の主な手順を実行する必要があります。
-
カーネル引数を使用して
/usr/lib/bootc/kargs.d内にファイルを作成します。 - コンテナーイメージを取得して OSTree コミットを取得します。
- OSTree コミットを使用してファイルツリーを返します。
-
/usr/lib/bootc/kargs.dに移動します。 - ディレクトリー内の各ファイルを読み取ります。
-
各
kargsファイルの内容を、必要なすべてのkargsを含むファイルにプッシュします。 -
kargsをstage()関数に渡します。 - カーネル引数を適用して、切り替え、アップグレード、または編集を行います。
12.3. Containerfile にカーネル引数を注入する方法 リンクのコピーリンクがクリップボードにコピーされました!
コンテナーイメージにカーネル引数を追加するには、Containerfile を使用します。以下に例を示します。
12.4. インストール時にカーネル引数を注入する方法 リンクのコピーリンクがクリップボードにコピーされました!
--karg を指定した boot install を使用すると、インストール時にカーネル引数を注入できます。これにより、カーネル引数がマシンローカル状態になります。
たとえば、カーネル引数を注入するには、次のコマンドを使用します。
bootc install to-filesystem --karg
# bootc install to-filesystem --karg
現在、bootc にはカーネル引数を操作するための API がありません。カーネル引数の操作は、rpm-ostree (rpm-ostree kargs コマンド) でのみサポートされています。
12.5. bootc-image-builder を使用してインストール時のカーネル引数を追加する方法 リンクのコピーリンクがクリップボードにコピーされました!
bootc-image-builder ツールは、インストール時に customizations.kernel.append をサポートします。
bootc-image-builder を使用してカーネル引数を追加するには、次のカスタマイズを使用します。
12.6. kargs.d によるインストール後のカーネル引数の変更について リンクのコピーリンクがクリップボードにコピーされました!
kargs.d ファイルに加えた変更とコンテナービルドに含めた変更は、インストール後に適用されます。カーネル引数セット間の差異は、現在のブートローダー設定に適用されます。これにより、マシンローカルのカーネル引数が保持されます。/boot/loader/entries ファイルは、任意のツールを使用して編集できます。これは標準化された形式のファイルです。/boot ファイルには、このファイルシステムに書き込むことができるツールセットを制限するために、読み取り専用アクセスが設定されています。
12.7. bootc システムのカーネル引数を編集する方法 リンクのコピーリンクがクリップボードにコピーされました!
マシンのローカル変更を実行するには、rpm-ostree kargs コマンドを使用して、bootc システムまたは rpm-ostree システム上のカーネル引数を編集することもできます。変更は user/lib/bootc/kargs.d パスを通じて行われます。このパスでは、最初のブートの変更に加えて、"Day 2" の変更も処理されます。
以下は、カーネル引数を追加、変更、または削除するために使用できるオプションです。
rpm-ostree kargs [option]
- --append=KEY=VALUE
-
カーネル引数を追加します。たとえば、複数回使用できる
console=などで便利です。引数には空の値を使用できます。 - --replace=KEY=VALUE=NEWVALUE
-
既存のカーネル引数を置き換えます。引数にすでに 1 つの値が存在する場合にのみ、その引数を
KEY=VALUEで置き換えることができます。 - --delete=KEY=VALUE
- 特定のカーネルのキー値ペア引数、または 1 つのキー値ペアを持つ引数全体を削除します。
- --append-if-missing=KEY=VALUE
- カーネル引数を追加します。キーがすでに存在する場合は何も行いません。
- --delete-if-present=KEY=VALUE
- 特定のカーネルのキー値ペア引数を削除します。キーがない場合は何も行いません。
- --editor
- エディターを使用してカーネル引数を変更します。
詳細は、ヘルプを確認してください。
rpm-ostree kargs --help
# rpm-ostree kargs --help
以下に例を示します。
rpm-ostree kargs --append debug
# rpm-ostree kargs --append debug
Staging deployment... done
Freed: 40.1 MB (pkgcache branches: 0)
Changes queued for next boot. Run "systemctl reboot" to start a reboot
第13章 Image Mode for RHEL でのファイルシステムの管理 リンクのコピーリンクがクリップボードにコピーされました!
イメージモードでは、バックエンドとして OSTree が使用され、ストレージ用に composefs がデフォルトで有効になっています。そのため、/opt などに書き込む派生コンテナーイメージに、サードパーティーのコンテンツを簡単にインストールできます。/opt および /usr のローカルパスはプレーンディレクトリーであり、/var へのシンボリックリンクではないためです。
サードパーティーのコンテンツを /opt にインストールすると、サードパーティーのコンポーネントも実行時に /opt 内のサブディレクトリーに書き込もうとする可能性があります。そのため、競合が発生する可能性があります。
13.1. /sysroot による物理ルートと論理ルート リンクのコピーリンクがクリップボードにコピーされました!
bootc システムが完全に起動すると、システムは chroot よって作成された環境と似た状態になります。つまり、オペレーティングシステムが、現在実行中のプロセスとその子プロセスの見かけ上のルートディレクトリーを変更します。物理ホストのルートファイルシステムは /sysroot にマウントされます。chroot ファイルシステムはデプロイメントルートと呼ばれます。
残りのファイルシステムパスは、システムブートの最終ターゲットとして使用されるデプロイメントルートの一部です。システムは、ostree=kernel 引数を使用してデプロイメントルートを検索します。
/usr-
すべてのオペレーティングシステムのコンテンツを
/usrに保存することが望ましいですが、必須ではありません。/binなどのディレクトリーは、/usr/binへのシンボリックリンクとして機能します。このレイアウトにより、オペレーティングシステムとホスト固有のリソースが分離されます。
composefs が有効な場合、/usr は / と変わりません。両方のディレクトリーは同じ不変イメージの一部であるため、bootc システムで完全な UsrMove を実行する必要はありません。
/usr/local-
bootc システムを使用すると、デフォルトのエントリーポイントとしてカスタムコンテナーイメージを作成できます。そのため、ベースイメージでは
/usr/localが通常のディレクトリー、つまりデフォルトのディレクトリーとして設定されます。
デフォルトのファイルシステムレイアウトでは、/opt と /usr/local の両方が通常のディレクトリーとして存在します。つまり、これらのディレクトリーはビルド時には書き込み可能で、実行時には変更できません。これは、たとえば、これらのシンボリックリンクを /var に作成する RHEL CoreOS とは異なります。
/etc/etcディレクトリーにはデフォルトで変更可能な永続状態が含まれますが、etc.transient configオプションを有効にすることがサポートされています。ディレクトリーが変更可能な永続状態にある場合は、アップグレード全体で 3 方向のマージが実行します。-
新しいデフォルトの
/etcをベースとして使用します -
現在の
/etcと以前の/etcの差分を新しい /etc ディレクトリーに適用します。 -
同じデプロイメントのデフォルトの
/usr/etcとは異なる、ローカルで変更されたファイルを/etcに保持します。
-
新しいデフォルトの
ostree-finalize-staged.service は、新しいブートローダーエントリーを作成する前に、シャットダウン時にこれらのタスクを実行します。
これは、Linux システムの多くのコンポーネントが /etc ディレクトリーにデフォルトの設定ファイルを置いて出荷されるために発生します。デフォルトパッケージに含まれていない場合でも、デフォルトではソフトウェアは /etc 内の設定ファイルのみをチェックします。/etc の明確なバージョンを持たない、bootc イメージベースではない更新システムは、インストール時にのみ設定され、インストール後は変更されません。これにより、/etc システムの状態が初期イメージバージョンの影響を受けるようになり、たとえば /etc/sudoers.conf に変更を適用する際に問題が発生し、外部からの介入が必要になる可能性があります。ファイル設定の詳細は、RHEL bootc イメージのビルドとテスト を参照してください。
/var-
/varディレクトリーは 1 つのみです。デフォルトでは、/varディレクトリーに配置されたファイルとデータは、明示的に削除されるまで保持され、異なるセッションやシステムの再起動後も利用できます。/var パーティションまたはそのサブディレクトリーは、一時ファイルシステム (TMPFS) やネットワークマウントポイントのようなマウントポイントにすることもできます。/varに専用のパーティションを作成しない場合、システムによってバインドマウントが実行され、単一の共有の永続的な/ostree/deploy/$stateroot/varが/varディレクトリーに作成されます。これにより、両方のディレクトリーがデプロイメント間で同じデータを共有するようになります。
/var ディレクトリーは 1 つだけです。別個のパーティションでない場合、物理的には /var ディレクトリーは /ostree/deploy/$stateroot/var へのバインドマウントとなり、利用可能なブートローダーエントリーのデプロイメント間で共有されます。
デフォルトでは、/var 内のコンテンツはボリュームとして機能します。つまり、コンテナーイメージのコンテンツは最初のインストール時にコピーされ、その後は更新されません。
/var ディレクトリーと /etc ディレクトリーは異なります。比較的小さな設定ファイルには /etc を使用でき、必要な設定ファイルは、多くの場合 /usr 内のオペレーティングシステムバイナリーにバインドされます。/var ディレクトリーには、システムログ、データベースなどの任意の大きさのデータが格納されます。デフォルトでは、オペレーティングシステムの状態がロールバックされても、このディレクトリーはロールバックされません。
たとえば、dnf downgrade postgresql などの更新を実行しても、/var/lib/postgres 内の物理データベースには影響しません。同様に、bootc update または bootc rollback を実行しても、このアプリケーションデータには影響しません。
/var を別々にしておくと、新しいオペレーティングシステムの更新を適用する前にステージングをスムーズに実行できるようになります。つまり、更新はダウンロードされて準備完了ですが、再起動時にのみ有効になります。同じことが Docker ボリュームにも当てはまり、アプリケーションコードとそのデータが切り離されます。
アプリケーションに /var/lib/postgresql などの事前に作成されたディレクトリー構造を持たせたい場合に、このケースを使用できます。これには systemd tmpfiles.d を使用します。ユニットで StateDirectory=<directory> を使用することもできます。
- その他のディレクトリー
-
コンテナーイメージ内の
/run、/proc、またはその他の API ファイルシステム内のコンテンツを出荷することはサポートされていません。それ以外にも、/usrや/optなどの他のトップレベルディレクトリーは、コンテナーイメージとともにライフサイクル化されます。 /opt-
bootcはcomposefsを使用するため、/optディレクトリーは/usrなどの他の最上位ディレクトリーと同様に読み取り専用になります。
ソフトウェアが /opt/exampleapp 内の独自のディレクトリーに書き込む必要がある場合は、ログファイルなどの操作のために、たとえば /var にリダイレクトするシンボリックリンクを使用するのが一般的なパターンです。
RUN rmdir /opt/exampleapp/logs && ln -sr /var/log/exampleapp /opt/exampleapp/logs
RUN rmdir /opt/exampleapp/logs && ln -sr /var/log/exampleapp /opt/exampleapp/logs
オプションで、これらのマウントを動的に実行するサービスを起動するように systemd ユニットを設定することもできます。以下に例を示します。
BindPaths=/var/log/exampleapp:/opt/exampleapp/logs
BindPaths=/var/log/exampleapp:/opt/exampleapp/logs
- 一時ルートを有効にする
-
永続化する必要があるコンテンツ用の
/varへのシンボリックリンクを使用して、/usrおよび/optを含むすべてのトップレベルディレクトリーにソフトウェアが一時的に (次回の再起動まで) 書き込むことを可能にするには、一時的なルートを有効にします。デフォルトで完全に一時的な書き込み可能なrootfsを有効にするには、/usr/lib/ostree/prepare-root.confで次のオプションを設定します。
[root] transient = true
[root]
transient = true
これにより、永続化する必要のあるコンテンツ用の /var へのシンボリックリンクを使用して、ソフトウェアが一時的に /opt に書き込めるようになります。
13.2. バージョンの選択と起動 リンクのコピーリンクがクリップボードにコピーされました!
Image Mode for RHEL では、s390x アーキテクチャーを除き、デフォルトで GRUB が使用されます。現在システムで使用可能な Image Mode for RHEL の各バージョンには、メニューエントリーがあります。
メニューエントリーは、Linux カーネル、initramfs、および OSTree コミットにリンクするハッシュで構成される OSTree デプロイメントを参照します。これは、ostree=kernel 引数を使用して渡すことができます。
起動時に、OSTree はカーネル引数を読み取り、ルートファイルシステムとして使用するデプロイメントを決定します。パッケージのインストール、カーネル引数の追加など、システムに対する更新または変更ごとに、新しいデプロイメントが作成されます。
これにより、更新によって問題が発生した場合に、以前のデプロイメントにロールバックできるようになります。
第14章 Image Mode for RHEL でのユーザー、グループ、SSH 鍵、シークレットの管理 リンクのコピーリンクがクリップボードにコピーされました!
Image Mode for RHEL でのユーザー、グループ、SSH 鍵、およびシークレットの管理について詳しく説明します。
14.1. ユーザーとグループの設定 リンクのコピーリンクがクリップボードにコピーされました!
Image Mode for RHEL は、汎用的なオペレーティングシステムの更新および設定メカニズムです。次のリストで、選択したユースケースのベストプラクティスを参照してください。
- 汎用ベースイメージのユーザーとグループの設定
- 通常、ディストリビューションのベースイメージには設定がありません。セキュリティーリスクがあるため、汎用イメージ内の公開されている秘密鍵を使用してパスワードと SSH 鍵を暗号化しないでください。
systemd認証情報を使用した SSH 鍵の注入-
一部の環境では、
systemdを使用して、root パスワードまたは SSHauthorized_keysファイルを注入できます。たとえば、System Management BIOS (SMBIOS) を使用して、SSH 鍵システムファームウェアを注入します。これは、qemuなどのローカルな仮想化環境で設定できます。 cloud-initを使用したユーザーと SSH 鍵の注入-
多くの Infrastructure as a Service (IaaS) および仮想化システムは、
cloud-initやignitionなどのソフトウェアによって一般的に処理されるメタデータサーバーを使用します。AWS instance metadata を参照してください。cloud-initまたは Ignition は、使用しているベースイメージに含まれる場合があります。または、独自の派生イメージにインストールすることもできます。このモデルでは、SSH 設定は bootc イメージの外部で管理されます。 - コンテナーまたはユニットのカスタムロジックを使用したユーザーと認証情報の追加
-
cloud-initなどのシステムには特権がありません。コンテナーイメージを起動する方法で、認証情報を管理するための任意のロジックを注入できます。たとえば、systemdユニットを使用できます。認証情報を管理するには、FreeIPA などのカスタムのネットワークホストソースを使用できます。 - コンテナービルドでのユーザーと認証情報の静的な追加
パッケージ指向のシステムでは、次のコマンドにより、派生ビルドを使用してユーザーと認証情報を注入できます。
RUN useradd someuser
RUN useradd someuserCopy to Clipboard Copied! Toggle word wrap Toggle overflow shadow-utilsのデフォルトのuseradd実装に問題がある場合があります。ユーザーとグループの ID が動的に割り当てられることにより、ドリフトが発生する可能性があります。- ユーザーとグループのホームディレクトリーと
/varディレクトリー 永続的に
/home → /var/homeに設定されたシステムの場合、最初のインストール後にコンテナーイメージで行われた/varへの変更は、その後の更新には適用されません。たとえば、コンテナービルドに
/var/home/someuser/.ssh/authorized_keysを注入した場合、既存のシステムは更新されたauthorized_keysファイルを取得しません。nss-altfilesの使用nss-altfilesは、システムユーザーを/usr/lib/passwdと/usr/lib/groupに分離します。この仕組みは、OSTree プロジェクトが/etc/passwdに関連する/etcの 3 方向マージを処理する方法と整合性を取るためのものです。現在、ローカルシステムで/etc/passwdファイルが何らかの方法で変更された場合、その後コンテナーイメージの/etc/passwdに対して行われた変更は適用されません。rpm-ostreeによってビルドされたベースイメージでは、nss-altfilesがデフォルトで有効になっています。また、ベースイメージには、UID または GID のドリフトを回避するために、NSS ファイルによって事前に割り当てられ、管理されるシステムユーザーがあります。
派生コンテナービルドでは、たとえば
/usr/lib/passwdにユーザーを追加することもできます。sysusers.dまたはDynamicUser=yesを使用します。systemdユニットでの DynamicUser=yes の使用システムユーザーの場合、可能な場合は
systemdDynamicUser=yesオプションを使用します。これは、潜在的な UID または GID のドリフトを回避できるため、パッケージのインストール時にユーザーまたはグループを割り当てるパターンよりもはるかに優れています。
systemd-sysusersの使用たとえば、派生ビルドでは
systemd-sysusers を使用します。詳細は、systemd-sysusers のドキュメントを参照してください。COPY mycustom-user.conf /usr/lib/sysusers.d
COPY mycustom-user.conf /usr/lib/sysusers.dCopy to Clipboard Copied! Toggle word wrap Toggle overflow sysusersツールは、必要に応じて起動時に従来の/etc/passwdファイルに変更を加えます。/etcが永続的であれば、UIDまたはGIDのドリフトを回避できます。つまり、UIDまたはGIDの割り当ては、特定のマシンがどのようにアップグレードされてきたかによって異なります。- ユーザーのマシンローカル状態
ファイルシステムのレイアウトは、ベースイメージによって異なります。
デフォルトでは、ユーザーデータはベースイメージに応じて、
/etc、/etc/passwd、/etc/shadowおよびgroupsと、/homeとの両方に保存されます。ただし、いずれの汎用ベースイメージもマシンローカルな永続状態である必要があります。このモデルでは、/homeは/var/home/userへのシンボリックリンクです。- システムプロビジョニング時のユーザーと SSH 鍵の注入
/etcと/varがデフォルトで永続化するように設定されたベースイメージの場合、Anaconda やキックスタートなどのインストーラーを使用してユーザーを注入できます。通常、汎用インストーラーは 1 回限りのブートストラップ用に設計されています。その後、設定はミュータブルなマシンローカル状態になり、他のメカニズムを使用して Day 2 操作で変更できるようになります。
Anaconda インストーラーを使用して初期パスワードを設定できます。ただし、この初期パスワードを変更するには、
passwdなどの別のシステム内ツールが必要です。これらのフローは
bootc-compatibleシステムでも同様に機能します。異なるシステム内ツールに変更する必要なく、ユーザーが汎用ベースイメージを直接インストールすることをサポートします。- 一時的なホームディレクトリー
多くのオペレーティングシステムのデプロイメントでは、永続的でミュータブルかつ実行可能な状態が最小限に抑えられます。これにより、ユーザーのホームディレクトリーが破損する可能性があります。
/homeディレクトリーをtmpfsとして設定すると、再起動後にユーザーデータが確実に消去されます。このアプローチは、一時的な/etcディレクトリーと組み合わせると特に効果的です。たとえば、SSH
authorized_keysやその他のファイルを注入するようにユーザーのホームディレクトリーをセットアップするには、systemdtmpfiles.dスニペットを使用します。f~ /home/user/.ssh/authorized_keys 600 user user - <base64 encoded data>
f~ /home/user/.ssh/authorized_keys 600 user user - <base64 encoded data>Copy to Clipboard Copied! Toggle word wrap Toggle overflow SSH は、
/usr/lib/tmpfiles.d/<username-keys.confとしてイメージ内に埋め込まれています。もう 1 つの例は、ネットワークからキーを取得して書き込むことができる、イメージに埋め込まれたサービスです。これはcloud-initで使用されるパターンです。- UID と GID のドリフト
-
/etc/passwdおよび同様のファイルは、名前と数値識別子間のマッピングです。マッピングが動的で、"ステートレス" なコンテナーイメージビルドと組み合わされると、問題が発生する可能性があります。各コンテナーイメージビルドでは、RPM のインストール順序やその他の理由により、UID が変更される場合があります。当該ユーザーが永続状態を維持する場合、これは問題になる可能性があります。このようなケースに対処するには、sysusers.dを使用するか、DynamicUser=yesを使用するように変換します。
14.2. Image Mode for RHEL でのシークレットの注入 リンクのコピーリンクがクリップボードにコピーされました!
Image Mode for RHEL には、シークレットに関する独自のメカニズムがありません。いくつかのケースでは、以下のようにコンテナープルシークレットをシステムに注入できます。
bootcが認証の必要なレジストリーから更新を取得するには、ファイルにプルシークレットを含める必要があります。次の例では、credsシークレットにレジストリープルシークレットが含まれています。FROM registry.redhat.io/rhel9/bootc-image-builder:latest COPY containers-auth.conf /usr/lib/tmpfiles.d/link-podman-credentials.conf RUN --mount=type=secret,id=creds,required=true cp /run/secrets/creds /usr/lib/container-auth.json && \ chmod 0600 /usr/lib/container-auth.json && \ ln -sr /usr/lib/container-auth.json /etc/ostree/auth.jsonFROM registry.redhat.io/rhel9/bootc-image-builder:latest COPY containers-auth.conf /usr/lib/tmpfiles.d/link-podman-credentials.conf RUN --mount=type=secret,id=creds,required=true cp /run/secrets/creds /usr/lib/container-auth.json && \ chmod 0600 /usr/lib/container-auth.json && \ ln -sr /usr/lib/container-auth.json /etc/ostree/auth.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow ビルドするには、
podman build --secret id=creds,src=$HOME/.docker/config.jsonを実行します。コンテナーイメージに埋め込まれた共通の永続ファイル (例:/usr/lib/container-auth.json) へのシンボリックリンクを両方の場所に対して使用することで、bootcと Podman に単一のプルシークレットを使用します。Podman がコンテナーイメージを取得するには、
/etc/containers/auth.jsonにプルシークレットを含めます。この設定では、2 つのスタックが/usr/lib/container-auth.jsonファイルを共有します。- コンテナービルドにシークレットを埋め込むことによるシークレットの注入
- レジストリーサーバーが適切に保護されている場合は、コンテナーイメージにシークレットを含めることができます。場合により、ブートストラップシークレットのみをコンテナーイメージに埋め込むことが実行可能なパターンになることがあります。特に、マシンをクラスターに対して認証するメカニズムと併用した場合が該当します。このパターンでは、プロビジョニングツールは、ホストシステムの一部として実行されるか、コンテナーイメージの一部として実行されるかに関係なく、ブートストラップシークレットを使用して SSH 鍵や証明書などの他のシークレットを注入または更新します。
- クラウドメタデータを使用したシークレットの注入
-
実稼働環境の Infrastructure as a Service (IaaS) システムのほとんどは、シークレット (特にブートストラップシークレット) をセキュアにホストできる、メタデータサーバーまたは同等のものをサポートします。コンテナーイメージには、これらのシークレットを取得するための
cloud-initやignitionなどのツールを含めることができます。 - ディスクイメージにシークレットを埋め込むことによるシークレットの注入
-
bootstrap secretsは、ディスクイメージにのみ埋め込むことができます。たとえば、AMI や OpenStack などの入力コンテナーイメージからクラウドディスクイメージを生成する場合、ディスクイメージには、実質的にマシンローカル状態であるシークレットが含まれることがあります。これらをローテーションするには、追加の管理ツールを使用するか、ディスクイメージを更新する必要があります。 - ベアメタルインストーラーを使用したシークレットの注入
- インストーラーツールは通常、シークレットを使用した設定の注入をサポートします。
systemd認証情報を使用したシークレットの注入-
systemdプロジェクトには、認証情報のデータをセキュアに取得してシステムやサービスに渡すための認証情報の概念があります。これは、一部のデプロイメント方法に適用されます。詳細は、systemd credentials のドキュメントを参照してください。
14.3. コンテナープルシークレットの設定 リンクのコピーリンクがクリップボードにコピーされました!
コンテナーイメージを取得するには、ホストの更新を含む "プルシークレット" を使用してホストシステムを設定する必要があります。詳細は、Image Mode for RHEL でのシークレットの注入 に関する付録を参照してください。
コンテナープルシークレットは、すでにビルドされたイメージに設定できます。ベアメタル用の Anaconda などの外部インストーラーや bootc-image-builder を使用する場合は、適切なプルシークレットを使用してシステムを設定する必要があります。
ホストの bootc 更新では、rpm-ostree と共有される /etc/ostree/auth.json ファイルに設定が書き込まれます。
Podman にはシステム全体の認証情報がありません。Podman は、次のディレクトリー配下にある containers-auth の場所を受け付けます。
-
/run: このディレクトリーの内容は再起動時に消去されます。これは望ましくありません。 -
/root: root のホームディレクトリーの一部。デフォルトではローカルで変更可能な状態です。
bootc と Podman の認証情報を統合するには、bootc と Podman の両方に単一のデフォルトのグローバルプルシークレットを使用します。次のコンテナービルドは、bootc と Podman の認証情報を統合する例です。この例では、creds という名前のシークレットに、ビルドするレジストリープルシークレットが含まれていることを想定しています。
手順
-
単一のプルシークレットを使用するために、
bootcと Podman の間にシンボリックリンクを作成します。シンボリックリンクを作成することにより、コンテナーイメージに埋め込まれる共通の永続ファイルに対する両方の場所を確保できます。 /usr/lib/container-auth.jsonファイルを作成します。FROM quay.io/<namespace>/<image>:<tag> COPY containers-auth.conf /usr/lib/tmpfiles.d/link-podman-credentials.conf RUN --mount=type=secret,id=creds,required=true cp /run/secrets/creds /usr/lib/container-auth.json && \ chmod 0600 /usr/lib/container-auth.json && \ ln -sr /usr/lib/container-auth.json /etc/ostree/auth.jsonFROM quay.io/<namespace>/<image>:<tag> COPY containers-auth.conf /usr/lib/tmpfiles.d/link-podman-credentials.conf RUN --mount=type=secret,id=creds,required=true cp /run/secrets/creds /usr/lib/container-auth.json && \ chmod 0600 /usr/lib/container-auth.json && \ ln -sr /usr/lib/container-auth.json /etc/ostree/auth.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow Containerfile を実行すると、次の操作が実行されます。
-
Containerfile により、
/run/containers/0/auth.jsonが一時的なランタイムファイルになります。 -
/usr/lib/container-auth.jsonへのシンボリックリンクが作成されます。 -
また、永続ファイルも作成されます。このファイルにも、
/etc/ostree/auth.jsonからのシンボリックリンクが設定されます。
-
Containerfile により、
14.4. レジストリーのプルシークレットの注入と TLS の無効化 リンクのコピーリンクがクリップボードにコピーされました!
コンテナー化された環境で、プライベートまたはセキュアでないレジストリーからイメージをプルできるように、コンテナーイメージを設定し、シークレットをプルし、システム内のレジストリーの TLS を無効にすることができます。
ベースイメージ内のレジストリーにアクセスするためのコンテナープルシークレットやその他の設定を含めることができます。ただし、Anaconda を使用してインストールする場合、ネットワーク経由で取得するときに対象のレジストリーにアクセスするために、インストール環境で "ブートストラップ" 設定の複製コピーが必要になる場合があります。
目的の bootc コンテナーイメージを取得する前にインストール環境に任意の変更を加えるには、Anaconda の %pre コマンドを使用できます。
auth.json ファイルの形式と設定の詳細は、containers-auth.json(5) を参照してください。
手順
プルシークレットを設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この設定では、システムが
/etc/ostree/auth.jsonに保存されている指定の認証情報を使用して、quay.ioからイメージをプルします。セキュアでないレジストリーの TLS を無効にします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この設定では、システムが TLS で保護されていないレジストリーからコンテナーイメージをプルします。この設定は開発や社内ネットワークで使用できます。
%pre は次の目的でも使用できます。
-
インストール環境に含まれているバイナリー (
curlなど) を使用して、ネットワークからデータを取得する。 -
update-ca-trustコマンドを使用して、信頼された認証局をインストール環境/etc/pki/ca-trust/source/anchorsに注入する。
同様に、/etc/containers ディレクトリーを変更することで、セキュアでないレジストリーを設定できます。
第15章 システムの設定 リンクのコピーリンクがクリップボードにコピーされました!
RHEL イメージモードのシステム設定には、オペレーティングシステムを構築、デプロイ、および管理するための Container-native のアプローチが含まれます。この方法は、特に registry.redhat.io/rhel9/rhel-bootc イメージに基づくコンテナーイメージを利用して、OS とその設定をカプセル化します。
15.1. 一時的なランタイムの再設定 リンクのコピーリンクがクリップボードにコピーされました!
ベースイメージ設定で動的な再設定を実行できます。たとえば、firewall-cmd --permanent コマンドを実行すると、再起動後も変更が永続的に適用されます。
/etc ディレクトリーはデフォルトで永続的です。ツールを使用して変更を実行する場合 (例: firewall-cmd --permanent)、システム上の /etc の内容がコンテナーイメージに記述されている内容と異なる可能性があります。
デフォルト設定では、まずベースイメージに変更を加え、実行中のシステムを再起動せずに変更をキューに入れます。その後、同時に書き込みを行って、メモリー内でのみ既存のシステムに変更を適用します。
バインドマウントを使用すると、/etc ディレクトリーを一時的に設定できます。この場合、etc ディレクトリーはマシンのローカルルートファイルシステムの一部になります。たとえば、Anaconda キックスタートを使用して静的 IP アドレスを注入すると、アップグレード後もそのアドレスが保持されます。
3-way マージがアップグレード間で適用されます。各 "デプロイメント" に専用の /etc のコピーがあります。
/runディレクトリー-
/runディレクトリーは、システムの再起動時に削除されるように定義されている API ファイルシステムです。/runディレクトリーは一時ファイルに使用します。 - 動的な再設定モデル
- Pull モデルでは、Podman API を使用して、ベースイメージに直接埋め込まれたコードや、リモートネットワークサーバーに接続して設定を行う特権コンテナーを含めることができます。その後、追加のコンテナーイメージを起動できます。
Push モデルでは、一部のワークロードが Ansible などのツールによって実装されます。
- systemd
-
/run/systemdディレクトリーに書き込むことで、動的な一時再設定に systemd ユニットを使用できます。たとえば、systemctl edit --runtime myservice.serviceは、変更を永続化せずに、myservice.serviceユニットの設定を動的に変更します。 - NetworkManager
-
一時的なネットワーク設定を適用するには、
/run/NetworkManager/conf.dディレクトリーを使用します。変更をメモリーにのみ書き込むには、nmcli connection modify --temporaryコマンドを使用します。--temporaryオプションを指定しないと、コマンドによって永続的な変更が書き込まれます。 - podman
-
コンテナーの終了時にコンテナーを自動的に削除するには、
podman run --rmコマンドを使用します。--rmオプションを指定しないと、システムの再起動後も保持されるコンテナーがpodman runコマンドによって作成されます。
15.2. Image Mode for RHEL での DNF の使用 リンクのコピーリンクがクリップボードにコピーされました!
rhel10/rhel-bootc コンテナーイメージには、dnf パッケージマネージャーが含まれています。dnf は、次のようなさまざまなユースケースで使用できます。
- コンテナービルドの一部として
dnfを使用する -
Containerfile で
RUN dnf installディレクティブを使用できます。 - 実行時に
dnfを使用する
dnf のバージョンによって機能が異なります。error: can’t create transaction lock on /usr/share/rpm/.rpm.lock (Read-only file system) というエラーが発生する場合があります。
bootc-usr-overlay コマンドを使用すると、/usr ディレクトリー用の書き込み可能なオーバーレイファイルシステムを作成できます。dnf install はこのオーバーレイに書き込みます。この機能を使用してデバッグツールをインストールできます。再起動すると変更内容が失われることに注意してください。
- ストレージの設定
サポートされているストレージテクノロジーは次のとおりです。
-
xfs/ext4 - 論理ボリューム管理 (LVM)
- Linux Unified Key Setup (LUKS)
-
ホストシステムに他のストレージパッケージを追加できます。
-
bootc-image-builderを使用したストレージ bootc-image-builder ツールを使用してディスクイメージを作成できます。パーティションとレイアウトに使用できる設定は、比較的固定されています。デフォルトのファイルシステムタイプは、コンテナーイメージの bootc インストール設定から取得されます。
bootc install を使用したストレージ 一律のストレージ設定には、bootc install to-disk コマンドを使用できます。より高度なインストールには、bootc install to-filesytem コマンドを使用できます。詳細は、to-filesystem を使用した高度なインストール を参照してください。
15.3. ネットワーク設定 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトイメージには NetworkManager 動的ネットワーク制御および設定システムが含まれており、bootc はケーブルが接続されているすべてのインターフェイスで DHCP を使用して接続を試みます。/run/NetworkManager/conf.d ディレクトリーをセットアップすることで、一時的なネットワーク設定を適用できます。
ただし、静的アドレス指定や、VLAN、ボンディング、ブリッジ、チームなどのより複雑なネットワークを使用する必要がある場合は、別の方法を使用できます。ネットワークを設定する方法に関係なく、NetworkManager の設定は NetworkManager キーファイルの形式を使用します。
- ホストネットワーク設定オプション
- 複雑なネットワーク設定では、多くの場合、マシンごとの状態も必要です。たとえば、静的 IP アドレスが含まれたマシン固有のコンテナーイメージを生成できます。ホストの MAC アドレスを検査して、イメージ内からネットワーク設定を生成するコードを含めることもできます。
- 利用可能なネットワーク設定オプション
静的 IP を設定するために使用できるオプションと、設定方法は次のとおりです。
Containerfile を使用する: 静的 IP を持つコンテナーイメージを作成するか、MAC アドレスに基づいてイメージ内からネットワーク設定を生成するコードを含めます。
- MAC アドレスまたはその他のアドレスをマッチさせるには、Device List Format で指定されている設定を使用します。
-
ネットワークを設定するには、起動済みのシステムで行うのと同様に、
nmcli connection addを使用できます。ただし、ビルド時には、明示的に--offline引数と組み合わせてコマンドを使用する必要があります。詳細は、nmcli を使用したイーサネット接続の設定 を参照してください。 ContainerFile 内の
nmcliコマンドの前に、必ず次のコマンドを追加してください。RUN nmcli --offline connection add
RUN nmcli --offline connection addCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
Anaconda を使用する場合: Anaconda キックスタートを使用して、ベアメタルインストール用に Wi-Fi を含むネットワークを設定できます。設定はデフォルトで
/etc/NetworkManager/system-connections/に保存され、基本的にマシン固有の状態として扱われます。 -
カーネル引数を使用する: 最初の起動時にカーネルパラメーターを追加して、ネットワーク設定を定義します。マシンの最初の起動時に、ネットワーク設定を定義するカーネル引数を入力します。カーネル引数のほとんどは、
dracut.cmdlineの man ページで定義されています。さまざまな方法を使用して、最初の起動時にこれらのカーネル引数を適用できます。bootc installを使用する場合、--kargを使用してマシンごとにカーネル引数を設定することもできます。 -
NetworkManager キーファイルを使用する:
nmcliまたはnm-initrd-generator
nmcli を使用して NetworkManager キーファイルを生成する
nmcli NetworkManager コマンドラインツールは、NetworkManager デーモンと通信せず、キーファイルの内容を標準出力に書き込むだけのオフラインモードを提供します。
作成する接続プロファイルごとに
nmcliツールを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
nmcli を使用して指定できるプロパティーのリストについては、設定の man ページを参照してください。Bash の自動補完が利用可能です。
nm-initrd-generator を使用して NetworkManager キーファイルを生成する
NetworkManager には、dracut カーネル引数構文からキーファイルを生成できる nm-initrd-generator ツールが含まれています。このツールを使用すると、カーネル引数からキーファイルに変換したり、少量の入力でキーファイルを素早く生成して、より詳細な設定を変更したりすることができます。
nm-initrd-generatorを使用してボンディングのキーファイルを生成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
このコマンドは、各インターフェイスに対して、bond0、ens3、ens2 の 3 つのキーファイルを生成します。生成された出力を使用して、さらに設定を追加したり、既存の設定を変更したりして、ファイルをコンテナーイメージにコミットできます。
静的 IP の設定
次の
dracutカーネル引数を使用できます。テンプレート:
ip=${ip}::${gateway}:${netmask}:${hostname}:${interface}:none:${nameserver}
ip=${ip}::${gateway}:${netmask}:${hostname}:${interface}:none:${nameserver}
以下に例を示します。
ip=10.10.10.10::10.10.10.1:255.255.255.0:myhostname:ens2:none:8.8.8.8
ip=10.10.10.10::10.10.10.1:255.255.255.0:myhostname:ens2:none:8.8.8.8
コンテナーイメージに埋め込まれた設定を書き込む
この形式は不変のイメージ状態の一部であるため、コンテナーイメージに埋め込まれた NetworkManager 設定を /usr/lib/NetworkManager/system-connections/ に保存します。コンテナーイメージの一部として /etc/NetworkManager/system-connections/ に設定を書き込むこともできます。デフォルトの OSTree 3 方向マージ (つまり、古いデフォルト設定、アクティブな /etc システム、および新しいデフォルト設定の使用) は、マシン固有の設定に適用されます。
キーファイルには 600 の root 専用アクセス権限が必要です。そうでない場合、NetworkManager はこのファイルを無視します。
イーサネットデバイスの自動設定を無効にする
デフォルトでは、NetworkManager はケーブルが接続されているすべてのインターフェイスで DHCP または SLAAC アドレスを使用して自動設定を試みます。一部のネットワーク環境では、これは望ましくない場合があります。そのためには、/usr/lib/NetworkManager/conf.d/noauto.conf などの設定ファイルを追加して、NetworkManager の動作を変更することができます。
Ethernet デバイスの
NetworkManager自動設定を無効にする[main] # Do not do automatic (DHCP or SLAAC) configuration on ethernet devices # with no other matching connections. no-auto-default=*
[main] # Do not do automatic (DHCP or SLAAC) configuration on ethernet devices # with no other matching connections. no-auto-default=*Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.4. Image Mode for RHEL でのホスト名の設定 リンクのコピーリンクがクリップボードにコピーされました!
システムにカスタムホスト名を設定するには、/etc/hostname ファイルを変更します。ホスト名は、Anaconda を使用するか、特権コンテナーを使用して設定できます。
システムを起動したら、hostnamectl コマンドを使用してホスト名を確認できます。
15.5. Image Mode for RHEL におけるプロキシー経由のインターネットアクセスの設定 リンクのコピーリンクがクリップボードにコピーされました!
プロキシーを使用したインターネットアクセスを必要とする環境にデプロイする場合は、サービスがリソースに想定どおりにアクセスできるようにサービスを設定する必要があります。
これを行うには、必要な環境変数を含む単一のファイルを設定で定義し、該当するすべてのサービスに systemd ドロップインユニットファイルを使用して、このファイルを参照します。
手順
- 一般的なプロキシー環境変数を定義すると、この共通ファイルは、その後インターネットへのアクセスを必要とする各サービスが明示的に参照する必要があります。
-
コアサービスのドロップインユニットを定義する
bootcおよびpodmanツールには、一般的にプロキシー設定が必要です。現時点では、bootcは常にsystemdユニットとして実行されるわけではありません。
/usr/lib/systemd/system/bootc-fetch-apply-updates.service.d/99-proxy.conf
# /usr/lib/systemd/system/bootc-fetch-apply-updates.service.d/99-proxy.conf
[Service]
EnvironmentFile=/etc/example-proxy.env
-
podman
systemdユニットのプロキシー使用の定義
Podman systemd 設定を使用して、同様に EnvironmentFile=/etc/example-proxy.env を追加します。podman およびコンテナーのプロキシー設定と環境設定は、root ユーザーとして /etc/containers/containers.conf 設定ファイルで設定するか、非 root ユーザーとして $HOME/.config/containers/containers.conf 設定ファイルで設定できます。
第16章 付録: コンテナーイメージのソースコードの取得 リンクのコピーリンクがクリップボードにコピーされました!
bootc イメージのソースコードは、Red Hat Ecosystem Catalog で提供されています。
手順
-
Red Hat Ecosystem Catalog にアクセスし、
rhel-bootcを検索します。 - Get this image タブで、Get the source をクリックし、指示に従います。
内容を展開すると、入力 RPM パッケージリストとその他のコンテンツリソースが
extra_src_dirディレクトリーで使用できるようになります。.tar ファイルは、入力 git リポジトリーのスナップショットであり、パッケージリストが記載された YAML ファイルを含んでいます。
第17章 付録: アップストリームプロジェクトへのコントリビューション リンクのコピーリンクがクリップボードにコピーされました!
以下のアップストリーム bootc プロジェクトでは、コントリビューションを歓迎しています。
- アップストリームの git リポジトリーは CentOS Stream にあります。
- CentOS Stream のソースは、主に Fedora アップストリームプロジェクト を追跡しています。