Docs

Deployen und überwachen

Was ein deployment ist — runtime-Materialisierung, die 1:1-Beziehung backend↔deployment, Container-Gesundheit und stabile Forwarding-URLs — siehe Deployments. Diese Seite hat ein einziges Ziel: ein geprüftes backend nehmen, es auf echter Hardware laufen lassen und dann gesund halten. Die Schleife ist deploy → forward → beobachten → redeploy → undeploy, und jeder Schritt unten ist ein Zug in dieser Schleife.

Wie sich ein deployment bewegt

Ein deployment hat einen kleinen, vorhersehbaren Lebenszyklus. deploy plant Container ein, und das deployment bewegt sich von deploying nach running; redeploy tauscht diese Container gegen den aktuellen backend-Zustand, während die Forwarding-URLs gültig bleiben; undeploy baut es ab. Alles außer running ist nicht bereit für Traffic.

   ppl backend deploy
          │
          ▼
   ┌───────────┐   up    ┌─────────┐  undeploy  ┌──────────────┐
   │ deploying │ ───────▶│ running │ ──────────▶│ tearing_down │
   └─────┬─────┘         └────┬────┘            └──────────────┘
         │ error              │ redeploy
         ▼                    │ (same forward URLs)
   ┌─────────┐                ▼
   │ failed  │           new containers
   └─────────┘

Der Rest dieser Seite durchläuft die Schleife der Reihe nach: eine runtime auswählen, starten, endpoints freigeben, Container beobachten, dann redeployen oder abbauen.

Eine runtime auswählen

Verwende diesen Schritt, um zu entscheiden, wo das backend läuft.

Eine runtime ist ein Pool von Compute-Nodes, auf die der Workspace deployen kann. Sie trägt die runtime-Beschränkungen: welche Nodes zu ihr gehören, ob sie GPUs haben, wie viel Spielraum nach den aktuellen deployments übrig ist und wie lange ein deployment leben darf, bevor die runtime es zurückfordert. runtimes halten „auf welcher Hardware läuft das" getrennt von „was läuft das", damit backend editing und Kapazitätsverwaltung getrennte Entscheidungen bleiben.

Das Auswählen einer runtime ist eine einmalige Auflistung. Jede runtime meldet ihren Namen, Node-Count, aktuelle deployments und das Timeout, das begrenzt, wie lange ein deployment auf ihr leben darf. Wähle eine mit freien Nodes und genügend Spielraum für die Workload.

ppl runtime list

Wenn die einzige verfügbare runtime voll ist oder ihre runtime-Klasse nicht zu dem passt, was das backend braucht (zum Beispiel eine reine CPU-runtime für ein GPU-vertex), lehnt deploy ab, bevor ein Container startet. Die Prüfung erfolgt im Voraus, sodass ein deployment nie auf eine runtime eingeplant wird, die es nicht hosten kann.

Siehe Runtimes und Nodes.

Das deployment starten

Verwende diesen Schritt, um ein geprüftes backend in laufende Container zu verwandeln.

Deployen plant die Container des backend für eine gegebene Lebensdauer auf eine runtime ein. Der deploy-Aufruf benennt nur das backend und die runtime.

ppl backend deploy --backend <backend_id> --runtime <runtime_id>

Der deployment-Datensatz gibt id, status und expires_at zurück. Behandle alles außer running als nicht bereit für Traffic. Für den Status-Lebenszyklus und die 1:1-Regel backend↔deployment (forke das backend für parallele Umgebungen) siehe Deployments.

Zwei Flags formen den runtime-Rahmen:

  • --debug aktiviert reichhaltigere Log-Erfassung. Der Start ist langsamer; reserviere es für die Fehlersuche, nicht als Standard.
  • --fixed-duration 1h30m fixiert die Lebensdauer des deployment, statt es automatisch zu verlängern. Nützlich, wenn die Arbeit ein bekanntes Wallclock-Budget hat, etwa ein Demo-Fenster oder einen geplanten Batch.

Das Wiederholen von --backend deployt mehrere backends in einem Aufruf im Batch; in diesem Modus ist --runtime zwingend, da die Plattform für einen Batch keine runtime auswählt.

Siehe Deployments.

Die endpoints freigeben

Verwende diesen Schritt, nachdem das deployment running ist, um Aufrufern oder deiner application eine URL zu geben.

