Docker e Containerizzazione — Dalla Prototipazione alla Produzione per PMI Italiane

Se stai ancora configurando ambienti di sviluppo manualmente su ogni macchina, se i tuoi deploy richiedono un’ora di checklist, se “funziona sulla mia macchina” è una frase che senti troppo spesso – allora hai un problema che Docker e containerizzazione risolvono. Noi, di Meteora Web, lo abbiamo visto decine di volte: progetti rallentati da conflitti di versione, server con dipendenze obsolete, clienti che aspettano giorni per un fix. Docker non è solo moda: è un cambio di paradigma operativo che trasforma il modo in cui sviluppi, testi e metti in produzione. E, come veniamo dalla contabilità, lo misuriamo in termini di tempo risparmiato, costi di infrastruttura ridotti e minor tasso di errore.

Cosa sono Docker e containerizzazione e perché interessano una PMI?

Docker è una piattaforma che permette di eseguire applicazioni in container: ambienti isolati e leggeri che includono tutto il necessario per far funzionare il software (codice, runtime, librerie, variabili d’ambiente). A differenza delle macchine virtuali, i container condividono il kernel del sistema operativo host, partendo da immagini minime. Questo significa che un container pesa pochi megabyte e si avvia in secondi.

Per una PMI italiana, il vantaggio è immediato: riproducibilità. Se il tuo sviluppatore lavora su Windows, il tuo server di staging su Ubuntu e la produzione su Debian, con Docker l’ambiente è identico ovunque. Addio “sulla mia macchina funziona”. Addio configurazioni infinite di Apache, PHP, MySQL ogni volta che arriva un nuovo membro nel team. Noi lo usiamo dal 2018 e abbiamo ridotto i tempi di setup dei progetti da giorni a minuti.

Cosa cambia rispetto a una macchina virtuale?

Una VM include un sistema operativo completo (kernel compreso) – occupa GB, richiede risorse dedicate. Un container condivide il kernel host: è più leggero, più veloce da avviare, consuma meno RAM e CPU. Per un’azienda con budget limitati, significa poter far girare più servizi sullo stesso server senza dover acquistare hardware aggiuntivo. Lo vediamo spesso: clienti che passano da 3 VM a un unico server con 5 container, risparmiando centinaia di euro al mese in hosting.

# Verificare che Docker sia installato
docker --version
# Comando base: run un container isolato
docker run hello-world

Come si costruisce un Dockerfile ottimizzato per applicazioni PHP/Laravel?

Il cuore della containerizzazione è il Dockerfile: un file di istruzioni che descrive come costruire l’immagine. Per un’app Laravel, vogliamo un’immagine leggera, sicura e veloce da ricostruire. Le best practice sono: partire da una base ufficiale, usare multi-stage build per separare build e produzione, sfruttare la cache dei layer, non installare pacchetti inutili.

Esempio pratico: multi-stage per Laravel

# Stage 1: Composer dependencies
FROM composer:2 AS vendor
WORKDIR /app
COPY composer.json composer.lock ./
RUN composer install --no-dev --prefer-dist --no-scripts --no-progress

# Stage 2: Node build (se necessario)
FROM node:18 AS frontend
WORKDIR /app
COPY package.json yarn.lock ./
RUN yarn install --frozen-lockfile
COPY . .
RUN yarn production

# Stage 3: Produzione
FROM php:8.2-fpm-alpine
RUN docker-php-ext-install pdo_mysql bcmath
COPY --from=vendor /app/vendor /var/www/vendor
COPY --from=frontend /app/public /var/www/public
COPY . /var/www

# Ottimizzazioni finali
RUN chown -R www-data:www-data /var/www/storage /var/www/bootstrap/cache
USER www-data
CMD ["php-fpm"]

