Heroku簡単じゃん。ビビるわ。
AWSのALB+Fargate+Auroraでちょーモダンな環境作るぜって息巻いていた。ただ、やっぱりAWSはインフラ構築の手順が色々あって(VPCだるい)、AWS力が低い私には一抹の不安があった。
Herokuだと「Dyno+JAWSDB」で、ALB+Fargate+Auroraと似たようなことができる。ホストOSの管理が要らないし、SSH開けなくて良い。ちょっとぐらいダウンしてもいいよインフラなら、$17で構築できる。やっす。アメリカにあるから多少レイテンシーが気になるけど、小規模なWebアプリならこれで充分だと判断。
herokuらしくgit push heroku master
でDockerイメージをビルドしてPUSHしてリリースまで一括で可能になっていた。それよ。
そのために必要なのが、heroku.yml
というファイル。こいつを作って、gitに追加しておくのだ。
heroku.yml の中身
build: docker: web: Dockerfile.web run: web: gunicorn -w2 -b 0.0.0.0:$PORT -t 60 run:app
docker-compose.yaml
に慣れてれば秒じゃん。
DBの接続情報やAPI_KEYのような機密情報は、全部HerokuのConfig-Vars
に寄せた。
heroku.yaml
ではConfig-Varsの値を参照できない。参照できるのはDockerFileに宣言した変数ENVとかARG
だけ。環境変数は、GitのようなレポジトリにPUSHするとまずい値はConfig-Vars
、別に問題ないものはDockerFileにセットするのがお作法かな。
上記で$PORT
を宣言しているけど、Herokuの仕様でDynoのポート番号がデプロイ時に決まり、それが環境変数を通して渡される格好になるので、このようになっています。
heroku.yml以前のデプロイ方法との違いが、下記に詳しい。
バッチ処理も秒で出来た
Heroku Schedulerを使って、秒でできた。python3 hoge.py
で完了。これでコンテナにあるhoge.py
を実行してくれる。そう、そういうの。最高。
今後のタスク
- Heroku PipeLineでCI/CDとステージング環境の作り方
- ログの永続化
- httpからhttpsへのリダイレクト
Heroku簡単じゃん。もっと早く覚えておけばよかったわ。