Динамическое управление Dockerfile для разных клиентов в реализации конвейера CI / CD

Я пытаюсь реализовать конвейер CI / CD для моего проекта, используя Docker, Kubernetes и Jenkins. Мое приложение является мультитенантным, в котором переменные приложения базы данных различны для разных арендаторов.

Стратегия применения

Когда я создаю образ докера, я использую Dockerfile. И я держу свой Dockerfile в своем хранилище кода SVN. Для каждого арендатора хранилище кода одинаково. Когда я создаю образ, мне нужно создавать разные образы для разных арендаторов.

Реализация Dockerfile

В моем файле Docker я добавляю точку входа, как показано ниже,

ENTRYPOINT ["java", "-jar", "-Dspring.profiles.active=tenant1config" , "TestProject.war"]

Если мне нужно создать образ Docker для другого арендатора, нужно добавить
-Dspring.profiles.active=tenant2config

Таким образом, точка входа в Dockerfile является динамической.

Моя путаница

1. Для управления точкой входа команда внутри Dockerfile возможна динамически?
2. Или мне нужно добавить еще один Dockerfile для другого арендатора? И нужно запустить команду сборки docker отдельно для отдельного арендатора?

Как мне найти хороший стандартный способ реализации этой проблемы?

Цитата из 12 Factor - Config

Конфигурация приложения - это все, что может варьироваться в зависимости от развертывания (подготовка, производство, среда разработки и т. Д.). Это включает в себя:

• Дескрипторы ресурса для базы данных, Memcached и других вспомогательных сервисов

• Учетные данные для внешних служб, таких как Amazon S3 или Twitter

• Значения для развертывания, такие как каноническое имя хоста для развертывания

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

Существуют разные варианты внедрения конфигурации во время выполнения

1. Переменные среды

Вместо жесткого кодирования профиля в точке входа добавьте переменную среды

ENTRYPOINT ["java", "-jar", "-Dspring.profiles.active=$TENANT_PROFILE" , "TestProject.war"]

Затем введите переменную среды из конфигурации развертывания kubernetes. См. Https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/

2. Смонтируйте конфигурацию профиля как конфиг и отошлите ее

Ваша точка входа будет выглядеть

ENTRYPOINT ["java", "-jar", --spring.config.location="file:/path/to/tenantconfig.yaml" , "TestProject.war"] Затем подключите требуемый файл конфигурации в качестве конфигурации kubernetes.

В любом случае извлеките конфигурацию среды выполнения из образа докера и внедрите ее через конфигурацию развертывания в качестве переменной среды или конфигурации.

Вы можете использовать докер ARGS, он будет доступен только во время сборки и может использоваться в точке входа.

docker build --build-arg CONFIG_FILE=<file_name> -t tag_name .

CONFIG_FILE будет содержать расположение файла конфигурации, и вы можете передать его динамически. Замените вашу точку входа на$CONFIG_FILE

ENTRYPOINT ["java", "-jar", "-Dspring.profiles.active=$CONFIG_FILE" , "TestProject.war"]

Refer - Лучшие практики Dockerfile

ENTRYPOINT помогает настроить контейнер для запуска в качестве исполняемого файла, который может принимать аргументы во время выполнения

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

Вы можете передать необходимый аргумент во время выполнения.