Руководство по настройке системного прокси для Docker-контейнеров: бесперебойная сборка образов и загрузка пакетов

Важность настройки прокси для среды Docker

В корпоративной среде разработки сети часто надежно защищены прокси-серверами или внутренними брандмауэрами. Это обеспечивает сетевую безопасность, но создает серьезные препятствия для DevOps-инженеров при работе с Docker. Базовые операции, такие как загрузка базовых образов с Docker Hub, обновление пакетов с помощью команд операционной системы или установка зависимостей, могут завершаться ошибками тайм-аута или невозможностью разрешения DNS-имен.

Понимание маршрутизации сетевых подключений и правильная настройка прокси docker — необходимое условие для бесперебойной работы процессов непрерывной интеграции (CI). Docker работает по клиент-серверной архитектуре, поэтому единая сетевая конфигурация на хост-сервере не применяется автоматически ко всем компонентам Docker. Необходимо четко разделять три независимые области: прокси для демона Docker, прокси для docker build и http proxy docker container во время выполнения.

Разделение трех областей прокси в архитектуре Docker

Многие инженеры сталкиваются с тем, что настройки не работают, из-за путаницы между различными сетевыми уровнями Docker. Ниже приведены три независимые области, требующие точной настройки:

• Docker Daemon (dockerd): Отвечает за загрузку (pull) образов из публичных или внутренних реестров на хост-машину. Прокси на этом уровне настраивается через системную службу.
• Процесс сборки образов (docker build): Инструкции в Dockerfile (например, установка пакетов) требуют доступа в интернет через прокси, который передается через аргументы сборки или конфигурацию клиента.
• Контейнеры во время выполнения (docker run): Среда внутри контейнера функционирует изолированно и требует собственных переменных окружения прокси для взаимодействия работающих приложений с внешней сетью.

Настройка прокси для Docker Daemon через systemd

Если при попытке загрузить образ появляется сообщение об ошибке подключения к удаленному серверу, основной причиной является то, что демон Docker не использует прокси. Поскольку в большинстве дистрибутивов Linux демон Docker управляется systemd, вам необходимо внести изменения в файл конфигурации службы.

Шаг 1: Создание каталога переопределения конфигурации

Создайте отдельный каталог конфигурации для службы Docker, чтобы избежать перезаписи настроек при обновлении системных пакетов:

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

Шаг 2: Создание конфигурационного файла http-proxy.conf

Создайте и откройте новый файл конфигурации в текстовом редакторе:

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

Добавьте объявления переменных окружения для прокси HTTP, HTTPS и список исключений, не требующих прокси:

[Service]
Environment="HTTP_PROXY=http://proxy.example.com:8080"
Environment="HTTPS_PROXY=http://proxy.example.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1,docker-registry.internal"

Примечание: Значение NO_PROXY крайне важно: оно гарантирует, что демон не будет отправлять запросы через прокси при обращении к внутренним реестрам или сервисам в локальной сети.

Шаг 3: Перезагрузка конфигурации и перезапуск службы

Примените изменения, перезагрузив конфигурацию systemd и перезапустив службу Docker daemon:

sudo systemctl daemon-reload
sudo systemctl restart docker

Убедитесь, что переменные окружения применились, выполнив команду вывода системной информации Docker и найдя раздел HTTP Proxy.

Настройка прокси для процесса Docker Build

При сборке образов инструкции, выполняющие загрузку пакетов из внешних репозиториев (например, системных репозиториев ОС или библиотек языков программирования), завершатся ошибкой при отсутствии подключения к интернету. Существует два основных подхода к решению этой проблемы.

Способ 1: Использование аргументов сборки (Build Args)

Это гибкий метод, применяемый к конкретным командам сборки без изменения глобальной конфигурации системы. Аргументы передаются непосредственно в команду:

docker build --build-arg HTTP_PROXY=http://proxy.example.com:8080 --build-arg HTTPS_PROXY=http://proxy.example.com:8080 --build-arg NO_PROXY=localhost,127.0.0.1 -t my-app:latest .

Преимуществом этого метода является наглядность, однако недостатком выступает то, что параметры прокси могут непреднамеренно сохраниться в истории метаданных образа, если за этим не следить.

Способ 2: Настройка файла config.json клиента Docker

