Гайд з Docker · 1 хв читання

Docker за проксі: демон, збірка і compose

Docker потребує проксі у трьох різних місцях: демон, що тягне образи, збірка, яка виконує команди, і самі контейнери. Налаштуєте не те — і pull усе одно падатиме. Розбираємо кожне з правильною областю дії.

Почати

Три рівні — три конфігурації

Скарга «я виставив http_proxy, а docker pull усе одно падає» така поширена тому, що в Docker три незалежні мережеві контексти, а змінні оточення вашої оболонки чіпають лише один із них. Перший: образи з реєстру тягне демон (dockerd) — він працює як системна служба й бере проксі з власного конфігу, а не з вашої оболонки. Другий: під час складання кожен крок RUN виконується в тимчасовому контейнері, якому потрібен свій проксі, щоб дістатися мережі. Третій: запущеному контейнеру проксі потрібен, якщо застосунок усередині сам ходить назовні.

Усі три використовують HTTP-ендпоінт s4m на порту 3128 з автентифікацією USER:PASS. Сучасний спосіб налаштувати складання й запуск — конфіг клієнта Docker ~/.docker/config.json: він автоматично підставляє налаштування проксі у складання та в docker run; сам демон налаштовується через systemd drop-in або налаштування Docker Desktop. Дивіться сторінку проксі; природний доповнювач — гайди про npm/yarn і pip/conda для того, що працює всередині ваших образів.

Налаштуйте всі три рівні

Демон — через systemd drop-in, складання й запуск — через docker config.json, плюс запасний варіант для compose. Замініть USER:PASS.

bash
# --- 1) DAEMON (image pulls): systemd drop-in on Linux ---
sudo mkdir -p /etc/systemd/system/docker.service.d
sudo tee /etc/systemd/system/docker.service.d/http-proxy.conf >/dev/null <<'CONF'
[Service]
Environment="HTTP_PROXY=http://USER:[email protected]:3128"
Environment="HTTPS_PROXY=http://USER:[email protected]:3128"
Environment="NO_PROXY=localhost,127.0.0.1,.internal"
CONF
sudo systemctl daemon-reload && sudo systemctl restart docker

# --- 2) BUILDS + RUNS: ~/.docker/config.json (injected automatically) ---
cat > ~/.docker/config.json <<'JSON'
{
  "proxies": {
    "default": {
      "httpProxy":  "http://USER:[email protected]:3128",
      "httpsProxy": "http://USER:[email protected]:3128",
      "noProxy":    "localhost,127.0.0.1,.internal"
    }
  }
}
JSON

# --- 3) docker-compose fallback (per-service build args) ---
# services:
#   app:
#     build:
#       context: .
#       args:
#         HTTP_PROXY:  http://USER:[email protected]:3128
#         HTTPS_PROXY: http://USER:[email protected]:3128

Щоб docker pull і build запрацювали

Лагодьте рівні в тому порядку, в якому зазвичай з'являються збої.

Спершу полагодьте демона

Якщо docker pull падає, демон не дістає реєстру. Додайте systemd drop-in із HTTP_PROXY/HTTPS_PROXY, зробіть daemon-reload і перезапустіть docker. У Docker Desktop проксі задається в Settings.

Налаштуйте клієнт для складання

Додайте блок proxies у ~/.docker/config.json, щоб docker build і docker run самі підставляли проксі в кожен крок і кожен контейнер — Dockerfile правити не доведеться.

Скрізь пропишіть NO_PROXY

Внесіть localhost, 127.0.0.1 і всі внутрішні реєстри та сервіси в NO_PROXY на кожному рівні, щоб внутрішній трафік даремно не йшов назовні через проксі.

Перевірте кожен рівень

Перевіряйте так: docker pull hello-world (демон), складання з apt-get або pip (build) і контейнер, який curl'ом стукає в ендпоінт, що віддає IP (runtime).

Межі, секрети й чесність

Два застереження. Перше: не залишайте облікові дані проксі в шарах образу. Змінні оточення з проксі, задані в Dockerfile через ENV, запікаються в образ; беріть натомість build args або підстановку з клієнтського config.json, щоб облікові дані лишалися на машині складання. Друге: будьте точні з NO_PROXY — забутий запис для внутрішнього реєстру означає, що Docker полізе до нього через зовнішній проксі й впаде так, що причину відразу не зрозумієш.

HTTP-проксі s4m — це дата-центровий ендпоінт з автентифікацією й оплатою за фактичний трафік, добре придатний для CI-збірників і DevOps-машин, яким треба тягнути образи та пакети з-за контрольованого виходу в мережу. Він не резидентний, і це forward-проксі, а не дзеркало чи кеш реєстру: якщо потрібне кешування, підніміть поруч дзеркало реєстру. Коли вашому парку збірників потрібен один вихідний IP для білого списку, додайте виділений персональний IP. 407 у будь-якому місці означає невірні облікові дані проксі — дивіться гайд про 407. Перевірити ендпоінт можна інструментами.

FAQ

Відповіді на питання

Чому docker pull падає, хоча я виставив http_proxy в оболонці?

Бо образи тягне демон, а не ваша оболонка. Пропишіть проксі для dockerd через systemd drop-in (або в налаштуваннях Docker Desktop) зі змінними HTTP_PROXY/HTTPS_PROXY, потім daemon-reload і перезапуск docker.

Як пустити docker build і docker run через проксі, не чіпаючи Dockerfile?

Додайте блок proxies у ~/.docker/config.json. Клієнт Docker сам підставляє httpProxy/httpsProxy у кожен крок складання й у кожен контейнер, тож правити Dockerfile не потрібно.

Як не занести облікові дані проксі в образ?

Не задавайте їх через ENV у Dockerfile — так вони запікаються в шари. Використовуйте build args або підстановку з клієнтського config.json, щоб облікові дані лишалися на машині складання, а не в готовому образі.

Чи дає s4m дзеркало або кеш реєстру?

Ні. s4m — це forward-проксі в дата-центрі для вихідного трафіку, а не кеш реєстру. Щоб кешувати образи, підніміть дзеркало реєстру і за потреби пустіть його через проксі.

Читайте далі

Вам також може сподобатися

Як приховати справжню IP-адресу вашого сервера

Читати →

Що таке проксі SOCKS5?

Читати →

Як налаштувати WireGuard VPN, крок за кроком

Читати →

Як використовувати проксі для веб-скрапінгу

Читати →

Тягніть образи й складайте через проксі

Пустіть демон Docker, складання й контейнери через HTTP-ендпоінт з автентифікацією на proxy.s4m.online:3128. Оплата за фактичний трафік, виділений IP для білих списків у CI.

Переглянути ціни на проксіДивитись ціни

Цю сторінку знаходять за запитами

Реальні пошукові фрази, на які відповідає ця сторінка — за посиланнями відкриються матеріали, що розкривають тему глибше.