どんな場面で検討するか
Webサービス、常駐worker、cron、DBを組み合わせるバックエンドをGitまたはコンテナから運用し、ビルド/起動を簡略化したい場合。
組織で使う条件
初期のfilesystemはdeployで失われるため、必要なデータはDB/diskに分離する。 health check・SIGTERM処理・deploy履歴を管理し、データ移行はコード切戻しと別に扱う。
採用前に試すこと
- 合成CRUDアプリとworkerをdeployし、DB保存と一時ファイルを別々に作る。
- 改版/失敗ビルド/再起動を試し、health checkとSIGTERM処理、DB件数を確認する。
- persistent disk有/無の停止範囲を比較し、隔離環境のデータ復元と旧版deploymentを試す。
合格と判断する条件
- API/workerが動き、合成データが保存される。
- 失敗deployで正常版を維持し、再起動後も必要なDB値を保持する。
- diskによる停止条件を説明でき、復元後の件数とコード版が一致する。
見落としたくない点
- persistent diskを付けたまま無停止deployが当然に成立するとみなさない。 freeサービスの停止/永続化条件で本番可用性を満たせないなら有料構成や別基盤を比較する。
- persistent diskを付けたまま無停止deployが当然に成立するとみなさない。
- freeサービスの停止/永続化条件で本番可用性を満たせないなら有料構成や別基盤を比較する。