В современных версиях Docker можно задать прокси по умолчанию как для процесса сборки, так и для среды выполнения контейнеров через файл конфигурации клиента на хосте. Этот файл находится по пути ~/.docker/config.json.

Откройте или создайте файл и добавьте блок конфигурации proxies:

{
  "proxies": {
    "default": {
      "httpProxy": "http://proxy.example.com:8080",
      "httpsProxy": "http://proxy.example.com:8080",
      "noProxy": "localhost,127.0.0.1"
    }
  }
}

При наличии этой конфигурации Docker-клиент будет автоматически подставлять соответствующие переменные окружения прокси при каждом выполнении docker build или создании нового контейнера без необходимости вручную указывать аргументы.

Настройка HTTP-прокси для работающих контейнеров Docker

Для запущенных контейнеров, которым требуется доступ к внешним публичным API или базам данных через прокси, можно использовать одно из следующих решений.

Передача переменных окружения напрямую через команду docker run

Используйте флаг -e для передачи стандартных переменных окружения в контейнер:

docker run -d -e HTTP_PROXY="http://proxy.example.com:8080" -e HTTPS_PROXY="http://proxy.example.com:8080" -e NO_PROXY="localhost,127.0.0.1" my-app:latest

Настройка в Docker Compose

Если вы развертываете мультиконтейнерное приложение с помощью Docker Compose, централизованное описание в конфигурационном файле является оптимальным выбором для синхронизации настроек окружения:

version: '3.8'
services:
  app:
    image: my-app:latest
    environment:
      - HTTP_PROXY=http://proxy.example.com:8080
      - HTTPS_PROXY=http://proxy.example.com:8080
      - NO_PROXY=localhost,127.0.0.1

Настройка прокси для специфических пакетных менеджеров внутри контейнера

Хотя стандартные системные переменные окружения поддерживаются большинством приложений, некоторые пакетные менеджеры языков программирования или системные утилиты все же требуют индивидуальной конфигурации файлов внутри Dockerfile для стабильной работы.

Настройка для пакетного менеджера операционной системы

Некоторые дистрибутивы Linux требуют явного указания прокси во внутренних файлах конфигурации пакетного менеджера. Например, в дистрибутивах на базе Debian или Ubuntu вы можете создать временный файл конфигурации перед выполнением команд установки:

RUN echo 'Acquire::http::Proxy "http://proxy.example.com:8080/";' > /etc/apt/apt.conf.d/proxy.conf

Настройка для инструментов разработки

Инструменты, такие как Git, а также пакетные менеджеры для Python или Node.js, иногда игнорируют системные переменные окружения при проблемах с SSL-сертификатами или формате строки прокси. Обязательно добавьте соответствующие директивы в процесс настройки среды, чтобы загрузка пакетов происходила без сбоев.

Важные рекомендации по безопасности и эксплуатации

При масштабном внедрении docker proxy инженерам необходимо учитывать следующие аспекты информационной безопасности:

1. Избегайте жестко заданных (hardcoded) учетных данных в образе: Ни в коем случае не сохраняйте логины и пароли прокси-сервера прямо в Dockerfile. Если прокси требует аутентификации, используйте защищенные механизмы, такие как монтирование секретов в BuildKit (secret mount).
2. Тщательно настраивайте NO_PROXY: Убедитесь, что все внутренние диапазоны сетей, доменные имена сетей демона Docker и связанные службы кластера добавлены в список исключений во избежание замедления или разрыва внутренних подключений.
3. Контролируйте сертификаты центра сертификации (CA Certificates): Если прокси-сервер выполняет глубокую инспекцию трафика (SSL Inspection), процессы внутри контейнера будут выдавать ошибку недоверенного сертификата. В таком случае вам потребуется скопировать внутренний корневой сертификат в хранилище доверенных сертификатов контейнера перед выполнением загрузки пакетов.

Заключение

Правильная настройка прокси docker — это фундаментальный шаг, позволяющий полностью избавиться от раздражающих сетевых ошибок при работе в корпоративной инфраструктуре. Четко разделяя уровни демона Docker, процесса сборки и среды выполнения контейнеров, вы сможете легко контролировать потоки трафика, повысить стабильность процессов CI/CD и обеспечить безопасность всей экосистемы разработки.