Herokuでアプリをつくるための基礎知識
Herokuのしくみ
抽象的な説明。上のチュートリアルのあとに読むと具体的に何を指してるのか理解しやすい
Herokuでビルドするために必要なもの
ソースコード
依存性
Nodeのアプリの場合、依存性はpackage.jsonに記述する
どれが実行可能かHerokuに教える
nodeの場合はpackage.jsonのmainフィールドが暗黙に利用される
Procfileはプロセスタイプ（実行するコマンドに名前をつけたもの）の一覧
アーキテクチャを記述することになる
エントリポイントはいくつあって…とか
プロセスタイプごとに独立してスケールさせることができるので設計上重要
webのプロセスタイプを5個たてる、とかがコマンド一発でできる
結局、アプリケーションは以下の構成要素からなる
ソースコード
依存性の記述
Procfile
Herokuにアプリをデプロイする方法
Heroku APIでデプロイ
アプリケーションのビルド
slugはソースコードやランタイムをひとまとめにしてコンパイルして実行可能にしたもの Dyno上でアプリケーションを動かす
dynoは仮想化された軽量Unixコンテナのようなもの dynoにslugをロードして、Procfileのコマンドで実行する
今動いてるDynoはheroku psでわかる
Dynoの数でスケールさせることができる
Config
アプリの外に設定ファイルをかける。アプリとは無関係に変更できる
設定heroku config:set ENCRYPTION_KEY=my_secret_launch_codes
取得ENV["ENCRYPTION_KEY"]
秘匿情報や環境設定をもたせたいときにつかう
リリース
dynoでは最近のslugを使うといったが、あれは嘘だ
本当はslugとconfigをロードしてあわせたものを使う。この組み合わせをリリースという。
つまり、設定だけかえてもリリースはつくられる
herokuにpushするごとにリリースが作成されてappend-onlyの台帳に記録される
Dyno manager
dynoの実行に責任を持つモジュール
dynoはサイクルする
いつおこる？
少なくとも1日1回
dyno managerが次のことを検知したとき
アプリの失敗（メモリ例外など）
dynoを動かしてるハードウェアが他のハードへdynoを動かしたがっている
dynoのサイクルは定常的におこっていてログにのこる
dyno managerがやるので、利用者はOSや内部の設定を気にする必要はない
one-off dynoを使うとmanagerのinput/outputをターミナルから見ることができる
例：heroku run bashでbashが起動する
one-off dynoとともにリリースがロードされる
このshellで加えた変更はセッション終了時に破棄される
アドオン
いろんなサードパーティのアドオンが使える
Dynoはファイルの状態共有しないのでredisアドオンとかを使ってjob queueでdyno間でやりとりするのが典型的な使い方
アドオンの設定はconfigに書くことが多い
リリースはslugとconfigの組み合わせといったが、あれは嘘だ
リリースはslugとconfigとaddonの組
つまり、add-onが追加/削除された場合、リリースが作られる
ロギングとモニタリング
herokuはすべてのdynoのログのイベントストリームをかきあつめてLogplexに送る
heroku logで全てのコンポーネントとdynoのログを見ることができる
heroku logs --ps web.1 --tailとかで単一のdynoのログをtailできる
logplexはパフォーマンスの都合で一定量のログしか保持しない
例外発生時にメールしたりしたいならlogging用のアドオンを使うこと
ルーティング
HerokuのHTTPルータがweb dynoにリクエストを中継する
webのトラフィックをスケールさせたいときは、web dynoをスケールさせる
ロードバランシングにはrandom selection algorithmが使われている
タイムアウトやmultiple simultaneous connectionsもできる
Tying it all together
ここまでの整理と要約