zero

Cos'è zero (ShipZero)?

zero è un motore di deployment per server singolo che esegue immagini Docker sulla tua infrastruttura. Fornisce un workflow da linea di comando per distribuire un'immagine, provisionare automaticamente HTTPS e instradare il traffico dopo un health check.

Lo scopo principale è eliminare le attività di setup comuni per passare da un'immagine container a un endpoint live, senza richiedere file di configurazione, un'interfaccia web o YAML. Supporta anche deployment di preview e rollback con lo stesso approccio command-driven.

Caratteristiche Principali

• Deployment con 1 comando da immagine container: Distribuisce qualsiasi immagine Docker da un registry (es. ghcr.io/...) usando zero deploy e gestisce il rilevamento della porta dell'applicazione.
• HTTPS automatico con redirect HTTP: Provisiona HTTPS tramite Let’s Encrypt e abilita redirect HTTP → HTTPS come parte del flusso di deployment.
• Switching del traffico zero-downtime tramite health check: Avvia un nuovo container su una porta efemera, esegue un health check TCP o HTTP e switcha il traffico solo se il check passa.
• Ambienti di preview: Usa --preview <name> (es. pr-21) per creare un deployment temporaneo con subdomain dedicato; i deployment di preview scadono automaticamente.
• Rollback istantaneo: zero rollback <app> avvia l'immagine precedente, la verifica con health check e switcha il traffico; se il check fallisce, i cambiamenti non vengono applicati.
• Metriche e log terminal live: Trasmette statistiche CPU, memoria e rete sul terminale, e può trasmettere log del server con zero logs --server.
• Auto-deploy webhook: Verifica richieste webhook firmate con HMAC-SHA256 e può attivare deployment da eventi del registry; tag non corrispondenti creano deployment di preview.
• Supporto Docker Compose per app multi-container: Distribuisce un file Docker Compose specificando il servizio entry e il nome, gestendo pull, avvio, health check e routing.

Come Usare zero

1. Prepara un server: Serve un VPS Linux e un dominio.
2. Installa zero:
   • Sul VPS: curl -fsSL https://shipzero.sh/install.sh | sudo bash
   • Sulla tua macchina (CLI): curl -fsSL https://shipzero.sh/cli/install.sh | bash
3. Connettiti via SSH: zero login <email-or-identifier> (es. zero login [email protected]).
4. Distribuisci un'immagine: zero deploy <image-reference> (es. zero deploy ghcr.io/shipzero/demo:latest).
5. Verifica l'output: Dopo gli health check, zero stampa l'URL live (basato sul dominio e sulla porta app rilevata).

Per preview, distribuisci con --preview (es. zero deploy demo --preview pr-21). Per rollback, esegui zero rollback <app>.

Casi d'Uso

• Distribuzione di una web app Docker single: Builda un'immagine, pushala su un registry, poi esegui zero deploy <image>:latest per ottenere un endpoint HTTPS con switching del traffico verificato.
• Link di preview per pull-request: Crea un deployment di preview per PR passando --preview <identifier> e condividi l'URL del subdomain con i reviewer.
• Rollback sicuro durante i release: Se un nuovo container fallisce gli health check o si comporta male, esegui zero rollback <app> per revertire mantenendo zero downtime (switch traffico solo dopo health check).
• Continuous deployment da registry: Configura un URL endpoint webhook e secret, poi lascia che un POST firmato attivi i deployment; i tag possono mappare a deployment normali vs preview.
• Distribuzione di servizi multi-container: Quando un'app è descritta da Docker Compose, usa zero deploy --compose <file> --service <name> --name <stack> per distribuire tutti i servizi del file compose e instradare il traffico per il servizio entry specificato.

FAQ

• Cosa significa “zero-downtime” qui?
  Il flusso descritto avvia un nuovo container, esegue un health check TCP o HTTP e solo allora switcha le route atomicamente. Se gli health check falliscono, il traffico resta sulla versione precedente.

• zero richiede file di config o YAML?
  La pagina specifica che non ci sono file di config, nessuna UI web e che il workflow tipico evita YAML.

• Come abilita zero l'HTTPS?
  Provisiona HTTPS automaticamente usando Let’s Encrypt, e gestisce anche i redirect HTTP.

• Posso distribuire più container, non solo un'immagine singola?
  Sì. La pagina descrive il supporto per Docker Compose, passando il file compose, un servizio entry e un nome di deployment.

• Come si creano e gestiscono le preview?
  I deployment di preview si creano passando --preview <name>, ottenendo un URL subdomain live. La pagina nota che le preview scadono automaticamente.

Alternative

• PaaS tradizionale (platform-as-a-service): Questi servizi gestiscono HTTPS, preview e flussi di deployment, ma tipicamente girano su una piattaforma anziché sul tuo server; potresti sacrificare flessibilità e controllo “sul tuo server”.
• Reverse proxy self-managed + orchestrazione manuale dei container: Puoi ottenere HTTPS e routing simili con i tuoi tool, ma il workflow è più manuale (dovresti gestire avvio/arresto servizi, health check, swap di routing e certificati da solo).
• Tool generici per deployment container (orchestratori basati su CLI): Tool che deployano container su un singolo host coprono passi simili, ma richiedono più file di configurazione, routing custom o logica manuale per health check e rollback.
• Kubernetes per deployment multi-nodo: Se hai bisogno di orchestrazione multi-nodo, RBAC o dashboard web, Kubernetes è una soluzione diversa rispetto a un motore di deployment single-server come zero.