デプロイの仕組み
サービスはそれぞれ単独でデプロイされます。サービスの Deploy（または Redeploy）は、そのサービスをビルドまたは pull し、現在の設定で再起動します。プロジェクトの他のサービスはそのまま動き続けます。サービスを追加すると自動でデプロイされ、ネットワーク設定を変更するとそのサービスが再デプロイされます。
すべてのサービスを一度に展開するには（いくつも編集したあとなど）、プロジェクトの Settings にある Deploy all を使います。Deploy all は、プロジェクトから削除したサービスの撤去も行います。
ステップ
各サービスは次の状態を経ていき、Overview とサイドバーに表示されます。
| 状態 | 何が起きているか |
|---|---|
| Pending | デプロイの中で順番を待っています |
| Building | Git サービスが Zenavo のビルドマシンでビルドされています |
| Deploying | Kubernetes オブジェクトをサーバーに適用しています |
| Starting | コンテナが起動し、ヘルスチェックの合格を待っています |
| Running | すべてのインスタンスが準備できています |
| Failed / Crashed | ビルドか展開が失敗したか、コンテナが終了を繰り返しています。原因は Logs で確認してください。 |
- ビルド。 Git サービスはクローンされてビルドされ（ビルドプラン）、イメージは Zenavo のイメージストアにサービスごとのリポジトリとして保存され、サーバーはそこから pull します（中国本土のサーバーは上海のコピーから）。イメージのサービスは digest に解決されるので、ロールバックでもまったく同じイメージが動きます。
- 適用。 サービスが適用されます。Deploy all では依存関係の順に適用され、各サービスは依存先の準備ができるのを待ちます。
- 展開。 ボリュームのないサービスはダウンタイムなしで更新されます。新しいインスタンスが healthy になってから古いものが止まります。ボリュームのあるサービスは、2 つのインスタンスが同じデータに書き込まないよう、いったん止めてから起動します。
- 初期化。 サービスに初期化コマンド（テンプレート由来）があれば、サービスが起動する前に、同じイメージ・変数・ボリュームを使ったジョブで一度だけ実行されます。
ビルドキュー
Git のビルドは、すべてのチームが共有する Zenavo のビルドマシンで動きます。チームが同時に実行できるビルドの数はプランで決まります（使用量と請求）。それを超えたビルドは待機し、そのことがログに表示されます。
ビルドマシンが混んでいるときは、空いたマシンを待機中のビルドのうち最上位のプランのものに割り当てます。Team、Pro、Dev、Free の順で、同じプラン内では先着順です。10 分待ったビルドはプランにかかわらず次に回されるので、長く待たされることはありません。Docker イメージやデータベースのデプロイはビルドがないので、ここで待つことはありません。
デプロイ中に Zenavo が再起動した場合
Zenavo のコントロールプレーンは、更新時などにときどき再起動します。実行中だったデプロイは中断したところから続行し、ログにその旨が記録されます（Control plane restarted; resuming from …）。
- ビルド中： デプロイはキューに戻り、もう一度ビルドします。
- ビルド後： ビルド済みのイメージをそのままデプロイし、再ビルドはしません。
- ロールアウト中： ロールアウトはサーバー側で続きます。Zenavo はまだ適用していないサービスだけを適用し、他のサービスの準備ができるのを待ってから、通常どおりデプロイを成功または失敗として記録し、通知します。
その時点でサービスの初期化コマンド（データベースのマイグレーションなど）が実行中だった場合、Zenavo はそれを止めることも再実行することもありません。デプロイは中断として記録されるので、コマンドの結果を確認してから再度デプロイしてください。1 回のデプロイが続行するのは再起動 2 回までで、3 回目も中断として記録されます。バックアップやプロジェクトの移動など、その他の操作は自動では繰り返されず、中断として記録されるので確認してください。
ログ
各デプロイの出力は、実行中も終了後も Logs → Build Logs にあります。ログを参照してください。