まとめ
- 前提
- monorepoである
- golangでapiとbatch(cron)が用意されている
- api,batchは実行時に環境変数を読み取り挙動を変える
- github actionsでherokuにdeployしてその結果をslackに通知している
- render.com側の仕組み
- 複数サービスを管理する際はBlueprintsを利用する(はず)
- 環境毎にBlueprint Instanceを作成する
- Blueprintはrender.yamlで設定される
- 微妙な点
- render.yamlの内容が環境毎に切り替えられない
- render.yamlでサービスのnameを設定するが、環境毎にnameを明示的に分けることができない
- render.yamlでenvVarsを設定するが、環境毎に参照先を分けることができない
- render.yamlでサービス毎にplanを設定するが、環境毎にplanを明示的に分けることができない
- deploy時の通知が各サービス毎であり、全てのdeployが完了したことを検知しづらい
- github actions側からrender側のdeployが完了したことを検知しづらい
- 関連する全サービスのdeploy状況を検知する仕組みを用意すればこの点は解消されそう
- 現状はサービスごとにdeployをhttp経由でhookする形になる
- 試したこと
- production用とdev用にaccountを用意してみたが、特定のgithub連携は1つのaccountにのみ可能であるため、うまくいかなかった
- render.yaml自体の記述(plan等)でenvを参照できるか試したが、参照できなかった
- 感想
- Blueprints側で(環境毎に設定を切り替えるために)設定ファイル(render.yaml)を選択可能になると良さそう
- Blueprintsの更新をhookするAPIが用意されて、github actionsから更新結果を受け取るactionが(marketplaceに)用意されると良さそう
Last modified: 2022年9月11日