Build-Pipeline

Builds laufen auf den Build-Nodes von Lizard — du brauchst Docker lokal nicht. Beim Bereitstellen entscheidet die Plattform anhand einer festen Reihenfolge, wie dein Quellcode in ein Container-Image umgewandelt wird, und führt dieses Image dann in einem isolierten Pod aus. Nicht jeder container as a service baut das Image für dich; der Blog vergleicht die drei Varianten, in denen diese Kategorie vorkommt.

Reihenfolge der Build-Entscheidung

Die Plattform wählt genau eine Build-Strategie, in dieser Reihenfolge:

1. Synthetisierte Dockerfile — wenn buildCommand und/oder startCommand im Service gesetzt sind (oder per lizard up --build-command / --start-command übergeben werden), erzeugt Lizard daraus eine Dockerfile. lizardpack wird nicht aufgerufen.
2. Dockerfile aus dem Repo (unverändert) — wenn dockerfilePath im Service gesetzt ist, wird diese Dockerfile aus deinem Repo unverändert verwendet.
3. Automatische Erkennung durch lizardpack — andernfalls klont die Plattform deinen Quellcode und führt lizardpack aus, den eigenen Buildpack-/Dockerfile-Generator.

Automatische Erkennung durch lizardpack

lizardpack prüft dein Repo und baut ein optimiertes Multi-Stage-Image. Unterstützte Stacks, in dieser Reihenfolge abgeglichen:

Hugo → Go → Node → Python → Rust → Ruby → PHP → Java → static

Siehe Framework guides für Produktionsskripte, Adapter, Ausgabepfade und Ports. Die Erkennung nutzt Projektdateien und Abhängigkeiten; ein Repository, das zu mehreren Providern passt, folgt dieser Reihenfolge.

Auf diesem Pfad gilt:

• Wenn eine Dockerfile im Repo existiert und einen echten Build-Schritt hat (eine RUN <package-manager>-Zeile, nicht nur COPY dist/), wird sie unverändert verwendet.
• Andernfalls erzeugt lizardpack die Dockerfile für dich.
• Der Startbefehl wird automatisch erkannt: eine Procfile-web:-Zeile (Python/Ruby) oder package.json scripts.start (Node) wird automatisch übernommen. Welche genaue Zeile Django, Flask und FastAPI jeweils brauchen, steht unter Python-App-Hosting.
• Der Port wird aus EXPOSE, Framework-Standards oder einer expliziten PORT-Umgebungsvariable abgeleitet.

Wichtig: Eine Dockerfile, die nur vorgebaute Artefakte kopiert (COPY dist/, build/, out/, .next/, public/) ohne einen RUN-Build-Schritt, gilt als unvollständig und wird von lizardpack neu erzeugt. Füge einen echten Build-Schritt hinzu oder setze dockerfilePath, um die unveränderte Verwendung zu erzwingen.

Was einen Neuaufbau auslöst

Nicht doppelt bauen. Nach einem service set, das ein Build-Feld ändert, startet der Neuaufbau automatisch — hänge nicht noch ein lizard redeploy direkt danach an, sonst stellst du einen zweiten, überflüssigen Build in die Warteschlange.

Einen Build beobachten

Build-Logs werden während lizard up gestreamt. Für jeden Service:

lizard logs --build            # the most recent build's logs
lizard events                  # deploy history + replica status

Wenn ein Build fehlschlägt, lies lizard logs --build, behebe die Ursache (in deinem Repo oder durch Anpassen von buildCommand / startCommand per lizard service set) und führe dann lizard redeploy aus.

Hinweise zur Laufzeit

• Keine Docker-HEALTHCHECK. Die Laufzeit führt keine Docker-Healthcheck-Schleife aus, daher werden HEALTHCHECK-Direktiven ignoriert. Lizard führt stattdessen einen TCP-Probe gegen deinen Port aus (im worker mode übersprungen).
• Schreibe nicht ungefragt eine Dockerfile. lizardpack erkennt die meisten Stacks automatisch — versuche zuerst ein Bereitstellen und füge nur dann eine Dockerfile hinzu (oder setze dockerfilePath), wenn der Auto-Build nicht passt.

Referenz der Build-Konfiguration

Setze beliebige davon mit lizard service set <svc> --set <field>=<value>. Siehe lizard service.