Was ist die bevorzugte Methode zum Speichern von Anwendungskonfigurationen?

Die meiste Zeit speichere ich die Konfiguration der Entwicklungsanwendung wie folgt im Stammverzeichnis des Projekts:

app
|-- config.json

Dies scheint jedoch nicht der beste Ansatz zu sein, da diese Konfiguration letztendlich im Versionskontrollsystem gespeichert wird - was möglicherweise zu einem Verlust von Benutzernamen, Passwörtern und anderen sensiblen Inhalten führt.

Im 12 Factor App- Handbuch wird empfohlen, die Konfigurationsdateien vollständig zu löschen und Umgebungsvariablen für die Konfiguration zu verwenden:

... speichert die Konfiguration in Umgebungsvariablen. Env-Vars können zwischen Bereitstellungen problemlos geändert werden, ohne dass Code geändert werden muss. Im Gegensatz zu Konfigurationsdateien besteht nur eine geringe Wahrscheinlichkeit, dass sie versehentlich in das Code-Repo eingecheckt werden. Im Gegensatz zu benutzerdefinierten Konfigurationsdateien oder anderen Konfigurationsmechanismen wie Java-Systemeigenschaften sind sie ein sprach- und betriebssystemunabhängiger Standard.

Das hört sich für mich wirklich gut an, aber wo speichert man die Umgebungsvariablen, ohne sie in die Quellcodeverwaltung einzuchecken? Und mit welchen Tools kann ich diese Variablen an die App übergeben? Es kann Dutzende von Konfigurationsoptionen geben, und es ist nicht schön, sie bei jedem Start der App von Hand einzugeben - sie müssen also irgendwo in einer Datei gespeichert werden. Die Datei wird somit in der Quellcodeverwaltung enden und wir kehren zu dem Punkt zurück, an dem wir begonnen haben.

Gibt es eine allgemein akzeptierte Möglichkeit, mit Konfigurationsoptionen umzugehen, die nicht das Risiko birgt, lokale Konfigurationen in der Quellcodeverwaltung zu speichern?

Möglicherweise gibt es keine gute Antwort darauf. Es scheint, dass Sie diese Daten an einem sicheren Ort speichern müssen, da sie eines Tages für Disaster Recovery-Zwecke benötigt werden. Dies gilt gleichermaßen für Eigenschaftendateien und Skripts, mit denen Umgebungsvariablen festgelegt werden.

• Mit dem Quellcode (in SVN / GIT usw.) ist eine wirklich schlechte Idee, da diese Daten Produktionsdatenbank-Passwörter und dergleichen enthalten.
• Das nächtliche Backup Ihres Unternehmens ist zwar ausreichend, es ist jedoch unwahrscheinlich, dass ein leicht zugänglicher Änderungsverlauf vorliegt.
• Die Daten müssen separat zur konsumierenden Software versioniert werden. In unserem aktuellen System führt eine Änderung der Konfiguration zu einer neuen Anwendungserstellung, und dies ist einfach falsch.

Wir suchen derzeit nach Lösungen für dieses Problem und tendieren zu einem Code-Repository mit eingeschränktem Zugriff. Dieses Repository würde nur Konfigurationsdaten enthalten. Haben andere Erfahrungen zu teilen?

Bei der Untersuchung von Problemen und möglichen Lösungen hilft es mir, eine Methode anzuwenden Wenn von Jeff Atwood verbreitete anwenden : Wenn Gott eine Möglichkeit schaffen würde, vertrauliche Konfigurationsinformationen zu speichern, wie würde er das tun?

Nun, er würde wissen, wer Konfigurationsinformationen benötigt, und diese nur an diese Personen weitergeben, und auf die Informationen könnte von niemand anderem zugegriffen werden.

Der erste Teil sollte bereits erledigt sein: Ihr Versionsverwaltungssystem sollte Benutzer authentifizieren. Und dieser Ansatz wird auch nach # 10 in Gültigkeit gegeben Troy Hunts 10 Geboten der Quellcodeverwaltung bestätigt : "Abhängigkeiten müssen in der Quellcodeverwaltung sein".

