.env-Dateien erfreuen sich zunehmender Beliebtheit als Möglichkeit, eine Anwendung zu konfigurieren, indem Konfigurationseinstellungen, Umgebungsvariablen und sensible Informationen sicher gespeichert werden. Dieser lose Standard bietet eine Reihe von Vorteilen, von denen die meisten bei Upsun voll zum Tragen kommen. Allerdings müssen .env-Dateien auch richtig verwendet werden; ein falscher Gebrauch kann, wie bei allem, schlimmer sein, als sie überhaupt nicht zu verwenden.
Um zu verstehen, wie man .env-Dateien am besten verwendet, müssen wir zunächst verstehen, was mit "Umgebung" gemeint ist.
Einordnung der .env-Datei in den Kontext
Unabhängig von der Sprache, in der sie geschrieben ist, besteht Ihre Anwendung letztendlich aus einem Haufen Code. Dieser Codestapel ist statisch und ändert sich nicht, wenn er an verschiedenen Orten und zu verschiedenen Zeiten ausgeführt wird.
Wenn sie läuft, kümmert sie sich jedoch um andere "Dinge". Dabei kann es sich um eine Datenbank, einen Cache-Server, ein Dateisystem, ein Gateway zur Fernauthentifizierung oder tausend andere Dinge handeln. Dieses andere "Zeug" ist der Kontext, in dem die Anwendung läuft. Oder, alternativ, die Umgebung.
Diese Umgebung kann variabel sein. Ihre Anwendung benötigt vielleicht einen PostgreSQL-Server, aber mit welchem PostgreSQL-Server sie sich verbindet und welche Daten sich zu einem bestimmten Zeitpunkt darin befinden, ist alles Teil der Umgebung und kann sich unabhängig von Ihrem Code ändern. Sie möchten, dass Ihre Anwendung mit einem Zahlungs-Gateway kommuniziert, aber welche Anmeldeinformationen verwendet werden, kann je nach dem Kontext, in dem Sie laufen, variieren. (Wenn Sie API-Schlüssel für Produktionszahlungen in Ihre Anwendung einbauen und diese dann zum Testen versenden, kann das schlecht ausgehen. Glauben Sie mir das...)
Bei der Erstellung einer Anwendung ist es wichtig, eine saubere Trennung zwischen "Dingen, die in allen Umgebungen gleich sind" und "Dingen, die sich in jeder Umgebung ändern" vorzunehmen. Ersteres ist Ihr Code. Letzteres ist die Konfiguration Ihrer Umgebung.
Unix-ähnliche Betriebssysteme verfügen seit Jahrzehnten über einen Mechanismus zur Handhabung dieser umgebungsspezifischen Konfiguration: Umgebungsvariablen. Umgebungsvariablen sind systemglobale Zeichenfolgen, die jede Anwendung jederzeit lesen kann, um zu entscheiden, welcher Code ausgeführt werden soll.
Konfigurationsdateien für unterschiedliches Anwendungsverhalten
Das ist natürlich nicht die einzige Möglichkeit, wie Anwendungen ihr Verhalten ändern können. Die meisten Anwendungen haben eine Art "Konfigurationsdatei", die andere Einstellungen enthält, die das Verhalten der Anwendung verändern können. Dabei kann es sich um ausführbare Dateien (PHP, Javascript, Python usw.) oder nicht ausführbare Dateien(YAML, XML, ini, JSON, TOML usw.) handeln, und die Details sind so unterschiedlich wie die Anwendungen selbst.
Der wichtige Unterschied ist, dass ein Teil der Konfiguration mit der Installation der Anwendung variieren sollte, während ein anderer Teil mit der Umgebung variiert. Denken Sie daran, dass eine bestimmte Anwendung zu Testzwecken in mehreren Instanzen ausgeführt werden kann.
Wenn Sie zum Beispiel eine Anwendung entwickeln, die die Benutzer selbst installieren und konfigurieren können, wird der "Firmenname", für den die Anwendung bestimmt ist, je nach Benutzer variieren. Aber die Datenbank, mit der sie sich verbindet, wird für jede Instanz der Anwendung, die der Benutzer ausführt, unterschiedlich sein. Denken Sie an die Produktion, den Testbetrieb, den lokalen Laptop usw. Diese sollten alle denselben Firmennamen, aber unterschiedliche Datenbankanmeldedaten haben.
Das ist der erste wichtige Schritt: die Trennung der Konfiguration Ihrer Anwendung pro Installation (Firmenname) von der Konfiguration pro Umgebung (Datenbank). Wenn beide in derselben Datei enthalten sind, ist es wesentlich schwieriger, die Konfiguration pro Umgebung zu ändern, ohne dass sich auch die Konfiguration pro Installation ändert.
Eine ausführbare Konfigurationsdatei enthält manchmal eine Hintertür, die es erlaubt, die Umgebung zu variieren. Je nachdem, wie die Datei geschrieben ist, kann es möglich sein, sie manuell zu modifizieren, um bestimmte Werte von irgendwo anders zu lesen: eine zusätzliche Include-Datei, Umgebungsvariablen usw. Das ist aber immer noch ein Hack. Sie möchten die konsistente Konfiguration in Git einpflegen können, damit ihre Änderungen in allen Instanzen aktualisiert werden, nicht aber die umgebungsspezifische Konfiguration.
Und genau hier kommen die Umgebungsvariablen ins Spiel.
Aufrechterhaltung der Konsistenz mit Umgebungsvariablen
Der ideale Ort zum Speichern der umgebungsspezifischen Konfiguration sind Umgebungsvariablen. Die Mechanismen zum Setzen dieser Variablen sind gut etabliert. Die APIs zum Lesen der Variablen sind universell. Auch wenn zwei verschiedene Anwendungen möglicherweise nicht denselben Variablennamen verwenden, gibt es viele einfache Möglichkeiten, eine Umgebungsvariable auf der Grundlage einer anderen zu setzen.
Für die Produktion und das Testen sind Umgebungsvariablen daher der beste Ort, um die umgebungsspezifische Konfiguration zu verwalten. Entweder entwerfen Sie Ihre Anwendung so, dass sie diese direkt ausliest, oder Sie entwerfen eine vom Benutzer modifizierbare, ausführbare Konfigurationsdatei, die so modifiziert werden kann, dass sie Werte aus der Umgebung ausliest, anstatt sie direkt zu codieren. Wenn Sie die Anwendung von der Produktionsumgebung in die Staging-Umgebung oder von der Staging-Umgebung in eine branchenspezifische Umgebung verschieben, brauchen Sie nur die Umgebungsvariablen für diese neuen Umgebungen zu aktualisieren, und die Anwendung wird weiterlaufen.
.env-Dateien: Ihre Lösung für lokale Entwicklungsherausforderungen
Der Nachteil bei diesem Ansatz ist jedoch die lokale Entwicklung. Wahrscheinlich möchten Sie nicht auf Ihrem gesamten Computer eine globale Variable setzen, nur um der Entwicklungskopie Ihrer Anwendung mitzuteilen, welche gefälschten Anmeldeinformationen zu verwenden sind oder wo sich Ihre Testdatenbank befindet. Selbst wenn Sie lokal eine containerisierte Umgebung verwenden, möchten Sie vielleicht nicht direkt mit Umgebungsvariablen hantieren.
An dieser Stelle kommt die .env-Datei ins Spiel. .env ist ein De-facto-Standard für eine ini-ähnliche Datei, die gefälschte Umgebungsvariablen enthält. Eine Anwendung, die .env-Dateien unterstützt, durchläuft beim Booten jede Zeile in dieser Datei und liest Schlüssel-Wert-Paare. Für jede Zeile wird ausgeführt: "WENN eine Umgebungsvariable mit diesem Namen noch nicht existiert, setze sie auf der Grundlage dieser Datei." Dadurch wird die Variable nur im Rahmen des Prozesses Ihrer Anwendung gesetzt, ohne andere Prozesse auf dem Computer zu beeinträchtigen. Dann kann der Rest Ihrer Anwendung fortfahren und aus der Umgebung lesen, wie er es sonst auch tun würde, ohne von diesem Switcheroo zu wissen. (Schreiben Sie diesen Code nicht selbst. Es gibt in jeder Sprache Bibliotheken zur Unterstützung von .env, die alle genau das Gleiche tun. Verwenden Sie eine davon.)
Das, und nur das, ist der Zweck von .env-Dateien: Werte, die sich je nach Umgebung ändern und daher nicht Teil Ihrer Codebasis sind. Das bringt uns zum wichtigsten Punkt, an den man sich bei .env-Dateien erinnern muss: Sie gehören nicht in Git. Alles in Git wird in jeder Umgebung gleich sein, was genau das Gegenteil von dem ist, wofür Umgebungsvariablen und .env-Dateien gedacht sind.
Werte, die sich zwischen verschiedenen Umgebungen nicht ändern, gehören auch nicht in die .env-Datei. Der Name der Website, die E-Mail-Adresse des Administrators usw. sollten entweder in einer schreibgeschützten Konfigurationsdatei stehen, die an Git übergeben wird, oder in der Datenbank, je nachdem, ob Sie wollen, dass diese Konfigurationswerte vom Endbenutzer geändert werden können. (Beides ist zulässig, solange Sie es absichtlich tun.) Diese Werte gehören jedoch nicht in die .env-Datei, da sie nicht umgebungsspezifisch sind.
Handhabung von Build-Modi
Manchmal möchten Sie vielleicht den Code selbst an die Umgebung anpassen. Im Allgemeinen ist damit nicht der Quellcode gemeint, sondern der Kompilierungsprozess. In einer kompilierten Sprache (C, Rust, Go, Java usw.) möchten Sie vielleicht Debugsymbole im kompilierten Code in der Entwicklung, aber nicht in der Produktion belassen. Auch in interpretierten Sprachen(PHP, Javascript, Python usw.) kann es sinnvoll sein, CSS oder aggregiertes Javascript anders zu kompilieren und Leerzeichen nur in der Produktion zu entfernen, damit es leichter zu debuggen ist, zum Beispiel.
Dies stellt bei Upsun ein Problem dar, da der Build-Schritt unabhängig von allen umgebungsspezifischen Werten ausgeführt wird. Das liegt daran, dass die Build-Ausgabe in einer anderen Umgebung, z. B. der Produktionsumgebung, wiederverwendet werden kann. Insbesondere im Falle eines Fast-Forward-Merge zur Produktion müssen wir Ihre Anwendung nicht neu erstellen. Die erstellte Version aus einer Verzweigung wird wiederverwendet, d. h., was Sie in einer Verzweigung getestet haben, ist auf der Festplatte genau dasselbe wie das, was in der Produktion bereitgestellt wird. Nur so lassen sich Fehler vom Typ "funktioniert in meiner Verzweigung" minimieren, und das ist ein wesentlicher Bestandteil des Konzepts der containerisierten Bereitstellung.
Was aber, wenn Sie auf einem Zweig "entwickeln" wollen? Hier wird die Namenskonvention für .env-Dateien wichtig. Betrachten Sie die Nicht-Produktionsumgebung nicht als Entwicklungsumgebung. Die Entwicklung ist der Ort, an dem Sie den Code schreiben, also Ihr lokaler Computer. Auf Ihrem lokalen Computer können Sie alle Umgebungsvariablen (oder .env-Dateien ) setzen, die Sie wollen. Anstatt jeden Zweig als Entwicklungsumgebung zu betrachten, sollten Sie jeden Zweig als Staging-Umgebung betrachten. Die Staging-Umgebung sollte der Produktionsumgebung so nahe wie möglich kommen, einschließlich der Build-Modi.
So gesehen macht es keinen Sinn, dass der Build-Modus je nach Umgebung variiert, denn diese Variation ist ein Ort, an dem Heisenbugs auftreten können. Sie wollen keine Heisenbugs. (Vertrauen Sie mir.) Der "Debug-Modus" sollte an dem Ort stattfinden, an dem Sie debuggen und Code schreiben, d.h. in Ihrer lokalen Umgebung.
Und das ist der einzige Ort, an dem Sie eine .env-Datei verwenden können und sollten.
Die .env-elope bitte...
Um es noch einmal zusammenzufassen:
- Werte, die in allen Umgebungen gleich sind, sollten in Git stehen.
- Werte, die sich von einer Umgebung zur anderen unterscheiden, sollten aus Umgebungsvariablen gelesen werden.
- Das Mappen von Umgebungsvariablen des Hosts auf Umgebungsvariablen der Anwendung ist in Ordnung, aber Ihre Anwendung braucht einen Ort, um dies zu tun.
- Statische Konfigurationsdateien für umgebungsspezifische Informationen (wie z.B. Datenbank-Zugangsdaten) sind eine schreckliche Idee und werden Sie später verfolgen.
.env-Dateiensind ein Ersatz für Umgebungsvariablen, die nur für die lokale Entwicklung verwendet werden können, sollten aber niemals an Git übergeben werden.- Verstehen Sie Ihre Anwendung! Das ist immer Schritt 0.
Nützliche Links
Ihr größtes Werk
steht vor der Tür
