Configuration Server
Konfiguration zentral bereitstellen
Die Idee und ihr Nutzen
Der Schadendienst, das Programm, das bei einer Versicherung die gemeldeten Schäden bearbeitet, läuft gleichzeitig in zwölf Exemplaren auf verschiedenen Servern. Alle zwölf Exemplare sollen dieselbe Grenze verwenden, ab der ein Schaden zusätzlich an die Betrugsprüfung geht, und diese Grenze soll nach einer Häufung von Betrugsfällen von 5.000 auf 3.000 Euro sinken. Statt den Wert in jedem Exemplar einzeln zu ändern, legt das Team des Schadendienstes ihn in einem gemeinsamen Programm ab, von dem alle Exemplare ihre Einstellungen laden. So ändert das Team den Wert nur einmal, und das gemeinsame Programm speichert zu jeder Änderung, wer sie wann gemacht hat. Dieses gemeinsame Programm heißt Configuration Server, auf Deutsch Konfigurationsdienst.
Wie funktioniert es?
Ein Mitarbeiter aus dem Team des Schadendienstes trägt im Konfigurationsdienst die neue Grenze für die Betrugsprüfung ein, 3.000 Euro statt 5.000 Euro. Eine Kollegin prüft die Änderung und gibt sie als Version 2 frei. Jedes der zwölf Exemplare des Schadendienstes fragt alle 30 Sekunden beim Konfigurationsdienst nach einer neuen Version und erhält Version 2 mit der Grenze von 3.000 Euro. Seltener nachzufragen würde die Zeit verlängern, bis alle Exemplare umgestellt haben; häufiger nachzufragen würde den Konfigurationsdienst belasten, bei dem die Programme aller Teams nachfragen. Die Exemplare laden den neuen Wert ohne Neustart, aber nicht alle gleichzeitig. Innerhalb einer Minute haben alle Exemplare Version 2 geladen. Während dieser Minute gelten beide Werte nebeneinander: Ein Exemplar hat schon umgestellt, ein anderes noch nicht. Ein Schaden von 4.000 Euro, der in dieser Zeit eingeht, kann also noch ohne Betrugsprüfung durchlaufen. Weil die Versicherung das nicht hinnehmen will, hält der Schadendienst bei jedem Schaden die Version fest, mit der über den Schaden entschieden wurde. So findet das Team des Schadendienstes nachträglich die Schäden, die in der Übergangsminute noch mit Version 1 entschieden wurden, und gibt sie an die Betrugsprüfung. Zum Schluss meldet jedes Exemplar seine Version an das Betriebsteam, das die laufenden Programme überwacht. Das Betriebsteam sieht in seiner Übersicht, dass alle zwölf Exemplare mit 3.000 Euro arbeiten.
Der Schadendienst läuft in mehreren Exemplaren, damit er viele Schäden gleichzeitig bearbeiten kann und der Ausfall eines Servers nicht den ganzen Schadendienst lahmlegt. Jedes Programm hat Einstellungen, auch Konfiguration genannt. Beim Schadendienst gehört dazu die Grenze für die Betrugsprüfung; andere Einstellungen sind zum Beispiel Adressen anderer Dienste und Zeitgrenzen. Jedes Team legt im Konfigurationsdienst die Einstellungen seines Programms je Umgebung ab. Eine Umgebung ist eine eigene Installation für einen Zweck, etwa das Testsystem oder das Produktivsystem, mit dem Kunden arbeiten. Für den Schadendienst gilt zum Beispiel im Produktivsystem die Grenze von 3.000 Euro und im Testsystem die Grenze von 100 Euro. Die niedrige Grenze im Testsystem sorgt dafür, dass schon kleine Testschäden an die Betrugsprüfung gehen; so kommt die Betrugsprüfung in jedem Test vor. Jede Änderung speichert der Konfigurationsdienst als neue Version. Die Werte liegen dort getrennt nach Programm, Umgebung und Version. Beim Start fragt jedes Exemplar seine Einstellungen beim Konfigurationsdienst ab. Von späteren Änderungen erfahren die laufenden Exemplare, indem sie in festen Abständen nachfragen oder indem der Konfigurationsdienst sie benachrichtigt.
Der Konfigurationsdienst sorgt nicht dafür, dass alle Exemplare im selben Augenblick umschalten, und er prüft nicht, ob ein Wert fachlich richtig ist. Ist der Konfigurationsdienst beim Start eines Exemplars nicht erreichbar, startet das Exemplar je nach Einrichtung mit dem zuletzt geladenen Stand, oder es verweigert den Start. Welche Möglichkeit gilt, legt das Team des Schadendienstes fest. Bei der Grenze für die Betrugsprüfung entscheidet das Team damit, ob ein neu gestartetes Exemplar womöglich noch mit der alten Grenze von 5.000 Euro arbeitet oder gar nicht startet.
Konfigurationsdienst: neue Grenze für die Betrugsprüfung verteilen
Wann ist es sinnvoll und wann nicht?
Ein Configuration Server lohnt sich
- Viele Programme laufen in mehreren Umgebungen und in mehreren Exemplaren, und ihre Einstellungen sollen einheitlich gepflegt werden. Ändert jemand einen Wert von Hand auf jedem Server, vergisst er leicht einen oder vertippt sich. Dann gelten auf den zwölf Exemplaren unterschiedliche Grenzen, und ein Schaden von 4.000 Euro geht je nach Exemplar zur Betrugsprüfung oder nicht. Niemand weiß dann sicher, welcher Wert gerade wo gilt.
- Einstellungen sollen im laufenden Betrieb geändert werden, ohne das Programm neu auszuliefern. Stehen die Einstellungen in einer Datei, die mit dem Programm ausgeliefert wird, muss für jede Änderung eine neue Programmversion gebaut und verteilt werden, obwohl sich am Code nichts ändert. Die Grenze für die Betrugsprüfung ändert sich aus fachlichen Gründen und unabhängig von den Auslieferungen. Sie richtet sich danach, wie viele Betrugsfälle gerade auffallen, nicht nach dem Stand des Codes.
- Einstellungen, die je Umgebung verschieden sind und sich selten ändern, sollen außerhalb des Codes liegen. Beispiele sind Adressen anderer Dienste und die Grenze für die Betrugsprüfung, die im Testsystem nur 100 Euro beträgt. Ohne Konfigurationsdienst pflegt das Team diese Werte für jede Umgebung getrennt auf deren Servern.
- Änderungen sollen nachvollziehbar und umkehrbar sein. Ändert jemand den Wert direkt auf den Servern, steht nirgends, wer ihn wann geändert hat und welcher Wert vorher galt. Version 2 ist mit Verfasser und Freigabe durch die Kollegin gespeichert, sodass später nachvollziehbar ist, wer die Grenze wann gesenkt hat. Erweist sich die neue Grenze als falsch, kann das Team des Schadendienstes Version 1 erneut verteilen.
Ein Configuration Server ist nicht das Richtige
- Ein einzelnes Programm läuft in einem einzigen Exemplar und hat nur wenige Werte. Das Team ändert einen Wert dann nur bei diesem einen Exemplar, und es gibt keine zwölf Exemplare, die denselben Wert brauchen. Dann gibt das Team des Programms die Werte als Umgebungsvariablen oder in einer Einstellungsdatei mit. Umgebungsvariablen sind Werte, die das Betriebssystem dem Programm beim Start mitgibt. Ein zusätzliches Programm, das betrieben, gesichert und gegen Ausfälle geschützt werden muss, entfällt.
- Werte ändern sich nur zusammen mit einer neuen Programmversion. Ein Beispiel ist der Name einer Datenbanktabelle, die erst die neue Programmversion verwendet. Über den Konfigurationsdienst kämen solche Werte getrennt von der Programmversion an, und ein Exemplar könnte mit der neuen Programmversion und den alten Werten laufen. Stattdessen legt das Team des Programms die Werte in Umgebungsvariablen oder in eine Datei, die mit jeder Auslieferung verteilt wird. Für diese Werte gilt so der übliche Auslieferungsablauf mit Tests und Freigabe.
- Es geht um Passwörter und andere vertrauliche Werte. Im Konfigurationsdienst könnte jeder, der dort lesen darf, die Passwörter sehen. Stattdessen legt das Team des Programms diese Werte nach Secrets Management in einen eigenen Speicher, der die Werte verschlüsselt aufbewahrt und nur berechtigten Programmen herausgibt. Der Konfigurationsdienst verweist höchstens auf diesen Speicher.
- Eine neue Funktion soll zuerst nur für eine Gruppe von Nutzern oder schrittweise für immer mehr Nutzer eingeschaltet werden. Der Konfigurationsdienst gibt jedem Exemplar aber denselben Wert für alle Nutzer. Stattdessen baut das Team des Programms Feature Toggles ein, Schalter im Code, mit denen sich einzelne Funktionen ein- und ausschalten lassen, und stellt die Schalter in einem Schalterdienst ein. Das Programm fragt den Schalterdienst bei jedem Aufruf, ob die Funktion für diesen Nutzer eingeschaltet ist.
Nachteile und typische Fehler
Der Konfigurationsdienst ist ein weiteres Programm, das betrieben, gesichert und gegen Ausfälle geschützt werden muss, denn alle Exemplare holen beim Start ihre Einstellungen bei ihm ab. Weil eine Änderung alle Exemplare innerhalb einer Minute erreicht, brauchen Änderungen eine Prüfung durch eine zweite Person und die Möglichkeit, schnell zur vorherigen Version zurückzukehren. Diese Prüfung verzögert jede Änderung. Nicht jede Einstellung lässt sich im laufenden Betrieb ändern. Das Programm muss für jede nachladbare Einstellung so gebaut sein, dass es den neuen Wert auch tatsächlich verwendet. Liest der Schadendienst die Grenze nur beim Start, wirkt eine neue Version erst nach einem Neustart.
Typische Fehler und woran man sie erkennt:
- Falscher Wert für alle: Ein Mitarbeiter trägt 300 statt 3.000 Euro ein, und die Kollegin übersieht den Fehler bei der Prüfung. Die falsche Grenze erreicht alle zwölf Exemplare innerhalb einer Minute, und jeder Schaden über 300 Euro geht an die Betrugsprüfung. Erkennbar ist das an einem sprunghaften Anstieg der Fälle in der Betrugsprüfung direkt nach der Freigabe.
- Konfigurationsdienst beim Start nicht erreichbar: Ein Exemplar verweigert den Start oder startet mit einem veralteten Stand, weil der Konfigurationsdienst gerade nicht antwortet. Erkennbar ist das an Exemplaren, die nach einem Neustart nicht hochkommen oder eine ältere Version melden.
- Geladen, aber nicht verwendet: Ein Exemplar liest die Grenze nur beim Start aus. Später lädt das Exemplar Version 2 und meldet sie, arbeitet aber weiter mit 5.000 Euro. Erkennbar ist das an Schäden über 3.000 Euro ohne Betrugsprüfung, bei denen Version 2 als verwendete Version vermerkt ist.
- Passwort im Klartext: Ein Passwort steht im Klartext im Konfigurationsdienst, und jeder mit Lesezugriff kann es sehen. Erkennbar ist das an Passwörtern in der Versionsgeschichte des Konfigurationsdienstes.
Weiterführend
Verwandte Ansätze
- Twelve Factor App: Sammlung von Regeln für Programme im Netz, die unter anderem verlangt, Einstellungen getrennt vom Code zu halten.
- Service Discovery: liefert die aktuellen Adressen anderer Dienste, die sonst fest in der Konfiguration stünden.
Werkzeuge und Umsetzungen
- Spring Cloud Config: Konfigurationsdienst, der Einstellungen aus einer Git-Ablage liest und an Java-Anwendungen ausliefert. Die Versionsgeschichte übernimmt dabei Git.
- etcd: verteilter, ausfallsicherer Speicher für Einstellungen, der angemeldete Programme über Änderungen benachrichtigt.
- Apache ZooKeeper: zentraler Dienst, über den verteilte Programme Einstellungen teilen und sich abstimmen.
- Nacos: verbindet Konfigurationsdienst und Verzeichnis der laufenden Dienste in einem Programm.
- Apollo: Konfigurationsdienst mit Bedienoberfläche, Freigabeablauf und Änderungsverlauf.
Quellen
- Microsoft: External Configuration Store pattern: beschreibt das Auslagern von Einstellungen in einen eigenen Speicher, Versionen, Nachfragen und Benachrichtigen bei Änderungen, einen zuletzt gültigen Stand für den Start und die Trennung von vertraulichen Werten.
- Adam Wiggins: The Twelve-Factor App, III. Config: begründet, warum Einstellungen, die sich zwischen Installationen unterscheiden, strikt vom Code getrennt sein müssen.