Tutti noi abbiamo imparato a usare Docker come se fosse una scatola magica: metti dentro il codice, lanci un comando e — puf! — hai un ambiente isolato e pronto all’uso. Ma se vi dicessi che, in realtà, stiamo solo giocando a nascondino con il kernel Linux?
Recentemente è uscito un post che mi ha fatto riflettere (e pure un po’ ridere) su quanto sia bizzarro il funzionamento dei container. Se state scrivendo il vostro runtime per puro divertimento — perché sì, siamo quel tipo di gente che perde il weekend a reinventare la ruota — saprete che la verità è molto meno ‘tecnologica’ e molto più ‘artigianale’ di quanto sembri.
Partiamo dal primo grande shock: i container non esistono. Non sono macchine virtuali, non hanno un proprio kernel. Sono semplicemente dei processi che indossano un travestimento. È come se un hacker indossasse un cappotto lungo (il famoso «trenchcoat») per nascondere cinque diverse funzionalità del kernel Linux (namespaces, cgroups e altre magie di networking) e convincerti di essere un’entità separata. Se sai dove guardare in /proc, il trucco svanisce in un attimo.
E le immagini? Non sono altro che cartelle messe lì in un posto qualsiasi di Docker, che il sistema poi ‘promuove’ a root directory tramite chroot o pivot_root. Praticamente, Docker scarica una cartella, la sposta e ti dice: «Ehi, guarda che questa è una nuova distro Ubuntu!». Un po’ come quando i bambini giocano a fare l’ufficio con le scatole di cartone.
La cosa più divertente, però, riguarda lo stack tecnologico. Runc, il runtime su cui poggia tutto, è scritto in Go. E qui la cosa si fa tecnica e un po’ assurda. Go è un linguaggio fantastico, ma per gestire un runtime di questo tipo è un incubo. Poiché Go non supporta il classico ‘fork’ (perché il suo runtime multi-thread non si sposa bene con l’idea di clonare solo un thread), gli sviluppatori hanno dovuto implementare dei workaround quasi surreali, come eseguire /proc/self/exe con argomenti speciali per simulare un processo figlio.
Infine, c’è il tema dei permessi. Se usate Docker su macOS, probabilmente non avete mai notato quanto sia pesante l’impatto del daemon che gira con i privilegi di root. Gestire la sicurezza in un ambiente dove tutto dipende da un insieme di ‘trucchetti’ applicati a processi condivisi è un lavoro da incubo, anche per i migliori.
In conclusione: Docker è una maraviglia ingegneristica, ma è costruita su una serie di stratagemmi che farebbero invidia a un prestigiatore della Silicon Valley. La prossima volta che lanciate un container, ricordatevi che non state accendendo un computer, state solo chiedendo al kernel di fingere che quel processo sia molto più importante di quello che è.
Source: Docker is weird