Blocco A · Fondamenta Docker — Modulo 6 di 16

Compose per ambienti reali

dev vs prod, healthcheck, configurazione

Obiettivi di oggi

Avvio deterministico: healthcheck + depends_on: condition
Configurazione fuori dai file: .env / .env.example
Stessa base, due ambienti: override di sviluppo, file di produzione
Redis nello stack: 4 servizi

Avvio deterministico

db:
  healthcheck:
    test: ["CMD-SHELL", "pg_isready -U pratiche"]
api:
  depends_on:
    db:
      condition: service_healthy   # aspetta che sia PRONTO, non solo avviato

depends_on da solo ordina l'avvio; con condition aspetta la salute. Da oggi ogni servizio ha un healthcheck.

Il contratto di configurazione

.env → valori reali, segreti, MAI committato
.env.example → tutte le variabili con valori d'esempio, committato: è il contratto
Principio: stessa immagine in ogni ambiente, cambia solo la configurazione

Tre file, due ambienti

File	Ruolo
`compose.yaml`	base comune (servizi, reti, volumi, healthcheck)
`compose.override.yaml`	sviluppo (auto): bind mount, debug, adminer coi profiles
`compose.prod.yaml`	produzione: restart, limiti risorse, log rotation

docker compose up -d                                  # dev
docker compose -f compose.yaml -f compose.prod.yaml up -d   # prod

Laboratorio (2h)

Healthcheck + condition; .env/.env.example; Redis (l'API è predisposta: header X-Cache)
Override dev (bind mount + flask --debug + adminer) e compose.prod
Avvia in entrambe le modalità e osserva le differenze

Fine Blocco A: dove siamo

Sai containerizzare un servizio a regola d'arte: immagini hardened, stack multi-servizio, dev/prod
Tutto però vive ancora sulla TUA macchina
Blocco B: registry, pipeline, deploy — la filiera dell'Ente

← portale · frecce/click per navigare · F = schermo intero · Ctrl+P = PDF