Che aspetto hanno i processi all'interno di un container Docker?

Di recente ho sentito confusione su cosa sia un container Docker, e più precisamente cosa succede all'interno, rispetto ai comandi e ai processi che invoco mentre sono all'interno di un container Docker.

Qualcuno può fornire una panoramica di alto livello di ciò che sta accadendo?

Docker viene gettato nel secchio di virtualizzazione, perché le persone presumono che stia in qualche modo virtualizzando l'hardware sottostante. Questo è un termine improprio che permea dalla terminologia utilizzata da Docker, principalmente il termine container.

Tuttavia Docker non sta facendo nulla di magico in termini di virtualizzazione dell'hardware di un sistema. Piuttosto sta sfruttando la capacità del kernel Linux di costruire "recinzioni" attorno a strutture chiave, il che consente a un processo di interagire con risorse come rete, file system e autorizzazioni (tra le altre cose) per dare l'illusione di interagire con un sistema completamente funzionale.

Ecco un esempio che illustra cosa sta succedendo quando avviiamo un container Docker e quindi lo inseriamo attraverso l'invocazione di /bin/bash.

$ docker run -it ubuntu:latest /bin/bash
root@c0c5c54062df:/#

Ora dall'interno di questo contenitore, se eseguiamo ps -eaf:

Passando a un'altra scheda terminale in cui siamo connessi al sistema host che ospita il contenitore Docker, possiamo vedere lo spazio di processo che il contenitore sta "effettivamente" occupando:

Ora se torniamo alla scheda Docker e lanciamo diversi processi al suo interno e li background tutti, possiamo vedere che ora abbiamo diversi processi figlio in esecuzione con il processo Bash primario che inizialmente abbiamo avviato come parte del lancio del contenitore Docker.

NOTA: i processi sono 4 sleep 1000comandi in background.

Notare come all'interno del contenitore Docker ai processi sono assegnati ID di processo (PID) di 48-51. Vedili ps -eafnell'output anche nel loro:

Tuttavia, con questa immagine successiva, viene rivelata gran parte della "magia" che Docker sta eseguendo.

Vedi come i 4 sleep 1000processi sono in realtà solo processi figlio del nostro processo Bash originale? Si noti inoltre che il nostro contenitore Docker originale /bin/bashè in realtà un processo figlio anche per il demone Docker.

Ora, se dovessimo aspettare oltre 1000 secondi per il completamento dei sleep 1000comandi originali , quindi eseguirne altri 4 nuovi e avviare un altro contenitore Docker in questo modo:

$ docker run -it ubuntu:latest /bin/bash
root@450a3ce77d32:/#

L'output del computer host da ps -eafdovrebbe apparire così:

E altri container Docker, verranno visualizzati come processi nel demone Docker.

Quindi vedi, Docker non sta davvero virtualizzando ( nel senso tradizionale ), sta costruendo "recinzioni" attorno alle varie risorse del Kernel e limitando la visibilità ad esse per un dato processo + figli.

All'interno del contenitore, i processi devono essere isolati (messi in quarantena). In effetti non dovresti vedere alcun processo ma quelli che specifichi (almeno una shell). Non è per i test di "socievolezza". L'unica somiglianza con chroot è che viene utilizzato il kernel host. Docker è eccezionale se è necessario isolare qualcosa o utilizzare versioni diverse del software di architettura della piattaforma rispetto a quelle in esecuzione sull'host. (dicono versioni molto vecchie di Java o un fork diverso di Python). Fai attenzione che le cartelle e i file binari con cui hai a che fare potrebbero non essere gli stessi di quelli sull'host. Non è la stessa cartella / bin ecc.

EDIT: somiglianza con chroot piuttosto che con VM.