{"id":91905,"date":"2020-08-20T07:42:23","date_gmt":"2020-08-20T05:42:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii"},"modified":"2020-08-20T07:42:23","modified_gmt":"2020-08-20T05:42:23","slug":"chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii","title":{"rendered":"Che cos'\u00e8 Docker: una breve panoramica sulla storia e le principali astrazioni","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Il 10 agosto \u00e8 iniziato un videocorso su Docker<\/a><\/noindex>, in cui esaminiamo ogni aspetto \u2014 dalle astrazioni di base ai parametri di rete. <\/p>\n

<\/p>\n

In questo articolo parleremo della storia di Docker e delle sue principali astrazioni: Image, Cli, Dockerfile. La lezione \u00e8 destinata ai principianti, quindi difficilmente sar\u00e0 interessante per gli utenti esperti. Non ci saranno elementi estremi, appendici o immersioni profonde. Solo le basi.<\/p>\n

<\/p>\n

\"Che<\/p>\n

<\/a><\/noindex><\/p>\n

Cos'\u00e8 Docker<\/h2>\n

<\/p>\n

Diamo un'occhiata alla definizione di Docker tratta da Wikipedia.<\/p>\n

<\/p>\n

Docker \u00e8 un software per l'automazione della distribuzione e gestione delle applicazioni in ambienti che supportano la containerizzazione.<\/p><\/blockquote>\n

Da questa definizione non si capisce molto. Non \u00e8 chiaro, in particolare, cosa significhi 'in ambienti che supportano la containerizzazione'. Per chiarire, torniamo indietro nel tempo. Iniziamo con l'epoca che definisco 'Era Monolitica'.<\/p>\n

<\/p>\n

Era Monolitica<\/h2>\n

<\/p>\n

L'era monolitica \u00e8 l'inizio degli anni 2000, quando tutte le applicazioni erano monolitiche, con molte dipendenze. Lo sviluppo era lungo. All'epoca non c'erano molti server, li conoscevamo tutti per nome e li monitoravamo. C'\u00e8 un confronto divertente:<\/p>\n

\n

\r\n \"Guarda\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Gli animali domestici sono come animali da compagnia. Nell'era monolitica trattavamo i nostri server come animali domestici, li curavamo e li coccolavamo, spolverando ogni particella. Per una migliore gestione delle risorse utilizzavamo la virtualizzazione: prendevamo un server e lo suddividevamo in pi\u00f9 macchine virtuali, garantendo cos\u00ec l'isolamento dell'ambiente.<\/p>\n

<\/p>\n

Sistemi di virtualizzazione basati su hypervisor<\/h2>\n

<\/p>\n

Tutti hanno certamente sentito parlare dei sistemi di virtualizzazione: VMware, VirtualBox, Hyper-V, Qemu KVM, ecc. Questi forniscono isolamento delle applicazioni e gestione delle risorse, ma hanno anche degli svantaggi. Per implementare la virtualizzazione \u00e8 necessario un hypervisor. E un hypervisor comporta un overhead delle risorse. Inoltre, la macchina virtuale stessa \u00e8 generalmente piuttosto pesante \u2014 un'immagine grande, con un sistema operativo, Nginx, Apache, e magari anche MySQL. L'immagine \u00e8 grande, e la macchina virtuale \u00e8 scomoda da gestire. Di conseguenza, lavorare con le virtual machine pu\u00f2 essere lento. Per risolvere questo problema, sono stati creati sistemi di virtualizzazione a livello di kernel.<\/p>\n

<\/p>\n

Sistemi di virtualizzazione a livello di kernel<\/h2>\n

<\/p>\n

La virtualizzazione a livello di kernel \u00e8 supportata da sistemi come OpenVZ, Systemd-nspawn, LXC. Un chiaro esempio di tale virtualizzazione \u00e8 LXC (Linux Containers). <\/p>\n

<\/p>\n

LXC \u00e8 un sistema di virtualizzazione a livello di sistema operativo per eseguire pi\u00f9 istanze isolate del sistema operativo Linux su un unico nodo. LXC non utilizza macchine virtuali, ma crea un ambiente virtuale con uno spazio di processi e uno stack di rete propri.<\/p>\n

<\/p>\n

In sostanza, LXC crea contenitori. Qual \u00e8 la differenza tra macchine virtuali e contenitori?<\/p>\n

<\/p>\n

\"Che<\/p>\n

<\/p>\n

Il contenitore non \u00e8 adatto per isolare i processi: nei sistemi di virtualizzazione a livello di kernel sono state trovate vulnerabilit\u00e0 che consentono di uscire dal contenitore verso l'host. Pertanto, se hai bisogno di isolare qualcosa, \u00e8 meglio utilizzare una virtual machine.<\/p>\n

<\/p>\n

Le differenze tra virtualizzazione e containerizzazione possono essere viste in uno schema.
\nCi sono hypervisor hardware, hypervisor sopra i sistemi operativi e contenitori. <\/p>\n

<\/p>\n

\"Che<\/p>\n

<\/p>\n

Gli hypervisor 'bare-metal' sono ottimi se desideri davvero isolare qualcosa, perch\u00e9 offrono la possibilit\u00e0 di isolare a livello di pagine di memoria e CPU.<\/p>\n

<\/p>\n

Ci sono hypervisor come programmi e ci sono contenitori, di cui parleremo di seguito. Nei sistemi di containerizzazione non c'\u00e8 hypervisor, ma c'\u00e8 il Container Engine che crea e gestisce i contenitori. Questa \u00e8 una soluzione pi\u00f9 leggera, quindi, grazie al lavoro con il kernel, l'overhead \u00e8 minore o addirittura assente.<\/p>\n

<\/p>\n

\n

Cosa viene utilizzato per la containerizzazione a livello di kernel<\/h2>\n

Le principali tecnologie che consentono di creare un contenitore isolato dagli altri processi sono Namespaces e Control Groups.<\/p>\n

Namespaces: PID, Networking, Mount e User. Ce ne sono altri, ma per semplificare ci concentreremo su questi.<\/p>\n

Il PID Namespace limita i processi. Quando, ad esempio, creiamo un PID Namespace e ci mettiamo un processo, esso ottiene il PID 1. Di solito, nel sistema, il PID 1 \u00e8 systemd o init. Pertanto, quando mettiamo un processo in un nuovo namespace, riceve anch'esso il PID 1.<\/p>\n

Il Networking Namespace consente di limitare\/isolare la rete e di gestire le proprie interfacce al suo interno. Mount \u00e8 una limitazione sulla filesystem. User \u00e8 una limitazione sugli utenti.<\/p>\n

Control Groups: Memoria, CPU, IOPS, Rete \u2014 ci sono circa 12 impostazioni. Sono anche chiamati Cgroups ('C-gruppi').<\/p>\n

I Control Groups gestiscono le risorse per il contenitore. Attraverso i Control Groups possiamo specificare che un contenitore non deve consumare pi\u00f9 di una certa quantit\u00e0 di risorse.<\/p>\n

Affinch\u00e9 la containerizzazione funzioni a pieno, vengono utilizzate tecnologie aggiuntive: Capabilities, Copy-on-write e altre.<\/p>\n

Capabilities sono quando diciamo a un processo cosa pu\u00f2 fare e cosa non pu\u00f2 fare. A livello di kernel, si tratta semplicemente di bitmap con una grande quantit\u00e0 di parametri. Per esempio, l'utente root ha pieni privilegi, pu\u00f2 fare tutto. Il server del tempo pu\u00f2 modificare l'ora di sistema: ha capabilities su Time Capsule, e basta. Con i privilegi, \u00e8 possibile configurare in modo flessibile le restrizioni per i processi e cos\u00ec proteggere se stessi.<\/p>\n

Il sistema Copy-on-write ci consente di lavorare con le immagini Docker, utilizzandole in modo pi\u00f9 efficiente.<\/p>\n

Attualmente, Docker ha problemi di compatibilit\u00e0 con Cgroups v2, quindi in questo articolo si considerano proprio i Cgroups v1.<\/em><\/p><\/blockquote>\n

Ma torniamo alla storia. <\/p>\n

<\/p>\n

Quando sono emersi i sistemi di virtualizzazione a livello di kernel, hanno iniziato a essere adottati attivamente. L'overhead del hypervisor \u00e8 scomparso, ma alcuni problemi sono rimasti:<\/p>\n

<\/p>\n