как я могу поддерживать http_proxy или логическое управление в Dockerfile во время сборки docker?

#docker

#docker

Вопрос:

Я работаю в корпоративной среде с брандмауэром, в основном мне нужен прокси для доступа к внешним для обновления пакетов

Хотя я хочу сохранить тот же Dockerfile для сборки внутри / за пределами компании.

 FROM ubuntu:latest
# for inside 
RUN echo 'Acquire::http::Proxy "http://<proxy>";' > /etc/apt/apt.conf
# for external
#RUN echo '#Acquire::http::Proxy "http://<proxy>";' > /etc/apt/apt.conf
RUN apt-get update
  

Как я могу добиться этого во время docker build ?

Ответ №1:

У вас не может быть логики в Dockerfile, однако ваш Dockerfile может ADD содержать скрипт (в оболочке, python, …) и RUN этот скрипт во время сборки.

Обратите внимание, что это затрудняет понимание вашего Dockerfile другими пользователями, которые не будут подозревать, что в зависимости от контекста будут создаваться разные изображения. Вам лучше написать четкий комментарий в Dockerfile непосредственно перед RUN командой.

http-прокси при создании образа

Теперь, если ваша единственная проблема связана с прокси, вам не придется иметь дело с такими вещами в вашем Dockerfile. Вместо этого запустите демон Docker с HTTP_PROXY переменной среды set. (есть ответы на вопросы по этому вопросу)

http-прокси при запуске контейнера

Вы можете указать процессу, который запускается контейнером, использовать http-прокси, введя переменную среды в контейнер с помощью -e опции docker run команды. Обратитесь к документации команды, которая выполняется в вашем контейнере, чтобы узнать, подчиняется ли она HTTP_PROXY переменной среды. Обратите внимание, что некоторым процессам требуется http_proxy переменная environnement в нижнем регистре.

Комментарии:

1. хорошее предложение. для http_proxy , это в /etc/default/docker ? может ли это работать для контейнера внутри?

2. /etc/default/docker хорошее место для установки этой переменной среды. Я обновил свой ответ подробностями о том, как передать переменную среды в контейнер

3. Я не думаю, что http_proxy в / etc / default / docker может повлиять на файл сборки Dockerfile и запустить контейнер. полезно знать, что run поддерживает это. существует github.com/dotcloud/docker/issues/4962 обсуждение того, как поддерживать http_proxy для сборки

4. Я предполагаю, что здесь срабатывает логика в сценарии сборки. Это может определить необходимость прокси-сервера и установить переменную среды для последующих команд в этом скрипте. (сценарий сборки, который вы добавляете и запускаете, а не Dockerfile)

5. На самом деле у меня проблема при сборке изображений, хотя http_proxy правильно настроен для демона docker (например, я могу извлекать изображения удаленно без проблем). Это потому, что я думаю, что создание образа выполняется в контексте БАЗОВОГО образа, и http_proxy не распространяется на этот образ сборки. Действительно, я должен явно установить ENV http_proxy, например, для запуска wget для извлечения данных. Есть идеи? Это действительно раздражает, например, при публикации автоматических сборок на registry.hub.docker.io

Ответ №2:

Обратите внимание, что эта функция была добавлена в docker > = 1.9.0 https://github.com/docker/docker/issues/14634