Aber wie hält man es sicher, wenn es durchgesickert ist? Nun, es muss dort nicht im Klartext gespeichert werden! Verwenden Sie die Verschlüsselung. In .NET können Sie Schritte ausführen, um Verbindungszeichenfolgendaten in Ihren Konfigurationsdateien zu verschlüsseln . Sie müssten die entsprechenden Methoden finden, um dies mit der Technologie Ihrer Wahl zu tun.

Viele Leute kritisieren das Speichern der Konfiguration in regulären Dateien zusammen mit Ihrem Quellcode, aber meiner Erfahrung nach ist dies eine ziemlich gute Lösung:

• Einfach in jeder Sprache zu implementieren. In vielen Fällen erhalten Sie sofort Unterstützung für komplexe Konfigurationsdateien. Im Fall von Java mit Spring Boot erhalten Sie beispielsweise YAML-Unterstützung, die jede baumartige Struktur ausdrücken kann, und es ist einfach, separate Konfigurationsdateien für verschiedene Umgebungen sowie eine Basiskonfiguration zu haben, von der umgebungsspezifische Dateien erben können.
• Zum Ausführen Ihrer Software ist eine Konfiguration erforderlich. Änderungen am Code erfordern häufig das Hinzufügen / Ändern von Konfigurationseinstellungen. Daher ist es natürlich, Konfiguration und Code zusammen zu halten.
• Das Speichern der Konfiguration mit der Quelle bietet Ihnen alle Vorteile der Quellcodeverwaltung, z. B. das Wissen, wer welche Einstellung geändert hat und wann oder in der Lage ist, die Konfigurationen während einer regelmäßigen Codeüberprüfung zu überprüfen.
• Wenn Sie nicht für die CIA arbeiten, scheint mir das Sicherheitsargument übertrieben. Ihr Datenbankkennwort wird also in einer Datei auf dem Computer gespeichert, auf dem Ihre App ausgeführt wird. Nun, wenn jemand mit Ihrer App Zugriff auf den Computer erhält, sind Sie wahrscheinlich bereits in großen Schwierigkeiten - er kann z. B. Ihre App herunterfahren und an seiner Stelle am selben Port eine eigene App starten. In einem solchen Szenario ist der Zugriff auf das DB-Kennwort möglicherweise kein so großes Problem. Sofern nicht alle Ihre Verbindungen vollständig verschlüsselt sind und Zugriff auf Ihr Gerät haben, können sie trotzdem einen Großteil der interessanten Daten von Netzwerkschnittstellen abrufen.
• Mit einem Tool wie Hiera können Sie eine Textkonfigurationsdatei erstellen, in der jedoch keine Kennwörter oder andere vertrauliche Daten gespeichert sind.

In vielen Fällen ist die in der Quellcodeverwaltung gespeicherte Textkonfiguration zusammen mit dem Code ein guter Anfang.

Wenn Sie sich für verteilte Systeme interessieren oder Ihre Konfiguration im laufenden Betrieb austauschen möchten, ohne Ihre Anwendungen erneut bereitstellen zu müssen, finden Sie möglicherweise eine Lösung, die auf einem Konfigurationsserver basiert. Spring Cloud unterstützt solche Mechanismen , und die Back-End-Serving-Konfigurationen können ein Git-Repository oder Eureka sein . Sie können auch Ihre eigenen mit zB Zookeeper rollen . Jede dieser Methoden erleichtert die Verwaltung konsistenter Konfigurationen auf vielen Servern, um Konfigurationen zu aktualisieren, ohne dass die Software neu erstellt und bereitgestellt werden muss. Dies ist natürlich mit Kosten verbunden, da der Konfigurationsserver und seine Verwendung von Ihren Anwendungen sowie von einem weiteren zu implementierenden und zu wartenden System gelernt werden.

Wir haben das gleiche Problem, wo ich arbeite. Im Moment sind alle unsere Konfigurationen dateibasiert und werden von den einzelnen Anwendungen, die sie verwenden, als Quelle gesteuert. Dies führt dazu, dass Duplikate erstellt werden und die Entwickler Zugriff auf Produktions- / QA-Kennwörter haben, anstatt nur auf die Entwicklung.

