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 und bei Services mit angehängtem Volume wird zuerst der alte Pod gestoppt; sie laufen daher bei jedem Deploy und Neustart kurz nicht.
  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 lizard up --json erhalten Sie ein JSON-Ereignis pro Zeile:

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

Das letzte Ereignis ist deployed, failed oder deploying. lizard redeploy --json gibt keine Log-Zeilen aus: Es liefert sofort ein Objekt (status: "deploying") oder mit --wait am Ende ein Objekt mit ok und dem endgültigen status. 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 listet der Tab Übersicht jedes Service seine Deploys auf. Öffnen Sie einen, um Status, Quelle, Build-Logs und Neustarts zu sehen.

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. Ein fehlgeschlagener Build ändert nichts: Die laufende Version bleibt in Betrieb. Wird ein neuer Pod nie bereit, liefert ein HTTP-Service weiterhin seine vorherige Version aus, und der neue Pod erhält keinen Traffic. Workers und Services mit angehängtem Volume stoppen den alten Pod, bevor der neue startet; ein Release, das nie bereit wird, legt sie daher still. 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