Questo Dockerfile è leggero (~150 MB), sicuro (non espone chiavi SSH), e sfrutta la cache dei layer: se modifichi solo il codice, le dipendenze non vengono ricostruite. Attenzione: l’ordine dei comandi è cruciale – copia prima i file che cambiano meno (composer.json, package.json) per massimizzare la cache.

Errori comuni

• Copiare tutto il progetto subito: ogni modifica invalida la cache dei layer successivi.
• Usare immagini latest: preferisci versioni specifiche (php:8.2-fpm-alpine) per riproducibilità.
• Lasciare credenziali nel Dockerfile: usa variabili d’ambiente passate al runtime.

Azione immediata: apri il tuo progetto PHP/Laravel, crea un Dockerfile seguendo lo schema multi-stage e testalo con docker build -t myapp .

Docker Compose semplifica davvero lo sviluppo locale multi-container?

Sì. In un ambiente reale non hai mai solo il web server: ci sono database, cache, code, mailcatcher. Gestirli a mano con docker run è caotico. Docker Compose permette di definire tutti i container, le loro relazioni, variabili e volumi in un unico file YAML. Con un solo comando docker compose up -d hai tutto il tuo stack attivo.

Docker Compose per Laravel + MySQL + Redis

version: '3.8'
services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "8080:80"
    volumes:
      - .:/var/www
    depends_on:
      - mysql
      - redis
    environment:
      DB_HOST: mysql
      REDIS_HOST: redis

  mysql:
    image: mysql:8.0
    ports:
      - "3307:3306"
    volumes:
      - dbdata:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: secret
      MYSQL_DATABASE: laravel

  redis:
    image: redis:7-alpine

volumes:
  dbdata:

Con questo setup, hai sviluppo locale identico alla produzione. Il volume montato su app permette di modificare il codice e vedere le modifiche in tempo reale (se usi un server con hot reload).
Azione immediata: installa Docker Compose (se non lo hai), copia il file sopra, esegui docker compose up -d e visita http://localhost:8080.

Noi, di Meteora Web, usiamo Compose anche per i progetti WordPress e Node.js: riduce i conflitti tra team e velocizza l’onboarding.

Docker Networking: come far comunicare container in sviluppo e produzione?

I container sono isolati per default. Per comunicare tra loro – per esempio l’app PHP con MySQL – devi metterli nella stessa rete Docker. Docker offre driver di rete: bridge (default), host, overlay (per swarm). Nello sviluppo locale, il bridge di default funziona bene; in produzione multi-server, si usa overlay.

Rete bridge personalizzata

# Crea una rete
 docker network create mynet
# Avvia due container nella stessa rete
docker run -d --network mynet --name db mysql:8.0
docker run -d --network mynet --name app -p 80:80 myapp:latest
# Ora app può risolvere db tramite nome host 'db'

Questo è esattamente ciò che fa Docker Compose automaticamente: crea una rete predefinita per tutti i servizi. In produzione, per sicurezza, definisci reti separate: una per il frontend pubblico, una per il backend interno. Ricorda di non esporre porte sui servizi interni (es. MySQL) – solo il necessario.

Azione immediata: nel tuo docker-compose.yml, aggiungi networks: con due reti: frontend e backend. Blocca l’accesso esterno al database.

Docker Volumes: dove salvare i dati per non perderli mai?

Un container è effimero: se lo cancello, perdo i dati al suo interno. I volumi Docker sono directory persistenti gestite dal motore Docker, indipendenti dal ciclo di vita del container. Vanno usati per database, upload, log, e qualsiasi dato che deve sopravvivere a riavvii o aggiornamenti.

Tipi di volumi

• Named volumes: gestiti da Docker (docker volume create mydata). Ideali per database.
• Bind mounts: montano una directory dell’host dentro il container. Utili per sviluppo (condividere codice).
• tmpfs: montano file in memoria RAM – velocissimi ma volatili. Per cache o sessioni temporanee.

Esempio: volume per MySQL

services:
  mysql:
    image: mysql:8.0
    volumes:
      - dbdata:/var/lib/mysql