Trotzdem denke ich, dass wir in Zukunft eine gute Lösung gefunden haben. Wir verschieben unsere Konfigurationsdateien in ein separates Git-Repo (das als Config-Repo bezeichnet wird). Wir haben dann einen Spring-Cloud-Config-Server (Java) eingerichtet, der einfach die Dateien aus dem Konfigurations-Repository basierend auf den an ihn übergebenen Profilen bereitstellt. Dies ist ideal für Java-Anwendungen, die den Client verwenden und diese beim Start herunterladen können. Für unsere PHP / Non-Java-Apps ziehen wir die Datei direkt herunter. (Nicht ideal). In Zukunft werden wir vielleicht etwas schreiben, mit dem die PHP-Anwendung die Configs von sich aus herunterladen und irgendwo zwischenspeichern kann, aber es hat keine hohe Priorität für den ersten Durchlauf. Ich betrachte diese Lösung als Config-as-a-Service, der die 12-Faktor-Apps-Empfehlungen nicht explizit verletzt.

Ich glaube, Zookeeper kann für die gleiche Sache verwendet werden (ich habe ein Setup mit Kubernetes + Zookeeper gesehen), also bin ich mir nicht ganz sicher, warum diese Antwort oben ein -1 bekam.

Links:

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

https://cloud.spring.io/spring-cloud-config/

Speichern Sie die gesamte Konfiguration nicht in einer Datei, sondern in mehreren Dateien.

• Haben Sie ein Konfigurationsverzeichnis . Alle Dateien dort werden als Konfigurationsdateien interpretiert, außer vielleicht README*.
• Alle Dateinamen sind alphabetisch sortiert und die Dateien werden in dieser Reihenfolge geladen. Aus diesem Grunde Dateien in solchen Fällen oft mit einer Ziffer oder zwei beginnen: 01-logging.json. 02-database.json, etc.
• Daten aus allen Dateien werden in dieselbe Konfigurationsstruktur geladen, die der Anwendung zur Verfügung steht. Auf diese Weise können mehrere Dateien die Einstellungen der anderen ergänzen und sogar vorhersehbar überschreiben.
• Speichern Sie die Konfigurationsdateien nur mit sicheren Werten oder Standardwerten im VCS. Fügen Sie die Konfigurationsdateien während der Bereitstellung mit Geheimnissen hinzu, oder verwenden Sie noch besser einen authentifizierten Geheimnisse-Speicherdienst.

Schauen Sie sich auf Ihrer nächsten Linux-Box /etc/sudoers.doder an /etc/nginx/conf.d. Es zeigt das gleiche Muster.

Secrets Management ist ein anderes Biest. Sie können sie als manuellen Schritt verwalten, während Sie klein sind. Sie können Dinge wie Zookeeper verwenden. Sie können die Geheimnisse sogar in verschlüsselter Form in ein VCS einchecken und sie als Bereitstellungsschritt entschlüsseln. Es gibt eine Reihe weiterer Optionen.

(Außerdem ein Kommentar: JSON ist kein gutes Konfigurationsdateiformat, da es keine Kommentare zulässt. Kommentare sind von entscheidender Bedeutung. TOML-, YAML- und sogar INI-Formate sind in der Praxis besser geeignet.)

Ich denke, Ihre Optionen werden in gewisser Weise von dem Betriebssystem bestimmt, auf dem Sie die Bereitstellung durchführen

Ich würde vorschlagen, die Werte ja in die Quellcodeverwaltung zu stellen. ABER nur die 'dev' Versionen. Sie möchten, dass Ihr Quellcode kompiliert UND funktioniert! keine zusätzlichen geheimen Schritte enthalten

Ihr Erstellungs- und Bereitstellungsprozess sollte diese Werte dann während der Bereitstellung pro Umgebung austauschen. (Krake hat diese Art von Modell)

Apache zookeeper bietet wundervolle Optionen zum Speichern der Anwendungskonfigurationen für verteilte Systeme. Am Zookeeper vorgenommene Änderungen können erfasst und verarbeitet werden, indem ein Kurator oder ein Zookeeper-Listener am Anwendungsende anwesend ist.