Als Plattformteam bei Trendyol Tech war es eines unserer Ziele, die Anwendungskonfiguration und die Verwaltung von Geheimnissen dynamisch, zuverlässig und sicher zu machen und von den Anwendungen zu abstrahieren. Wir verwenden Kubernetes ConfigMaps und Secrets schon seit langem und sie erfüllen unsere Anforderungen nicht vollständig. Wenn wir zum Beispiel eine Konfiguration in einer ConfigMap ändern, müssen wir unsere Anwendungs-Pods neu starten, damit die Änderung wirksam wird. Manchmal dauert es mehrere Minuten, bis sich die Änderung auf alle Anwendungsinstanzen auswirkt. Ein weiteres Problem ist, dass die Kubernetes-Geheimnisse nicht sicher genug sind. Unsere Geheimnisse müssen sicher und überprüfbar sein.
Unsere Hauptanforderungen waren:
- Wir sollten in der Lage sein, Anwendungskonfigurationen dynamisch zu ändern, ohne Anwendungsprozesse neu zu starten. Wenn wir eine Konfiguration ändern, sollte sich dies sofort auf alle Anwendungsinstanzen auswirken.
- Unsere Anwendungsgeheimnisse müssen sicher und überprüfbar sein. Wir wollen auch eine rollenbasierte Zugriffskontrolle auf Geheimnisse anbieten.
- Wir müssen die Konfigurationsverwaltung von den Anwendungen abstrahieren. Mit anderen Worten, die Anwendungen sollten nicht wissen, wo und wie Geheimnisse und Konfigurationen aufbewahrt und für sie bereitgestellt werden.
- Unser Konfigurations- und Geheimnisverwaltungssystem muss hochverfügbar und skalierbar sein.
Nach einigen Recherchen kamen wir auf 2 Anwendungen: envconsul und consul-template.
Wir wussten bereits, dass Vault das Standardwerkzeug für die Speicherung von Geheimnissen ist. Es erfüllt alle unsere Anforderungen und verfügt über Funktionen wie dynamische Geheimnisse, die für uns in Zukunft nützlich sein könnten. Sie können auch Consul als Speicher-Backend für Vault verwenden.
Consul ist ein verteiltes, hochverfügbares und skalierbares Tool für die Erkennung und Konfiguration von Diensten. In unserem Fall werden wir nur die Key-Value-Store-Funktion von Consul verwenden, um nicht geheime Konfigurationen zu speichern.
Wir könnten envconsul oder consul-template hauptsächlich für die dritte Anforderung verwenden: die Abstraktion des Konfigurationsmanagements von den Anwendungen.
Envconsul bietet eine Möglichkeit, einen Unterprozess mit Umgebungsvariablen aus Consul und Vault zu starten.
Consul-template füllt Werte aus Consul und Vault in das Dateisystem ein und hält die Werte synchron, während man im Daemon-Modus arbeitet.
Eine Zwölf-Faktoren-App-Regel ist, Konfigurationen in der Umgebung zu speichern. Aber das Problem mit Envconsul (oder Umgebungsvariablen) ist, dass man die Umgebungsvariablen eines Prozesses nicht ändern kann, ohne ihn neu zu starten. Dies steht im Widerspruch zu unserer ersten Anforderung. Wir wollen in der Lage sein, Konfigurationen zu ändern, ohne Anwendungsprozesse neu zu starten. Deshalb haben wir uns für consul-template entschieden.
In consul-template kann man eine Vorlagendatei für die Darstellung von Konfigurationsdateien verwenden. Das gibt uns eine große Flexibilität. Hier ein Beispiel für eine Vorlagendatei;
Consul-template liest diese Vorlage und ersetzt die Platzhalter durch Werte aus Consul, wenn Sie das Schlüsselwort „key“ verwenden, und aus Vault, wenn Sie das Schlüsselwort „with secret“ verwenden. Mehr über die Vorlagensprache erfahren Sie hier. Die gerenderte Ausgabedatei würde wie folgt aussehen;
server:
port: "8080"
toggles:
fooEnabled: true
database:
username: "username"
password: "password"