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