Зашто 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-оване датотеке; конфигурација демона и окружење контејнера нису складишта тајни.

Повезани чланци