第6章 再現可能なコンテナービルドの概要
Red Hat Enterprise Linux (RHEL) は、Red Hat のツールである Podman および Buildah を使用した再現可能なコンテナービルドをサポートするようになりました。この新機能は、ユーザーが同じ入力情報を使用して異なる時刻にイメージをビルドした際に生じるイメージの差分を削減します。イメージ間の変更が少ないほど、あるイメージのバージョンを新しいバージョンに移行するときに、レジストリーから取得する必要があるデータの量を減らすことができます。再現可能なコンテナービルドは、サプライチェーンのセキュリティーの確保、信頼性の高いソフトウェアデプロイの支援、効果的なデバッグの促進に不可欠です。
以前から、コンテナーイメージのサイズが増大し続け、更新ペイロードのサイズに関するお客様の懸念が高まっていました。これにより、tarball の作成に関連する課題や制限がさらに拡大しています。Konflux のようなシステムでは、Git コミットごとに新しい tarball が生成されるため、イメージ全体を完全に再ダウンロードする必要があります。mtime の変更などの要因により、ユーザーが同じ RPM をインストールした場合であっても、基礎となるデータには変更がないにもかかわらず、必要なストレージ容量が倍増します。これにより、レジストリーのストレージに負担がかかるだけでなく、変更が発生していない場合でも、クライアントが新しいレイヤーをプルする必要が生じます。この状況は、より高速な更新を優先する rhel-bootc や RHEL AI などの環境において、問題をさらに悪化させます。
6.1. 再現可能なコンテナービルドの利点 リンクのコピーリンクがクリップボードにコピーされました!
RHEL コンテナーの再現可能なビルドでは、ソースコードとビルド環境に変更がない限り、イメージレイヤーの一貫性が確保されます。これにより、レジストリーストレージが削減され、更新ペイロードのサイズが小さくなり、ダウンロードが高速化されます。このプロセスにより、レイヤーキャッシュの効率が最大化され、同一データの冗長な保存と転送が防止されます。再現可能なコンテナービルドの主な利点は次のとおりです。
- レジストリーストレージの削減: イメージが更新されたときに、変更されたレイヤーのみが保存されます。再現可能なビルドは、非決定論的な要因 (タイムスタンプ、ファイルの順序、メタデータ) による変更を防ぎ、同じソースコードから必ず同一のイメージが生成されるようにすることで、余計なストレージ消費を回避します。
- 効率的で小さい更新ペイロード: セキュリティーパッチなどのコンテナーの軽微な更新の場合、イメージ全体ではなく、変更されたレイヤーだけをダウンロードするだけで済みます。また、再現可能なビルドでは、ソースの更新時に、影響を受けるレイヤーしか変更されません。これは、わずかなコード変更でも複数のレイヤーが変わる可能性がある再現不可能なビルドとは異なります。
- ダウンロードの高速化: コンテナーの再現可能なビルドは、効率的なキャッシュとネットワークトラフィックの削減によってダウンロードを高速化し、ビルドシステムとエンドユーザーの両方を最適化します。