GrundkonzepteBereitstellungen

Bereitstellungen

Ein Deployment ist ein Build-und-Release eines Service. Services laufen als Kubernetes-Pods. Ein erfolgreicher Build belegt für sich allein nicht, dass die Anwendung gestartet ist oder Anfragen verarbeiten kann.

Wie ein Bereitstellen erfolgt

Ein Deployment wird ausgelöst durch:

  • Ein git push auf den verfolgten Branch (bei Services mit github-Quelle).
  • lizard redeploy — Neuaufbau vom neuesten Commit (git) oder letzten Upload mit den aktuellen Variablen.
  • lizard up — lädt das aktuelle Verzeichnis hoch und deployt es.
  • Ein service set, das ein buildrelevantes Feld ändert.
lizard redeploy --service api      # rebuild + redeploy from current source
lizard up                          # upload cwd and deploy

Ablauf

  1. Build — die Plattform führt Ihren Build aus (siehe Build-Pipeline).
  2. Vor dem Bereitstellen: Wenn sowohl preDeployCommand als auch startCommand gesetzt sind, führt der Container sh -c "<pre> && exec <start>" aus. Der Pre-Deploy-Befehl läuft beim Start jedes Containers (jedes Replikat, jeder Neustart). Machen Sie ihn daher so, dass er sich gefahrlos mehrfach und gleichzeitig ausführen lässt. Ohne startCommand wird er übersprungen.
  3. Start — Lizard startet den neuen Pod neben dem alten. Bei Workers wird zuerst der alte Pod gestoppt.
  4. Health-Checks — eine TCP-Probe prüft alle 2 Sekunden den Port der App, und Traffic wird erst auf einen bereiten Pod umgeschaltet. Lizard wartet darauf etwa 30 Sekunden; ist der neue Pod bis dahin nicht bereit, wird das Deployment als fehlgeschlagen markiert. Workers überspringen die Probe.
  5. Prüfen — prüfen Sie den Release-Status und rufen Sie die Anwendungs-URL auf. Die Erreichbarkeit des Ports ist kein vollständiger Health-Checks der Anwendung.

Streaming-Ausgabe

Wenn Sie ein nicht-detachtes lizard up (oder redeploy) ausführen, werden Build-Logs live gestreamt. Mit --json erhalten Sie ein JSON-Ereignis pro Zeile:

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

endet mit deployed, failed oder deploying. Verwenden Sie --detach, um das Bereitstellen zu starten und sofort zurückzukehren, ohne Streaming.

Verlauf prüfen

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

Im Dashboard zeigt die Ansicht Bereitstellungen die vollständige Zeitleiste, Build-Logs pro Deployment und einen Detailbereich für jedes Release.

Neustarts vs. Redeploys

BefehlWas es tut
lizard restart --service <svc>Neustart des aktuellen Builds — kein Neuaufbau
lizard redeploy --service <svc>Neuer Build vom neuesten Commit/Upload, dann Release

Siehe lizard restart und lizard redeploy. Verwenden Sie restart, um Replikate neu zu starten (z. B. um ein Runtime-Secret zu übernehmen, das nicht per Hot-Reload geladen wurde); verwenden Sie redeploy, wenn Sie einen neuen Build benötigen.

Wiederherstellung nach einem Absturz

Prüfen Sie die Logs des letzten Absturzes oder Neustarts:

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

Konfigurationsänderungen (kein Neuaufbau)

Die meisten Änderungen an Umgebungsvariablen und Secrets werden ohne Neuaufbau übernommen: Lizard aktualisiert die Konfiguration des Service und startet ihn neu, was einige Sekunden dauert. Build-Zeit-Werte (VITE_*, NEXT_PUBLIC_*) und Änderungen an Build-Feldern erzwingen bei einem laufenden Service jedoch einen Neuaufbau. Siehe die Tabelle der Rebuild-Auslöser und Build-Zeit-Variablen.

Fehlgeschlagene Releases und Wiederherstellung

Ein fehlgeschlagener Build und ein fehlgeschlagener Start der Anwendung sind unterschiedliche Fälle. In beiden Fällen liefert ein HTTP-Service, der bereits läuft, weiterhin seine vorherige Version aus: Ein fehlgeschlagener Build ändert nichts, und ein neuer Pod, der nie bereit wird, erhält keinen Traffic. Der alte Pod eines Workers wird gestoppt, bevor der neue startet, daher läuft nach einem fehlerhaften Worker-Release kein Worker mehr. Prüfen Sie den aktiven Service, die Build-Logs und die Runtime-Logs. lizard redeploy baut die ausgewählte Quelle erneut; es ist kein Befehl zum Wiederherstellen eines vorherigen Builds. Setzen Sie bei Bedarf den Quell-Commit zurück, deployen Sie ihn und prüfen Sie das Ergebnis. Siehe bekannte Probleme.

Build-PipelineÜbersicht

Aktualisiert