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

Падобныя артыкулы