第6章 再現可能なコンテナービルドの概要
Podman と Buildah によって再現可能なビルドを使用して、同じソースコードから同じコンテナーイメージを作成します。この一貫性により、サプライチェーンのセキュリティーが確保され、ストレージと帯域幅の使用量を削減できます。
イメージ間の変更が少ないほど、あるイメージのバージョンを新しいバージョンに移行するときに、レジストリーから取得する必要があるデータの量を減らすことができます。再現可能なコンテナービルドは、サプライチェーンのセキュリティーの確保、信頼性の高いソフトウェアデプロイの支援、効果的なデバッグの促進に不可欠です。
mtime の 更新などの変更は、ユーザーが基となるデータに変更を加えることなく同一の RPM をインストールする場合でも、ストレージ要件を倍増させる可能性があります。この動作はレジストリーのストレージ使用量を増加させ、機能的な変更がない場合でも、ユーザーに新しいレイヤーの取得を要求します。これは、高速なアップデートに依存する rhel-bootc や RHEL AI などの環境でのアップデート速度を低下させます。
6.1. 再現可能なコンテナービルドの利点 リンクのコピーリンクがクリップボードにコピーされました!
RHEL コンテナーの再現可能なビルドでは、ソースコードとビルド環境に変更がない限り、イメージレイヤーの一貫性が確保されます。これにより、レジストリーストレージが削減され、更新ペイロードのサイズが小さくなり、ダウンロードが高速化されます。
このプロセスにより、レイヤーキャッシュの効率が最大化され、同一データの冗長な保存と転送が防止されます。再現可能なコンテナービルドの主な利点は次のとおりです。
- レジストリーストレージの削減: イメージが更新されたときに、変更されたレイヤーのみが保存されます。再現可能なビルドは、非決定論的な要因 (タイムスタンプ、ファイルの順序、メタデータ) による変更を防ぎ、同じソースコードから必ず同一のイメージが生成されるようにすることで、余計なストレージ消費を回避します。
- 効率的で小さい更新ペイロード: セキュリティーパッチなどのコンテナーの軽微な更新の場合、イメージ全体ではなく、変更されたレイヤーだけをダウンロードするだけで済みます。また、再現可能なビルドでは、ソースの更新時に、影響を受けるレイヤーしか変更されません。これは、わずかなコード変更でも複数のレイヤーが変わる可能性がある再現不可能なビルドとは異なります。
- ダウンロードの高速化: コンテナーの再現可能なビルドは、効率的なキャッシュとネットワークトラフィックの削減によってダウンロードを高速化し、ビルドシステムとエンドユーザーの両方を最適化します。