Gestione dinamica del Dockerfile per diversi tenant nell'implementazione della pipeline CI / CD

Sto cercando di implementare la pipeline CI / CD per il mio progetto usando Docker, Kubernetes e Jenkins. La mia applicazione è un'applicazione multi-tenant in cui le variabili dell'applicazione del database sono diverse per ogni tenant.

Strategia applicativa

Quando sto costruendo un'immagine docker sto usando un Dockerfile. E tengo il mio Dockerfile all'interno del mio repository di codice SVN. Per ogni tenant, il repository di codice è lo stesso. Quando sto costruendo un'immagine, in quel momento ho bisogno di costruire immagini diverse per inquilino diverso.

Implementazione di file Docker

Nel mio file docker sto aggiungendo un punto di ingresso come il seguente,

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

Se devo creare un'immagine Docker per un altro inquilino, devo aggiungere
-Dspring.profiles.active=tenant2config

Quindi l'entrata nel Dockerfile è dinamica.

La mia confusione

1. Per la gestione del comando del punto di ingresso all'interno del Dockerfile è possibile in modo dinamico?
2. O devo aggiungere un altro Dockerfile per un altro inquilino? E devi eseguire il comando build docker separatamente per un tenant separato?

Come posso trovare un buon modo standard di implementazione di questo problema?

Citando da 12 Fattore - Config

La configurazione di un'app è tutto ciò che può variare tra le distribuzioni (stadiazione, produzione, ambienti di sviluppo, ecc.). Ciò comprende:

• Gestisce le risorse per il database, Memcached e altri servizi di supporto

• Credenziali per servizi esterni come Amazon S3 o Twitter

• Valori per distribuzione come il nome host canonico per la distribuzione

Si dovrebbe non genera immagini docker separate per ciascun conduttore come il binario deve essere lo stesso e tutte le configurazioni runtime deve essere iniettato attraverso l'ambiente.

Esistono diverse opzioni per iniettare la configurazione di runtime

1. Variabili ambientali

Invece di codificare il profilo nel punto di accesso aggiungere una variabile di ambiente

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

Quindi iniettare la variabile di ambiente dalla configurazione di distribuzione di kubernetes Consultare https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/

2. Montare la configurazione del profilo come configurazione e riferirla

Il tuo punto di entrata sarà simile

ENTRYPOINT ["java", "-jar", --spring.config.location="file:/path/to/tenantconfig.yaml" , "TestProject.war"] Quindi montare il file di configurazione richiesto come configurazione di kubernetes.

In entrambi i casi esternalizzare la configurazione di runtime dall'immagine docker e iniettarla attraverso la configurazione di distribuzione come variabile di ambiente o config.

È possibile utilizzare la finestra mobile ARGS, che sarà disponibile solo al momento della creazione e può essere utilizzata su entrypoint.

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

CONFIG_FILE manterrà la posizione del file di configurazione e puoi passarlo in modo dinamico. Sostituisci il tuo punto di ingresso con$CONFIG_FILE

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

Consultare - Best practice Dockerfile

ENTRYPOINT ti aiuta a configurare un contenitore per l'esecuzione come eseguibile che può accettare argomenti in fase di esecuzione

Qualsiasi proprietà dinamica che desideri sostituire, può essere eseguita in fase di esecuzione con la stessa immagine.

È possibile passare l'argomento necessario in fase di esecuzione.