ECR イメージプル: S3 レイヤーダウンロードのプロキシ迂回
プライベート ECR ルートが依然としてレイヤーダウンロードを社内プロキシへ送っている場合、レジストリホストの先までイメージプルを追跡します。
ECR へのログインとマニフェスト取得が機能していても、イメージレイヤーが止まることがあります。Amazon ECR はレイヤーを S3 に保存しており、VPC エンドポイントのガイダンスでは ECR API、レジストリ、S3 取得経路を別々に扱っています。
- 失敗したレイヤーのホスト名を特定します。レジストリのバイパスがプル全体をカバーすると決めつけず、実際のリクエストからホスト名を取得してください。
- 送信元を特定します。Docker プルの場合は、デーモンのプロキシ設定を確認します。ネイティブな Docker Engine の daemon.json の例は、プライベートな ECR と S3 のレイヤー経路をまとめて保持します。新しいアプリケーションコンテナ向けの環境変数では、そのコンテナが存在する前に発生するイメージダウンロードを設定できません。
- 想定される S3 経路を確認します。バイパス項目をリージョナルエンドポイント名とクライアントがサポートする文法に一致させます。プライベート DNS、ルートテーブル、エンドポイントポリシー、アクセス許可もその経路を支える必要があります。
| 観察された障害 | そこから分かること |
|---|---|
| プロキシによる拒否 | レイヤーリクエストが仲介者に到達した。 |
| 直接接続のタイムアウト | バイパスが直接ルーティングを選んだ可能性はあるが、その経路が使えないこともある。 |
プロバイダーのドメイン内のすべてのサービスに対して、未検討の例外で不足しているレイヤーホストを置き換えるのは避けてください。直接の例外では、不足しているゲートウェイ経路を作ることはできません。
実際のイメージのリクエストとプロバイダーの現在の指示を使用してください。外部の Windows レイヤーを含む特殊な内容は、別の取得元を導入する可能性があります。過去の 2 ホストの許可リストがそれらをカバーする必要はありません。