Translated message

A translation of this page exists in English.

コンテナーイメージのプルに関するファイアウォールの変更

更新 -

Red Hat コンテナーイメージレジストリーが変更されています。つまり、Red Hat レジストリーからイメージをプルする可能性がある docker/podman ユーザーは、場合によっては、ファイアウォール設定を調整する必要があります。この調整は 2023 年 5 月 1 日までに必ず行ってください。OpenShift ユーザーは、2022 年 6 月以降すでに Quay.io にアクセスしているため、影響を受けません。

変更対象

現在、すべてのイメージマニフェストとファイルシステム BLOB は、registry.redhat.io および registry.access.redhat.com から直接提供されています。今回の変更により、ファイルシステム BLOB は Quay.io から提供されることになります。コンテナーイメージをプルする際の問題を回避するには、これらのホスト名へのアウトバウンド TCP 接続 (ポート 80 および 443) を許可する必要があります。

  • cdn.quay.io
  • cdn01.quay.io
  • cdn02.quay.io
  • cdn03.quay.io

この変更は、特に registry.redhat.io または registry.access.redhat.com へのアウトバウンド接続を許可するファイアウォール設定に対して行う必要があります。この変更を適用した後も、これまでと同様に registry.redhat.io および registry.access.redhat.com からイメージをプルできます。引き続き Red Hat コンテナーイメージをプルするために、Quay.io ログインや Quay.io レジストリーとの直接対話は必要ありません。

この変更は、Red Hat レジストリーからイメージをプルする可能性のあるすべての製品に必要です。これまでに OpenShift インストール手順 を実行したことがある場合、または Quay.io レジストリーを使用する必要があった場合、これらのホストへのアウトバウンド接続は、ファイアウォール設定ですでに許可されている場合があります。Red Hat Ansible Automation Platform (AAP) や Red Hat Satellite など、Red Hat レジストリーからコンテナーイメージを同期またはダウンロードする他の製品では、上記のホストへのアウトバウンドアクセスを許可するために、関連するファイアウォールまたはプロキシーへの変更が必要になる場合があります。

ファイアウォールルールを設定する際は、IP アドレスの代わりにホスト名を使用することが推奨されます。詳細は、こちら のアーティクル記事を参照してください。

この変更が予定されている理由

2022 年 6 月以降、Red Hat OpenShift Operator インデックスイメージ (redhat/redhat/operator-index) は、Quay.io をバックエンドとして使用して、registry.redhat.io から提供されています。インストール手順で説明されているように、OpenShift 自体は、すでに Quay.io レジストリーと CDN ホストにアクセスする必要があるため、この変更は、その時点でお客様からのアクションを必要としませんでした。

これをすべての Red Hat コンテナーイメージに拡張します。これにより、お客様は Quay.io レジストリーの利点である高可用性を活用でき、同時に Red Hat によるコンテナーイメージの提供方法が簡素化され、将来的な機能強化への道を開くことになります。

テスト

レジストリーの変更前に、イメージプルが引き続き機能することを確認できます。これを実行するには、registry.redhat.io/redhat/redhat-operator-index:v4.12 イメージをプルします。これには、Quay.io でホストされているファイルシステム BLOB がすでに存在します。このイメージをプルするには、カスタマーポータルの認証情報を使用して、以下のコマンドを実行します。

# podman login registry.redhat.io
# podman pull registry.redhat.io/redhat/redhat-operator-index:v4.12
# echo $?

イメージが正常にプルされると、echo $? コマンドで "0" が 表示されます。

追加情報

この変更以外は、多くの点が以前と同じままとなっています。

  • コンテナーイメージのプル仕様は変更されていないため、registry.redhat.io および registry.access.redhat.com から引き続きイメージをプルできます。
  • Red Hat コンテナーイメージは、引き続き同じ方法、同じキーで署名されます。
  • コンテナーイメージのマニフェストは、registry.redhat.io および registry.access.redhat.com から直接提供されます。Quay.io CDN へのリダイレクトは、config BLOB およびファイルシステム BLOB のみを対象としています。
  • sha256 ダイジェストを使用してイメージをプルする場合は、引き続きスキーマ 2 ダイジェストを使用して行う必要があります (こちら のアーティクル記事を参照)。
  • イメージタグ、スキーマ 2 ダイジェスト、イメージ ID、署名に変更はありません。
  • 変更前にプルされたイメージは、引き続き有効であるため、再プルする必要はありません。
  • OpenShift または Kubernetes クラスターの場合、ImageContentSourcePolicy に関連する変更は必要ありません。
  • OpenShift または Kubernetes クラスターの場合、ノードの再起動、設定の変更、キャッシュの変更、いかなる種類のアップグレードも必要ありません。
  • registry.connect.redhat.com レジストリーは、この変更の影響を受けません。

