Konfiguration der Umgebung — warum, was und wie?

Das Konfigurationsmanagement ist ein wichtiger Aspekt der Softwareentwicklung. In diesem Artikel wird das Warum und Was des Problems sowie die Gründe für die verschiedenen Lösungen, die es gibt, beleuchtet.

Der Ansatz zur Verwaltung der Konfiguration ändert sich, wenn die App skaliert — sowohl in Bezug auf den Traffic als auch in Bezug auf die Größe des Entwicklerteams. Um die Reise zu veranschaulichen, beginnen wir mit einer einfachen App.

Dies ist eine einfache Server-App, die eine Verbindung zu MongoDB herstellt und die Liste der Benutzer zurückgibt. Der Code ist nur Pseudocode und soll keiner Sprache entsprechen.

Hardcode-Konfiguration in der App: ein GROSSES NEIN!

Wenn Sie die MongoDB-URI fest in die App einprogrammieren, wird es wirklich schwierig, die Anwendung in einer anderen Umgebung auszuführen — z. B. auf den Laptops anderer Teamkollegen oder für die Produktion. Wir sollten dem folgen 12-Faktor-App-Methodik hier, um die Konfiguration vom Code zu trennen.

„KONFIGURATION VOM CODE TRENNEN“

Nun stellt sich die Frage, was die Konfiguration einer App umfasst? Zitat von https://12factor.net/config

Eine App Konfiguration ist alles, was wahrscheinlich variieren wird zwischen bereitstellt (Staging, Produktion, Entwicklerumgebungen usw.). Dies beinhaltet:

1. Ressourcen-Handles für die Datenbank, Memcached und andere unterstützende Dienste

2. Anmeldeinformationen für externe Dienste wie Amazon S3 oder Twitter

3. Werte pro Bereitstellung, z. B. der kanonische Hostname für die Bereitstellung

Die einfachste und gebräuchlichste Methode, die Konfiguration vom Code zu trennen, besteht darin, die Variablen in einer ENV-Datei abzulegen.

Sobald wir dies getan haben, müssen wir die Variablen im Code aus der Datei .env laden. Dazu gibt es mehrere Pakete dotenv und dotenv-expand. Die .env-Datei wird in diesem Fall nicht an Git übertragen und jeder Entwickler überschreibt die Variable entsprechend seiner eigenen Umgebung. Um allen Entwicklern eine Vorstellung davon zu geben, welche Umgebungsvariablen hinzugefügt werden müssen, übergeben wir normalerweise eine Datei wie .env.Beispiel zu Git.

Wir müssen auch Werte dieser Variablen in den Staging- und Produktionsumgebungen bereitstellen. Fast alle Bereitstellungssysteme bieten eine Möglichkeit, Umgebungsvariablen wie ConfigMap und Secrets in Kubernetes oder S3 für Elastic Container Service zu speichern und bereitzustellen.

Wir müssen diese Variablen in diese Umgebungen kopieren und sie synchronisieren, wenn Entwickler Umgebungsvariablen hinzufügen/entfernen. Ein möglicher Ansatz besteht darin, eine separate ENV-Datei für Staging-, Produktions- usw. Umgebungen zu verwenden.

Wie und wo speichern wir die umgebungsspezifischen ENV-Dateien?

Man kann vorschlagen, diese Dateien in Git zu speichern, aber es gibt eine großes Sicherheitsproblem in diesem Fall — speziell für einige der vertraulichen Anmeldeinformationen in den env-Dateien.

1. Wir möchten wahrscheinlich nicht, dass alle Entwickler Zugriff auf Datenbankanmeldeinformationen und andere sicherheitsrelevante Informationen haben.
2. Das Speichern aller Anmeldeinformationen im Klartext im Github-Repository ist auch unter dem Gesichtspunkt der Sicherheitslücke ein großes Sicherheitsrisiko.

Die Menschen verwenden hier unterschiedliche Herangehensweisen — einige der bekanntesten Methoden sind jedoch:

