カスタム Rails 環境へデプロイする
最終更新日 2024年04月30日(火)
Table of Contents
Heroku では、git リポジトリにチェックインする暗号化ファイルを使用するのでなく、代わりに環境変数を使用してアプリケーションを設定することをお勧めします。環境変数に基づく設定を変更でき、git チェックインや新規デプロイを必要としません。
Rails には、様々な環境の概念があります。デフォルトでは、「テスト」、「開発」、「本番」があります。それぞれの環境の設定ファイルが config/environments フォルダの中にあるので、これを使用してカスタム動作を指定できます。Rails は Rails.env も公開しているので、コードの内部でカスタムロジックを記述できます。
if Rails.env.production?
# ...
else
# ...
end
Bundler が環境を認識しているので、特定の環境で特定の gem だけをロードできます。
gem 'rails_12factor', group: "production"
「ステージング」のような別のカスタム環境を作成して、config/environments/staging.rb を作成して Heroku アプリに RAILS_ENV=staging でデプロイしたいと思われるかもしれません。
しかし、これはお勧めできません。代わりに、必ず production モードで実行して、環境設定を設定してあらゆる動作を修正することをお勧めします。
開発/本番パリティ
Heroku では、開発環境と本番環境をできるだけ似せておくことを強くおすすめします。これを開発/本番パリティと呼びます。stagingをできるだけ production と似せておくこともお勧めします。これらが違い過ぎると、ステージングアプリをデプロイしてテストしても本番インスタンスが機能することを検証できません。
明示的動作
ベストプラクティスは、環境に関係したロジックを記述しながら 1 つの環境だけをベースにした動作を明記することです。たとえば、以下のように記述しないようにします。
if !Rails.env.development? && !Rails.env.test?
# ...
代わりに、次のように記述するのがよいでしょう。
if Rails.env.production?
# ...
動作の違いはごくわずかですが、重要です。staging環境を導入すると、Rails.env.production? 内のいずれのカスタムロジックも実行されません。
環境固有コードに加えて、Bundler が RAILS_ENV=staging 環境で実行したときターゲットを :production にした gem をロードしません。
ステージング動作を設定する
コードを記述するのは、多くが環境に基づいて設定を変更するためです。たとえば、ステージングアプリが実際のメールを送信したり、本番 S3 バケットを使用したら困るでしょう。そのため、Rails.env とカスタム staging 環境を次のように使用しないようにします。
if Rails.env.staging?
S3_BUCKET = "my_staging_bucket_name"
end
次のように、環境変数を使って設定するのがよいでしょう。
S3_BUCKET = ENV['MY_BUCKET_NAME']
こうすることでカスタム環境が不要になり、環境設定のセットをアプリごとに変えることで動作を完全コントロールできます。
上述したメールの例は、メールプロバイダーの認証情報が環境変数の中にある場合、それを変更することで防ぐことができます。あるいは、ご使用のプロバイダーがたとえば「テスト」モードを使用するよう設定することで、Mailgun にメールを送信しないよう指示することができます。
config/environments/production.rb で変更したいあらゆる設定を、環境変数から設定できます。ハードコーディングして git にチェックインする必要がありません。
ローカル
ローカルで、これらの環境変数を .env ファイルを使って設定できます。
まとめ
「ステージング」アプリまたは他のあらゆるカスタム環境を RAILS_ENV=production で実行して、動作における差異を最小限にする必要があります。カスタム環境の代わりに環境変数を使用して、アプリケーションが必要なときに異なる動作を実行できるように設定します。