🏗️ Docker Compose: Standard & Best Practices

::: info Docker Compose permette di definire e gestire applicazioni multi-container. Seguire uno standard di stesura garantisce la portabilità del codice tra ambienti diversi (Sviluppo vs Produzione) e facilita il debugging tramite l’astrazione di reti e volumi. :::

1. Anatomia di un File “Gold Standard”

Un file Compose professionale deve essere autocontenuto e ben commentato. Ecco il template di riferimento che adotteremo per ogni nuovo tool nel laboratorio.

# docker-compose.yaml standard
services:
  app-name:
    image: vendor/image-name:latest
    container_name: app-core
    restart: unless-stopped
    
    # 1. Network Isolation
    networks:
      - backend_net
      - proxy_net
      
    # 2. Environment Management
    env_file: .env
    environment:
      - NODE_ENV=${ENVIRONMENT}
      
    # 3. Persistence
    volumes:
      - ./data:/app/data
      - /etc/localtime:/etc/localtime:ro
      
    # 4. Resource Hardening
    deploy:
      resources:
        limits:
          cpus: '0.50'
          memory: 512M
          
    # 5. Healthcheck (Automated Recovery)
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 30s
      timeout: 10s
      retries: 3

networks:
  backend_net:
    internal: true # Rete isolata senza accesso a internet
  proxy_net:
    external: true # Rete condivisa con il Reverse Proxy

2. I Pilastri della Standardizzazione

A. Gestione delle Variabili (`.env`)

Mai inserire password, chiavi API o percorsi specifici direttamente nel file YAML.

Crea un file .env nella stessa cartella.
Usa il file YAML solo per definire le chiavi.
Vantaggio: Puoi cambiare configurazione senza toccare la logica del deploy.

B. Persistenza dei Dati (Volumes)

Distinguiamo tra due tipi di mount:

Named Volumes: Gestiti da Docker, ideali per database (es. db_data:/var/lib/mysql).
Bind Mounts: Percorsi locali relativi (es. ./config:/app/config). Ideali per file di configurazione che devi modificare a mano.

Best Practice: Mappa sempre /etc/localtime:ro per sincronizzare il fuso orario del container con il server host.

C. Isolamento di Rete

Non usare la rete di default.

Front-end: Connesso alla rete del Reverse Proxy.
Back-end/DB: Connesso a una rete internal: true. Il database non deve mai essere raggiungibile dall’esterno del cluster Docker.

📉 Ciclo di Orchestrazione (Mermaid)

graph TD
    YAML[docker-compose.yaml] --> ENV[.env file: Secrets/Config]
    YAML --> PULL[Docker Hub: Image Pull]
    
    subgraph Execution_Runtime
        PULL --> CONT[Containers Spawn]
        CONT --> VOL[Volumes Mount: Persistence]
        CONT --> NET[Networks: Isolation]
    end
    
    CONT --> HC{Healthcheck}
    HC -- Failed --> CONT
    HC -- Success --> READY[Service Ready]

3. Comandi Operativi Standard

Azione	Comando	Note
Deploy	`docker compose up -d`	Avvio in modalità detached (background).
Update	`docker compose pull && docker compose up -d`	Aggiorna le immagini e riavvia solo se necessario.
Logs	`docker compose logs -f --tail=100`	Debugging in tempo reale.
Cleanup	`docker compose down --volumes`	Rimuove tutto, inclusi i dati (usare con cautela!).

💡 Note dell’Ingegnere (Critical Thinking)

Version Tagging: Evita l’uso di :latest in produzione. Usa tag specifici (es. :1.2.4) per evitare che un aggiornamento automatico rompa la compatibilità.
Restart Policy: Usa unless-stopped per i servizi server. Evita always se non vuoi che un container in crash continuo saturi i log al riavvio del server.
Resource Limits: Fondamentali su Proxmox o VPS. Senza i limiti cpus e memory, un memory leak in un container potrebbe causare l’intervento dell’OOM (Out Of Memory) Killer del kernel Linux, abbattendo l’intero host.

Tags: #Docker #DockerCompose #InfrastructureAsCode #DevOps #BestPractices*