第6章 再現可能なコンテナービルドの概要


Red Hat Enterprise Linux (RHEL) は、Red Hat のツールである Podman および Buildah を使用した再現可能なコンテナービルドをサポートするようになりました。この新機能は、ユーザーが同じ入力情報を使用して異なる時刻にイメージをビルドした際に生じるイメージの差分を削減します。イメージ間の変更が少ないほど、あるイメージのバージョンを新しいバージョンに移行するときに、レジストリーから取得する必要があるデータの量を減らすことができます。再現可能なコンテナービルドは、サプライチェーンのセキュリティーの確保、信頼性の高いソフトウェアデプロイの支援、効果的なデバッグの促進に不可欠です。

以前から、コンテナーイメージのサイズが増大し続け、更新ペイロードのサイズに関するお客様の懸念が高まっていました。これにより、tarball の作成に関連する課題や制限がさらに拡大しています。Konflux のようなシステムでは、Git コミットごとに新しい tarball が生成されるため、イメージ全体を完全に再ダウンロードする必要があります。mtime の変更などの要因により、ユーザーが同じ RPM をインストールした場合であっても、基礎となるデータには変更がないにもかかわらず、必要なストレージ容量が倍増します。これにより、レジストリーのストレージに負担がかかるだけでなく、変更が発生していない場合でも、クライアントが新しいレイヤーをプルする必要が生じます。この状況は、より高速な更新を優先する rhel-bootc や RHEL AI などの環境において、問題をさらに悪化させます。

6.1. 再現可能なコンテナービルドの利点

RHEL コンテナーの再現可能なビルドでは、ソースコードとビルド環境に変更がない限り、イメージレイヤーの一貫性が確保されます。これにより、レジストリーストレージが削減され、更新ペイロードのサイズが小さくなり、ダウンロードが高速化されます。このプロセスにより、レイヤーキャッシュの効率が最大化され、同一データの冗長な保存と転送が防止されます。再現可能なコンテナービルドの主な利点は次のとおりです。

  • レジストリーストレージの削減: イメージが更新されたときに、変更されたレイヤーのみが保存されます。再現可能なビルドは、非決定論的な要因 (タイムスタンプ、ファイルの順序、メタデータ) による変更を防ぎ、同じソースコードから必ず同一のイメージが生成されるようにすることで、余計なストレージ消費を回避します。
  • 効率的で小さい更新ペイロード: セキュリティーパッチなどのコンテナーの軽微な更新の場合、イメージ全体ではなく、変更されたレイヤーだけをダウンロードするだけで済みます。また、再現可能なビルドでは、ソースの更新時に、影響を受けるレイヤーしか変更されません。これは、わずかなコード変更でも複数のレイヤーが変わる可能性がある再現不可能なビルドとは異なります。
  • ダウンロードの高速化: コンテナーの再現可能なビルドは、効率的なキャッシュとネットワークトラフィックの削減によってダウンロードを高速化し、ビルドシステムとエンドユーザーの両方を最適化します。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat