12.1 Gestione dei container

Panoramica dei comandi fondamentali di Docker per la gestione delle immagini. Vedremo come elencarle, scaricarle, crearle, rimuoverle e comprenderne il ruolo nel ciclo di vita dei container.

frank@debian:~$ sudo usermod -aG docker $USER
frank@debian:~$ newgrp docker
frank@debian:~$ docker -v
frank@debian:~$ groups

Creazione ed esecuzione di un container

A partire da un’immagine è possibile creare ed avviare un container. Se l’immagine non è presente localmente Docker la scarica automaticamente.

$ docker run nome_immagine

Assegnare un nome ai container

Ogni container ha un ID univoco ma è possibile assegnare un nome per semplificarne la gestione.

Quando crei un container il nome non dovrebbe essere casuale perché quel container rappresenta un servizio reale che sta svolgendo una funzione precisa nel tuo sistema. Per questo conviene scegliere nomi chiari e descrittivi in modo da capire subito cosa fa ogni container quando esegui docker ps.

Evita nomi generici come test, prova o container1: all’inizio sembrano comodi ma dopo poco tempo non ti aiutano più a ricordare quale servizio stia girando e rischi di fermare il container sbagliato.

Un buon criterio è usare un nome che indichi il servizio e il suo ruolo. Ad esempio, per Nextcloud puoi usare nextcloud-app per l’applicazione principale e nextcloud-db per il database. Se hai più progetti o un laboratorio personale puoi anche aggiungere un prefisso, ad esempio franklab-nginx o franklab-postgres così mantieni tutto ordinato.

Il comando per avviare un container specificando il nome è il seguente:

$ docker run --name nextcloud-app nextcloud

assegnazione di un nome al container:
--name nextcloud-app
l’immagine da cui il container viene creato:
nextcloud

Container interattivi

Con l’opzione -it la shell locale viene collegata al processo in esecuzione nel container.

$ docker run -it ubuntu bash
root@container:/# apt update
root@container:/# exit

Quando il processo principale termina anche il container viene arrestato.

Container in background

L’opzione -d esegue il container in background. In questo esempio avviamo un server nginx che continua a funzionare senza occupare il terminale.

frank@debian:~$ docker ps
CONTAINER ID   IMAGE     COMMAND                  CREATED         STATUS         PORTS                                     NAMES
6ea3e314a538   nginx     "/docker-entrypoint.…"   6 seconds ago   Up 5 seconds   0.0.0.0:8080->80/tcp, [::]:8080->80/tcp   goofy_bouman

Come scollegarsi e ricollegarsi a un container in esecuzione

Per uscire da un container interattivo senza fermarlo si utilizza la combinazione CTRL + P seguita da CTRL + Q. Per rientrare nel container il comando docker attach si collega al processo principale ed è quindi più rischioso mentre docker exec apre una sessione separata senza interferire con il servizio in esecuzione.

In Docker la differenza tra attach ed exec riguarda il modo in cui accedi a un container già in esecuzione.

• Con docker attach ti colleghi direttamente al processo principale del container come se stessi usando il suo terminale originale. Non viene avviato alcun nuovo processo: condividi lo stesso flusso di input e output. Il punto critico è che interrompendo quel processo ad esempio con il comando exit potresti fermare il container.
• Con docker exec invece avvii un nuovo processo all’interno del container tipicamente una shell come bash. Il processo principale continua a funzionare normalmente e tu lavori in una sessione separata. Chiudendo la shell il container rimane attivo.

Per ricollegarsi al container tramite attach

frank@debian:~$ docker run --cpus 1 --rm -it ubuntu bash

root@3d1f0042f311:/#

CTRL + P seguito da CTRL + Q per uscire da un container interattivo senza fermarlo
  
frank@debian:~$ docker ps
CONTAINER ID   IMAGE     COMMAND   CREATED              STATUS              PORTS     NAMES
3d1f0042f311   ubuntu    "bash"    About a minute ago   Up About a minute             condescending_burnell