Forwarding stellt für jede endpoint-Rolle des backend eine öffentliche URL und ein Token aus. Forwarding-Tokens überdauern das Redeploy — siehe Deployments, wie die Bindung funktioniert.

ppl forward <backend_id>ppl forward <backend_id> --endpoint image-input --expiration 1h

--expiration begrenzt die Lebensdauer eines Tokens; das Weglassen lässt das Token so lange leben, wie die Bindung besteht.

Wenn die URL aufgerufen wird, bevor jeder vertex-Container running ist, liefert der Aufruf 404: Der Container, der sie bedient, ist noch nicht gestartet. Frage die Container ab, bis alles running ist, bevor du echten Traffic auf das deployment lenkst.

Siehe Solutions.

Beobachten, was läuft

Verwende diesen Schritt fortlaufend, solange das deployment lebt.

Ein deployment zu überwachen bedeutet, seinen Container-Zustand zu lesen.

ppl deployment containers <deployment_id>

Jede Zeile meldet die Container-id, auf welcher node_id er gelandet ist, das vertex, das er bedient, und seinen aktuellen status — eines von starting, running, restarting, stopping oder failed. Ein Container, der beim Start immer wieder abstürzt, erscheint als restarting, was meist ein Problem auf component-Ebene ist — eine fehlende Modelldatei, eine Ausnahme während der Initialisierung, eine fehlkonfigurierte Serving-Service-Abhängigkeit, ein ungebundener Parameter, den die component als erforderlich behandelte. Container-Logs sind der nächste Schritt:

ppl deployment logs --container <container_id>ppl deployment logs --container <container_id> --tail 200ppl deployment logs --container <container_id> --since 10mppl deployment logs --container <container_id> --timestamps

--since / --until akzeptieren RFC3339-Zeitstempel, Unix-Sekunden oder Go-Duration-Strings (30m, 2h). Jeder Abruf ist ein einmaliger strukturierter Batch — ein Eintrag pro Container, abgestürzte zuerst; füge --failed-only hinzu, um nur die toten zu lesen, oder lass --container weg, um das ganze deployment abzudecken.

Für umfassendere Fehlermuster siehe Häufige Fehler.

Redeployen

Verwende diesen Schritt nach einem component-Versionssprung oder zur Erholung von einem runtime-Neustart.

Redeploy tauscht die laufenden Container in einer Operation gegen den aktuellen backend-Zustand und behält die Forwarding-URLs:

ppl backend redeploy --backend <backend_id>ppl backend redeploy --backend <backend_id> --runtime <runtime_id>

Gib genau eines von --backend oder --deployment an. Das Hinzufügen von --runtime migriert das deployment im selben Redeploy auf eine andere runtime. Die Forwarding-URLs bleiben über den Tausch unverändert, mit nur einem kurzen Fenster, in dem Anfragen warten oder 404 zurückgeben können, während die neuen Container hochfahren.

Der typische Auslöser ist ein vertex-Versionssprung, der zuvor mit ppl backend change-version gemacht wurde. Die graph-Mutation landet zuerst; das Redeploy wendet sie auf die laufende Hardware an.

Abbauen

Verwende diesen Schritt, wenn die Arbeit des deployment abgeschlossen ist.

Undeploy stoppt die Container und gibt den runtime-Spielraum frei. Die backend-Definition bleibt unberührt; nur ihre runtime-Instanz wird entfernt.

ppl backend undeploy --deployment <deployment_id>ppl backend undeploy --backend <backend_id>

Gib genau eines von --deployment oder --backend an. Das Flag --save lädt jede in dem generated_file_schema jedes vertex deklarierte Datei vor dem Abbau in den Workspace-Dateispeicher hoch. Verwende es, wenn das deployment Ausgaben erzeugt hat, die es wert sind, behalten zu werden — berechnete Artefakte, Modell-Checkpoints, abgeleitete Datensätze — und lass es bei ephemeren Läufen weg.

Wo das hineinpasst

Die Produktionsschleife ist klein: deployen, forwarden, beobachten, redeployen, undeployen. Änderungen am graph selbst gehören zurück ins backend editing, vor das deployment. Warum die Definitionsschicht und die runtime-Schicht getrennt sind, siehe Deployments.

Verwandt

War diese Seite hilfreich?