Почему docker pull игнорирует прокси-настройки контейнера

Настройте компонент Docker, который действительно загружает образы, вместо ожидания, что переменные контейнера управляют демоном.

Если docker pull не удался, настройте демон Docker или Docker Desktop. Образ загружается до того, как контейнер приложения сможет прочитать свои переменные прокси.

Нативный Docker Engine

Объедините этот раздел с существующей прокси-конфигурацией демона, заменив документационную точку и сохранив посторонние настройки. Для тестов загрузки публичных образов, где разрешены публичные прокси, список HTTP-прокси даёт кандидатов:

{
  "proxies": {
    "http-proxy": "http://203.0.113.10:8080",
    "https-proxy": "http://203.0.113.10:8080",
    "no-proxy": "localhost,127.0.0.1,registry.example.internal"
  }
}

Ключи демона с дефисами отличаются от ключей camelCase в ~/.docker/config.json клиента Docker. Прокси-раздел клиента задаёт переменные окружения для новых контейнеров и сборок; он не настраивает ни загрузки демона, ни окружения уже существующих контейнеров.

Выполните документированный для установки перезапуск демона, запланировав его влияние на текущие нагрузки. Демон также может получить переменные прокси в окружении запуска; последующий export в терминале не обновляет уже работающую службу.

Docker Desktop

Используйте настройки прокси Desktop. Docker указывает, что Desktop игнорирует прокси-записи в daemon.json, поэтому постоянное изменение примера нативного Engine не настроит маршрут этого продукта.

После обновления нужного компонента повторите загрузку образа. Разберите, что не удалось: доступ к реестру, аутентификация, перенаправления или загрузка слоёв. Успешный HTTP-запрос внутри существующего контейнера проверяет только маршрут этого приложения. Не включайте учётные данные прокси в общие снимки экрана и закоммиченные файлы; конфигурация демона и окружение контейнера не являются хранилищами секретов.

Похожие статьи