Докер: Создание внутри корпоративного брандмауэра, развертывание снаружи

Question

У меня есть программный комплекс (веб-сервер узла, база данных, другие инструменты), который я разрабатываю внутри корпоративного брандмауэра, встраиваю в образы докеров и внедряю с помощью docker-compose.Чтобы фактически установить все программное обеспечение в образы, мне нужно настроить среду для использования сетевого прокси-сервера, а также отключить строгую проверку SSL (поскольку брандмауэр включает проверку ssl) не только с точки зрения переменных среды, но идля npm, apt и т. д.

У меня все это работает, так что я могу строить в брандмауэре и развертывать в брандмауэре, и настроил мои файлы Docker и сценарии сборки так, чтобыВключение всех параметров конфигурации proxy / ssl зависит от докера --build-arg, который устанавливает переменную среды с помощью ENV enable_proxies=$my_build_arg, поэтому я также могу легко пропустить всю эту конфигурацию для сборки и развертывания вне брандмауэра.

Тем не менее, мне нужно иметь возможность создавать все внутри брандмауэра и развертывать за его пределами.Это означает, что все прокси-компоненты должны быть включены во время сборки (чтобы можно было установить все программные пакеты), если указан соответствующий --build-arg, а затем также отдельно включены или отключены во время выполнения, используя --env enable_proxies=true или что-то подобное.

Я все еще относительно новичок в некоторых аспектах Docker, но, насколько я понимаю, единственное, что выполняется при запуске образа, - это содержимое записи CMD в Dockerfile и что CMD может выполнить только одну команду.

Кто-нибудь знает, как я могу / должен идти о разделении параметров прокси / ssl во время сборки и выполнения, как это?

Answer 1

Вы должны иметь возможность создавать и отправлять одно изображение;«Построить внутри брандмауэра, развернуть за пределами» - это вполне нормально.

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

FROM ... AS build
ARG my_build_arg
ENV enable_proxies=$my_build_arg
WORKDIR /artifacts
RUN curl http://internal.source.example.com/...

FROM ...
COPY --from=build /artifacts/ /artifacts/
...
CMD ["the_app"]

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

Другой аналогичный подход - написать скрипт, который запускается на хосте, который загружает зависимости в локальное дерево сборки и затем запускает docker build.(Это может потребоваться, если вам нужно поддерживать особенно старые докеры.) Тогда вы можете использовать все, что хост установил для $http_proxy, и не беспокоиться о том, чтобы обрабатывать случай с прокси-сервером и без него.