Server di sviluppo locale con Docker Compose
Docker Compose consente di descrivere stack di sviluppo complessi in un singolo file YAML e di avviarli con un comando. E lo strumento ideale per riprodurre localmente ambienti server che rispecchiano la produzione, accelerare l'onboarding e isolare i progetti tra loro.
Cosa serve
Dal 2023 Compose e integrato in Docker CE come plugin (docker compose, senza trattino). Su Linux installa il pacchetto docker-ce e docker-compose-plugin; su macOS e Windows usa Docker Desktop. Verifica con docker compose version.
Struttura tipica
Un file compose.yaml definisce uno o più services, ognuno con immagine, porte, volumi, variabili d'ambiente, dipendenze. Esempio per stack LEMP: Nginx con reverse proxy verso PHP-FPM, MariaDB con volume persistente, phpMyAdmin opzionale. Le reti possono essere isolate per progetto.
Esempio commentato
Service web: image: nginx:alpine, mount del codice come bind mount ./src:/var/www/html, esposizione porta 8080. Service php: image: php:8.3-fpm, stesso volume, connessione interna via network. Service db: image: mariadb:11, environment con root password, volume named per i dati persistenti.
Procedura passo-passo
- Installa Docker e Compose plugin sul tuo sistema.
- Crea una directory per il progetto.
- Scrivi
compose.yamlcon i servizi necessari. - Aggiungi un file
.envper variabili sensibili (escluso dal versioning). - Avvia con
docker compose up -d. - Verifica con
docker compose pse log condocker compose logs -f. - Per hot-reload, usa bind mount del codice + volumi named per dipendenze (node_modules).
- Spegni con
docker compose down; con -v elimini anche i volumi. - Versiona compose.yaml ma escludi .env dal repository.
Best practice
- Usa tag espliciti: non latest in produzione; in dev alpine e slim sono buoni compromessi.
- Volumi named per dati persistenti: i bind mount sono per il codice.
- Healthcheck: definisci healthcheck per servizi critici, usa depends_on con condition: service_healthy.
- Resource limits: imposta cpus e mem_limit per evitare che un container saturi la macchina.
- Network isolata: una network per progetto evita conflitti.
Errori comuni e come risolverli
- Permessi sui file mount: utente container diverso dal host; usa user matching UID/GID.
- Porte già in uso: cambia mapping host se 80/3306 occupate.
- Dati DB persi su down -v: cancella i volumi solo intenzionalmente.
- Immagini outdated:
docker compose pullperiodicamente.
Domande frequenti
D: Compose va bene in produzione?
R: Per piccoli ambienti si; per scala usa Kubernetes o Docker Swarm.
D: Posso usare Compose con Podman?
R: Si, con podman-compose o podman-compose-plugin.
D: Come gestire ambienti multipli (dev/staging)?
R: File compose.override.yaml o variabili COMPOSE_FILE.
Approfondimento tecnico: profili e override
Compose v2 introduce i profili: ogni servizio puo essere assegnato a uno o più profili (es. profiles: [debug]), e docker compose --profile debug up avvia solo i servizi corrispondenti. Permette di mantenere in un'unico file servizi opzionali (Mailhog, Adminer, debugger) senza avviarli sempre.
Il sistema di override permette di stratificare configurazioni: compose.yaml e base, compose.override.yaml e applicato automaticamente in dev (porte esposte, debug). Per staging/prod si usa docker compose -f compose.yaml -f compose.prod.yaml up con override specifici (image tags fissi, limits, restart policy). Pattern pulito che evita duplicazione.
Scenari d'uso reali
Un team di sviluppatori PHP condivide compose.yaml versionato in git: tutti partono in 2 minuti con LAMP identico.
Una CI/CD pipeline usa docker compose per testare l'app contro DB e servizi reali in un sandbox isolato.
Un homelab orchestra Nextcloud, Bitwarden, Jellyfin, Photoprism con un singolo compose.yaml di 200 righe.
Checklist operativa Compose
- Tag espliciti, mai latest in produzione.
- Variabili sensibili in .env escluso dal versioning.
- Volumi named per dati persistenti.
- Healthcheck per servizi critici.
- Resource limits configurati.
- Network isolata per progetto.
- Pulizia periodica di immagini orfane.
Risorse e riferimenti
docs.docker.com/compose. Compose specification: github.com/compose-spec. Per produzione: Docker Swarm mode o migrazione a Kubernetes. Portainer offre UI web per gestione. Pattern dev/staging/prod ben coperti da awesome-compose su GitHub.
Considerazioni economiche e organizzative
Implementare correttamente quanto descritto in questo articolo su server di sviluppo locale con docker compose richiede tempo, formazione e talvolta investimenti hardware o software. La buona notizia e che il ritorno e quasi sempre positivo: meno incidenti, meno tempo speso in troubleshooting reattivo, maggiore predicibilita dei servizi. Stima sempre il costo del downtime per il tuo business: anche poche ore l'anno di indisponibilita possono giustificare investimenti che a prima vista sembrano sovradimensionati.
Sul piano organizzativo, la documentazione e il fattore decisivo. Un sistema brillantemente configurato ma non documentato e una bomba a orologeria: il giorno in cui il sysadmin originale lascia l'azienda, ogni intervento diventa archeologia. Mantieni runbook aggiornati, versionali in git, fai pratica di lettura nei momenti di calma e non solo durante gli incidenti.
Glossario rapido dei termini chiave
RTO (Recovery Time Objective): tempo massimo entro cui un servizio deve tornare operativo dopo un'incidente. RPO (Recovery Point Objective): perdita massima accettabile di dati misurata nel tempo (es. 1 ora di transazioni). SLA (Service Level Agreement): contratto formale che definisce livelli di servizio e penali. SLO/SLI (Service Level Objective/Indicator): metriche interne di qualità usate per misurare e mantenere lo SLA. MTBF/MTTR: tempo medio tra guasti e tempo medio di ripristino, indicatori di affidabilità. Idempotenza: proprietà di un'operazione che, applicata più volte, produce lo stesso risultato della singola applicazione (fondamentale per automazione).
Hai bisogno di aiuto?
Se hai dubbi sulla gestione server, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.