Red Hat レジストリー、registry.redhat.io および registry.access.redhat.com は、HTTP 302 リダイレクト応答でヘッダーを返します。これにより、Quay.io CDN 内の特定のコンテンツのみへのアクセスが短期間許可されます。このメカニズムにより、イメージコンテンツを Quay.io CDN ホストから直接プルすることはできません。代わりに、コンテナーレジストリーを使用してプルする必要があります。Red Hat レジストリーは、Red Hat コンテナーイメージへのアクセスのみを提供します。

上記のホスト名へのアウトバウンド接続を許可すると、使用しているファイアウォールの特性に応じて、以下の問題が解決される可能性があります。

  • イメージをプルすると、接続が拒否される
  • イメージをプルする際に I/O タイムアウトが発生する
  • OpenShift または Kubernetes クラスター内でイメージをプルする際の ImagePullBackOff ステータス

以下は、さまざまなファイアウォール設定での "podman pull" で表示される可能性があるエラーの例です。

Trying to pull [...]...
WARN[0033] Failed, retrying in 1s ...(1/3).Error: copying system image from manifest list: parsing image configuration: Get "https://cdn02.quay.io/sha256/[...]": dial tcp [...]: i/o timeout
WARN[0065] Failed, retrying in 1s ...(2/3).Error: copying system image from manifest list: parsing image configuration: Get "https://cdn02.quay.io/sha256/[...]": dial tcp [...]: i/o timeout
WARN[0099] Failed, retrying in 1s ...(3/3).Error: copying system image from manifest list: parsing image configuration: Get "https://cdn02.quay.io/sha256/[...]": dial tcp [...]: i/o timeout
Error: copying system image from manifest list: parsing image configuration: Get "https://cdn02.quay.io/sha256/[...]": dial tcp [...]: i/o timeout

Trying to pull [...]...
WARN[0033] Failed, retrying in 1s ...(1/3).Error: copying system image from manifest list: parsing image configuration: Get "https://cdn02.quay.io/sha256/[...]": dial tcp [...]: connect: connection refused
WARN[0065] Failed, retrying in 1s ...(2/3).Error: copying system image from manifest list: parsing image configuration: Get "https://cdn02.quay.io/sha256/[...]": dial tcp [...]: connect: connection refused
WARN[0099] Failed, retrying in 1s ...(3/3).Error: copying system image from manifest list: parsing image configuration: Get "https://cdn02.quay.io/sha256/[...]": dial tcp [...]: connect: connection refused
Error: copying system image from manifest list: parsing image configuration: Get "https://cdn02.quay.io/sha256/[...]": dial tcp [...]: connect: connection refused

関連する変更

レジストリー API 仕様 で説明されているように、イメージマニフェストの要求に対する HTTP 応答には、docker-content-digest ヘッダーが含まれます。

最新のコンテナークライアントソフトウェアは、V2 スキーマ 2 のイメージマニフェスト形式を使用していますが、古い V2 スキーマ 1 形式のマニフェストは、引き続きタグで使用できます。これらのイメージコンテンツは変更前と同じですが、マニフェストの形式とファイルシステムレイヤーの BLOB 圧縮に技術的な違いがあります。この結果の 1 つは、変更前にプルされた V2 スキーマ 1 マニフェストが、変更後に同じタグからプルされた場合と比較して、異なるマニフェストダイジェストを持つことです。もう 1 つは、一部のファイルシステムレイヤー BLOB ダイジェストも、(圧縮されていないコンテンツは同一であるにもかかわらず) 変更の前後で異なることです。config BLOB の "diff_ids" は、圧縮されていないコンテンツを参照し、変更されません。

リポジトリー内のタグのリストを取得すると、ページネーションされた応答が返されます。最初の 50 個のタグがまず返され、次のページに使用する URL を示すヘッダーが付けられます。このページネーションスキームの詳細は、Docker Registry HTTP API V2 仕様 で説明されており、準拠ツール (skopeo など) はその使用方法をすでに理解しています。

サポートが必要な場合

Red Hat アカウントチームまたは Red Hat パートナーのサポートを受けることができます。あるいは、Red Hat サポートチーム (https://access.redhat.com/support/) までお問い合わせください。

Comments