Perché i container

Obiettivi di oggi

• Capire cosa risolve un container (e cosa no)
• Ambiente Docker installato e verificato sulla tua macchina
• Gestire il ciclo di vita: run, ps, logs, exec, stop, rm
• Servire la prima versione del Portale Pratiche da un container

Il problema da cui partiamo

• Ogni servizio dell'Ente = una VM configurata a mano, nel tempo, da persone diverse
• Deriva di configurazione: nessuno sa più esattamente cosa c'è installato
• Rilascio = "collegarsi alla VM e fare le cose" → non ripetibile, non tracciato
• "Sulla mia macchina funziona" — e in produzione no

VM vs container

Il container NON è una VM leggera: è un processo isolato + un pacchetto immutabile.

Le tre parole da non confondere

• Immagine — il pacchetto: filesystem + comando di avvio, immutabile, versionato
• Container — un'istanza in esecuzione di un'immagine (usa-e-getta)
• Registry — il magazzino da cui si scaricano/pubblicano le immagini

docker run -d --name web -p 8080:80 nginx:1.27
#          │        │       │          └ immagine:versione
#          │        │       └ porta host:porta container
#          │        └ nome del container
#          └ in background

Il quotidiano: 6 comandi

docker run ...      # crea e avvia
docker ps           # cosa gira
docker logs web     # cosa dice
docker exec -it web bash   # entrarci
docker stop web     # fermare
docker rm web       # eliminare

Riepilogo e prossimo passo

• Container = processo isolato; immagine = pacchetto immutabile
• Il bind mount è comodo in sviluppo ma non è un rilascio
• Modulo 2: costruiamo noi le immagini — il contenuto entra DENTRO, con un Dockerfile