Container Docker

Un container Docker è un processo avviato da un’immagine Docker e isolato dal resto della macchina: ha il proprio filesystem, la propria interfaccia di rete e il proprio elenco di processi, ma condivide il kernel dell’host. L’immagine è il modello in sola lettura (un layer di base del sistema operativo, i runtime, la tua app); il container ne è un’istanza in esecuzione. Puoi avviare molti container da una sola immagine e buttarli via quando hai finito.

Esempio

Avvia un nodo Selenium Chrome usa e getta e un database Postgres per eseguire i test in locale:

docker run --rm -d --name chrome -p 4444:4444 --shm-size=2g selenium/standalone-chrome:latest
docker run --rm -d --name db -p 5432:5432 -e POSTGRES_PASSWORD=test postgres:16-alpine

docker ps          # list running containers
docker logs db     # read a container's output
docker stop chrome db

--rm elimina il container quando si ferma, -d lo esegue in background e -p host:container pubblica una porta. Nei progetti reali si fissano i tag delle immagini (per esempio postgres:16.4-alpine) invece di usare latest, così che una nuova release upstream non cambi il tuo ambiente di test da un giorno all’altro.

Perché i tester usano i container

• Ambienti riproducibili. La stessa immagine gira su ogni laptop e su ogni runner di CI, eliminando un’intera categoria di fallimenti del tipo “sulla mia macchina funziona”.
• Dipendenze usa e getta. Un database nuovo per ogni esecuzione dei test significa nessun dato residuo dall’esecuzione di ieri.
• Browser in parallelo. Selenium Grid e le immagini dei browser ti permettono di aumentare e ridurre i nodi con un comando.
• Eseguire la suite di test stessa. Playwright pubblica immagini ufficiali con browser e librerie di sistema preinstallati, evitando errori per dipendenze mancanti sugli agent di CI.

Differenza rispetto a una macchina virtuale

Una VM emula una macchina completa con il proprio kernel, quindi è più pesante e più lenta ad avviarsi. Un container condivide il kernel dell’host, si avvia in pochi secondi e usa molta meno memoria. Il compromesso è un isolamento più debole, che conta per i confini di sicurezza ma raramente per gli ambienti di test.

Errori comuni

Salvare i dati di test dentro un container aspettandosi che sopravvivano a un riavvio (usa i volumi), usare i tag latest e dimenticare --shm-size per i container dei browser, cosa che fa andare in crash Chrome sotto carico.