dotenv

dotenv

Shim zum Laden von Umgebungsvariablen von .env in ENV in der Entwicklung .

Das Speichern der Konfiguration in der Umgebung ist einer der Grundsätze einer Zwölf-Faktor-App. Alles, was sich wahrscheinlich zwischen den Bereitstellungsumgebungen ändert – etwa Ressourcenhandles für Datenbanken oder Anmeldeinformationen für externe Dienste –, sollte aus dem Code in Umgebungsvariablen extrahiert werden.

Es ist jedoch nicht immer praktisch, Umgebungsvariablen auf Entwicklungsmaschinen oder Continuous-Integration-Servern festzulegen, auf denen mehrere Projekte ausgeführt werden. dotenv lädt Variablen aus einer .env Datei in ENV wenn die Umgebung gebootet wird.

Installation

Fügen Sie diese Zeile oben in die Gemfile Ihrer Anwendung ein und führen Sie bundle install aus:

 gem 'dotenv' , groups : [ :development , :test ] 

Verwendung

Fügen Sie Ihre Anwendungskonfiguration zu Ihrer .env Datei im Stammverzeichnis Ihres Projekts hinzu:

S3_BUCKET=YOURS3BUCKET
SECRET_KEY=YOURSECRETKEYGOESHERE

Immer wenn Ihre Anwendung geladen wird, sind diese Variablen in ENV verfügbar:

 config . fog_directory = ENV [ 'S3_BUCKET' ]

Weitere Informationen finden Sie in den API-Dokumenten.

Schienen

Dotenv wird automatisch geladen, wenn Ihre Rails-App startet. Informationen zum Ändern, welche Dateien wann geladen werden, finden Sie unter Anpassen von Rails.

Sinatra / Rubin

Laden Sie Dotenv so früh wie möglich im Bootstrap-Prozess Ihrer Anwendung:

 require 'dotenv/load'

# or
require 'dotenv'
Dotenv . load

Standardmäßig sucht load im aktuellen Arbeitsverzeichnis nach einer Datei namens .env . Übergeben Sie mehrere Dateien und sie werden der Reihe nach geladen. Der erste für eine Variable festgelegte Wert gewinnt.

 require 'dotenv'
Dotenv . load ( 'file1.env' , 'file2.env' )

Automatische Wiederherstellung in Tests

Seit 3.0 stellt dotenv in einer Rails-App ENV nach jedem Test automatisch wieder her. Dies bedeutet, dass Sie ENV in Ihren Tests ändern können, ohne befürchten zu müssen, dass der Status an andere Tests weitergegeben wird. Es funktioniert sowohl mit ActiveSupport::TestCase als auch mit Rspec .

Um dieses Verhalten zu deaktivieren, legen Sie config.dotenv.autorestore = false in config/application.rb oder config/environments/test.rb fest. Es ist standardmäßig deaktiviert, wenn Ihre App „climate_control“ oder „ice_age“ verwendet.

Um dieses Verhalten außerhalb einer Rails-App zu nutzen, require "dotenv/autorestore" in Ihrer Testsuite.

Siehe Dotenv.save , Dotenv.restore und Dotenv.modify(hash) { ... } für die manuelle Verwendung.

Rechen

Um sicherzustellen, dass .env in Rake geladen wird, laden Sie die Aufgaben:

 require 'dotenv/tasks'

task mytask : :dotenv do
  # things that require .env
end

CLI

Sie können die ausführbare Datei dotenv „load .env verwenden, bevor Sie Ihre Anwendung starten:

$ dotenv ./script.rb

Die ausführbare Datei dotenv akzeptiert auch das Flag -f . Sein Wert sollte eine durch Kommas getrennte Liste von Konfigurationsdateien sein, in der Reihenfolge vom Wichtigsten zum Unwichtigsten. Alle Dateien müssen vorhanden sein. Zwischen dem Flag und seinem Wert muss ein Leerzeichen stehen.

$ dotenv -f " .env.local,.env " ./script.rb

Die ausführbare Datei dotenv kann optional fehlende Dateien mit dem Flag -i oder --ignore ignorieren. Wenn beispielsweise die Datei .env.local nicht vorhanden ist, wird im Folgenden die fehlende Datei ignoriert und nur die Datei .env geladen.

$ dotenv -i -f " .env.local,.env " ./script.rb

Auftrag laden

Wenn Sie Gems verwenden, für die vor dem Laden Umgebungsvariablen festgelegt werden müssen, listen Sie dotenv in der Gemfile vor diesen anderen Gems auf und erfordern dotenv/load .

 gem 'dotenv' , require : 'dotenv/load'
