この記事は、The Twelve-Factor Appを補足し、実際に現代的なWebアプリケーションで適用する場合の注意点などを紹介するシリーズです。下記の原文を読んだ上でのワンポイント解説になります。
概要
- 管理プロセスはアプリケーションの実行環境と同一リリースで行う
- 単発の処理を実行できる仕組みを用意しておく
これは何を表しているか
DBのマイグレーションや単発のスクリプトを実行する場合でも、アプリケーションの実行環境と同じリリースで実行することによって、処理の実行の差を少なくすることができます。
リリースというのは「5. ビルド、リリース、実行」で解説しましたが、コードベースをビルドしたものに環境要因の設定を合成したものです。実行環境と全く同じ構成になっているので、例えば実行環境のWebサーバーを bundle exec … で起動している場合、単発スクリプトも bundle exec… で実行することによって全く同じ状態で実行できるようになります。
また、REPLシェルが提供されていると、単発のスクリプトを自由に実行することが簡単になります。本番環境ではSSHなどを通じてリモートからコマンドを叩けるようになっているのが良いでしょう。
実際に運用する場合
Docker環境の場合、単発スクリプトをWebアプリケーションと全く同一のイメージ・同一の環境変数で、 docker run … で起動することによって、確実に同じリリースで実行することができます。コンテナオーケストレーションツールにはこのような単発実行の仕組みが用意されていると思いますので、それらを利用するのが良いでしょう。
本番環境へのSSHに関しては、セキュリティの懸念点や、リリース（「5. ビルド、リリース、実行」）を変更できてしまうという点、autoscaling環境ではそもそも接続先がはっきりしないという点などから、現代では可能な限り行わないほうが良いとされています。本番では実行できる単発処理を制限し、決められた単発処理だけリモートから実行できるような仕組みにしておくのが良いでしょう。
