Docker, seconda puntata: il primo container non si scorda mai. Gli altri si fermano con stop

Nella prima puntata abbiamo installato Docker senza dover sacrificare una Debian sull’altare delle dipendenze. Ora il comando risponde. Bene. È il momento di capire cosa fa, prima di riempire il disco di container dal nome poetico e dalla funzione ignota.

Faremo tre cose: lanceremo un processo, pubblicheremo una pagina e vedremo sopravvivere un dato alla rimozione del suo container. Tutto in locale, senza mandare un Nginx a salutare l’intero condominio.

Un processo, non un acquario

sudo docker run --rm alpine:3.22 echo "Ciao, pilota di Gundam"
sudo docker ps
sudo docker ps -a

Docker cerca l’immagine in locale, se manca la scarica, crea il container e lancia echo. Finito echo, finito il container. Con --rm viene anche rimosso: quindi non lo ritrovi in ps -a. Senza --rm resterebbe fermo. Le immagini restano disponibili per i prossimi avvii.

Un container rimane attivo finché vive il suo processo principale. Se il comando termina, non è necessariamente un guasto. A volte il computer ha semplicemente finito ciò che gli avevi chiesto. Dovremmo provarci anche noi.

Un sito, finalmente qualcosa da guardare

sudo docker run -d --name hangar-test -p 127.0.0.1:8080:80 nginx:stable-alpine
curl -I http://127.0.0.1:8080
sudo docker ps
sudo docker logs --tail 20 hangar-test

Apri http://localhost:8080: dovrebbe comparire la pagina di benvenuto di Nginx. -d lo lascia lavorare in background, --name assegna un nome riconoscibile, -p collega la porta 8080 dell’host alla 80 del container. Il prefisso 127.0.0.1 limita l’ascolto all’interfaccia locale.

curl deve ottenere una risposta HTTP 200. Nei log vedi le richieste. Se la porta 8080 è occupata, usa 8081 sul lato sinistro e cambia anche l’URL. Se il nome esiste già, controlla con ps -a: un container fermo conserva il nome, come certe band che continuano a esistere anche senza più suonare.

Entrare, guardare, uscire

sudo docker exec -it hangar-test sh
ls /usr/share/nginx/html
exit
sudo docker inspect --format "{{.State.Status}}" hangar-test
sudo docker stop hangar-test
sudo docker start hangar-test
curl -I http://127.0.0.1:8080

exec avvia un altro processo dentro un container già acceso. Qui usiamo sh perché le immagini minimali non garantiscono bash. Lo stop ferma il container; start riavvia quello stesso container. run, invece, ne crea uno nuovo. Tre verbi piccoli, capaci di produrre parecchia confusione se scambiati dopo mezzanotte.

Il dato che non vuole morire

sudo docker volume create hangar-dati
sudo docker run --rm -v hangar-dati:/dati alpine:3.22 sh -c 'echo "RX-78-2 presente" > /dati/inventario.txt'
sudo docker run --rm -v hangar-dati:/dati:ro alpine:3.22 cat /dati/inventario.txt

Il primo container scrive e viene rimosso. Il secondo legge dallo stesso volume: devi ritrovare «RX-78-2 presente». Un nome Docker identifica il volume, /dati è il percorso interno. :ro monta il volume in sola lettura. Il filesystem scrivibile del container è un’altra cosa: sparisce quando quel container viene rimosso. Il volume resta finché non lo rimuovi esplicitamente.

La tua prima immagine

In una cartella nuova creiamo due file, senza usare il nome della cartella della prossima puntata:

mkdir -p primo-hangar
cd primo-hangar

index.html

<!doctype html>
<html lang="it">
<meta charset="utf-8">
<title>Primo hangar</title>
<h1>Ciao, pilota!</h1>
<p>Il Gundam è ancora in garage. Il server, invece, parte.</p>
</html>

Dockerfile

FROM nginx:stable-alpine
COPY index.html /usr/share/nginx/html/index.html

Poi costruiamo l’immagine e avviamo un nuovo container, liberando prima la porta del test:

sudo docker stop hangar-test
sudo docker rm hangar-test
sudo docker build -t primo-hangar:1 .
sudo docker run -d --name primo-hangar -p 127.0.0.1:8080:80 primo-hangar:1
curl http://127.0.0.1:8080

Il punto finale del build è il contesto: la cartella da cui Docker prende i file. Cambiare index.html sul disco non modifica magicamente l’immagine già costruita. Dopo una modifica rifai build, rimuovi il vecchio container e ricrealo. Anche Docker, ogni tanto, pretende che gli diciamo cosa intendiamo.

Riordino senza lanciafiamme

sudo docker stop primo-hangar
sudo docker rm primo-hangar
sudo docker volume rm hangar-dati

L’ultimo comando elimina definitivamente il volume di prova e il suo inventario: eseguilo solo quando quel dato non serve più. Evitiamo prune indiscriminati: sullo stesso computer potrebbe vivere qualcosa a cui teniamo più di questo esercizio.

Ora sappiamo osservare processi, porte, log e dati persistenti. Nella terza puntata i protagonisti diventano tre: un’interfaccia Vue, un’API FastAPI e PostgreSQL. Il catalogo vende soltanto l’illusione di avere ancora spazio sulla mensola.

Per approfondire: esecuzione dei container e volumi Docker.