1. Verschlüsselte Werte im Git-Repository speichern und die Werte können nur von jemandem entschlüsselt werden, der die Schlüssel hat. Eine gute Bibliothek, um dies zu erreichen, ist https://github.com/StackExchange/blackbox
2. Verwenden Sie externen Speicher: Bei diesem Ansatz werden die Umgebungsvariablen für Staging, Produktion usw. in einer anderen Speicherebene wie S3 oder AWS Parameter Store gespeichert. Nur die Produktions- und Staging-Umgebungen verfügen über die Berechtigungen zum Lesen dieser Werte und können daher vor Entwicklern geschützt werden. Hier kommen auch SecretManager ins Spiel, die die Geheimnisse verschlüsselt speichern, die Zugriffskontrolle ermöglichen und die Geheimnisse auch automatisch rotieren können. Einige Beispiele für solche geheimen Manager/Parameterspeicher sind:

Während wir eines dieser externen Systeme verwenden, haben wir jetzt die Konfiguration zwischen den.env-Dateien und den Secretmanagers aufgeteilt. Einige der nicht sensiblen Parameter stammen aus den.env-Dateien, andere aus dem Remote-Speicher der Anmeldeinformationen. Wir können argumentieren, dass wir alle Parameter im Remote-Speicher speichern können — aber das kann manchmal übertrieben sein. Am Ende haben wir also Folgendes:

Unsere Anwendung benötigt jetzt Code zum Lesen aus diesen beiden Konfigurationsquellen. Das Lesen aus den.env-Dateien kann mit dem Paket dotenv erfolgen. Um die Umgebungsvariablen von den Secretmanagers abzurufen, müssen wir jedoch die entsprechenden APIs verwenden, um die Werte abzurufen.

Dies löst das Problem, unsere Konfiguration sicher zu halten und auch die 12-Faktoren-Methode zu befolgen.

Das Schreiben von Anwendungscode zum Abrufen von Geheimnissen ist jedoch eine sich wiederholende Praxis, bei der jede Anwendung jetzt Secretmanager-spezifischen Code hinzufügen muss, um die Werte von der API abzurufen. Das bedeutet auch, dass, wenn wir jemals unseren Secretsmanager-Anbieter ändern, der Code in allen Anwendungen geändert werden muss. Um dieses Problem zu lösen, gibt es mehrere Ansätze:

1. Abstrahieren Sie den Code, um Geheimnisse als Standardbibliothek abzurufen, die von allen Ihren Anwendungen gemeinsam genutzt werden kann. Dies kann das Problem bis zu einem gewissen Grad vereinfachen.
2. Synchronisieren Sie Werte von den Secretmanagers asynchron mit der Hosting-Umgebung. Dazu ist ein externes System erforderlich, das die Synchronisation von Code-Releases und Konfigurationsänderungen erschweren kann. Zum Beispiel Vault-K8S ermöglicht das Synchronisieren von Vault-Geheimnissen mit Kubernetes-Umgebungen.
3. Verwenden Sie eine kostenpflichtige Lösung wie Doppler (doppler.com)
4. Verwenden Sie Open-Source-Lösungen wie Secrets Foundry — Auf diese Weise können Sie mit verschiedenen Geheimdienstmanagern sprechen, ohne Ihren Anwendungen Code hinzufügen zu müssen. Ich werde in meinem nächsten Artikel mehr über SecretsFoundry schreiben.

Das Konfigurationsmanagement ist komplex und sollte von Anfang an ordnungsgemäß durchgeführt werden, um sicherzustellen, dass die Geschwindigkeit der Entwickler hoch bleibt, ohne auf Sicherheitsaspekte zu verzichten. Kubernetes, das heute am häufigsten für die Bereitstellung von Anwendungen verwendet wird, verfügt über eine eigene Konfiguration und eine eigene Geheimverwaltung, auf die ich in einem anderen Artikel näher eingehen werde. Auch wenn Sie eine andere Methode für das Konfigurationsmanagement verwenden, erwähnen Sie dies bitte in den Kommentaren — ich würde gerne mehr erfahren und von Ihnen lernen!

Wahre Gießerei ist ein KI-Gateway für Unternehmen, das LLM, MCP und Agenten-Gateways umfasst und es Unternehmen ermöglicht, den Zugriff auf Modelle, Tools, Leitplanken und Agenten von einer einzigen Kontrollebene aus sicher zu verbinden, zu beobachten und zu steuern. Das AI Gateway ermöglicht folgende agentische Workloads:
a) Sicher — Lösung für Schlüsselverwaltung, Authentifizierung und Autorisierung
b) Effizient — Optimierung von Kosten, Latenz und Failovers für mehrere Regionen
c) Zukunftssicher — ermöglicht einheitliche und zusammensetzbare Verbindungen zwischen LLMs, MCPs und Guardrails von jedem Anbieter