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


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

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