Чому 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-запит усередині наявного контейнера перевіряє лише маршрут цього застосунку. Не включайте облікові дані проксі у спільні знімки екрана й закомічені файли; конфігурація демона та середовище контейнера не є сховищами секретів.

Схожі статті