Konfigurationen für Applikationen - im WAR oder auf dem Server?


slowfly

Erfahrenes Mitglied
#1
Hallo zusammen

Wir entwickeln bei uns Webapplikationen und Webservices. Bislang wurden Konfigurationen jeweils innerhalb der Applikationen, also innerhalb eines WAR-Files, gespeichert (4 verschiede Konfigurationen, pro Zielsystem eine, also DEV/INT/TST/PRD)

Jetzt kam uns die Idee, die Konfigurationen auf dem Server zu konfigurieren,... mal ein kurzer Gedankenerguss:

Innerhalb einer Applikation:
Vorteile:
Es ist alles zusammen, man muss nur das WAR-File deployen, und gut ist.

Nachteile:
Bei Änderungen eines Properties, muss(sic) die Applikation CVS-Mässig geändert und ge-released werden (relativ aufwändig).
Lange Reaktionszeit ("Server xy heisst jetzt Server yx, sorry, wir haben vergessen, euch zu benachrichten, könnt ihr schnell,...")

Ausserhalb einer Applikation, auf dem Server:
Vorteile:
Kein Release der Applikation nötig
Unabhängig von Release
(Server-weite Konfigurationen möglich)
Schnell!

Nachteile:
Deployments evtl "komplexer" (Kommunikation Entwickler->Deployer; evtl. weil sich ja die Konfigurationen nicht immer ändern)
Konfigurationsdateien müssen separat, bzw. überhaupt versionisiert sein (organisatorischer Aufwand, welcher ja nicht immer erst genommen wird...)

Wir sind auf unserer Seite jetzt ziemlich unschlüssig, was denn eigentlich die beste Variante wäre, und ob wir uns selber ein Bein stellen, wenn wir da jetzt was ändern würden,...

Es gibt jetzt auch noch andere Varianten, zum Beispiel ganze Konfigurationen in eine zentrale Datenbank speichern, da bin ich aber auch nicht sicher, inwiefern das Sinn macht, Stichwort Versionskontrolle...

Was meint ihr dazu, bzw. wie wird das bei euch gehandhabt?
Könnt ihr vielleicht die Liste mit Vor- und Nachteilen ergänzen?

Besten Dank und Gruss
slowfly
 

slowfly

Erfahrenes Mitglied
#2
Hallo zusammen

So, "die" Lösung:

Ich habe ein MBean für JBoss geschrieben, welche Konfigurationen verwaltet. Die Konfigurationen liegen im JBoss im "conf"-directory (gibt zum Glück ne tolle System property, um an das Verzeichnis zu kommen). Das ist eine "zentrale" Komponente (zentral pro JBoss Instanz), von welcher die Applikationen ihre Konfigurationen laden kann.
Die Komponente kann Konfiguration direkt aus dem CVS auschecken, ebenso werden Änderungen an Propertyfiles direkt eingecheckt. Somit kann man auch von anderen Instanzen (bei uns laufen die Applikationen immer auf mind. zwei Servern) Änderungen auschecken.

Grüsse
slowy
 
#3
Hallo,

ich finde das Ablegen der Laufzeitkonfiguration in externen Konfigurationsdateien mit Versionierung
über CVS/SVN oder GIT/MERCURIAL generell sehr sinnvoll.
Man muss hierbei nur darauf achten, dass bei Konfigurationsänderungen auch ein entsprechder
Commit-gemacht wird bzw. sichergstellt wird das immer die "letzte" gültige Konfiguration aus dem Repository gezogen wird,
aber das stellst du ja über dein MBean sicher.

Die andere genannte Variante die Konfiguration in die Datenbank auszulagern. Dies hat IMHO den Vorteil,
das man alle Anwendungsinformationen an einer Stelle hat, sprich Backups der Datenbank
enthalten neben den "reinen" Anwendungsdaten auch die Anwendungskonfiguration.
Versionierung wäre natürlich auch über entsprechende Datenbank-Trigger möglich. Die Audit-Informationen
welcher Benutzer von welchem Rechner, was, wieso und wann geändert hat kann je nach verwendetem RDBMS aus
der Datenbankverbindung ermittelt oder über die Anwendung mitgegeben werden.
Unterschiedliche Konfigurationen (etwa System / Instanz, Variante, Mandant, Version) könnte man über eine entsprechende
Diskriminator-Spalten auseinanderhalten. Auch kann man so einfach mehrstufige Konfigurationsmechanismen
realisieren (Überschreibbare Defaults, auf mehreren Ebenen)
Auch lassen sich über diesen Mechanismus entsprechend einfache
Pflegeoberflächen (Z.Bsp.: mit MS Access / bzw. sogar Excel) aufsetzen.

Natürlich ergibt sich bei der Speicherung in der Datenbank ein kleines "Bootstrapping Problem":
Die Konfiguration zur Datenbankverbindung selbst muss natürlich noch woanders stehen als in der Datenbank ;-)
Aber das ist dann IMHO wirklich "nur reine Deployment" Konfiguration die auch in Dateien stehen kann :).

Gruß Thomas
 

slowfly

Erfahrenes Mitglied
#4
Tschäu Thomas

Besten Dank, für deinen Gedankenerguss ;P

Also das mit Versionisierung ist jetzt an und für sich "schlechter" *g*, weil bis anhin die Konfigurationsdateien jeweils mit dem war-file getaggt wurden. Aber das ist ja auch einer der Gründe, wieso wir das zentral wollen, eben um die bekannten "Schnellschüsse" (Servernamen ändern sich, Migration von Server A nach B, etc,...) von unserer Seite schnellere Reaktionszeiten hinzubekommen,... und so ohne Entwickler/Release/INT+TST+PRD-System, Emergency Change usw wird das doch, so hoffen wir, einiges schneller gehen :). Die Vorteile überwiegen unserer Meinung nach die Nachteile der Nicht-Versionisierung der Propertyfiles.

Die ganze DB-Geschichte hört sich auch sehr, sehr nett an... evtl. werde ich aus der Klasse StorageHelper ein Interface machen und (ne Factory dazu, wie man's gelernt hat hehe)

Das Bootstrappingproblem lässt sich insofern lösen, indem man die Konfiguration nicht in die Datenbank der Applikation speichert, sondern in eine zentrale "Konfig-DB", so hätte ich es jedenfalls gemacht, weil, wir haben auch diverse Applikationen, die keine Datenbank haben, oder dass wir da keine User mit update/insert-Rechten bekommen, etc.
Und dann muss man im JBoss mit einer Datasource arbeiten, funktioniert in anderen Appl Servern ja auch. Wenn man dann noch den Namen der DataSource mit System-Properties der VM mitteilt und das MBean über dieses Property die DS lädt, ist man ziemlich gut losgelöst...

Andere Vorteile für "Konfiguration in einer Datenbank", resp, Nachteile Filesystem/CVS: ProcessBuilder und cvs client auf den Servern installieren. Ich arbeite zwar mit den exit-codes vom CVS-Client, und das scheint auch sehr gut zu funktionieren, aber prinzipiell würde ich mit jdbc wohler fühlen, als da Prozesse aus der VM zu starten,...

Grüsse
slowy
 

Neue Beiträge