dotenv Télécharger - dotenv Téléchargement du code source

dotenv

Autre code source

3.1.4

Télécharger

dotenv

Cale pour charger les variables d'environnement de .env dans ENV en cours de développement .

Le stockage de la configuration dans l'environnement est l'un des principes d'une application à douze facteurs. Tout ce qui est susceptible de changer entre les environnements de déploiement, comme les descripteurs de ressources pour les bases de données ou les informations d'identification pour les services externes, doit être extrait du code dans des variables d'environnement.

Mais il n'est pas toujours pratique de définir des variables d'environnement sur des machines de développement ou des serveurs d'intégration continue sur lesquels plusieurs projets sont exécutés. dotenv charge les variables d'un fichier .env dans ENV lorsque l'environnement est démarré.

Installation

Ajoutez cette ligne en haut du Gemfile de votre application et exécutez bundle install :

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

Usage

Ajoutez la configuration de votre application à votre fichier .env à la racine de votre projet :

S3_BUCKET=YOURS3BUCKET
SECRET_KEY=YOURSECRETKEYGOESHERE

A chaque chargement de votre application, ces variables seront disponibles dans ENV :

 config . fog_directory = ENV [ 'S3_BUCKET' ]

Consultez la documentation API pour en savoir plus.

Rails

Dotenv se chargera automatiquement au démarrage de votre application Rails. Voir Personnalisation de Rails pour modifier quels fichiers sont chargés et quand.

Sinatra / Rubis

Chargez Dotenv le plus tôt possible dans le processus de démarrage de votre application :

 require 'dotenv/load'

# or
require 'dotenv'
Dotenv . load

Par défaut, load recherchera un fichier appelé .env dans le répertoire de travail actuel. Transmettez plusieurs fichiers et ils seront chargés dans l’ordre. La première valeur définie pour une variable gagnera.

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

Restauration automatique dans les tests

Depuis la version 3.0, dotenv dans une application Rails restaurera automatiquement ENV après chaque test. Cela signifie que vous pouvez modifier ENV dans vos tests sans craindre de fuite d'état vers d'autres tests. Il fonctionne à la fois avec ActiveSupport::TestCase et Rspec .

Pour désactiver ce comportement, définissez config.dotenv.autorestore = false dans config/application.rb ou config/environments/test.rb . Il est désactivé par défaut si votre application utiliseclimate_control ou ice_age.

Pour utiliser ce comportement en dehors d'une application Rails, require "dotenv/autorestore" dans votre suite de tests.

Voir Dotenv.save , Dotenv.restore et Dotenv.modify(hash) { ... } pour une utilisation manuelle.

Râteau

Pour vous assurer que .env est chargé dans rake, chargez les tâches :

 require 'dotenv/tasks'

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

CLI

Vous pouvez utiliser l'exécutable dotenv load .env avant de lancer votre application :

$ dotenv ./script.rb

L'exécutable dotenv accepte également l'indicateur -f . Sa valeur doit être une liste de fichiers de configuration séparés par des virgules, du plus important au moins important. Tous les fichiers doivent exister. Il doit y avoir un espace entre le drapeau et sa valeur.

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

L'exécutable dotenv peut éventuellement ignorer les fichiers manquants avec l'indicateur -i ou --ignore . Par exemple, si le fichier .env.local n'existe pas, ce qui suit ignorera le fichier manquant et chargera uniquement le fichier .env .

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

Ordre de chargement

Si vous utilisez des gemmes qui nécessitent que des variables d'environnement soient définies avant leur chargement, répertoriez dotenv dans le Gemfile avant ces autres gemmes et exigez dotenv/load .

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

Personnalisation des rails

Dotenv chargera les fichiers suivants en fonction de RAILS_ENV , le premier fichier ayant la priorité la plus élevée et .env ayant la priorité la plus basse :

Priorité	Environnement			`.gitignore` ?	Remarques
	développement	test	production
le plus élevé	`.env.development.local`	`.env.test.local`	`.env.production.local`	Oui	Remplacements locaux spécifiques à l'environnement
2ème	`.env.local`	N / A	`.env.local`	Oui	Remplacements locaux
3ème	`.env.development`	`.env.test`	`.env.production`	Non	Variables spécifiques à l'environnement partagées
dernier	`.env`	`.env`	`.env`	Peut être	Partagé pour tous les environnements

Ces fichiers sont chargés lors du rappel before_configuration , qui est déclenché lorsque la constante Application est définie dans config/application.rb avec class Application < Rails::Application . Si vous avez besoin qu'il soit initialisé plus tôt ou si vous devez personnaliser le processus de chargement, vous pouvez le faire en haut de application.rb

 # 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

Options disponibles :

