Gestión dinámica de Dockerfile para diferentes inquilinos en la implementación de canalizaciones de CI / CD

Estoy tratando de implementar la canalización de CI / CD para mi proyecto usando Docker, Kubernetes y Jenkins. Mi aplicación es una aplicación multiinquilino en la que las variables de la aplicación de base de datos son diferentes para un inquilino diferente.

Estrategia de aplicación

Cuando estoy creando una imagen de Docker estoy usando un Dockerfile. Y mantengo mi Dockerfile dentro de mi repositorio de código SVN. Para cada inquilino, el repositorio de código es el mismo. Cuando estoy construyendo una imagen, en ese momento necesito construir diferentes imágenes para diferentes inquilinos.

Implementación de Dockerfile

En mi archivo acoplable estoy agregando un punto de entrada como el siguiente,

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

Si necesito crear una imagen de Docker para otro inquilino, debo agregar
-Dspring.profiles.active=tenant2config

Entonces el punto de entrada en el Dockerfile es dinámico.

Mi confusión

1. ¿Para gestionar el comando de punto de entrada dentro del Dockerfile es posible dinámicamente?
2. ¿O necesito agregar otro Dockerfile para otro inquilino? ¿Y necesita ejecutar el comando Docker Build por separado para un inquilino separado?

¿Cómo puedo encontrar una buena forma estándar de implementación de este problema?

Citando desde 12 Factor - Config

La configuración de una aplicación es todo lo que puede variar entre implementaciones (puesta en escena, producción, entornos de desarrollador, etc.). Esto incluye:

• Controladores de recursos para la base de datos, Memcached y otros servicios de respaldo

• Credenciales para servicios externos como Amazon S3 o Twitter

• Valores por despliegue como el nombre de host canónico para el despliegue

Usted debe no construye imágenes acoplables por separado para cada inquilino que el binario debe ser la misma y cualquier configuraciones de ejecución debe administrarse en el medio ambiente.

Hay diferentes opciones para inyectar la configuración de tiempo de ejecución

1. Variables de entorno

En lugar de codificar el perfil en el punto de entrada, agregue una variable de entorno

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

Luego, inyecte la variable de entorno desde la configuración de implementación de kubernetes Consulte https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/

2. Montar la configuración del perfil como una configuración y referirla

Su punto de entrada se verá así

ENTRYPOINT ["java", "-jar", --spring.config.location="file:/path/to/tenantconfig.yaml" , "TestProject.war"] Luego monte el archivo de configuración requerido como una configuración de kubernetes.

De cualquier manera, externalice la configuración de tiempo de ejecución desde la imagen del acoplador e inyéctela a través de la configuración de implementación como una variable de entorno o una configuración.

Puede hacer uso de Docker ARGS, esto solo estará disponible en el momento de la compilación y se puede usar en el punto de entrada.

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

CONFIG_FILE mantendrá la ubicación del archivo de configuración y puede pasarlo dinámicamente. Reemplace su punto de entrada con$CONFIG_FILE

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

Consulte - Mejores prácticas de Dockerfile

ENTRYPOINT lo ayuda a configurar un contenedor para que se ejecute como un ejecutable que puede tomar argumentos en tiempo de ejecución

Cualquier propiedad dinámica que desee anular se puede hacer en tiempo de ejecución con la misma imagen.

Podría pasar el argumento necesario en tiempo de ejecución.