Dotenvはproductionで使わないほうがよいのではという話の続き

前の話

t-cyrill.hatenablog.jp

もう二年近く前の話になりますが、昔の書いた記事のアクセスが地味に多いので、 結局自分はどうしているのかという話を少しだけ書きます。

以下はRuby on Railsな環境ででdotenvを使って本番サーバの設定を切り替えられるようにしようとしても、unicornなどのRackサーバを再起動しないと読み込まれないから微妙な感じがあるから、結局どうしているのかという話です。

1. /etc/environment を使う

物理サーバ固有の設定は /etc/environment に記述します。 サーバ構築時に設定は記述し、ほとんど変更の必要がないパラメータのみこちらに書いています。

私の場合、CPU性能が異なるマシンを使わなければならない場合に、 性能に応じてunicornのworker数を決めるなどの用途に使うことが多いです。

# /etc/environment
UNICORN_WORKERS = 32

2. Figaro を使う

サーバの役割ごとの設定は Figaro を使っています。

github.com

Figaroの設定は unicorn の再起動時に読み直されるので、頻繁に更新される設定も Figaro に記述しておくと便利です。

Environment-Specific Configuration の節にもあるように環境ごとに設定を用意し、 test や production の設定をまとめて書くようにします。

FigaroはYAMLの構文を解釈するのでアンカーとエイリアスを使って設定の共有と上書きを実現できます。

# Global configration
common: "global"

test:
  testing: "1"
staging_and_production: &staging_and_production
  common: "for_staging_and_prodction" 
staging:
  <<: *staging_and_production
  override: "for_staging"
production:
  <<: *staging_and_production
  override: "for production"

このようにすると、全環境共通の設定と、一部環境で共有したい設定、環境ごとに異なる設定を綺麗にまとめることができます。

設定漏れも少なくなりますが、複雑な構文を多用しすぎると可読性に難が出るので上記の設定程度にとどめておくのが理想です。

実際のところ

ここ2年ほどRailsのサーバでは上記のほうほうで環境ごとに設定の切り替えができるようにしていますが、 今のところ問題なくうまく運用できています。

Figaroの設定ファイル application.yml はgithubなどの外部サービスとは分けた(例えばVPN内のgitサーバの)プライベートリポジトリで管理しておくことで、 設定ファイルの変化を追跡できるようにしつつ、秘密の情報を外部に漏らすことなく運用することができます。

前回の記事では具体的な運用例を挙げていなかったので、よさげと思ったら採用してみてください。 We are busters!