Защо 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 заявка в съществуващ контейнер проверява само маршрута на това приложение. Пазете прокси данните за вход извън споделени снимки и commit-нати файлове; конфигурацията на демона и средата на контейнера не са хранилища за тайни.

Подобни статии