Docker e container spiegati semplice: guida pratica per IT e sysadmin

Un container è come uno ZIP file eseguibile. Dentro c’è il programma, le sue dipendenze, la sua configurazione. Lo sposti da un server all’altro e funziona uguale. Nessun “ma sul mio PC funzionava” — o funziona, o c’è un problema reale da risolvere.

È questa la promessa che Docker ha mantenuto dal 2013. Nel 2025, deployare un servizio AI in azienda senza container è come installare software copiando cartelle a mano: si può fare, ma ti stai complicando la vita.

VM vs container: la differenza che conta

Una VM è un computer virtuale completo: ha il suo kernel, il suo OS, i suoi driver. Pesa gigabyte, si avvia in minuti, consuma RAM anche quando non fa nulla. È la scelta giusta quando hai bisogno di isolamento forte — ambienti multi-tenant, OS diversi sullo stesso host, sicurezza di tipo “questo processo non deve poter fare nulla al di fuori della VM”.

Un container condivide il kernel del sistema host ed esegue solo il processo che ti serve, con le sue dipendenze impacchettate dentro. Si avvia in secondi, pesa megabyte, puoi farne girare decine sullo stesso server senza che si pestino i piedi. Per la stragrande maggioranza dei servizi — web app, API, tool interni, modelli AI — i container sono la scelta migliore.

I 4 comandi che usi ogni giorno

docker run -d -p 8080:80 nginx          # avvia nginx in background, porta 8080
docker ps                               # vedi cosa sta girando
docker logs nome_container              # leggi i log
docker compose up -d                    # avvia uno stack da docker-compose.yml

docker run scarica l’immagine se non ce l’hai, crea il container, lo avvia. Il flag -d lo manda in background. -p 8080:80 mappa la porta 80 del container sulla porta 8080 del tuo server.

docker ps ti mostra i container attivi con ID, immagine, porte e stato. docker logs è il tuo primo strumento di debug — se qualcosa non va, guardali.

docker compose up -d è quello che userai quasi sempre in produzione: legge un file docker-compose.yml e avvia tutto lo stack definito lì.

docker-compose.yml in pratica: Ollama + Open WebUI

Questo è uno stack reale che puoi deployare adesso:

services:
  ollama:
    image: ollama/ollama
    volumes:
      - ollama_data:/root/.ollama
    ports:
      - "11434:11434"
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    ports:
      - "3000:8080"
    depends_on:
      - ollama
volumes:
  ollama_data:

Riga per riga: ollama è il servizio che fa girare i modelli AI — usa il volume ollama_data per persistere i modelli scaricati tra i riavvii. open-webui è l’interfaccia web tipo ChatGPT — riceve la variabile d’ambiente che gli dice dove trovare Ollama (http://ollama:11434, che funziona perché i due container sono nella stessa rete Docker). depends_on garantisce che Ollama sia partito prima di avviare la UI. Il volume ollama_data viene creato automaticamente da Docker se non esiste.

Per avviare:

docker compose up -d

Apri il browser su http://localhost:3000, crea il primo account, e hai il tuo ChatGPT privato funzionante. Poi scarica un modello:

docker exec -it nome_container_ollama ollama pull qwen2.5:7b

Portainer: gestione container senza terminale

Se gestisci container per un team e non tutti vogliono stare alla riga di comando, Portainer è la risposta. È un’interfaccia web che mostra container, stack, volumi, log — tutto cliccabile.

docker run -d -p 9443:9443 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  portainer/portainer-ce

Apri https://localhost:9443, crea l’utente admin, e hai una dashboard completa. Portainer Community Edition è gratuita.

Quando non usare Docker

Docker non è la risposta a tutto. Evitalo o sii cauto in questi casi:

Database in produzione su storage condiviso: i container nascono stateless, i database sono tutto il contrario. PostgreSQL o MySQL in Docker funzionano, ma aggiungono un layer di complessità per backup, failover e tuning delle performance. Su piccoli ambienti va bene, in produzione pesante valuta istanze gestite o VM dedicata.

Accesso hardware diretto complesso: alcune configurazioni GPU, device USB specializzati, o schede di acquisizione non si passano facilmente ai container. Proxmox LXC con configurazione cgroup esplicita risolve molto, ma non tutto.

Team che non conosce i container: Docker non è difficile, ma richiede un minimo di formazione. Se il team non sa cosa sono immagini, volumi e reti Docker, deployare container in produzione senza formazione prima crea problemi difficili da debuggare nel momento sbagliato.

Cosa fare

• Installa Docker su un server di test e avvia lo stack Ollama + Open WebUI con il compose mostrato sopra — ci vogliono 5 minuti e hai subito qualcosa di concreto da mostrare.
• Aggiungi Portainer allo stesso server: rende la gestione accessibile a tutto il team IT, non solo a chi è comodo con il terminale.
• Prima di portare container in produzione, stabilisci una policy per i backup dei volumi — è l’unica parte stateful e quella che perdi se nessuno ci pensa.