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