😸
Railsの環境変数の管理でconfig_forを利用する
Railsアプリケーションにおける環境変数の管理についてconfig_forを使った事例を紹介する
背景
Railsアプリケーションでは、以下のような環境を使い分けています：
- 開発環境（development）
- テスト環境（test）
- ステージング環境（production）
- 本番環境（production）
構成をシンプルとしたいため、ステージング環境と本番環境は同じproduction環境として運用している。
課題
環境固有の設定をどう管理するか。例えば：
- APIキー（SendGridなど）
- 外部サービスのエンドポイント
- 通知先メールアドレス
は環境毎にパラメータが異なる。
環境変数は、インフラチームに依頼して設定可能。
一方でインフラチームに依頼せずに、アプリ固有の環境情報についてはアプリチームで完結できるようにしたい。
解決策
上記の通り環境変数による設定と、config_forを利用した設定を組み合わせる。
① 環境変数による設定
セキュリティ的に重要な情報や、インフラチームの管理が必要な設定値は環境変数で管理します。
# 環境変数による設定例
ENV["SENDGRID_APIKEY"] # APIキー
ENV["DATABASE_URL"] # データベース接続情報
ENV["EXTERNAL_SERVICE_ENDPOINT"] # 外部サービスエンドポイント
② config_forを使用
アプリケーション固有の設定はconfig_forを使用します。
環境変数APP_ENVを
- ステージング環境（staging）
- 本番環境（production）
設定しておく前提。
# config/application.rb
config.x.app = config_for(:app, ENV["APP_ENV"] || Rails.env)
# config/app.yml
development:
admin_email: "develop@example.com"
test:
admin_email: "test@example.com"
staging:
admin_email: "staging@example.com"
production:
admin_email: "production@example.com"
config_forは、envを引数に取るため環境毎に設定を切り替えることが可能
メリット・デメリット
[メリット]
設定値の管理責任が明確となった。
[デメリット]
設定値の参照箇所が分散する可能性
環境変数とconfig_forの使い分けの判断が必要
代替案
-
config/environments/staging.rbの作成- Rails Guidesで紹介されている方法
-
RAILS_ENV=stagingとして独立した環境を作成 - 却下理由：既存のインフラ環境がECSのため環境変数が利用しやすい。EC2やオンプレ環境であれば、stagingやcredentialsを使った切り替えのほうが便利だと思われる。
- すべての設定を環境変数で管理
- アプリ固有情報をインフラチームに依頼して設定
- 却下理由：インフラチームへの依頼が頻繁に必要
参考
Discussion