Dotenv::Rails.files - liste des fichiers à charger, par ordre de priorité.
Dotenv::Rails.overwrite - Remplacer les variables ENV existantes par le contenu des fichiers .env*
Dotenv::Rails.logger - Le logger à utiliser pour la journalisation de dotenv. La valeur par défaut est Rails.logger
Dotenv::Rails.autorestore - Activer ou désactiver la restauration automatique

Valeurs multilignes

Les valeurs multilignes avec des sauts de ligne doivent être entourées de guillemets doubles.

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

Avant la version 3.0, dotenv remplaçait n dans les chaînes entre guillemets par une nouvelle ligne, mais ce comportement est obsolète. Pour utiliser l'ancien comportement, définissez DOTENV_LINEBREAK_MODE=legacy avant toute variable incluant n :

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

Remplacement de commande

Vous devez ajouter la sortie d'une commande dans l'une de vos variables ? Ajoutez-le simplement avec $(your_command) :

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

Substitution de variables

Vous devez ajouter la valeur d'une autre variable dans l'une de vos variables ? Vous pouvez référencer la variable avec ${VAR} ou souvent simplement $VAR dans des valeurs non cotées ou entre guillemets doubles.

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

Si une valeur contient un $ et qu'elle n'est pas destinée à être une variable, placez-la entre guillemets simples.

PASSWORD= ' pas$word '

Commentaires

Des commentaires peuvent être ajoutés à votre dossier comme tels :

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

Exportations

Pour des raisons de compatibilité, vous pouvez également ajouter export devant chaque ligne afin de pouvoir source le fichier en bash :

 export S3_BUCKET=YOURS3BUCKET
export SECRET_KEY=YOURSECRETKEYGOESHERE

Clés requises

Si une valeur de configuration particulière est requise mais n'est pas définie, il est approprié de générer une erreur.

Pour exiger des clés de configuration :

 # config/initializers/dotenv.rb

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

Si l'une des clés de configuration ci-dessus n'est pas définie, votre application générera une erreur lors de l'initialisation. Cette méthode est préférable car elle évite les erreurs d'exécution dans une application de production dues à une configuration incorrecte.

Analyse

Pour analyser une liste de fichiers env pour une inspection programmatique sans modifier l'ENV :

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

Cette méthode renvoie un hachage des paires nom/valeur de la variable ENV.

Modèles

Vous pouvez utiliser l'indicateur -t ou --template sur la cli dotenv pour créer un modèle de votre fichier .env .

$ dotenv -t .env

Un modèle sera créé dans votre répertoire de travail nommé {FILENAME}.template . Ainsi, dans l'exemple ci-dessus, cela créerait un fichier .env.template .

Le modèle contiendra toutes les variables d'environnement de votre fichier .env mais avec leurs valeurs définies sur les noms de variables.

 # .env
S3_BUCKET=YOURS3BUCKET
SECRET_KEY=YOURSECRETKEYGOESHERE

Deviendrait

 # .env.template
S3_BUCKET=S3_BUCKET
SECRET_KEY=SECRET_KEY

Questions fréquemment répondues

Puis-je utiliser dotenv en production ?

dotenv a été créé à l'origine pour charger des variables de configuration dans ENV en cours de développement . Il existe généralement de meilleures façons de gérer la configuration dans les environnements de production - telles que /etc/environment géré par Puppet ou Chef, heroku config , etc.

Cependant, certains trouvent que dotenv est un moyen pratique de configurer des applications Rails dans des environnements de transfert et de production, et vous pouvez le faire en définissant des fichiers spécifiques à l'environnement comme .env.production ou .env.test .

Si vous utilisez cette gemme pour gérer les variables d'environnement pour plusieurs environnements Rails (développement, test, production, etc.), veuillez noter que les variables d'environnement générales à tous les environnements doivent être stockées dans .env . Ensuite, les variables d'environnement spécifiques à l'environnement doivent être stockées dans .env. .

Dois-je valider mon fichier .env ?

Les informations d'identification ne doivent être accessibles que sur les machines qui doivent y accéder. Ne confiez jamais d’informations sensibles à un référentiel qui n’est pas nécessaire à chaque machine et serveur de développement.

Personnellement, je préfère valider le fichier .env avec des paramètres de développement uniquement. Cela permet aux autres développeurs de démarrer facilement le projet sans compromettre les informations d'identification pour d'autres environnements. Si vous suivez ces conseils, assurez-vous que toutes les informations d'identification de votre environnement de développement sont différentes de celles de vos autres déploiements et que les informations d'identification de développement n'ont accès à aucune donnée confidentielle.

Pourquoi n'écrase-t-il pas les variables `ENV` existantes ?

Par défaut, il n'écrasera pas les variables d'environnement existantes car dotenv suppose que l'environnement de déploiement a plus de connaissances sur la configuration que l'application. Pour écraser les variables d'environnement existantes, vous pouvez utiliser Dotenv.load files, overwrite: true .

Vous pouvez également utiliser l'indicateur -o ou --overwrite sur la cli dotenv pour écraser les variables ENV existantes.