Wo soll ich meine Anwendungskonfiguration ablegen?

Ich habe in letzter Zeit eine Debatte über " Wo sollten Eigenschaften, die von der Umgebung abhängen, gespeichert werden? " Gelesen .

Die klassische Methode besteht darin, mehrere Eigenschaftendateien zu haben, eine nach Umgebung, und basierend auf einer Umgebungsvariablen (DEV, PROD ...) auszuwählen, wo sie beim Starten der Anwendung gelesen werden sollen (wie bei Spring-Profilen).

Wenn Sie dagegen einen Container zum Bereitstellen Ihrer Anwendung verwenden, wird angegeben, dass diese Art der Konfiguration von der Umgebung selbst stammen sollte (mithilfe von Umgebungsvariablen, die von der Anwendung gelesen werden), damit sich das Image zwischen den Umgebungen nicht ändert.

Was sind die Vor- und Nachteile der einzelnen Ansätze? Gibt es einen "besten" Ansatz für das Containerszenario?

Wer hat gesagt, dass sich Eigenschaftendateien und Umgebungsvariablen gegenseitig ausschließen?

Es ist zu unterscheiden zwischen "Wo speichere ich meine App-Konfiguration?" Und " Woher bezieht meine App die Konfiguration?"

Das wahrscheinlichste Ergebnis ist, dass jeder als Speichermechanismus einfach so weitermachen sollte , wie er es mit Konfigurationsdateien tut (denken Sie an einen langfristigen, beständigen Zustand, solange die Umgebung existiert).

Anstatt diese Konfigurationsdatei in den Anwendungskontext abzulegen und ausführen zu lassen, sollte die Anwendung jedoch nur erwarten können, dass diese Variablen beim Start bereits in der Umgebung verfügbar sind.

Dies bedeutet, dass Sie zwei Bereitstellungsworkflows benötigen:

1. Ich stelle möglicherweise eine Anwendung in einer Umgebung bereit, indem ich den X-Änderungskontrollprozess durchlaufe und Y-Überprüfungen mit dem Z-Tool durchführe, was auch immer.
2. Ich stelle meine Umgebungskonfiguration in einer Umgebung bereit, indem ich den A-Änderungskontrollprozess durchlaufe und B-Überprüfungen mit dem C-Tool durchführe, denselben Prozess, unterschiedliche Ergebnisse.

Um ein Beispiel für die Verwaltung von Umgebungsvariablen als Schlüsselwertpaare in einem Tool wie consul zu verwenden, wenn Sie Konfigurationsdateien in git speichern, verwenden Sie Tools wie git2consul, um diese Konfiguration bei der Aktualisierung in die Umgebung zu übertragen.

Wenn Sie eine App haben, die erwartet, dass die Konfiguration als Konfigurationsdatei verfügbar ist, können Sie vermeiden, dass mehrere Kopien der Konfigurationsdatei mit der App versendet werden, indem Sie einen Bereitstellungsprozess mit so etwas wie einer Konsul-Vorlage erstellen, die die Möglichkeit bietet, Ihre Konfiguration zu ändern consul-Werte zurück in eine Datei.

 So wie wir es machen, haben wir 3 Teile (oder Artefakte) für jede laufende Anwendung.

1. Die Anwendung, die wir entwickeln. Dies ist unabhängig von der Umgebung gleich. Passend zu Ihrem Beispiel ist dies die Spring-Anwendung als Gefäß / Krieg.
2. Der Container, in dem die Anwendung ausgeführt wird. Dies ist unabhängig von der Umgebung gleich. Wenn Sie Spring Boot verwenden, benötigen Sie nicht mehr Tomcat und nur die Java-Laufzeit. Verwenden Sie also den openjdk Docker-Container.
3. Die Konfiguration, die die Anwendung benötigt. Dies ist das einzige, was sich je nach Umgebung unterscheidet. In einer Spring-App verwenden Sie wahrscheinlich eine Eigenschaftendatei.

Die Konfigurationsdatei befindet sich in einer separaten Quellcodeverwaltung. Früher war das Git, jetzt verwenden wir ein SaaS mit dem Namen Config unter http://www.configapp.com . Das Hauptmerkmal von Config ist die einfache Handhabung der umgebungsspezifischen Konfiguration. Um unsere Anwendung auf einem neuen Server auszuführen, ziehen wir den Docker-Container, das Anwendungsartefakt und die Konfigurationsdatei für diese Umgebung. Im Container mounten wir das Verzeichnis, in dem die Anwendung und die Konfigurationsdatei gespeichert sind, als Teil des Containerlaufs. Unsere Anwendung ist die gleiche. Unser Container / Image ist das gleiche. Nur die Konfigurationsdatei ist anders.

In Bezug auf Konfigurationsdatei vs Umgebungsvariablen. Die längste Zeit verwendeten wir Konfigurationsdateien. Als wir PaaS / Cloud verwendeten, verwendeten wir Umgebungsvariablen. Es war zusätzliche Arbeit, wenn Sie viel Konfiguration haben, sodass wir Umgebungsvariablen verwendet haben, um die richtige Konfigurationsdatei zu ermitteln. Wir haben eine Anwendung, die Eigenschaften in Umgebungsvariablen umwandelt, aber das ist untypisch. Wenn wir einen vom Unternehmen genehmigten zentralen Konfigurationsserver haben, verwenden wir diesen, andernfalls mögen wir die Einfachheit der Konfigurationsdateien.

Zusammenfassend ziehen wir app.jar, app.properties, openjdk Docker. Dann führen wir openjdk Docker aus und mounten den Speicherort von app.jar und app.properties. Das einzige, was umgebungsspezifisch ist, sind app.properties. Um app.properties unabhängig von der Anzahl der Eigenschaftsschlüssel, Umgebungen und Cluster- / Regionsinstanzen einfach zu verwalten, verwenden wir Config.