volumes:
  dbdata:

In produzione, esegui backup periodici del volume. Noi utilizziamo docker run --rm -v dbdata:/volume -v $(pwd):/backup alpine tar czf /backup/db_backup.tar.gz -C /volume . per esportare.

Azione immediata: verifica che tutti i servizi che scrivono dati (DB, Redis, storage) abbiano volumi nominati. Mai usare bind mount per database in produzione.

Come containerizzare un'app Laravel con Docker per sviluppo e produzione?

Abbiamo già visto il Dockerfile. Per la produzione, servono alcuni accorgimenti: ridurre al minimo l’immagine, eseguire il container con utente non root, usare variabili d’ambiente per la configurazione, abilitare il logging su stdout/stderr (Docker li cattura automaticamente).

Produzione con Nginx + PHP-FPM

Spesso si usano due container: Nginx per servire i file statici (e fare da proxy per PHP-FPM) e PHP-FPM per eseguire il codice. Ecco un esempio di docker-compose per produzione:

version: '3.8'
services:
  nginx:
    image: nginx:1.25-alpine
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
      - .:/var/www
    depends_on:
      - php
  php:
    build:
      context: .
      dockerfile: Dockerfile.prod  # immagine multi-stage ottimizzata
    volumes:
      - .:/var/www
    environment:
      - APP_ENV=production
      - DB_HOST=mysql
      - ...
    depends_on:
      - mysql
  mysql:
    image: mysql:8.0
    volumes:
      - dbdata:/var/lib/mysql

Questo stack è scalabile, sicuro e facile da aggiornare. Azione immediata: separa il Dockerfile in due (sviluppo e produzione) e crea un nginx.conf che punti a php:9000.

Docker per Node.js e React: esempi di configurazione multi-stage

Per applicazioni full-stack con Node.js backend (Express, Nest, Next.js) e frontend React, la containerizzazione segue la stessa logica: multi-stage per ridurre la dimensione finale. Nel caso di Next.js, puoi sfruttare la build statica o il runtime Node.

Dockerfile per un'app Next.js

# Build stage
FROM node:18-alpine AS builder
WORKDIR /app
COPY package.json yarn.lock ./
RUN yarn install --frozen-lockfile
COPY . .
RUN yarn build

# Production stage
FROM node:18-alpine AS runner
WORKDIR /app
ENV NODE_ENV production
COPY --from=builder /app/public ./public
COPY --from=builder /app/.next ./.next
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./package.json
EXPOSE 3000
CMD ["yarn", "start"]

Nota: per lo sviluppo, usa un volume bind mount per avere hot reload. Noi consigliamo di separare l’immagine di sviluppo (con nodemon) da quella di produzione.

Azione immediata: crea un Dockerfile per il tuo progetto Node.js, usa multi-stage e verifica la dimensione con docker images.

Registro immagini privato: quando serve e come gestirlo con Harbor?

Quando inizi a distribuire immagini tra team o in produzione, il Docker Hub pubblico non è sufficiente: limiti di pull, sicurezza, necessità di audit. Un registro privato ti permette di ospitare le tue immagini in un repository controllato, con scansione vulnerabilità e controllo accessi. Harbor è una soluzione open source potente, con interfaccia web, replica tra regioni e integrazione con AD/LDAP.

Installare Harbor con Docker Compose

Harbor stesso si installa via Docker Compose. Scarichi l’installer ufficiale, configuri harbor.yml, esegui ./install.sh e hai un registro completo con scansione basata su Trivy.

# Push di un'immagine nel registro privato
docker tag myapp:latest myregistry.example.com/myapp:1.0
docker push myregistry.example.com/myapp:1.0
# Pull da un server remoto
docker pull myregistry.example.com/myapp:1.0

Azione immediata: se gestisci più di 3 container in produzione, valuta l’adozione di un registro privato. Harbor offre anche repliche per disaster recovery.