gem 'gem-that-requires-env-variables'

Anpassen von Schienen

Dotenv lädt abhängig von RAILS_ENV die folgenden Dateien, wobei die erste Datei die höchste Priorität und .env die niedrigste Priorität hat:

Priorität	Umfeld			.gitignore es?	Notizen
	Entwicklung	prüfen	Produktion
höchste	.env.development.local	.env.test.local	.env.production.local	Ja	Umgebungsspezifische lokale Überschreibungen
2	.env.local	N / A	.env.local	Ja	Lokale Überschreibungen
3	.env.development	.env.test	.env.production	NEIN	Gemeinsame umgebungsspezifische Variablen
zuletzt	.env	.env	.env	Vielleicht	Für alle Umgebungen freigegeben

Diese Dateien werden während des before_configuration Rückrufs geladen, der ausgelöst wird, wenn die Application Konstante in config/application.rb mit class Application < Rails::Application definiert ist. Wenn Sie eine frühere Initialisierung benötigen oder den Ladevorgang anpassen müssen, können Sie dies oben in application.rb tun

 # config/application.rb
Bundler . require ( * Rails . groups )

# Load .env.local in test
Dotenv :: Rails . files . unshift ( ".env.local" ) if ENV [ "RAILS_ENV" ] == "test"

module YourApp
  class Application < Rails :: Application
    # ...
  end
end

Verfügbare Optionen:

• Dotenv::Rails.files – Liste der zu ladenden Dateien, in der Reihenfolge ihrer Priorität.
• Dotenv::Rails.overwrite – Überschreiben Sie vorhandene ENV Variablen mit Inhalten von .env* -Dateien
• Dotenv::Rails.logger – Der Logger, der für die Protokollierung von dotenv verwendet werden soll. Standardmäßig ist Rails.logger
• Dotenv::Rails.autorestore – Automatische Wiederherstellung aktivieren oder deaktivieren

Mehrzeilige Werte

Mehrzeilige Werte mit Zeilenumbrüchen müssen in doppelte Anführungszeichen gesetzt werden.

PRIVATE_KEY= " -----BEGIN RSA PRIVATE KEY-----
...
HkVN9...
...
-----END DSA PRIVATE KEY----- "

Vor 3.0 ersetzte dotenv n in Zeichenfolgen in Anführungszeichen durch einen Zeilenumbruch, dieses Verhalten ist jedoch veraltet. Um das alte Verhalten zu verwenden, legen Sie DOTENV_LINEBREAK_MODE=legacy vor allen Variablen fest, die n enthalten:

DOTENV_LINEBREAK_MODE=legacy
PRIVATE_KEY= " -----BEGIN RSA PRIVATE KEY-----nHkVN9...n-----END DSA PRIVATE KEY-----n "

Befehlsersetzung

Sie müssen die Ausgabe eines Befehls in eine Ihrer Variablen einfügen? Fügen Sie es einfach mit $(your_command) hinzu:

DATABASE_URL= " postgres:// $( whoami ) @localhost/my_database "

Variablensubstitution

Sie müssen den Wert einer anderen Variablen in einer Ihrer Variablen hinzufügen? Sie können die Variable mit ${VAR} oder oft auch nur mit $VAR in Werten ohne oder in doppelten Anführungszeichen referenzieren.

DATABASE_URL= " postgres:// ${USER} @localhost/my_database "

Wenn ein Wert ein $ enthält und nicht als Variable gedacht ist, setzen Sie ihn in einfache Anführungszeichen.

PASSWORD= ' pas$word '

Kommentare

Kommentare können Ihrer Datei wie folgt hinzugefügt werden:

 # This is a comment
SECRET_KEY=YOURSECRETKEYGOESHERE # comment
SECRET_HASH= " something-with-a-#-hash "

Exporte

Aus Kompatibilitätsgründen können Sie vor jeder Zeile auch export hinzufügen, damit Sie die Datei in Bash source können:

 export S3_BUCKET=YOURS3BUCKET
export SECRET_KEY=YOURSECRETKEYGOESHERE

Erforderliche Schlüssel

Wenn ein bestimmter Konfigurationswert erforderlich, aber nicht festgelegt ist, ist es angebracht, einen Fehler auszulösen.

So fordern Sie Konfigurationsschlüssel an:

 # config/initializers/dotenv.rb

Dotenv . require_keys ( "SERVICE_APP_ID" , "SERVICE_KEY" , "SERVICE_SECRET" )

