第3章 論理的にバインドされたイメージのビルドと管理

論理的にバインドされたイメージを使用することで、コンテナーアプリケーションイメージをベース bootc システムイメージに関連付けることができます。デフォルトでは、podman などによって実行されるアプリケーションコンテナーには、ホストのアップグレードに依存しないライフサイクルがあります。これらのコンテナーはいつでも追加または削除でき、コンテナーイメージが存在しない場合は通常、起動後にオンデマンドで取得されます。

論理的にバインドされたイメージの主な利点は、この方法でバインドされたアプリケーションコンテナーのライフサイクルがホストのアップグレードと連動し、ホストが新しいオペレーティングシステムで再起動する 前に コンテナーが利用可能になる点です。このようにバインドされたコンテナーイメージは、bootc コンテナーが参照している限り存在します。

以下は、通常はホスト外部では更新されない、ライフサイクルにバインドされたワークロードの例です。

このようなタイプのワークロードでは通常、ネットワークが利用可能になる前に、ブートプロセスの非常に早い段階からコンテナーを起動することが重要です。論理的にバインドされたイメージを使用すると、ベース bootc イメージ内のバイナリーの ExecStart= を使用するのと同じ信頼性でコンテナーを起動できます (多くの場合、systemd 経由)。

論理的にバインド という用語は、アプリケーションコンテナーのコンテンツが bootc コンテナーイメージに物理的に保存される、物理的にバインドされたイメージの別のモデルと対比されることもあります。物理的ではなく、論理的にバインドする利点として主に、変更なしのアプリケーションコンテナーイメージをダウンロードし直すことなく、bootc システムを更新できる点が挙げられます。

論理的にバインドされたイメージを使用する場合、システムが論理的にバインドされたイメージをインストールできるように、複数のコンテナーイメージを管理する必要があります。これは利点であると同時に欠点でもあります。たとえば、非接続インストールまたはオフラインインストールの場合は、1 つのコンテナーだけでなく、すべてのコンテナーをミラーリングする必要があります。アプリケーションイメージは、.image ファイルまたは同等のファイルとしてベースイメージからのみ参照されます。