frank@debian:~$ docker attach 3d1f0042f311

root@3d1f0042f311:/# ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.0   4588  3884 pts/0    Ss   21:28   0:00 bash
root           9  0.0  0.1   7888  4028 pts/0    R+   21:30   0:00 ps aux

Per ricollegarsi al container tramite exec

frank@debian:~$ docker run --cpus 1 --rm -it ubuntu bash
root@9beac9e4b54c:/# 
  
CTRL + P seguito da CTRL + Q per uscire da un container interattivo senza fermarlo

rank@debian:~$ docker ps
CONTAINER ID   IMAGE     COMMAND   CREATED         STATUS         PORTS     NAMES
9beac9e4b54c   ubuntu    "bash"    2 minutes ago   Up 2 minutes             frosty_hellman

frank@debian:~$ docker exec -it 9beac9e4b54c /bin/bash

root@9beac9e4b54c:/# ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.0   4588  3940 pts/0    Ss+  22:21   0:00 bash
root           8  0.3  0.0   4588  3896 pts/1    Ss   22:26   0:00 /bin/bash
root          17  0.0  0.1   7888  4052 pts/1    R+   22:26   0:00 ps aux

Dopo aver usato docker exec il comando ps aux mostra sia il processo principale del container (PID 1) sia il nuovo processo shell avviato manualmente. Questo dimostra che exec aggiunge un processo senza interrompere quello principale.

Arresto dei container

Per fermare un container:

$ docker stop nome_container

Monitoraggio dei container

Per visualizzare lo stato dei container:

frank@debian:~$ docker ps

Per visualizzare tutti i container fermati torna utile il comando docker ps -a con cui sono mostrati tutti i container presenti nel sistema inclusi quelli fermati o terminati permettendo di gestire e analizzare anche i container non più in esecuzione.

frank@debian:~$ docker ps -a

Rimozione dei container

Un container deve essere arrestato prima di essere rimosso:

$ docker stop nome_container
$ docker rm nome_container
oppure direttamente:
$ docker rm -f nome_container

Con l’opzione --rm il container viene eliminato automaticamente alla terminazione:

$ docker run --rm -it ubuntu bash

Il comando docker container prune elimina in un’unica operazione tutti i container fermati mantenendo intatti quelli in esecuzione. È utile per ripulire l’ambiente di lavoro e recuperare spazio su disco.

$ docker container prune
$ docker container prune -f

Ispezione e troubleshooting

Per analizzare il comportamento di un container e individuare errori:

$ docker logs nome_container
$ docker logs -f nome_container

Per ottenere tutte le informazioni di configurazione in formato JSON:

$ docker inspect <nome_container> oppure <container_ID>

Limitare le risorse

È possibile limitare CPU e memoria assegnate a un container per evitare impatti sull’intero sistema. Questo approccio migliora la stabilità del sistema limitando l’impatto di singoli container.

Limitare la CPU

Visualizza quanti core ha il pc:
frank@debian:~$ nproc
2

Avvia il container per limitare la potenza utilizzabile:
frank@debian:~$ docker run --cpus 1 --rm -it ubuntu bash

Dentro il container:
root@8f1730b26a95:/# nproc
2

Il comando nproc mostra quanti core la macchina possiede realmente mentre --cpus stabilisce quanta CPU puoi consumare. Il container continua a vedere tutte le CPU perché utilizza il kernel dell’host. Docker usa i cgroups per limitare la potenza di calcolo non per nascondere i core.

Con cgroupsv2 Docker limita la CPU del container scrivendo nel file /sys/fs/cgroup/cpu.max che è l’interfaccia del kernel che controlla quanta CPU può essere utilizzata.

Questo permette al container di usare il 100% di una CPU, oppure il 50% di due CPU, oppure il 25% di quattro CPU. Il totale però resta sempre pari a una CPU.

Puoi verificare il limite reale dall’interno del container con:

root@8f1730b26a95:/# cat /sys/fs/cgroup/cpu.max
max 100000

