Изтегляния на образи от ECR: заобикаляне на прокси за изтегляне на слоеве от S3
Проследявайте изтеглянията на образи отвъд хоста на регистъра, когато частен маршрут към ECR все още изпраща изтеглянето на слоеве към корпоративно прокси.
Входът в ECR и извличането на манифест могат да работят, докато даден слой на образа засяда. Amazon ECR съхранява слоевете в S3 и указанията му за VPC крайна точка разглеждат ECR API, регистъра и пътя за извличане от S3 поотделно.
- Намерете името на хоста на неуспешния слой.Използвайте името на хоста от действителната заявка, вместо да предполагате, че заобикалянето на регистъра покрива цялото изтегляне.
- Открийте изпращача.При изтегляне с Docker прегледайте прокси конфигурацията на демона. Пример за собствен daemon.json на Docker Engine държи частните пътища за слоеве на ECR и S3 заедно. Променливи на средата, предназначени за нов контейнер на приложение, не могат да конфигурират изтегляне на образ, което се случва преди този контейнер да съществува.
- Проверете предвидения път към S3.Съпоставете записите за заобикаляне с регионалните имена на крайни точки и граматиката, поддържана от клиента. Частен DNS, таблици за маршрутизиране, политика на крайната точка и разрешения също трябва да поддържат този маршрут.
| Наблюдаван отказ | Какво ви казва |
|---|---|
| Отхвърляне от прокси | Заявката за слоя е достигнала до посредник. |
| Изтичане на времето за директна връзка | Заобикалянето може да е избрало директно маршрутизиране, но този маршрут все още може да е неизползваем. |
Избягвайте да заменяте един липсващ хост на слой с непрегледано изключение за всяка услуга в домейна на доставчика. Директното изключение не може да създаде липсващ маршрут към шлюз.
Използвайте заявките на действителния образ и актуалните инструкции на доставчика. Специално съдържание, включително чужди слоеве на Windows, може да въведе други източници; исторически списък с разрешени два хоста не е длъжен да ги покрива.