Cloud, Docker e DevOps — rilasci rapidi e affidabili
Mettiamo in container tutte le applicazioni con Docker, le orchestriamo con Docker Compose (o Kubernetes nei progetti enterprise), configuriamo Caddy come reverse proxy con SSL automatico e automatizziamo l'intero ciclo di rilascio tramite GitHub Actions: dal commit alla produzione, senza passaggi manuali.
Container con Docker e Docker Compose
Ogni servizio ha il proprio Dockerfile multi-stage: una fase di build che installa le dipendenze e compila, e una fase finale minimale (distroless o alpine) che contiene solo gli artefatti necessari. Un'immagine Next.js tipica resta sotto i 150 MB, una FastAPI sotto gli 80 MB. Le immagini vengono ricostruite a ogni merge su main e taggate in modo semantico (`v1.2.3` e `latest`).
Docker Compose descrive l'intero stack: frontend, API, database, Redis e worker. Le variabili sensibili (password del database, chiavi API, secret di Stripe) risiedono in un file `.env` escluso da git, mai fissate nell'immagine. Gli health check di Compose assicurano che le dipendenze siano pronte prima dell'avvio (database pronto → parte l'API → parte il frontend).
- Cache di build con `--mount=type=cache`: `npm ci` riutilizza le dipendenze tra un build e l'altro
- Ordine dei layer ottimizzato: prima le dipendenze stabili, poi il codice sorgente
- Gestione dei secret con Docker secrets oppure HashiCorp Vault nei progetti enterprise
- `restart: unless-stopped` e `docker compose up --no-deps` per un rilascio atomico
Caddy: reverse proxy moderno con SSL automatico
Caddy 2.8 gestisce SSL/TLS in automatico tramite ACME (Let's Encrypt o ZeroSSL): il certificato si rinnova da solo, senza configurazione manuale. HTTP/2 e HTTP/3 (QUIC) sono attivi per impostazione predefinita. Gli header di sicurezza (HSTS, X-Frame-Options, CSP) vengono impostati globalmente con snippet riutilizzabili. La configurazione dichiarativa del Caddyfile è confrontabile con diff e versionata su git.
Rate limiting, compressione gzip/brotli e logging strutturato in JSON si attivano con direttive native di Caddy, senza moduli Nginx né configurazioni Apache complesse. L'accesso ai percorsi sensibili (`/admin`, `.env`, `.git`) restituisce un 444 (nessuna risposta), definito in uno snippet di sicurezza globale.
- Configurazione TLS moderna: solo TLS 1.3 con cipher suite recenti
- TLS on-demand per i SaaS multi-tenant con sottodomini dinamici
- Ricaricamento a caldo: `caddy reload` non chiude le connessioni attive
- Log di Caddy → Loki → Grafana: analisi del traffico e avvisi sulle anomalie
CI/CD con GitHub Actions e monitoraggio
La pipeline di CI gira a ogni PR: lint, controllo dei tipi, test unitari, build dell'immagine Docker e scansione delle vulnerabilità (Trivy). Se tutto passa, l'immagine viene caricata sul registry e il rilascio su staging avviene in automatico. Un merge su main significa rilascio automatico in produzione con health check successivo. Se quest'ultimo fallisce entro 60 secondi, il rollback è automatico.
Per il monitoraggio usiamo Grafana e Prometheus per le metriche applicative (latenza, tasso di errore, dimensione della coda) e Loki per l'aggregazione dei log. Gli avvisi sono configurati su Slack o e-mail: tasso di errore oltre l'1%, latenza P95 oltre i 500 ms, disco oltre l'85%. Il monitoraggio esterno dell'uptime è affidato a Better Uptime, con una dashboard SLA pubblica disponibile su richiesta.
- Scansione delle vulnerabilità con Trivy sulle immagini: i CVE critici bloccano il rilascio
- Dependabot con merge automatico per gli aggiornamenti di patch (richiede CI verde)
- Backup automatico del database su storage compatibile S3 (notturno, conservazione 30 giorni)
Vantaggi e limiti
Vantaggi
- Rilascio controllato, con rollback automatico se l'health check fallisce.
- SSL/TLS automatico grazie a Caddy: nessun certificato da rinnovare a mano.
- Ambiente riproducibile: la stessa immagine Docker in sviluppo, staging e produzione.
- Monitoraggio e avvisi (Grafana, Loki) su metriche e log dell'applicazione.
Limiti
- Docker Compose non scala come Kubernetes su installazioni enterprise multi-nodo.
- La configurazione iniziale di CI/CD richiede tempo e competenze DevOps.
- Immagini e log occupano spazio su disco: serve una pulizia periodica.
- Un monitoraggio completo (Prometheus e Grafana) aggiunge servizi da mantenere.
Verdetto in breve
Docker, Caddy e GitHub Actions sono la combinazione ideale per rilasci affidabili su un VPS o su pochi nodi. Con decine di nodi e scalabilità automatica aggressiva conviene passare a Kubernetes.
Tabella delle specifiche
| Capacità | Limite / soglia | Uso tipico | |
|---|---|---|---|
| Orchestrazione | Docker Compose, stack completo | Nodo singolo; con più nodi servono Swarm o K8s | VPS, progetti piccoli e medi |
| Reverse proxy | Caddy 2.8, HTTP/3, SSL automatico | Regole molto complesse richiedono una configurazione estesa | Multi-dominio, multi-tenant |
| CI/CD | GitHub Actions, rilascio automatico su ogni merge | I minuti di CI si pagano oltre il piano gratuito | Dal commit alla produzione in automatico |
| Costo tipico | VPS da circa 5 €/mese | Monitoraggio e backup aggiungono costi | Da un singolo sito a più marchi |
Docker Compose a confronto con Kubernetes
| Criterio | Docker Compose | Kubernetes |
|---|---|---|
| Complessità di configurazione | Bassa | Alta |
| Scalabilità multi-nodo e automatica | Limitata (un solo nodo) | Eccellente |
| Adatto a | VPS, progetti piccoli e medi | Grandi parchi macchine, enterprise |
Domande frequenti
Perché Caddy e non Nginx?
Caddy gestisce SSL/TLS in automatico tramite ACME, attiva HTTP/2 e HTTP/3 per impostazione predefinita e ha una configurazione dichiarativa breve. Nginx richiede certbot e molta più configurazione manuale per lo stesso risultato.
Ho bisogno di Kubernetes?
Per la maggior parte dei siti no. Docker Compose su un VPS gestisce in modo affidabile un sito o qualche servizio. Kubernetes diventa utile solo con decine di nodi e scalabilità automatica aggressiva.
Come funziona il rilascio di una nuova versione?
GitHub Actions costruisce una nuova immagine, la avvia accanto a quella vecchia, esegue un health check e poi sposta il traffico. Se l'health check fallisce entro 60 secondi, si torna automaticamente alla versione precedente.
Quale monitoraggio consigliate?
Grafana e Prometheus per le metriche (latenza, tasso di errore) e Loki per i log aggregati, con avvisi su Slack o e-mail. Per l'uptime esterno aggiungiamo un servizio indipendente come Better Uptime.