Se l’output è:

100000 100000

significa che hai il 100% di 1 CPU. Se fosse:

200000 100000

avresti il limite equivalente a 2 CPU.

Se invece vuoi che il container veda davvero una sola CPU devi usare:

Visualizza quanti core ha il pc:
frank@debian:~$ nproc
2

frank@debian:~$ docker run --cpuset-cpus="0" --rm -it ubuntu bash

root@8f1730b26a95:/# nproc 
1

Adesso nproc mostra 1 perché non stai solo limitando la potenza utilizzabile ma stai restringendo le CPU visibili al container. In pratica il kernel permette al container di usare solo il core 0 mentre gli altri core non sono accessibili.

Limitare la memoria

frank@debian:~$ free
               total        used        free      shared  buff/cache   available
Mem:         3994244      437880     3239304         740      537852     3556364
Swap:        2710524           0     2710524
  
frank@debian:~$ docker run --memory 1024m --rm -it ubuntu bash

root@07486ba26a2b:/# free
               total        used        free      shared  buff/cache   available
Mem:         3994244      445196     3232220         828      537700     3549048
Swap:        2710524           0     2710524

Stai imponendo un limite massimo di memoria RAM al container. In questo caso --memory 1024m significa che il container può utilizzare fino a 1024 MB (1 GB) di memoria.

Il container continua a vedere tutta la memoria del sistema ma non può superare il limite impostato. Il controllo viene fatto dal kernel Linux tramite i cgroups che Docker utilizza per gestire le risorse.

Dentro il container il comando free mostra ancora tutta la RAM dell’host. Questo non significa che il limite non funzioni. Il comando free legge i dati da /proc/meminfo, che mostra la memoria fisica totale del sistema. I container condividono il kernel Linux quindi vedono la RAM reale non il limite imposto. Docker limita la memoria tramite i cgroups non nascondendo la RAM ma impedendo di superare un certo utilizzo.

Il limite reale impostato dal sistema si può controllare qui:

root@07486ba26a2b:/# cat /sys/fs/cgroup/memory.max

Se il valore è max significa che non è stato impostato alcun limite. Un numero (espresso in byte) indica invece il limite effettivo applicato al container.

Per dimostrare in modo pratico che il limite è realmente applicato si può eseguire uno stress test:

root@aea2633b5e9e:/# apt update

root@aea2633b5e9e:/# apt install -y stress-ng

root@aea2633b5e9e:/# stress-ng --vm 2 --vm-bytes 2G --vm-keep --timeout 60s --metrics-brief &

root@aea2633b5e9e:/# watch -n 0.5 'cat /sys/fs/cgroup/memory.current; echo; cat /sys/fs/cgroup/memory.events'

Se un processo nel container prova a usare più memoria di quella consentita, il kernel Linux rileva una condizione di OOM (Out Of Memory). Non è Docker a intervenire direttamente ma è il kernel tramite i cgroups che applica il limite.

Quando si entra in OOM entra in azione l’OOM Killer un meccanismo di emergenza che termina uno o più processi per riportare il consumo di memoria sotto il limite stabilito.

Questo comportamento può essere osservato nel file:

root@aea2633b5e9e:/# cat /sys/fs/cgroup/memory.events

• max: quante volte il container ha raggiunto il limite massimo di memoria
• oom: quante volte si è verificata una condizione di memoria insufficiente
• oom_kill: quante volte il kernel ha terminato processi per rientrare nel limite

Se durante il test questi valori aumentano significa che il limite di memoria sta funzionando correttamente e che il kernel sta impedendo al container di superarlo.

Durante l’esecuzione vedrai memory.current salire verso il limite e i contatori max, oom e oom_kill aumentare se il limite viene superato.

I container non isolano l’hardware come una macchina virtuale ma il kernel Linux controlla rigidamente le risorse tramite i cgroups. Questo è il motivo per cui il limite è reale anche se non è visibile con i comandi tradizionali come free.