Завантаження базових образів Docker: проксі збирача та аргументи build
Аргументи проксі, що передаються крокам збирання, не налаштовують кожен запит до реєстру, який виконує збирач. Знайдіть збирача, який розв'язує базовий образ.
Збирання може завершитися помилкою під час розв'язання FROM ще до запуску будь-якого кроку завантаження пакетів у Dockerfile. Клієнту реєстру збирача потрібен власний маршрут, щоб отримати цей базовий образ.
| Операція | Компонент, якому потрібен маршрут |
|---|---|
| Розв'язати й отримати базовий образ | Клієнт реєстру збирача |
| Завантаження під час RUN | Процес, що виконує крок збирання |
| Виклик API під час виконання | Застосунок, що працює |
Знайдіть збирача
Стандартний драйвер Docker будується навколо демона. Інші драйвери Buildx можуть використовувати окремий контейнер BuildKit, Kubernetes або віддалений сервіс. Налаштуйте підтримуваний вибраним драйвером механізм проксі там, де працює цей worker.
Loopback-проксі на ноутбуці не доступний автоматично з віддаленого worker, а редагування локального демона не переналаштовує цей віддалений збирач.
ARG перед FROM може допомогти вибрати посилання на образ. Однак це не налаштовує мережевий маршрут клієнта реєстру. Пізніші команди RUN, які записують налаштування пакетів або встановлюють сертифікати, не можуть виправити цей попередній запит.
Довіра, облікові записи та кешовані дані
Схвалений матеріал CA має бути доступним компоненту, який перевіряє початкове з'єднання з реєстром. Облікові дані реєстру та проксі дають права різним сторонам; вхід у реєстр не може відповісти на 407 проксі.
Worker, який повторно використовує кешовані дані образу, може не повторити той самий мережевий запит, що й новий worker. Порівняйте фактично зафіксовану операцію. Коли доступ до базового образу працює через передбачений маршрут, діагностуйте будь-яке подальше завантаження у кроці збирання на цій наступній межі.