Procfile
最終更新日 2022年02月16日(水)
Table of Contents
Heroku アプリには、起動時にアプリで実行するコマンドを指定する Procfile があります。 Procfile を使用して、次のようなさまざまなプロセスタイプを定義できます。
- アプリの Web サーバー
- 複数タイプの Worker プロセス
- シングルトンプロセス (clock など)
- 新しいリリースのデプロイ前に実行するタスク
アプリの各 dyno は、宣言されているプロセスタイプのいずれかに属し、そのプロセスタイプに関連付けられている起動コマンドを実行します。
プロセスモデルについての詳細を参照してください。
Procfile の名前と場所
Procfile は、常に、Procfile という名前のシンプルなテキストファイルで、ファイル拡張子はありません。たとえば、Procfile.txt は有効ではありません。
Procfile は、アプリのルートディレクトリに常駐している必要があります。ほかの場所に配置すると、機能しません。
Procfile の形式
Procfile では、個々の行で、次の形式を使用してプロセスタイプを宣言します。
<process type>: <command>
<process type> は、コマンドの英数字の名前です (web、worker、urgentworker、clock など)。<command> には、起動時にそのプロセスタイプのすべての dyno で実行する必要があるコマンドを指定します (rake jobs:work など)。
web プロセスタイプ
Heroku アプリの web プロセスは特殊です。Heroku のルーターから外部 HTTP トラフィックを受信できるのは、このプロセスタイプのみです。アプリに Web サーバーが含まれている場合は、その Web サーバーをアプリの web プロセスとして宣言する必要があります。
たとえば、Rails Web アプリの Procfile には、次のようなプロセスタイプが入ります。
web: bundle exec rails server -p $PORT
この場合、すべての web dyno で、Web サーバーを起動する bundle exec rails server -p $PORT が実行されます。
Clojure アプリの web プロセスタイプは、次のようになります。
web: lein run -m demo.web $PORT
指定するコマンドで、アプリの環境設定 (最も役立つのは $PORT) を参照できます。
Spring Boot を使用する場合などに、実行可能な Java JAR ファイルの web プロセスタイプを宣言することもできます。
web: java -jar target/myapp-1.0.0.jar
release プロセスタイプ
アプリの[Release Phase](release-phase)中に実行するコマンドを指定するには、`release` プロセスタイプを使用します。
その他のプロセスタイプ
web と release 以外のプロセスタイプには、特別なプロパティはありません。
多くのシンプルなアプリでは、1 つの web プロセスだけで十分です。より複雑なアプリでは、またアプリケーションに必要なランタイムプロセスを明示的に宣言するという推奨方式に従うために、追加のプロセスタイプを定義することもできます。たとえば、Rails アプリケーションには、このような追加プロセスタイプが含まれます。
worker: bundle exec rake jobs:work
ローカルでデプロイする
アプリケーションを開発およびデバッグするときには、ローカル開発環境をリモート環境と同じ方法で実行することが重要です。同じ方法で実行することで、非互換性や見つけにくいバグを本番環境にデプロイする前に発見し、アプリケーションを独立して動作する一連の個別コマンドではなく、総体的なユニットとして扱うことができます。
アプリをローカルで実行するには、Heroku Local コマンドラインツールを使用します。詳細は、Heroku Local の記事を参照してください。
Heroku にデプロイする
ほとんどの Heroku 対応言語で作成されたシンプルなアプリをデプロイする場合、技術的には Procfile は必要ありません。プラットフォームで自動的に言語が検出され、アプリケーションサーバーを起動するためのデフォルト web プロセスタイプが作成されます。ただし、アプリの制御と柔軟性を強化するためには、明示的な Procfile を作成することをお勧めします。
作成した Procfile を Heroku で使用するには、Procfile をアプリケーションのルートディレクトリに追加してから、Heroku にプッシュします。
$ git add .
$ git commit -m "Procfile"
$ git push heroku master
...
-----> Procfile declares process types: web, worker
Compiled slug size is 10.4MB
-----> Launching... done
http://strong-stone-297.herokuapp.com deployed to Heroku
To git@heroku.com:strong-stone-297.git
* [new branch] master -> master
heroku ps を使用して、実行中の dyno の数を調べます。 リストの左側の列にプロセスタイプが表示され、右側の列にそのプロセスタイプに対応するコマンドが表示されます。
$ heroku ps
=== web: `bundle exec rails server -p $PORT`
web.1: up for 2m
すべてのプロセスタイプのすべての dyno のログメッセージを集約したリストを表示するには、heroku logs を使用します。
$ heroku logs
2011-04-26T01:24:20-07:00 heroku[slugc]: Slug compilation finished
2011-04-26T01:24:22+00:00 heroku[web.1]: Running process with command: `bundle exec rails server mongrel -p 46999`
2011-04-25T18:24:22-07:00 heroku[web.1]: State changed from created to starting
2011-04-25T18:24:29-07:00 heroku[web.1]: State changed from starting to up
2011-04-26T01:24:29+00:00 app[web.1]: => Booting Mongrel
2011-04-26T01:24:29+00:00 app[web.1]: => Rails 3.0.5 application starting in production on http://0.0.0.0:46999
2011-04-26T01:24:29+00:00 app[web.1]: => Call with -d to detach
2011-04-26T01:24:29+00:00 app[web.1]: => Ctrl-C to shutdown server
プロセスタイプをスケールする
Heroku では 1 つの web dyno が自動的に実行されますが、ほかのプロセスタイプはデフォルトでは起動されません。 Worker を起動するには、Worker を 1 つの dyno にスケールアップする必要があります。
$ heroku ps:scale worker=1
Scaling worker processes... done, now running 1
dyno のサイズ をスケールすることもできます。
$ heroku ps:resize worker=standard-2x
Resizing dynos and restarting specified processes... done
worker dynos now standard-2x
実行中の新しいプロセスタイプを確認するには、次のようにして ps を確認します。
$ heroku ps
=== web: `bundle exec rails server -p $PORT`
web.1: up for 2m
=== worker: `env QUEUE=* bundle exec rake resque:work`
worker.1: up for 5s
Worker プロセスタイプからのメッセージのみ表示するには、heroku logs --ps worker を使用します。
$ heroku logs --ps worker
2011-04-25T18:33:25-07:00 heroku[worker.1]: State changed from created to starting
2011-04-26T01:33:26+00:00 heroku[worker.1]: Running process with command: `env QUEUE=* bundle exec rake resque:work`
2011-04-25T18:33:29-07:00 heroku[worker.1]: State changed from starting to up
2011-04-26T01:33:29+00:00 app[worker.1]: (in /app)
ここで表示される出力はローカル出力と一致し、ルーターや Dyno Manager などの Heroku のシステムコンポーネントからのシステムメッセージとインターリーブされています。
同じコマンドで、さらに上位へスケールアップできます。 たとえば、2 つの Web dyno と 4 つの Worker dyno にスケールアップします。
$ heroku ps:scale web=2 worker=4
Scaling web processes... done, now running 2
Scaling worker processes... done, now running 4
$ heroku ps
=== web: `bundle exec rails server -p $PORT`
web.1: up for 7m
web.2: up for 2s
=== worker: `env QUEUE=* bundle exec rake resque:work`
worker.1: up for 7m
worker.2: up for 3s
worker.3: up for 2s
worker.4: up for 3s
スケールについての詳細を参照してください。
その他のプロセスタイプの例
プロセスタイプの実行の Procfile モデルは、非常に柔軟です。 dyno は、どのコマンドででも、いくつでも実行でき、それぞれを個別にスケールできます。
たとえば、Ruby を使用して、 Release Phaseコマンドに加え、それぞれ別のキューを処理する 2 種類のキューワーカーを実行することができます。
release: ./release-tasks.sh
worker: env QUEUE=* bundle exec rake resque:work
urgentworker: env QUEUE=urgent bundle exec rake resque:work
この 2 種類のキューワーカーは、個別にスケールできます。
$ heroku ps:scale worker=1 urgentworker=5
Procfile と heroku.yml
heroku.yml をビルドのマニフェストとして使用している場合は、Procfile は不要です。 heroku.yml の run セクションで指定するコマンドに、Procfile と同じ形式を使用する必要があります (release を除く)。
参考情報
- 「Web アプリへの Unix プロセスモデルの適用」
- Release Phaseでは新しいリリースが本番環境にデプロイされる前にタスクを実行できる