Docker non crea VM: le immagini sono solo cartelle

Il 22 ottobre 2026 su codeandcake.dev un esperimento descrive Docker come “strano”: i container non sono macchine, sono processi del kernel, e le immagini sono cartelle che diventano la loro root¹.

L’autore ha iniziato a scrivere un proprio container runtime “per divertimento”. È alle prime fasi, ma mette a fuoco alcuni punti su come funziona Docker¹. Il primo: “i container non sono reali”. A differenza delle VM, un container è un processo con restrizioni applicate. Il kernel lo esegue come ogni altro processo. Se sai dove guardare, lo trovi in /proc¹.

Secondo: non esiste una singola feature di Linux chiamata “container”. Quello che chiamiamo container nasce dalla combinazione di più meccanismi del kernel. L’autore parla di “cinque” feature sotto un impermeabile. Cita i namespaces, che nascondono cosa vedono host e container. Cita i cgroups, che limitano l’uso delle risorse. Per la rete ammette “un sacco di magia” che non capisce, ma che isola la connettività del container¹.

Terzo punto, sullo storage: “le immagini sono solo cartelle”. Docker mette quei file da qualche parte sul filesystem. Poi chiama chroot, o pivot_root, per rendere quella cartella la nuova root del processo del container¹.

L’articolo entra anche in un esempio minimale. Se esegui: docker run -it --rm ubuntu /bin/bash, Docker fa tre cose. Scarica l’immagine ubuntu da Dockerhub. La mette in una posizione sul disco. Avvia poi /some/weird/docker/path/bin/bash¹.

Questa impostazione ha una conseguenza diretta nell’osservazione dell’autore: “i container non sono davvero reali”. Il processo del container gira sul kernel della macchina che lo ospita, con una vista del filesystem resa diversa cambiando la root del processo¹.

L’autore non propone una spiegazione completa della rete. La definisce “magia” che non capisce, sottolineando che l’isolamento della connettività c’è, ma resta fuori dallo scopo del suo esperimento. Indica invece i due meccanismi che ha toccato con mano, namespaces e cgroups, come esempio della combinazione che rende possibile il comportamento che chiamiamo container¹.

Il post rimane concreto. Mostra dove cercare il processo, indica i componenti che limitano visibilità e risorse, e descrive come le immagini diventano la root del processo con chroot o pivot_root. Si ferma ai dettagli che ha verificato durante il lavoro sul proprio runtime, senza estendere il discorso oltre ciò che ha osservato¹.

C’è anche una nota a margine sul linguaggio usato nel suo progetto. La frase resta tronca: “Go is kind of a terrible language for a co”. Non c’è altro dettaglio, né un giudizio articolato su Go o su come si rapporta all’uso dei container descritto nel post¹.

Nel post, la rete resta la zona d’ombra dichiarata. L’autore la chiama “magia”, e chiude il cerchio su ciò che mostra con sicurezza: processi che puoi trovare in /proc, risorse limitate da cgroups, visibilità separata dai namespaces, e immagini che sono cartelle usate come root del processo¹.