あまり考えずに適当に設定を管理していると、コンテナ化して試験環境で確認したサーバーをそのまま本番にアタッチさせたりとかしたいってなったときに死ぬことになる。色々考えてみる。2.1.5で確認。
内容の要約
- distでビルドするときは引数に何も加えない
- アプリとloggerの設定はstartの実行引数に加える
- propertiesは使うとややこしくなるのでtypesafe configに一本化する
- 設定はサーバーアプリとは別に管理する
設定の種類
Playのサーバーにおける設定は色々ある。DBに格納、などは考えるとキリはないので静的ファイルとしてアタッチするものだけ。
- アプリ系設定
- .conf
- .properties
- ルーティング
- .routes
- ログ設定
- application-logger.xml(～2.3)
- logger.xml(～2.3)
- logback.xml(2.4～2.5)
- evolution用sql
一応propertiesも書いてるけど、play側でそれよりも便利なtypesafe configを導入してるのでそれに一本化した方がいいと思う。
設定を当てるタイミングについて
play dist時にくっつける場合
play distを使って実際に動くアプリケーションを作ると思うけれども、ここでplay -Dconfig.file=conf/prod.conf distとか設定するとその設定で動かすための準備をplay側でやってくれる。
具体的に書くと、以下のことをやってくれる。
- zipの直下に設定ファイルを置いてくれる
- startスクリプトのjava実行オプションに｢-Dconfig.file=`dirname $0 `/application.conf｣をくっつけてくれる
便利。
でもこれを使うと、このアプリケーションを別の環境に移し替えたときにstartを置き換えたりzip直下の設定ファイルを置き換えないといけないので色々困る。なので使わない。
実行時にくっつける場合
play/activator distで生成される実行スクリプトのstartはとても便利で、以下のように$*で引数を受け付ける作りになっている。
#!/usr/bin/env sh
scriptdir=`dirname $0`
classpath="$scriptdir/lib/hoge.jar:..."
exec java $* -cp $classpath play.core.server.NettyServer `dirname $0`
たとえば、./start -Dconfig.file=~/path/to/test.conf -Dlogger.file=/path/to/logger.xmlとかやればその設定で動く。
なので、daemontoolsやsupervisorなどでプロセス管理をしている場合はそこの実行内容に記載すればいい。
設定の配置
conf/以下にファイルを置くと全部activator distで出来たzipの内のlib/hoge-SNAPSHOT.jarの中に展開される。
上記では-Dconfig.fileと-Dlogger.fileを使ってファイル指定をしているけれど、-Dconfig.resourceと-Dlogger.resourceを使うとクラスパスの中身から検索を行う。
conf以下に設定ファイルを置くとこれが利用可能。startでどれを使うか設定できるのは変わらないのでこの辺はお好みで。
個人的には、設定とアプリケーションを完全に切り分けて管理するといいと思う。
設定だけ変更する場合、playのdistから始めなくても設定だけ別にfetchしてplayの再起動かければわざわざアプリのビルドは必要ないし。
ちなみに
今触ってるplayのサーバーアプリはこんな感じ。
- conf/の下に設定系全部ぶち込んでる
- propertiesも使ってる
- hoge.properties.forbetaみたいなファイルをビルドスクリプト中でデプロイ先に合わせてhoge.propertiesに変えて配置し直してる
- -Dconfig.file=hoge.conf distでビルドしてる
- ヒープなどのjvm系の設定はビルドスクリプト中でstartファイルをsedで置換して埋め込んでる
- ログの設定はどの環境も指定してない(application-logger.xml使ってる)
- どの環境でもトレースまで出してる
はい。