Налаштування проксі Docker

Налаштування проксі Docker передбачає конфігурацію окремих контейнерів, сервісів docker-compose або самого демона Docker для маршрутизації вихідного мережевого трафіку через проміжний проксі-сервер для таких завдань, як завантаження образів, збірка або доступ до зовнішніх ресурсів із програм.

Навіщо використовувати проксі з Docker?

Інтеграція проксі з середовищами Docker відповідає кільком поширеним вимогам:

• Контроль доступу до Інтернету: У корпоративних або обмежених мережевих середовищах прямий доступ до Інтернету з серверів збірки або контейнерів може бути заборонений. Проксі діє як контрольований шлюз.
• Сканування та фільтрація безпеки: Проксі можуть перехоплювати та сканувати вихідний трафік з контейнерів на наявність шкідливого вмісту або застосовувати політики вмісту.
• Кешування: Проксі можуть кешувати часто використовувані зовнішні ресурси (наприклад, репозиторії менеджерів пакетів, базові образи), зменшуючи використання пропускної здатності та прискорюючи збірки/завантаження.
• Анонімність/Розблокування географічних обмежень: Хоча це менш поширено в корпоративних налаштуваннях, проксі можуть маскувати вихідну IP-адресу або обходити географічні обмеження.

Типи конфігурацій проксі

Існує два основні контексти для проксі-серверів у Docker:

1. Проксі демона Docker: Конфігурує сам демон Docker для використання проксі для таких операцій, як завантаження базових образів, доступ до віддалених реєстрів або під час процесу збірки (для команд типу RUN apt-get update).
2. Проксі контейнера/сервісу: Конфігурує окремі контейнери або сервіси в docker-compose для використання проксі для їхнього власного вихідного трафіку програм під час виконання.

Ці конфігурації є незалежними, і часто обидві потрібні для повного налаштування.

Конфігурація проксі демона Docker

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

Для хостів Linux на базі systemd

Більшість сучасних дистрибутивів Linux використовують systemd. Створіть каталог для служби Docker:

sudo mkdir -p /etc/systemd/system/docker.service.d

Створіть файл конфігурації (наприклад, http-proxy.conf) у цьому каталозі:

sudo nano /etc/systemd/system/docker.service.d/http-proxy.conf

Додайте наступний вміст, замінивши YOUR_PROXY_HOST та YOUR_PROXY_PORT на дані вашого проксі:

[Service]
Environment="HTTP_PROXY=http://YOUR_PROXY_HOST:YOUR_PROXY_PORT"
Environment="HTTPS_PROXY=http://YOUR_PROXY_HOST:YOUR_PROXY_PORT"
Environment="NO_PROXY=localhost,127.0.0.1,::1,YOUR_DOCKER_NETWORK_CIDR,YOUR_INTERNAL_DOMAINS"

Примітка:
* HTTP_PROXY та HTTPS_PROXY зазвичай повинні використовувати схему http://, навіть для HTTPS-трафіку, оскільки проксі-сервер обробляє узгодження TLS.
* NO_PROXY є критично важливим. Він запобігає проходженню трафіку до вказаних хостів або мереж через проксі. Включіть localhost, 127.0.0.1, ::1 та будь-які внутрішні мережі Docker (наприклад, 172.17.0.0/16 для мережі мосту за замовчуванням або власні CIDR мережі), щоб забезпечити безперебійний зв'язок контейнерів між собою та з хостом. Також додайте будь-які внутрішні доменні імена, які повинні обходити проксі.

Перезавантажте systemd та перезапустіть демон Docker, щоб зміни набули чинності:

sudo systemctl daemon-reload
sudo systemctl restart docker

Перевірте, завантаживши образ:

docker pull alpine

Якщо проксі налаштовано правильно, ця операція завантаження пройде через проксі.

Для Docker CLI (конфігурація на стороні клієнта)

Ця конфігурація впливає на клієнт Docker під час взаємодії з реєстрами. Вона менш поширена для проксі-серверів на рівні демона, але корисна для конкретних операцій CLI.

Створіть або відредагуйте ~/.docker/config.json:

{
  "proxies": {
    "default": {
      "httpProxy": "http://YOUR_PROXY_HOST:YOUR_PROXY_PORT",
      "httpsProxy": "http://YOUR_PROXY_HOST:YOUR_PROXY_PORT",
      "noProxy": "localhost,127.0.0.1,::1,YOUR_DOCKER_NETWORK_CIDR,YOUR_INTERNAL_DOMAINS"
    }
  }
}

Ця конфігурація застосовується до користувача, який запускає Docker CLI.

Конфігурація проксі контейнера/сервісу

Цей метод конфігурує конкретні контейнери або сервіси docker-compose для використання проксі для їхнього вихідного трафіку під час виконання. Це відрізняється від проксі демона і часто необхідно для програм, що працюють всередині контейнерів, для доступу до зовнішніх ресурсів через проксі.

Використання Dockerfile

Ви можете встановити змінні середовища проксі безпосередньо у вашому Dockerfile. Це вбудовує налаштування проксі в образ.

FROM ubuntu:latest

# Set proxy for build time operations (e.g., apt-get update)
ENV HTTP_PROXY="http://YOUR_PROXY_HOST:YOUR_PROXY_PORT" \
    HTTPS_PROXY="http://YOUR_PROXY_HOST:YOUR_PROXY_PORT" \
    NO_PROXY="localhost,127.0.0.1,::1,YOUR_DOCKER_NETWORK_CIDR,YOUR_INTERNAL_DOMAINS"

RUN apt-get update && apt-get install -y curl

