Externe Spring Boot-Eigenschaften bei der Bereitstellung in Docker

Ich persönlich würde Spring Cloud Config Server verwenden, anstatt zu versuchen, überall Eigenschaftsdateien einzurichten.

damit können Sie Eigenschaften in git (die Versionskontrolle, Verzweigung usw. zulassen) auf einer Ebene pro Umgebung/Profil an einem zentralen Ort halten, die dann von REST bedient werden. Spring Boot bietet volle Unterstützung dafür. Tatsächlich ist es nur eine andere Eigenschaftsquelle, die in Ihrer Umgebung endet.

https://spring.io/guides/gs/centralized-configuration/

Also habe ich es geschafft, es zum Laufen zu bringen. Anstatt den Klassenpfad an das Verzeichnis in meiner DockerFile zu übergeben:

"--spring.config.location=classpath:${configDirectory}"]

Ich habe stattdessen versucht, den vollständigen Speicherort der Datei zu übergeben:

 "--spring.config.location=file:${configDirectory}/application.yml"]

Dies wird jetzt beim Neustart des Docker-Containers aktualisiert.

Eine Variation der answer von Xtreme Biker, diesmal für die Einführung eines Spring-Boot-Krieges in einen angedockten Tomcat…

Ich empfehle Ihnen, einen nominalen application.yml in Ihre App aufzunehmen, aber verwenden Sie Docker-Umgebungsvariablen, um einzelne Schlüssel zu überschreiben, die umgebungsspezifische Variationen erfordern.

Der Grund, warum ich diesen Ansatz (mit Docker-Umgebungsvariablen) empfehle, ist:

• ihr Docker-Image kann genau dasselbe Artefakt verwenden, das Sie für die lokale Entwicklung verwenden könnten
• die Verwendung von Volume-Mounts ist schmerzhaft. Sie müssen einen Ort finden, an dem sie auf Ihrem Docker-Host leben können - was diesen Host zu einer Schneeflocke macht
• die Verwendung von Docker-Geheimnissen ist schmerzhaft; Bild oder Anwendungsebene müssen geändert werden, um Geheimnisse explizit aus dem Dateisystem herauszufinden

Spring Boot's Externalized Configuration docs erklären zwei Möglichkeiten, die Umgebung über die Befehlszeile bereitzustellen:

• UN * X-Umgebungsvariablen (d. H. SPRING_DATASOURCE_USERNAME=helloworld)
• Java-Optionen (d. H. -Dspring.datasource.username=helloworld)

Ich bevorzuge Java-Optionen, weil sie eine explizite Absicht ausdrücken: "Dies ist für den folgenden Java-Prozess und only für diesen Java-Prozess gedacht".

Zum Schluss: Ich würde Tomcat's CATALINA_OPTS als Mechanismus für die Übergabe dieser Java-Optionen verwenden. Dokumentation von catalina.sh:

(Optional) Java-Laufzeitoptionen, die beim "Start" verwendet werden, "run" oder "debug" -Befehl wird ausgeführt . Fügen Sie hier und nicht in Java_OPTS alle Optionen ein, die darf nur von Tomcat selbst verwendet werden, nicht vom Stopp-Prozess der Versionsbefehl etc . Beispiele sind Heapgröße, GC-Protokollierung, JMX-Ports usw.

Weil CATALINA_OPTS eine einfachere Route ist, als dafür zu sorgen, dass Ihr Docker-Image dafür verantwortlich ist, einen setenv.sh zu erstellen und die entsprechenden Docker-Env-Deklarationen zu übergeben.

Erstellen Sie Ihr .war-Artefakt wie folgt:

./gradlew war

Wir erwarten, dass ein .war-Artefakt von Gradle an build/libs/api-0.0.1-SNAPSHOT.war ausgegeben wird.

Verwenden Sie eine solche Docker-Datei:

FROM Tomcat:8.5.16-jre8-Alpine

EXPOSE 8080

COPY build/libs/api-0.0.1-SNAPSHOT.war /usr/local/Tomcat/webapps/v1.war

CMD ["catalina.sh", "run"]

Bauen Sie Ihr Docker-Image so auf:

docker build . --tag=my-api

Übergeben Sie CATALINA_OPTS wie folgt an Ihren Container:

docker run -it \
-p 8080:8080 \
-e CATALINA_OPTS="\
-Dspring.datasource.url='jdbc:mysql://mydatabase.stackoverflow.com:3306' \
-Dspring.datasource.username=myuser \
" \
my-api

Und eine Docker-Compose-Variante sieht folgendermaßen aus:

version: '3.2'
services:
  web:
    image: my-api
    ports:
      - "8080:8080"
    environment:
      - >
        CATALINA_OPTS=
        -Dspring.datasource.url='jdbc:mysql://mydatabase.stackoverflow.com:3306'
        -Dspring.datasource.username=myuser

Ihr Ansatz ist definitiv eine praktikable Lösung, wird jedoch nicht empfohlen, da Ihr Image dadurch nicht zwischen verschiedenen Produktions- und Entwicklungsumgebungen portierbar ist. Container sollten unveränderlich sein und alle Umgebungskonfigurationen sollten externalisiert werden.

Für Spring Boot gibt es ein sehr leistungsfähiges Projekt, mit dem Sie die Konfiguration externisieren können. Es heißt Spring Cloud Config . Mit dem Konfigurationsserver können Sie Ihre umgebungsspezifische Konfiguration in einem git-Repository speichern und die Konfiguration für Anwendungen bereitstellen, die diese benötigen. Sie speichern im Grunde nur die gleiche application.yml in git und verweisen den Konfigurationsserver auf den Repository-Speicherort.

Mit diesem Ansatz können Sie mehrere Konfigurationsdateien für verschiedene Umgebungen definieren und Ihren Docker-Container unveränderlich halten.

Ich persönlich würde zwei Möglichkeiten in Betracht ziehen:

1. Eine Umgebungsvariable verwenden

   app:
     image: my-app:latest
     ports:
       - "8080:8080"
     environment:
        SPRING_DATASOURCE_URL=jdbc:mysql://db:3306/table
   

2. SPRING_APPLICATION_JSON verwenden

   app:
     image: my-app:latests
     ports:
       - "8080:8080"
     environment:
       SPRING_APPLICATION_JSON: '{
         "spring.datasource.url": "jdbc:mysql://db:3306/table",
       }'