デプロイの仕組み

deployment とは、サービスの 1 回のビルドとリリースのことです。サービスは Kubernetes の Pod として実行されます。ビルドが成功しただけでは、アプリケーションが起動したことやリクエストを処理できることは証明されません。

デプロイが行われる仕組み

デプロイは、次のいずれかによってトリガーされます:

• 追跡対象ブランチへの git push（github-source サービスの場合）。
• lizard redeploy：最新のコミット（git）または最後のアップロードから、現在の変数を使って再ビルドします。
• lizard up：現在のディレクトリをアップロードしてデプロイします。
• ビルドに影響するフィールドを変更する service set。

lizard redeploy --service api      # rebuild + redeploy from current source
lizard up                          # upload cwd and deploy

ライフサイクル

1. ビルド：プラットフォームがビルドを実行します（ビルド Pipeline を参照）。
2. Pre-deploy：preDeployCommand と startCommand の両方が設定されている場合、コンテナは sh -c "<pre> && exec <start>" を実行します。プレデプロイコマンドはすべてのコンテナの起動時（各レプリカ、各再起動）に実行されるため、何度実行しても、また同時に実行しても安全なものにしてください。startCommand がない場合はスキップされます。
3. Start：Lizard は新しい Pod を古い Pod と並べて起動します。Workers は先に古い Pod を停止します。
4. Health check：TCP プローブが 2 秒ごとにアプリのポートを確認し、トラフィックは ready になった Pod にだけ移ります。Lizard は約 30 秒待機し、それまでに新しい Pod が ready にならない場合、デプロイは失敗として扱われます。Workers ではプローブはスキップされます。
5. Verify：リリースのステータスを確認し、アプリケーション URL を呼び出します。ポート到達性は完全なアプリケーションヘルスチェックではありません。

ストリーミング出力

非デタッチの lizard up（または redeploy）を実行すると、ビルドログがライブでストリーミングされます。--json を使うと、1 行ごとに 1 つの JSON イベントを受け取れます:

{ "event": "log", "line": "..." }
{ "event": "deployed", "status": "...", "url": "https://..." }

最後は deployed、failed、または deploying で終了します。--detach を使うと、ストリーミングせずにデプロイを開始してすぐに戻れます。

履歴の確認

lizard events                  # deploy history + per-replica status
lizard events --limit 25       # show more
lizard ps                      # current services, status, and URLs

ダッシュボード では、デプロイメント ビューに完全なタイムライン、デプロイごとのビルドログ、各リリースの詳細ドロワーが表示されます。

再起動と再デプロイ

lizard restart と lizard redeploy を参照してください。restart はレプリカを再起動するために使います（例: ホットリロードされなかったランタイムシークレットを反映するため）。新しいビルドが必要な場合は redeploy を使ってください。

クラッシュからの復旧

直近のクラッシュまたは再起動のログを確認します:

lizard logs --restart latest       # log tail around the latest restart
lizard logs --restart <id>         # a specific restart
lizard events                      # see replica status

設定変更（再ビルドなし）

ほとんどの環境変数とシークレットの変更は、再ビルドなしで適用されます。Lizard はサービスの設定を更新して再起動し、これには数秒かかります。ビルド時の値（VITE_*、NEXT_PUBLIC_*）とビルドフィールドの変更は、稼働中のサービスの再ビルドを強制します：再ビルドトリガー表 と ビルド時の変数 を参照してください。

失敗したリリースと復旧

ビルドの失敗とアプリケーション起動の失敗は別のケースです。どちらの場合も、すでに稼働中の HTTP サービスは以前のバージョンを配信し続けます。ビルドが失敗しても何も変わらず、ready にならない新しい Pod にはトラフィックが送られません。worker では新しい Pod の起動前に古い Pod が停止するため、壊れた worker のリリースでは worker が 1 つも稼働しない状態になります。アクティブなサービス、ビルドログ、ランタイムログを確認してください。lizard redeploy は選択したソースを再度ビルドします。以前のビルドを復元するためのコマンドではありません。必要に応じてソースコミットを元に戻し、それをデプロイして結果を確認してください。既知の問題 を参照してください。

更新日 2026年10月12日