# These ENV variables will also be present at runtime unless overridden
CMD ["curl", "http://example.com"]

Міркування:
* Облікові дані проксі в Dockerfiles є ризиком безпеки. Розгляньте можливість використання аргументів збірки (ARG) або змінних середовища під час виконання (-e або environment у docker-compose.yml).
* Якщо проксі потрібен лише під час збірки, скасуйте встановлення змінних наприкінці етапу збірки в багатоетапній збірці або використовуйте RUN --mount=type=secret,id=proxy,target=/run/secrets/proxy-creds для більш безпечної обробки.

Використання docker run

Для окремих контейнерів передайте налаштування проксі за допомогою прапора -e:

docker run -e HTTP_PROXY="http://YOUR_PROXY_HOST:YOUR_PROXY_PORT" \
           -e HTTPS_PROXY="http://YOUR_PROXY_HOST:YOUR_PROXY_PORT" \
           -e NO_PROXY="localhost,127.0.0.1,::1,172.17.0.0/16,my-app-service" \
           my-image:latest curl http://example.com

Використання docker-compose.yml

Для багатосервісних програм docker-compose є стандартом. Визначте змінні середовища проксі в розділі environment кожного сервісу, який потребує доступу до проксі:

version: '3.8'
services:
  webapp:
    image: my-webapp:latest
    environment:
      - HTTP_PROXY=http://YOUR_PROXY_HOST:YOUR_PROXY_PORT
      - HTTPS_PROXY=http://YOUR_PROXY_HOST:YOUR_PROXY_PORT
      - NO_PROXY=localhost,127.0.0.1,::1,your-db-service,your-cache-service,172.18.0.0/16 # Add internal service names and network CIDRs
    # ... other service configurations

  database:
    image: postgres:13
    # This service typically does not need proxy settings if it only communicates internally or is not outbound
    # ... other service configurations

Примітка щодо NO_PROXY у docker-compose:
* Включіть localhost, 127.0.0.1, ::1.
* Включіть імена інших сервісів у тій самій мережі docker-compose (наприклад, your-db-service).
* Включіть діапазон CIDR мережі Docker, створеної docker-compose (наприклад, 172.18.0.0/16, якщо ваша мережа docker-compose знаходиться в цьому діапазоні). Ви можете перевірити мережу за допомогою docker network inspect <network_name>, щоб знайти її CIDR.

Зовнішній файл proxy.env

Для кращого керування конфіденційними або часто змінюваними налаштуваннями проксі ви можете визначити їх у зовнішньому файлі .env та посилатися на нього в docker-compose.yml:

proxy.env:

HTTP_PROXY=http://YOUR_PROXY_HOST:YOUR_PROXY_PORT
HTTPS_PROXY=http://YOUR_PROXY_HOST:YOUR_PROXY_PORT
NO_PROXY=localhost,127.0.0.1,::1,your-db-service,your-cache-service,172.18.0.0/16

docker-compose.yml:

version: '3.8'
services:
  webapp:
    image: my-webapp:latest
    env_file:
      - ./proxy.env
    # ... other service configurations

Цей підхід є чистішим і дозволяє легко оновлювати налаштування без безпосередньої зміни docker-compose.yml.

Конфігурація SOCKS проксі

Хоча HTTP/HTTPS проксі є найпоширенішими, деякі середовища використовують SOCKS проксі. Docker не підтримує змінні середовища SOCKS проксі (SOCKS_PROXY, ALL_PROXY) так повсюдно, як HTTP/HTTPS.

• На рівні програми: Більшість програм потребують явної підтримки SOCKS. Якщо ваша програма всередині контейнера підтримує SOCKS, ви можете передати ALL_PROXY або подібні змінні.
• Proxychains-NG: Для програм, які не підтримують SOCKS нативно, інструменти, такі як proxychains-ng, можуть бути встановлені всередині контейнера, щоб примусово направляти трафік через SOCKS проксі. Це додає складності та накладних витрат.

Для типових розгортань Docker перевага надається HTTP/HTTPS проксі через ширшу підтримку.

Порівняння методів конфігурації проксі

Усунення поширених проблем з проксі

• Перевірте змінні середовища: Всередині запущеного контейнера використовуйте docker exec -it <container_id> env, щоб перевірити, чи правильно встановлені HTTP_PROXY, HTTPS_PROXY та NO_PROXY.
• Перевірте підключення з контейнера:
  bash docker exec -it <container_id> curl -v --proxy <YOUR_PROXY_HOST:YOUR_PROXY_PORT> http://example.com
  Це явно змушує curl використовувати проксі, обходячи змінні середовища контейнера, для прямого тестування.
• Перевірте журнали проксі-сервера: Перегляньте журнали доступу вашого проксі-сервера, щоб побачити, чи досягає трафік від хоста Docker або контейнерів його та обробляється.
• Мережеве підключення: Переконайтеся, що хост Docker може досягти проксі-сервера на вказаному порту. Використовуйте curl або telnet з хоста Docker.
• Правила брандмауера: Перевірте, чи не блокує брандмауер (хост, мережа або проксі-сервер) трафік між хостом Docker/контейнерами та проксі-сервером.
• Роздільна здатність DNS: Переконайтеся, що роздільна здатність DNS працює правильно всередині контейнерів, особливо для самого хоста проксі та цільових доменів.
• Конфігурація NO_PROXY: Неправильні або неповні налаштування NO_PROXY часто призводять до збоїв внутрішнього зв'язку. Переконайтеся, що перераховані всі внутрішні мережі, мережі мостів Docker та імена сервісів.