Dynamisches Verwalten von Dockerfile für verschiedene Mandanten in der Implementierung der CI / CD-Pipeline

Ich versuche, die CI / CD-Pipeline für mein Projekt mit Docker, Kubernetes und Jenkins zu implementieren. Meine Anwendung ist eine mandantenfähige Anwendung, bei der Datenbankanwendungsvariablen für verschiedene Mandanten unterschiedlich sind.

Anwendungsstrategie

Wenn ich ein Docker-Image erstelle, verwende ich eine Docker-Datei. Und ich behalte meine Docker-Datei in meinem SVN-Code-Repository. Das Code-Repository ist für jeden Mandanten gleich. Wenn ich ein Image erstelle, muss ich zu diesem Zeitpunkt verschiedene Images für verschiedene Mandanten erstellen.

Dockerfile-Implementierung

In meiner Docker-Datei füge ich einen Einstiegspunkt wie den folgenden hinzu:

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

Wenn ich ein Docker-Image für einen anderen Mandanten erstellen muss, muss ich hinzufügen
-Dspring.profiles.active=tenant2config

Der Einstiegspunkt in der Docker-Datei ist also dynamisch.

Meine Verwirrung

1. Zum Verwalten von Einstiegspunktbefehlen innerhalb der Docker-Datei ist dynamisch möglich?
2. Oder muss ich eine weitere Docker-Datei für einen anderen Mandanten hinzufügen? Und müssen Sie den Docker-Build-Befehl separat für einen separaten Mandanten ausführen?

Wie kann ich einen guten Standard für die Implementierung dieses Problems finden?

Zitat aus 12 Faktor - Konfig

Die Konfiguration einer App ist alles, was zwischen den Bereitstellungen (Staging, Produktion, Entwicklerumgebungen usw.) variieren kann. Das beinhaltet:

• Ressourcenhandles für die Datenbank, Memcached und andere Sicherungsdienste

• Anmeldeinformationen für externe Dienste wie Amazon S3 oder Twitter

• Werte pro Bereitstellung, z. B. der kanonische Hostname für die Bereitstellung

Sie sollten nicht für jeden Mandanten separate Docker-Images erstellen, da die Binärdatei identisch sein sollte und alle Laufzeitkonfigurationen über die Umgebung eingefügt werden sollten.

Es gibt verschiedene Optionen zum Einfügen der Laufzeitkonfiguration

1. Umgebungsvariablen

Anstatt das Profil im Einstiegspunkt fest zu codieren, fügen Sie eine Umgebungsvariable hinzu

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

Fügen Sie dann die Umgebungsvariable aus der Konfiguration der kubernetes-Bereitstellung ein. Siehe https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/

2. Hängen Sie die Profilkonfiguration als Konfiguration ein und verweisen Sie darauf

Ihr Einstiegspunkt wird so aussehen

ENTRYPOINT ["java", "-jar", --spring.config.location="file:/path/to/tenantconfig.yaml" , "TestProject.war"] Hängen Sie dann die erforderliche Konfigurationsdatei als Kubernetes-Konfiguration ein.

In beiden Fällen wird die Laufzeitkonfiguration aus dem Docker-Image ausgelagert und durch die Bereitstellungskonfiguration als Umgebungsvariable oder Konfiguration eingefügt.

Sie können Docker-ARGS verwenden. Dies ist nur zur Erstellungszeit verfügbar und kann am Einstiegspunkt verwendet werden.

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

CONFIG_FILE enthält den Speicherort der Konfigurationsdatei und kann dynamisch übergeben werden. Ersetzen Sie Ihren Einstiegspunkt durch$CONFIG_FILE

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

Siehe - Best Practices für Dockerfile

Mit ENTRYPOINT können Sie einen Container so konfigurieren, dass er als ausführbare Datei ausgeführt wird, die zur Laufzeit Argumente annehmen kann

Jede dynamische Eigenschaft, die Sie überschreiben möchten, kann zur Laufzeit mit demselben Image ausgeführt werden.

Sie könnten das erforderliche Argument zur Laufzeit übergeben.