Wenn einer der oben genannten Konfigurationsschlüssel nicht festgelegt ist, löst Ihre Anwendung während der Initialisierung einen Fehler aus. Diese Methode wird bevorzugt, da sie Laufzeitfehler in einer Produktionsanwendung aufgrund einer falschen Konfiguration verhindert.

Parsing

So analysieren Sie eine Liste von Env-Dateien zur programmgesteuerten Überprüfung, ohne die ENV zu ändern:

 Dotenv . parse ( ".env.local" , ".env" )
# => {'S3_BUCKET' => 'YOURS3BUCKET', 'SECRET_KEY' => 'YOURSECRETKEYGOESHERE', ...}

Diese Methode gibt einen Hash der ENV-Var-Name/Wert-Paare zurück.

Vorlagen

Sie können das Flag -t oder --template auf der Dotenv-CLI verwenden, um eine Vorlage Ihrer .env Datei zu erstellen.

$ dotenv -t .env

In Ihrem Arbeitsverzeichnis wird eine Vorlage mit dem Namen {FILENAME}.template erstellt. Im obigen Beispiel würde also eine .env.template Datei erstellt.

Die Vorlage enthält alle Umgebungsvariablen in Ihrer .env Datei, deren Werte jedoch auf die Variablennamen festgelegt sind.

 # .env
S3_BUCKET=YOURS3BUCKET
SECRET_KEY=YOURSECRETKEYGOESHERE

Würde werden

 # .env.template
S3_BUCKET=S3_BUCKET
SECRET_KEY=SECRET_KEY

Häufig beantwortete Fragen

Kann ich dotenv in der Produktion verwenden?

dotenv wurde ursprünglich erstellt, um in der Entwicklung Konfigurationsvariablen in ENV zu laden. Normalerweise gibt es bessere Möglichkeiten, die Konfiguration in Produktionsumgebungen zu verwalten – etwa /etc/environment verwaltet von Puppet oder Chef, heroku config usw.

Einige halten dotenv jedoch für eine bequeme Möglichkeit, Rails-Anwendungen in Staging- und Produktionsumgebungen zu konfigurieren, und Sie können dies tun, indem Sie umgebungsspezifische Dateien wie .env.production oder .env.test definieren.

Wenn Sie dieses Gem verwenden, um Umgebungsvariablen für mehrere Rails-Umgebungen (Entwicklung, Test, Produktion usw.) zu verwalten, beachten Sie bitte, dass Umgebungsvariablen, die für alle Umgebungen gelten, in .env gespeichert werden sollten. Anschließend sollten umgebungsspezifische Umgebungsvariablen in .env. gespeichert werden.

Soll ich meine .env-Datei festschreiben?

Anmeldeinformationen sollten nur auf den Computern zugänglich sein, die Zugriff darauf benötigen. Übertragen Sie niemals vertrauliche Informationen in ein Repository, das nicht von jedem Entwicklungscomputer und Server benötigt wird.

Persönlich bevorzuge ich es, die .env Datei mit reinen Entwicklungseinstellungen zu übernehmen. Dies erleichtert anderen Entwicklern den Einstieg in das Projekt, ohne die Anmeldeinformationen für andere Umgebungen zu gefährden. Wenn Sie diesen Rat befolgen, stellen Sie sicher, dass sich alle Anmeldeinformationen für Ihre Entwicklungsumgebung von denen Ihrer anderen Bereitstellungen unterscheiden und dass die Entwicklungsanmeldeinformationen keinen Zugriff auf vertrauliche Daten haben.

Warum werden vorhandene ENV Variablen nicht überschrieben?

Standardmäßig werden vorhandene Umgebungsvariablen nicht überschrieben, da dotenv davon ausgeht, dass die Bereitstellungsumgebung mehr Kenntnisse über die Konfiguration hat als die Anwendung. Um vorhandene Umgebungsvariablen zu überschreiben, können Sie Dotenv.load files, overwrite: true .

Sie können auch das Flag -o oder --overwrite auf der Dotenv-CLI verwenden, um vorhandene ENV Variablen zu überschreiben.

$ dotenv -o -f " .env.local,.env " 

Mitwirken

Wenn Sie eine bessere Vorstellung davon haben möchten, wie dotenv funktioniert, schauen Sie sich die Ruby Rogues Code Reading von dotenv an.

1. Gabel es
2. Erstellen Sie Ihren Feature-Zweig ( git checkout -b my-new-feature )
3. Übernehmen Sie Ihre Änderungen ( git commit -am 'Added some feature' )
4. Zum Zweig pushen ( git push origin my-new-feature )
5. Erstellen Sie eine neue Pull-Anfrage