dotenv
3.1.4
Shim は、開発時に.envからENVに環境変数をロードします。
環境内に構成を保存することは、12 要素アプリの原則の 1 つです。データベースのリソース ハンドルや外部サービスの資格情報など、デプロイメント環境間で変更される可能性があるものはすべて、コードから抽出して環境変数に入れる必要があります。
ただし、複数のプロジェクトが実行される開発マシンまたは継続的統合サーバーに環境変数を設定することが常に現実的であるとは限りません。 dotenv は、環境がブートストラップされるときに、 .envファイルからENVに変数をロードします。
この行をアプリケーションの Gemfile の先頭に追加し、 bundle install実行します。
gem 'dotenv' , groups : [ :development , :test ] アプリケーション構成をプロジェクトのルートにある.envファイルに追加します。
S3_BUCKET=YOURS3BUCKET
SECRET_KEY=YOURSECRETKEYGOESHEREアプリケーションがロードされるたびに、次の変数がENVで使用可能になります。
config . fog_directory = ENV [ 'S3_BUCKET' ]詳細については、API ドキュメントを参照してください。
Dotenv は、Rails アプリの起動時に自動的にロードされます。どのファイルをいつロードするかを変更するには、「Rails のカスタマイズ」を参照してください。
アプリケーションのブートストラップ プロセスでできるだけ早い段階で Dotenv をロードします。
require 'dotenv/load'
# or
require 'dotenv'
Dotenv . loadデフォルトでは、 load現在の作業ディレクトリで.envというファイルを探します。複数のファイルを渡すと、それらは順番にロードされます。変数に設定された最初の値が優先されます。
require 'dotenv'
Dotenv . load ( 'file1.env' , 'file2.env' )3.0 以降、Rails アプリの dotenv は各テスト後にENV自動的に復元します。これは、他のテストに状態が漏洩することを心配せずに、テスト内のENV変更できることを意味します。 ActiveSupport::TestCaseとRspec両方で動作します。
この動作を無効にするには、 config/application.rbまたはconfig/environments/test.rbでconfig.dotenv.autorestore = falseを設定します。アプリがclimate_controlまたはice_ageを使用している場合、デフォルトでは無効になっています。
Rails アプリの外部でこの動作を使用するには、テスト スイートでrequire "dotenv/autorestore"だけです。
手動での使用方法については、 Dotenv.save 、 Dotenv.restore 、およびDotenv.modify(hash) { ... }を参照してください。
.envが rake にロードされていることを確認するには、タスクをロードします。
require 'dotenv/tasks'
task mytask : :dotenv do
# things that require .env
endアプリケーションを起動する前に、 dotenv実行可能ファイルload .envを使用できます。
$ dotenv ./script.rb dotenv実行可能ファイルは、フラグ-fも受け入れます。その値は、最も重要なファイルから最も重要でないファイルの順に並べたコンマ区切りのリストである必要があります。すべてのファイルが存在する必要があります。フラグとその値の間にはスペースが必要です。
$ dotenv -f " .env.local,.env " ./script.rb dotenv実行可能ファイルは、 -iまたは--ignoreフラグを使用して、欠落しているファイルをオプションで無視できます。たとえば、 .env.localファイルが存在しない場合、次のコマンドは欠落しているファイルを無視し、 .envファイルのみをロードします。
$ dotenv -i -f " .env.local,.env " ./script.rbロードする前に環境変数を設定する必要がある gem を使用する場合は、 Gemfile内で他の gem の前にdotenvリストし、 dotenv/load要求します。
gem 'dotenv' , require : 'dotenv/load'
gem 'gem-that-requires-env-variables'Dotenv は、 RAILS_ENVに応じて次のファイルをロードします。最初のファイルの優先順位が最も高く、 .env優先順位が最も低くなります。
| 優先度 | 環境 | .gitignore無視しますか？ | 注意事項 | ||
|---|---|---|---|---|---|
| 発達 | テスト | 生産 | |||
| 最高 | .env.development.local | .env.test.local | .env.production.local | はい | 環境固有のローカルオーバーライド |
| 2番目 | .env.local | 該当なし | .env.local | はい | ローカルオーバーライド |
| 3位 | .env.development | .env.test | .env.production | いいえ | 共有環境固有の変数 |
| 最後 | .env | .env | .env | 多分 | すべての環境で共有 |
これらのファイルは、 before_configurationコールバック中にロードされます。このコールバックは、 Application定数がconfig/application.rbでclass Application < Rails::Applicationで定義されているときに起動されます。より早く初期化する必要がある場合、または読み込みプロセスをカスタマイズする必要がある場合は、 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利用可能なオプション:
Dotenv::Rails.files - ロードされるファイルのリスト (優先順位)。Dotenv::Rails.overwrite - 既存のENV変数を.env*ファイルの内容で上書きしますDotenv::Rails.logger - dotenv のロギングに使用するロガー。デフォルトはRails.loggerですDotenv::Rails.autorestore - 自動復元を有効または無効にする改行を含む複数行の値は二重引用符で囲む必要があります。
PRIVATE_KEY= " -----BEGIN RSA PRIVATE KEY-----
...
HkVN9...
...
-----END DSA PRIVATE KEY----- " 3.0 より前では、dotenv は引用符で囲まれた文字列内のn改行に置き換えていましたが、その動作は非推奨になりました。古い動作を使用するには、 nを含む変数の前にDOTENV_LINEBREAK_MODE=legacyを設定します。
DOTENV_LINEBREAK_MODE=legacy
PRIVATE_KEY= " -----BEGIN RSA PRIVATE KEY-----nHkVN9...n-----END DSA PRIVATE KEY-----n "コマンドの出力を変数の 1 つに追加する必要がありますか? $(your_command)で追加するだけです。
DATABASE_URL= " postgres:// $( whoami ) @localhost/my_database "変数の 1 つに別の変数の値を追加する必要がありますか?変数は${VAR}で参照できますが、多くの場合、引用符で囲まれていない値または二重引用符で囲まれた値の$VARだけを参照することもできます。
DATABASE_URL= " postgres:// ${USER} @localhost/my_database "値に$含まれており、それが変数であることを意図していない場合は、一重引用符で囲みます。
PASSWORD= ' pas$word 'コメントは次のようにファイルに追加できます。
# This is a comment
SECRET_KEY=YOURSECRETKEYGOESHERE # comment
SECRET_HASH= " something-with-a-#-hash "互換性を保つために、bash でファイルをsourceできるように、各行の前にexportを追加することもできます。
export S3_BUCKET=YOURS3BUCKET
export SECRET_KEY=YOURSECRETKEYGOESHERE特定の構成値が必要であるにもかかわらず設定されていない場合は、エラーを発生させるのが適切です。
構成キーを要求するには:
# config/initializers/dotenv.rb
Dotenv . require_keys ( "SERVICE_APP_ID" , "SERVICE_KEY" , "SERVICE_SECRET" )上記の構成キーのいずれかが設定されていない場合、アプリケーションは初期化中にエラーを発生させます。この方法は、不適切な構成による実稼働アプリケーションの実行時エラーを防ぐため、推奨されます。
ENV を変更せずにプログラムによる検査のために env ファイルのリストを解析するには:
Dotenv . parse ( ".env.local" , ".env" )
# => {'S3_BUCKET' => 'YOURS3BUCKET', 'SECRET_KEY' => 'YOURSECRETKEYGOESHERE', ...}このメソッドは、ENV var の名前と値のペアのハッシュを返します。
dotenv cli で-tまたは--templateフラグを使用して、 .envファイルのテンプレートを作成できます。
$ dotenv -t .env {FILENAME}.templateという名前の作業ディレクトリにテンプレートが作成されます。したがって、上記の例では、 .env.templateファイルが作成されます。
テンプレートには、 .envファイル内のすべての環境変数が含まれますが、その値は変数名に設定されます。
# .env
S3_BUCKET=YOURS3BUCKET
SECRET_KEY=YOURSECRETKEYGOESHEREなるだろう
# .env.template
S3_BUCKET=S3_BUCKET
SECRET_KEY=SECRET_KEY dotenv は元々、開発中に構成変数をENVにロードするために作成されました。通常、実稼働環境で設定を管理するには、Puppet または Chef によって管理される/etc/environment 、 heroku configなどのより良い方法があります。
ただし、 dotenv がステージング環境や本番環境で Rails アプリケーションを構成する便利な方法であると考える人もいます。これは、 .env.productionや.env.testなどの環境固有のファイルを定義することで実現できます。
この gem を使用して複数の Rails 環境 (開発、テスト、運用環境など) の環境変数を処理する場合、すべての環境に共通する環境変数は.envに保存する必要があることに注意してください。次に、環境固有の環境変数を.env.に保存する必要があります。
資格情報には、アクセスする必要があるマシン上でのみアクセスできるようにする必要があります。すべての開発マシンやサーバーで必要とされない機密情報をリポジトリにコミットしないでください。
個人的には、 .envファイルを開発専用の設定でコミットすることを好みます。これにより、他の開発者は、他の環境の認証情報を損なうことなく、プロジェクトを簡単に開始できるようになります。このアドバイスに従う場合は、開発環境のすべての認証情報が他の展開とは異なること、および開発認証情報が機密データにアクセスできないことを確認してください。
ENV変数を上書きしないのはなぜですか?デフォルトでは、dotenv はデプロイメント環境がアプリケーションよりも構成に関する知識を持っていると想定しているため、既存の環境変数は上書きされません。既存の環境変数を上書きするには、 Dotenv.load files, overwrite: true使用できます。
dotenv cli で-oまたは--overwriteフラグを使用して、既存のENV変数を上書きすることもできます。
$ dotenv -o -f " .env.local,.env " dotenv がどのように機能するかをより詳しく知りたい場合は、dotenv の Ruby Rogues Code Reading を参照してください。
git checkout -b my-new-feature )git commit -am 'Added some feature' )git push origin my-new-feature )
