Spesso quando si parla di Docker si tende a confondere tra loro diverse cose.
In particolare:
- Docker Inc.
- Docker Runtime / Docker Orchestration engine
- Docker Project
Docker Inc.
Si tratta dell’azienda che in questo momento mantiene il progetto Docker.
Quando è nata non si chiamava così, ma “dotCloud” e forniva un servizio di tipo PaaS (Platform as a Service) per la gestione dei container linux.
Per fare ciò, dotCloud aveva sviluppato un tool interno, chiamato appunto: ‘Docker’.
Il nome Docker è stato ricavato da “Dock-Worker”, ovvero le persone che si occupano di caricare e scaricare le navi dai porti, in questo caso con particolare riferimento ai container.
Purtroppo il modello di business si è rivelato particolarmente fragile e nel 2013 vi è stato un cambio di dirigenza che ha visto cambiare l’amministratore delegato in Ben Golub.
Con Ben Golub, il framework è diventato disponibile a tutti.
Docker Runtime / Docker Orchestration engine
In questo caso stiamo parlando del core.
Questo è il motore che si occupa di far funzionare i container.
Una delle caratteristiche certamente più interessanti è la possibilità di estendere questa componente mediante dei plugin.
Esistono due versioni diverse:
- CE – Community Edition
- EE – Enterprise Edition
La versione community è gratuita, mentre la versione enterprise è a pagamento.
La differenza tra le due è che la versione enterprise mette a disposizione delle caratteristiche pensate appositamente per il business, tra le quali il supporto qualificato e le modalità supporto alle versioni.
Il 13 Novembre 2019, Docker Enterprise è stato acquisito da Mirantis.
Tutti gli esempi presenti sul tutorial, saranno eseguiti in ambiente community, quindi saranno replicabili nell’ambiente gratuito previsto dalla community edition.
La versione Enterprise si divide a sua volta in tre versioni:
- Enterprise Basic
- Enterprise Standard
- Enterprise Advanced
Politica delle release
Sia per la versione community, sia per la versione enterprise, è previsto un rilascio di tipo stable ogni tre mesi.
La versione enterprise garantisce patch e bugfix per 12 mesi a partire dal rilascio della versione di Docker. La versione community, invece, fornisce lo stesso tipo di assistenza solo per i 4 mesi successivi al rilascio della versione stable,
È disponibile anche un terzo canale di rilascio per le versioni community, ovvero il canale edge.
Questo tipo di rilascio avviene con cadenza mensile e vengono mantenuti solo per il mese successivo alla data di rilascio.
Guardando con attenzione il grafico dei rilasci, emergono i tag utilizzati per indicare i numeri di versione.
A partire dal 2017, si compone il numero di versione in questo modo:
v 2 numeri per l’anno . 2 numeri per il mese
Ad esempio v17.09 è la versione che è stata rilasciata nel settembre del 2017.
A dire il vero questo tag di release non è completo.
Oltre a queste informazioni è possibile trovare la patch appena dopo il mese e l’indicazione del tipo di release. I tag di release, infatti, specificano se si tratta di una release di Docker CE o EE. Per fare ciò viene posta la stringa -ce in coda al tag di versione nel caso si tratti di un release di tipo community.
È possibile consultare l’elenco delle versioni community a questo link.
Docker Project
Quando si parla di Docker o Moby project si parla del progetto che nasce per scomporre Docker, che fino al 2017 si presentava come monolitico, in componenti. Andremo più in dettaglio su tale aspetto nelle prossime sezioni.
Questo progetto ha chiesto aiuto al mondo open source, rivolgendosi in particolare a chi aveva (ed ha) dimestichezza con il mondo GO.
Nel caso qualcuno se la sentisse e avesse voglia di dare il suo contributo, ecco il repository.
Nella DockerCon (la principale conferenza annuale su Docker) del 2017, ha cambiato nome in Moby Project.
Ma perché è nato moby?
C’è stato un momento in cui ci sono state delle scaramucce nel mondo di Docker.
La causa principale deriva dal fatto che le componenti di Docker sono pensate per essere intercambiabili, un po’ come se fossero dei pezzi di motore di un auto (se qualcuno li conosce, può averne riscontro immediato pensando ai driver di rete).
Questo, a dirla tutta, è un fattore positivo poiché permette di poter scegliere la componente che risponde meglio alle esigenze del caso specifico in cui ci si imbatte.
Il problema è che questo funziona bene solo se tutti giocano con le stesse regole.
Nelle fasi iniziali di docker purtroppo non è stato così.
Vi erano componenti sviluppate da Docker e componenti di terze parti.
Ad un certo punto si è verificato un braccio di ferro tra Docker e CoreOs che ha portato dei problemi di compatibilità tra i plugin di terze parti e quelli ufficiali.
La crescita di Docker e della sua adozione era seriamente compromessa proprio a causa della non interoperabilità di plugin ufficiali con plugin di terze parti.
È risultato evidente che c’era bisogno di adottare uno standard condiviso.
Da qui, è stata fondata OCI (Open Container Initiative).
OCI è un’organizzazione che racchiude tutti i principali player che si occupano di container e si pone come obiettivo quello di guidare una crescita secondo regole comuni e degli standard che devono essere adottati da tutti.
L’architettura del motore di Docker si è conformata ai dettami previsti dalla release di OCI relativa ai runtime.
—
Prosegui su: Il motore