Docker Scout: tenere sotto controllo le vulnerabilità delle immagini

La sicurezza è un tema che in Meteora Web prendiamo molto sul serio. Molte PMI italiane sottovalutano le vulnerabilità nelle immagini Docker: un’immagine base obsoleta può esporre l’intero stack. Docker Scout è un servizio integrato in Docker Desktop e CLI che analizza le immagini e segnala CVE (Common Vulnerabilities and Exposures) con rimedi.

Usare Docker Scout

# Analizzare un'immagine locale
docker scout quickview myapp:latest
# Ottenere raccomandazioni per aggiornare i pacchetti
docker scout recommendations myapp:latest

Scout confronta le librerie con i database di vulnerabilità (NVD, GitHub Advisory) e fornisce una valutazione: “Critical”, “High”, “Medium”. Noi lo eseguiamo in CI/CD: se un’immagine ha vulnerabilità critiche, blocchiamo il deploy.

Azione immediata: nel tuo workflow CI (GitHub Actions, GitLab CI), aggiungi un passo che esegue docker scout quickview e fallisce se ci sono CVEs critici. Ecco un esempio:

- name: Scan image
  run: |
    docker scout quickview myapp:latest --exit-code --only-severity critical

Documentazione ufficiale: Docker Scout docs

Da Docker Compose a Kubernetes: quando è il momento di migrare?

Docker Compose è perfetto per ambienti a singolo host o cluster piccoli. Ma quando la tua applicazione cresce, i container si moltiplicano, devi gestire scaling automatico, rolling update, health check avanzati – allora Kubernetes diventa necessario. Non c’è una regola fissa, ma noi vediamo tre indicatori:

• Hai bisogno di scalare orizzontalmente i servizi in base al carico.
• Vuoi aggiornamenti senza downtime (Canary, Blue-Green).
• Gestisci più ambienti (staging, produzione) su cluster multi-server.

Primi passi verso K8s

Inizia con un cluster locale (minikube o kind) per imparare i concetti: Pod, Deployment, Service, Ingress. Converti il tuo docker-compose.yml in manifest YAML Kubernetes. Usa strumenti come Kompose (convertitore automatico) ma rivedi il risultato manualmente.

# Installare Kompose
curl -L https://github.com/kubernetes/kompose/releases/latest/download/kompose-linux-amd64 -o kompose
chmod +x kompose
sudo mv kompose /usr/local/bin/
# Convertire docker-compose.yml
kompose convert -f docker-compose.yml
# Applicare i manifest
kubectl apply -f .

Kubernetes ha una curva di apprendimento, ma il ritorno in termini di affidabilità e automazione è enorme. Noi di Meteora Web abbiamo accompagnato clienti dal singolo container su VPS a cluster Kubernetes su cloud (DigitalOcean, AWS), riducendo i downtime da ore a secondi.

Azione immediata: installa minikube, lancia minikube start e deploya la tua applicazione con un semplice Deployment e Service.

Cosa fare adesso

Hai le basi per trasformare il tuo workflow. Ecco 5 azioni concrete da iniziare oggi:

1. Installa Docker Desktop (o Docker Engine su Linux) e verifica con docker run hello-world.
2. Crea un Dockerfile per il tuo progetto principale – inizia con un semplice app web statica per prendere confidenza.
3. Imposta Docker Compose per lo sviluppo locale con database e cache – nota la differenza nel tempo di setup.
4. Esegui un’analisi di sicurezza con docker scout sulle tue immagini attuali e risolvi le vulnerabilità critiche.
5. Valuta se Kubernetes fa per te: inizia con minikube e prova a deployare una versione containerizzata.

Ricorda: un container non è fine a se stesso – è uno strumento per ridurre costi, aumentare affidabilità e velocizzare lo sviluppo. Noi, di Meteora Web, lo usiamo ogni giorno e lo misuriamo in fatturato risparmiato.