Завантаження образів з ECR: обхід проксі для завантаження шарів S3
Відстежуйте завантаження образів далі за хост реєстру, коли приватний маршрут ECR усе ще надсилає завантаження шарів до корпоративного проксі.
Вхід в ECR і отримання маніфесту можуть працювати, поки шар образу зупиняється. Amazon ECR зберігає шари в S3, і його настанови щодо кінцевої точки VPC розглядають ECR API, реєстр і шлях отримання з S3 окремо.
- Знайдіть ім'я хоста шару, що не вдався.Беріть ім'я хоста з фактичного запиту, а не припускайте, що обхід реєстру охоплює все завантаження.
- Визначте відправника.Під час завантаження Docker перевірте конфігурацію проксі демона. Приклад власного daemon.json Docker Engine тримає приватні шляхи шарів ECR і S3 разом. Змінні середовища, призначені для нового контейнера застосунку, не можуть налаштувати завантаження образу, яке відбувається до появи цього контейнера.
- Перевірте передбачуваний шлях S3.Зіставте записи обходу з регіональними іменами кінцевих точок і граматикою, яку підтримує клієнт. Приватний DNS, таблиці маршрутизації, політика кінцевої точки та дозволи також мають підтримувати цей маршрут.
| Спостережуваний збій | Що це вам каже |
|---|---|
| Відмова проксі | Запит шару дійшов до посередника. |
| Час очікування прямого з'єднання | Обхід міг вибрати пряму маршрутизацію, але цей маршрут усе ще може бути непридатним. |
Уникайте заміни одного відсутнього хоста шару неперевіреним винятком для кожної служби в домені постачальника. Прямий виняток не може створити відсутній маршрут шлюзу.
Використовуйте запити фактичного образу та поточні інструкції постачальника. Особливий вміст, зокрема сторонні шари Windows, може додавати інші джерела; історичний список дозволених із двох хостів не зобов'язаний їх покривати.