zero

Was ist zero (ShipZero)?

zero ist ein Single-Server-Deployment-Engine zum Ausführen von Docker-Images auf deiner eigenen Infrastruktur. Es bietet einen Kommandozeilen-Workflow, um ein Image bereitzustellen, HTTPS automatisch bereitzustellen und Traffic nach einem Health-Check umzuleiten.

Der Kernzweck ist es, gängige Setup-Aufgaben zu eliminieren, die vom Container-Image bis zum Live-Endpoint notwendig sind – ohne Konfigurationsdateien, Web-UI oder YAML. Es unterstützt zudem Preview-Deployments und Rollback mit demselben kommandozentrierten Ansatz.

Wichtige Features

• 1-Kommando-Deploy aus einem Container-Image: Stellt jedes Docker-Image aus einem Registry (z. B. ghcr.io/...) mit zero deploy bereit und erkennt automatisch den Application-Port.
• Automatisches HTTPS mit HTTP-Weiterleitungen: Stellt HTTPS über Let’s Encrypt bereit und aktiviert HTTP → HTTPS-Weiterleitungen als Teil des Deployment-Flows.
• Zero-Downtime-Traffic-Switching via Health-Checks: Startet einen neuen Container auf einem ephemeral Port, führt einen TCP- oder HTTP-Health-Check durch und wechselt Traffic nur, wenn der Check erfolgreich ist.
• Preview-Umgebungen: Verwende --preview <name> (z. B. pr-21), um eine temporäre Deployment mit eigener Subdomain zu erstellen; Preview-Deployments verfallen automatisch.
• Sofortiger Rollback: zero rollback <app> startet das vorherige Image, prüft es per Health-Check und wechselt Traffic zurück; bei fehlgeschlagenem Check werden keine Änderungen übernommen.
• Live-Terminal-Metrics und Logs: Streamt CPU-, Memory- und Network-Stats in die Terminal und kann Server-Logs mit zero logs --server streamen.
• Webhook-Auto-Deploy: Verifiziert signierte Webhook-Requests mit HMAC-SHA256 und triggert Deploys aus Registry-Events; nicht passende Tags erzeugen Preview-Deployments.
• Docker Compose-Unterstützung für Multi-Container-Apps: Stellt eine Docker-Compose-Datei bereit, indem du den Entry-Service und Namen angibst, und handhabt Pulling, Starten, Health-Checking und Routing.

So nutzt du zero

1. Server einrichten: Du brauchst einen Linux-VPS und eine Domain.
2. zero installieren:
   • Auf dem VPS: curl -fsSL https://shipzero.sh/install.sh | sudo bash
   • Auf deinem Rechner (CLI): curl -fsSL https://shipzero.sh/cli/install.sh | bash
3. Per SSH verbinden: zero login <email-or-identifier> (z. B. zero login [email protected]).
4. Image deployen: zero deploy <image-reference> (z. B. zero deploy ghcr.io/shipzero/demo:latest).
5. Ausgabe prüfen: Nach Health-Checks druckt zero die Live-URL aus (basierend auf Domain und erkanntem App-Port).

Für Previews deploye mit --preview (z. B. zero deploy demo --preview pr-21). Für Rollbacks führe zero rollback <app> aus.

Anwendungsfälle

• Einzelne Dockerisierte Web-App deployen: Baue ein Image, pushe es in ein Registry, dann führe zero deploy <image>:latest aus, um einen HTTPS-Endpoint mit Health-Check-Traffic-Switching zu erhalten.
• Pull-Request-Preview-Links für Reviews: Erstelle pro PR ein Preview-Deployment mit --preview <identifier> und teile die resultierende Subdomain-URL mit Reviewern.
• Sicherer Rollback bei Releases: Wenn ein neues Container Health-Checks scheitert oder falsch verhält, führe zero rollback <app> aus, um zurückzuwechseln, bei zero Downtime (Traffic-Wechsel nur nach Health-Checks).
• Continuous Deployment aus Registries: Konfiguriere eine Webhook-Endpoint-URL und Secret, dann lass signierte POSTs Deploys triggern; Tags können zu normalen oder Preview-Deployments mappen.
• Multi-Container-Services deployen: Wenn eine App per Docker Compose beschrieben ist, nutze zero deploy --compose <file> --service <name> --name <stack>, um alle Services aus der Compose-Datei zu deployen und Traffic für den Entry-Service zu routen.

FAQ

• Was bedeutet „Zero-Downtime“ hier?
  Der beschriebene Flow startet einen neuen Container, führt einen TCP- oder HTTP-Health-Check durch und wechselt Routen erst dann atomar. Bei fehlgeschlagenen Checks bleibt Traffic auf der vorherigen Version.

• Erfordert zero Konfigurationsdateien oder YAML?
  Die Seite betont: Keine Konfigurationsdateien, keine Web-UI und der Workflow vermeidet YAML.

• Wie aktiviert zero HTTPS?
  Es stellt HTTPS automatisch über Let’s Encrypt bereit und führt HTTP-Weiterleitungen durch.

• Kann ich mehrere Container deployen, nicht nur ein einzelnes Image?
  Ja. Die Seite beschreibt Docker Compose-Unterstützung, bei der du die Compose-Datei, einen Entry-Service und einen Deployment-Namen angibst.

• Wie werden Previews erstellt und verwaltet?
  Preview-Deployments entstehen durch --preview <name> und erzeugen eine Live-Subdomain-URL. Previews verfallen automatisch.

Alternativen

• Traditionelle PaaS (Platform-as-a-Service): Diese Dienste verwalten HTTPS, Previews und Deployment-Flows, laufen aber typischerweise auf einer Plattform statt auf deinem eigenen Server; du gibst Flexibilität und „Server-Eigentum“-Kontrolle auf.
• Selbstverwalteter Reverse Proxy + manuelle Container-Orchestrierung: Du kannst ähnliches HTTPS und Routing mit eigenen Tools erreichen, aber der Workflow ist manueller (du kümmerst dich selbst um Service-Start/Stop, Health-Checks, Routing-Wechsel und Zertifikate).
• Generische Container-Deployment-Tools (CLI-basierte Orchestratoren): Tools, die Container auf einem Single Host bereitstellen, decken ähnliche Schritte ab, erfordern aber oft mehr Konfigurationsdateien, Custom-Routing oder manuelle Health-Check- und Rollback-Logik.
• Kubernetes für Multi-Node-Deployments: Wenn du Multi-Node-Orchestrierung, RBAC oder ein Web-Dashboard brauchst, ist Kubernetes eine andere Wahl als ein Single-Server-Deployment-Engine wie zero.