Per rispondere a questa domanda in realtà dobbiamo partire da un po’ più distante.

Qual è l’idea che sta alla base di Docker? Quali sono le cause che hanno portato alla nascita di questa tecnologia?

Partiamo dicendo che Docker è una tecnologia nata per consentire la creazione e gestione di container Linux.

Linux fa già ampio uso dei container in diverse tecnologie, anche nel proprio kernel. Per fare qualche nome: kernel namespace, control groups, union file system e, per ultimo, Docker.

Si è scelto di utilizzare Linux perché al momento in cui è stato lanciato il progetto era l’unico sistema operativo in grado di gestire nativamente una struttura a Container. Questo è stato possibile grazie a diverse entità, sia la community di Linux, sia diversi player commerciali. Giusto per fare un esempio, Kubernetes vede la sua origine in un progetto di Google ed ha proprio Docker come runtime di default.

Kubernetes

Giusto due parole in merito a Kubernetes. Kubernes deriva dal greco “κυβερνήτης” che significa Timoniere. Si tratta di uno dei principali sistemi per la gestione ad alto livello di container ( orchestration, deployment, autoscaling, load balancing, service discovery, … ).

Riassumendo con una metafora, in sistemi complessi Docker è il braccio e Kubernetes è la mente.

Non è strettamente necessario utilizzare Kubernetes, Docker mette a disposizione il suo orchestrator chiamato Docker Swarm anche se la community sembra preferire sempre più Kubernetes a Swarm.

Linux fa già ampio uso dei container in diverse tecnologie, anche nel proprio kernel. Per fare qualche nome: kernel namespace, control groups, union file system e, per ultimo, Docker.

Sebbene sia possibile gestire tutte le dipendenze tra container a mano, è molto comodo avere uno strumento che centralizzi la gestione di dipendenze, relazioni e interazioni tra container al crescere delle applicazioni.

Perché dovrei usare Docker?

Essendo un container ricavato da un’immagine, è possibile dire con le dovute approssimazioni che nel momento in cui devo replicare un ambiente da una parte ad un altra mi basterà istanziare un container a partire dalla stessa immagine e collegare eventualmente le risorse necessarie.

Questo trova risvolto immediato in due situazioni:

• Tra sviluppatori
• Nei vari ambienti:
  • Sviluppo
  • Produzione
  • Staging
  • Test
  • …
• Cambio provider hosting
• Scalabilità
• Pacchettizzazione
• Provisioning gestito da infrastruttura docker

Utilizzando docker possiamo praticamente azzerare il tempo necessario a mettere uno/a sviluppatore/trice in condizione di lavorare su un nuovo progetto poiché il tempo necessario alla replica dell’ambiente in locale si limiterà ad avviare un container da un’immagine che gli/le forniremo

Quando cambiamo provider per l’hosting, potremmo replicare l’ambiente semplicemente facendo deploy dello stesso cluster.

La scalabilità viene gestita mediante dei balancer. Il meccanismo è simile a quello dei servizi cloud con le macchine virtuali ovvero spawn e kill in base a delle soglie sull’utilizzo delle risorse. A differenza di questi ultimi però, non saranno macchine virtuali ad essere istanziate o spente, ma container. Questo permette maggior controllo su costi e risorse.

Questo concetto, applicato ad ambienti cloud, permette di scalare praticamente all’infinito.

Per ultima, la pacchettizzazione. Tutto ciò che è necessario per l’esecuzione può essere spedito assieme. Questo è diretta conseguenza del fatto che un container viene costruito sempre a partire da un’immagine che deve dichiarare tutto il necessario affinché esso possa venire eseguito.

Partire sempre dalla stessa immagine, significa partire sempre dalla stessa condizione iniziale. Di riflesso, non ci saranno problemi di configurazione poiché già affrontati in fase di configurazione dell’immagine.

Se decidiamo di affidare l’immagine all’infrastruttura di Docker, ci togliamo anche il problema di garantirne la fruibilità. Per fare ciò docker usa una sorta di repository di immagini chiamato Docker Registry. Se affidiamo le nostre immagini a questo servizio, una volta caricata l’immagine con il tag di versione, sarà poi il registry a distribuire l’immagine per noi.

Nel caso appena descritto, la nostra responsabilità sta nella costruzione dell’immagine e nel corretto funzionamento del container una volta in esecuzione sul server. tutto ciò che sta nel mezzo è sotto la responsabilità di Docker.

Questo, di riflesso, fa si che un utilizzatore possa usare un immagine così com’è senza preoccuparsi dei dettagli implementativi, basta che venga utilizzata in conformità all’architettura.

Vedremo anche questo in dettaglio, tuttavia un container disegnato per eseguire in ambiente x86_64 non funzionerà in ambiente ARM. Questo perché non si tratta di una macchina virtuale ma di un processo in esecuzione sull’host nel quale è in esecuzione il demone di Docker

Che cos’è un container?

Quando ci si approccia a Docker, ci si aspetta di avere a che fare con i container dal primo momento. Ed in qualche modo è così.

Ma è troppo presto, non si può definire dettagliatamente il concetto di container senza sapere cosa sia un’immagine.

—
Prosegui su: Introduzione sulle immagini

Immagine: lifeforstock – it.freepik.com

L'articolo Cos’è Docker? Perché usarlo? proviene da Docker Tutorial.

Per ora, quando parliamo di un’immagine, parliamo di una configurazione che determina come deve essere fatto il sistema che andrà eseguito.

Facendo un parallelo con la programmazione ad oggetti, possiamo trattare l’immagine alla stregua di una classe ed i container eseguiti su di essa alla stregua di oggetti.

Microservizi

Questa soluzione si sposa alla perfezione con l’approccio a Microservizi.

Ogni immagine specifica come deve essere fatto il servizio che rappresenta, mentre ogni container è esattamente un’istanza di quel servizio.

In caso di sovraccarico o carenza di risorse di un container, andremo ad istanziare un altro servizio. Con le stesse caratteristiche. Dalla stessa immagine.

—
Prosegui su: Cosa c’era prima

Immagine: Acqua foto creata da wirestock – it.freepik.com

L'articolo Introduzione sulle Immagini proviene da Docker Tutorial.

Rispondere a questa domanda senza generalizzare troppo è molto difficile.
Tuttavia, semplificando, possiamo racchiudere tutto in due macro-categorie: Macchine Fisiche e Macchine Virtuali.

Macchine Fisiche

Come tutte le soluzioni, presentano sia pro sia contro.
Dato che stiamo parlando do Docker, mi limito a esplicitare i problemi che hanno spinto a trovare una soluzione in tale direzione.

• Dimensionate con una stima, spesso difficile da eseguire
• Costi Elevati
• Difficoltà a scalare
• Difficoltà a replicare il codice in altre macchine
• Difficoltà di monitoraggio delle risorse in modo centralizzato
• Tempistiche d’intervento molto lunghe in caso di failure

I punti trovano riscontro in diversi aspetti. Il primo che mi viene in mente è un servizio con picchi di utenza e lunghi periodi di carico basso.

Con in sistema a macchine fisiche (Bare-Metal) l’unica soluzione è avere in dotazione l’infrastruttura necessaria alla gestione dell’intero carico. Pagando per la gestione della stessa ed il costo di mantenimento in servizio anche nei periodi in cui l’utilizzo è ridotto.

A questo aspetto si somma anche l’esattezza della stima di massimo carico che, se errata, rischia anche di rendere il costoso sistema inadeguato al carico.

Con Docker si può risolvere, attraverso i Command Line Tool, la problematica della decentralizzazione delle risorse. Vi è un sistema infatti che permette di vedere in modo centralizzato, lo stato di tutte le risorse in ogni momento.

E in caso di failure?

In un ambiente di questo tipo, un problema ad una macchina determina una procedura risolutiva piuttosto lunga. Innanzitutto capire di quale macchina si tratta. Poi dobbiamo ripristinare il suo ambiente e solo dopo possiamo tornare operativi.

Con Docker invece sarà sufficiente riavviare il container associando eventualmente la nuova risorsa. Qualora il problema si facesse più grave e coinvolgesse una macchina su cui sta girando Docker, basterà installare Docker su una nuova macchina ed il resto, dopo il deploy dell’infrastruttura, verrà da se.

Macchine Virtuali

Spesso utilizzate per spedire (delivery) delle applicazioni complete.
Di conseguenza, se volessimo trasportare l’approccio a microservizi alle macchine virtuali, dovremmo avere una macchina virtuale per ogni servizio.

Per ogni macchina virtuale dovrei gestire singolarmente sistema operativo, ram, disco, processori, visibilità di rete.

Non è sicuramente la miglior soluzione possibile.

Prendiamo ad esempio avere un server Apache con MySql e un reverse proxy NGINX. Una gestione a microservizi si macchine virtuali richiederebbe tre sistemi operativi, magari anche della stessa versione.

È proprio qui che emerge il reale vantaggio di utilizzare Docker.

Quello che succede è che vengono creati dei container. I container sono una sorta di sandbox, e dialogano con l’esterno con delle modalità che approfondiremo quando parleremo di Network e di apertura delle porte nei container.

—
Prosegui su: Container su Windows e Mac

Immagine: photoangel – it.freepik.com

L'articolo Cosa c’era prima? proviene da Docker Tutorial.

Sebbene Docker sia nato per per la gestione di container Linux, anche microsoft ha deciso di mettere a disposizione degli sviluppatori una tecnologia che permetta di lavorare in un ambiente simile. Stiamo parlando di: “Windows Container“.

Purtroppo è una tecnologia nuova e, nel momento in cui scrivo, solo Windows 10 (Professional o Enterprise a 64 bit) e Windows Server 2016 supportano nativamente questa funzionalità. Per maggiori dettagli e una lista aggiornata delle versioni, vi rimando a questo link.

Nel caso non abbiate a disposizione una di queste versioni di Windows, esiste un’alternativa.

Per le altre versioni di Windows, è possibile utilizzare una Toolbox che predispone l’ambiente su una macchina virtuale creata ad-hoc su VirtualBox. Ne consegue che verrà chiesto di installare l’ambiente di virtualizzazione “Virtual Box” che appesantirà l’esecuzione e brucerà delle risorse, ma per lo sviluppo va benissimo ed è anche gratuito.

Mac

Per quanto riguarda macOs, il supporto ai container non è nativo.

In questo caso è possibile scaricare Docker for Mac che fornisce un pacchetto completo che esegue, anche in questo caso, i container in una macchina virtuale Linux.

—
Prosegui su: Facciamo Chiarezza

Immagine: Albero foto creata da freepik – it.freepik.com

L'articolo Container su Windows e Mac proviene da Docker Tutorial.

1. Docker Inc.
2. Docker Runtime / Docker Orchestration engine
3. 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

Foto creata da mrsiraphol – it.freepik.com

L'articolo Facciamo chiarezza proviene da Docker Tutorial.

In questa sezione approfondiremo quella che è stata l’evoluzione del motore di Docker e delle principali componenti che lo compongono.

È possibile utilizzare Docker ad un buon livello anche senza conoscere nel dettaglio questa tematica. Incoraggio comunque a conoscere anche questo aspetto per avere un idea più chiara di cosa succede a basso livello. A me è tornato utile per risolvere alcuni bug particolarmente insidiosi.

Il motore di Docker, Docker Engine, ha la responsabilità di gestire ed eseguire i container.
Proprio come il motore di un’auto, è composto da componenti specializzate ed intercambiabili ed è aderente, dove possibile, alle specifiche definite da OCI.

I principali componenti che compongono il Docker engine sono: “Docker Client“, “Docker Daemon“, “containerd” e “runc“.

Per quanto riguarda il demone, in particolare, la storia è un po’ travagliata.
All’inizio il demone era monolitico, accorpando quindi molte funzionalità nella stessa codebase.
Esso si serviva di LXC per avere accesso alle principali primitive relative i container presenti nel kernel Linux. Questa dipendenza ha fatto nascere un problema serio: le funzionalità core di Docker erano dipendenti da un servizio di terze parti, LXC, sul quale Docker non aveva nessuna tipologia di controllo.

La soluzione è stata l’implementazione in casa un framework in grado di prendersi in carico le responsabilità che fino a quel momento erano state demandate a LXC. Questo strumento proprietario si chiama libcontainer ed è utilizzato da Docker a partire dalla versione 0.9.
Il modulo libcontainer, oltre al non essere più dipendente da LXC, è anche cross platform, quindi può venire eseguito in diverse piattaforme e non più solo su linux.

Anche il fatto di utilizzare un demone, Docker daemon, monolitico ha portato non poche problematiche, soprattutto alla luce della grande diffusione. Un codice non modulare è per definizione difficile da estendere, correggere e, più in generale, da mantenere.
Preso atto della situazione, Docker Inc. ha iniziato un refactor molto accurato, che per altro è ancora in corso. L’obiettivo è quello di scomporre il demone in moduli più piccoli, che siano specializzati, intercambiabili e soprattutto – manutenibili.

Alcune funzionalità di primo piano sono già state scorporate dal demone, quali container runtime e esecuzione dei container in moduli chiamati rispettivamente runc e containerd. Di questi ultimi parleremo tra pochissimo.

Componenti principali

Prima di spiegarle ad una ad una, cerchiamo di capire come sono in relazione tra loro aiutandoci con la seguente figura. 

CLI

La componete più in alto nella figura rappresenta il client, dove è possibile eseguire comandi della CLI (Command Line Interface) di Docker. Qui il link alla documentazione.

La CLI viene utilizzata per controllare il demone di Docker, il quale si avvale del container supervisor “containerd” per avviare, fermare o sospendere i container.
I container vengono eseguiti all’interno di un container runtime chiamato “runc”.

Per il momento lasciamo un attimo da parte “shim”, ci arriveremo tra un attimo. Per ora è importante che siano chiare le funzionalità a cui assolvono i moduli appena descritti e, dato che ci siamo, cerchiamo di capire qualcosa di più su di essi.

Runc

Runc è l’implementazione del container runtime aderente alle specifiche definite da OCI. 
Si tratta di un modulo standalone che ha il compito di creare container. 

Più in generale si tratta di un’interfaccia a linea di comando per libcontainer.

Containerd

Containerd gestisce invece la logica di esecuzione dei container.

Questo modulo gestisce i container ma non li crea. La loro creazione è gestita mediante l’apposito modulo runc.

Gestisce routine come start, stop, pause, rm, ed alcune altre per le quali vi lascio il link al sito ufficiale.

Come potrete notare dal sito, oltre ai container, containerd gestisce anche alcune funzionalità relative alle immagini. Questo per esigenze dettate da sistemi di Orchestration, Kubernetes in primis.
Containerd è stato sviluppato da Docker Inc. ma è stato donato a CNCF (Cloud Native Computing Foundation).

Shim

Runc crea i container, ma una volta assolto questo compito, esso termina, lasciando il container senza un processo padre.

Per prevenire ciò, viene creato un processo shim per ogni container. Il processo shim diventa il padre del container a cui è riferito.

Alcune delle responsabilità che assume inerenti al processo riferito container figlio sono, Gestione degli stream di IO e notifica degli eventi ad esso pertinenti al demone.

—
Prosegui su: Container – Le basi

Immagine: mrsiraphol – it.freepik.com

L'articolo Il motore proviene da Docker Tutorial.

In questa sezione ci faremo un’idea di base del funzionamento di un container, in modo da avere gli strumenti minimi per affrontare il prossimo capitolo.

Faccio una premessa, io sono solito utilizzare il client per mac. I comandi sono gli stessi per tutti i sistemi operativi, tuttavia può capitare che qualche immagine non sia compatibile con alcuni sistemi operativi o architetture. Questo risulterà più chiaro nel prossimo capitolo ed in particolare quando parleremo di immagini ad architettura multipla e di manifest.

Lanciare il primo container

Iniziamo con l’istruzione di base, quella che permette di creare un container a partire da un immagine, ovvero:

docker container run

L’istruzione “docker container run”, istanzia un container a partire da una specifica immagine.

Coma da tradizione, quando si inizia a prendere confidenza con una nuova tecnologia, si comincia sempre con un “Hello world”. Guarda caso esiste proprio un’immagine che si chiama “hello-world”.

Eseguiamo quindi il comando

docker container run hello-world

Nel mio caso, l’output generato è il seguente:

Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
0e03bdcc26d7: Pull complete 
Digest: sha256:8e3114318a995a1ee497790535e7b88365222a21771ae7e53687ad76563e8e76
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

Interpretazione dell’output

Le prime righe dell’output prodotto dal run sono particolarmente interessanti perché ci permettono di intuire cosa sta succedendo under-the-hood.

Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
0e03bdcc26d7: Pull complete
Digest: sha256:8e3114318a995a1ee497790535e7b88365222a21771ae7e53687ad76563e8e76
Status: Downloaded newer image for hello-world:latest

Come prima cosa vediamo che Docker cerca di recuperare l’immagine richiesta da un repository locale all’host, ma senza avere successo.
Per ora tralasciamo la stringa “:latest”, avremo modo di parlarne molto presto.
Dal momento che abbiamo richiesto un’immagine che non abbiamo mai scaricato prima d’ora, essa viene recuperata dal docker daemon, come vediamo dalla seconda riga.

Subito dopo viene indicato l’esito del pull dell’immagine, l’hash a 256 bit ottenuto mediante l’algoritmo di encryption sha256 e la conferma di avvenuto download.

Tutto ciò che segue è l’output del container che il demone di Docker inoltra al client a sua volta scrive sullo standard output.

Visualizzare i container

Abbiamo creato un container, ora verifichiamo i dettagli mediante il comando che fornisce la lista dei container presenti sul nostro host:

docker container ls

Eseguendo questa istruzione, però, ci accorgiamo di qualcosa di strano. La lista non mostra nessun container relativo all’immagine “hello-world”.

Com’è possibile?
Eppure lo abbiamo creato! Abbiamo anche visto l’output!

Quando abbiamo di questi dubbi, la soluzione più efficace è quella di utilizzare l’help del comando.

docker container ls --help

Ottenendo questo output

Usage:	docker container ls [OPTIONS]

List containers

Aliases:
  ls, ps, list

Options:
  -a, --all             Show all containers (default shows just running)
  -f, --filter filter   Filter output based on conditions provided
      --format string   Pretty-print containers using a Go template
  -n, --last int        Show n last created containers (includes all states) (default -1)
  -l, --latest          Show the latest created container (includes all states)
      --no-trunc        Don't truncate output
  -q, --quiet           Only display numeric IDs
  -s, --size            Display total file sizes

Ecco svelato il problema!
Eseguendo il comando nella versione di default, ovvero senza flag aggiuntivi, vengono mostrati solo i container in esecuzione.
Questo significa che il container che abbiamo appena creato non è più in esecuzione. Nel caso specifico, hello-world termina dopo aver stampato un messaggio.

Per vedere tutti i container, compresi quelli che non sono in esecuzione, dobbiamo aggiungere il flag –all o -a.
La nuova versione del comando diventa quindi:

docker container ls --all

Dalla quale otteniamo un output di questo tipo:

CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS                          PORTS               NAMES
9f0b8fee671c        hello-world         "/hello"            About a minute ago   Exited (0) About a minute ago                       laughing_visvesvaraya

Ora il container che abbiamo generato a partire dall’immagine hello-world è visibile.

Nella colonna status si nota che il container è terminato. Vedremo dettagliatamente questi aspetti nel capitolo dedicato ai container.

Eliminare un container

Sebbene in molti casi può risultare comodo avere accesso ai container terminati, questa volta non ce ne facciamo niente e decidiamo di eliminare il container appena creato.

Per eliminare il container non più in uso dalla lista, il comando è:

docker container rm 

Per container_id si intende il codice identificativo del container visibile nella prima colonna del comando docker container ls. In questo caso, l’istruzione da eseguire sarà:

docker container rm 9f0b8fee671c

In generale, quando viene richiesto di inserire il container id, è sufficiente inserire i primi caratteri dell’hash a condizione che non ci sia un altro container con lo stesso prefisso.

Container rimossi automaticamente

Quando sappiamo già non ci interessa persistere un container una volta terminato, possiamo eseguirlo direttamente con il flag –rm. Questa particolare notazione su occuperà di rimuovere automaticamente il container quando terminerà la sua esecuzione.
Nel caso di hello world avremmo potuto eseguire il comando in questo modo:

docker container run --rm hello-world

Start & Stop vs Pause & Unpause

Spesso si fa confusione tra questi comandi, ma il concetto è molto semplice.
Nel primo caso i container vengono terminati e riavviati. Nel secondo caso vengono “congelati” e “risvegliati”.

Per fermare e riavviare i container si usano:

docker container start
docker container stop

Per sospendere e risvegliare un container, invece si usano:

docker container pause 
docker container unpause

I comandi saranno sempre seguiti dal o dai container_id dei container ai quali vogliamo applicare l’istruzione.

Il modo migliore per spiegare cosa cambia tra i due è mediante un esempio. In questo caso ho scelto di utilizzare un’immagine di Alpine Linux sulla quale eseguirò lo start e lo stop di un container.
Pause e unpause hanno la stessa notazione, quindi eviterò di riportarli.

Proviamo con il primo set di comandi, ovvero container start e container stop. Dato che abbiamo imparato che i container possono terminare l’esecuzione appena dopo l’avvio, mettiamo le mani avanti e impostiamo uno sleep di 1000 secondi. In questo modo il container rimarrà in esecuzione per 1000 secondi prima di terminare.

Per impostare lo sleep è sufficiente digitare il comando ‘sleep 1000’ in coda all’istruzione di run.

docker container run alpine sleep 1000

Quando parleremo nel dettaglio di Dockerfile, la modalità con la quale viene invocato questo comando sarà più chiara, per ora immaginate che il comando specificato in coda al comando run, sovrascrive l’ultimo comando che eseguirebbe il container all’avvio.

Ora per 1000 secondi il terminale rimarrà occupato, poi, secondo il normale flusso, il container terminerà rilasciando il terminale.

Apriamo allora un nuovo tab e cerchiamo il nostro container in esecuzione con:

docker container ls

Questa volta vediamo che l container figura nella lista. Nel mio case il container id è ‘61652fca85f0′, quindi per fermare il container mi basterà digitare:

docker container stop 616

Al termine di questa istruzione il container non sarà più in esecuzione, quindi se proviamo a cercarlo con docker container ls non lo troveremo nella lista.

Per visualizzarlo, ci basterà eseguire il comando docker container ls –all, e lo troveremo con stato Exited(137) e non più Exited(0).
Per far ripartire il container, ci basterà eseguire:

docker container start 616

Eseguendo docker container ls vediamo che il container è attivo perché la colonna relativa allo stato riporterà: Up.

Curiosità

Abbiamo assimilato i rudimenti della CLI per quanto riguarda i container.
Dopo aver letto lo scorsa sezione, a qualcuno potrebbe venire la curiosità di sapere cosa succede sotto il cofano quando viene avviato un container.

Se ti riconosci in questa descrizione, le prossime righe sono per te!

Quando lanciamo il comando docker container run, il Client converte l’istruzione in una chiamata POST all’endpoint che il demone di Docker ha predisposto a tale scopo.
Il demone invoca containerd che che chiede a runc di istanziare il container.
runc crea il container e termina, mentre il processo containerd-shim diventerà il nuovo padre del container.

—
Prosegui su: Immagini

Immagine: Viaggio foto creata da freepik – it.freepik.com

L'articolo Container – le basi proviene da Docker Tutorial.

“An Image is an ordered collection of root filesystem changes and the corresponding execution parameters for use within a container runtime.”

Moby Image readme.md v1.2

Tradotto: “Un’immagine è una raccolta ordinata di modifiche al filesystem di root e dei corrispondenti parametri di esecuzione da utilizzare all’interno di un container runtime.”

Mi rendo conto che da questa definizione si possa capire ben poco, cerco di rendere questa definizione più comprensibile.

Un immagine è fondamentalmente un pacchetto che contiene: Codice binario di un’App, dipendenze necessarie, Metadati e Istruzioni su come eseguire l’App.
Fondamentalmente è tutto qui.

L’applicazione verrà eseguita in un container, come processo dell’host. Questo significa che il kernel su cui gira il container creato a partire da questa immagine, è quello dell’host.

Le immagini e l’host condividono il kernel.

Un immagine può tuttavia utilizzare un Sistema Operativo diverso dall’host purché condividano il kernel, ad esempio potrei avere un host RedHat ed un container Ubuntu che condividono il kernel linux.

Spesso le immagini contengono svariate utility dei sistemi operativi di cui fanno parte, fornendo un ambiente il più completo o specializzato possibile. Questo determina inesorabilmente un aumento della loro dimensione. Un esempio è l’immagine di Ubuntu.
Di contro, possono essere anche molto scarne, privilegiando la leggerezza e lasciando agli utilizzatori l’onere di aggiungere i pacchetti necessari. Un esempio di questa categoria è Alpine.

—
Prosegui su: Com’è fatta un’immagine

Immagine: eberhard9 – it.freepik.com

L'articolo Cos’è un’immagine? proviene da Docker Tutorial.

L’insieme ordinato dei layer, costituisce il singolo oggetto immagine. 

Questa struttura ha numerosi vantaggi; Il principale è che i layer sono riusabili. 

Ad esempio, se più immagini sono costruite a partire da un’immagine della stessa versione di Ubuntu, Docker non scaricherà ogni volta una nuova copia di tale immagine ma userà la stessa per costruire tutte le immagini coinvolte.

Come funziona la condivisione dei layer?

Alla prima richiesta l’immagine di partenza verrà scaricata, alle successive sarà recuperata dal repository locale dell’host. Per “repository locale dell’host” intendo il sistema che colleziona e organizza le immagini presenti sul device che sta scaricando le immagini.

A seconda delle dipendenze la dimensione di un’immagine può variare di molto. Si può variare da pochi KiloByte a svariati GigaByte.

E’ anche possibile creare un’immagine a partire da un container, facendone una sorta di fotografia. Per fare ciò si usa il comando docker container commit.
Va detto però che è un caso che trova applicazione solo in contesti particolari.

Per chi come me si occupa di sviluppare software, penso possa essere utile fare un parallelo (per cercare di dare un’idea, non una definizione). Pensate alle immagini come a delle classi e i container come degli oggetti, ovvero delle immagini istanziate.

In realtà anche le immagini vengono costruite, producendo un binario, ma questo avviene build-time. I container invece vengono costruiti run-time.

—
Prosegui su: Cosa succede quando scarichiamo un’immagine

Immagine: Legno foto creata da wirestock – it.freepik.com

L'articolo Com’è fatta un’immagine? proviene da Docker Tutorial.

Quando scarichiamo un’immagine, ne specifichiamo solo il nome ed in alcuni casi il tag identificativo. Questo può far pensare di aver a che fare con un oggetto unico.

Nella sezione “Com’è fatta un’immagine” abbiamo visto che non è così, siamo a conoscenza del fatto che esiste un meccanismo che compone le immagini per layer successivi.

Tuttavia vale la pene vederlo con i nostri occhi scaricando due release consecutive della stessa immagine. Facciamo un esempio con redis basato su Alpine:

docker image pull redis:5-alpine

ottenendo questo output:

5-alpine: Pulling from library/redis
cbdbe7a5bc2a: Already exists 
dc0373118a0d: Pull complete 
cfd369fe6256: Pull complete 
3e45770272d9: Pull complete 
558de8ea3153: Pull complete 
a2c652551612: Pull complete 
Digest: sha256:83a3af36d5e57f2901b4783c313720e5fa3ecf0424ba86ad9775e06a9a5e35d0
Status: Downloaded newer image for redis:5-alpine
docker.io/library/redis:5-alpine

Già da qui notiamo che vengono scaricati più frammenti e non un blocco unico. Qualcosa dovrebbe già farci sospettare che l’ipotesi dell’immagine a blocco unico comincia a scricchiolare.
Possiamo inoltre vedere già il primo esempio di riuso (dalla riga “cbdbe7a5bc2a: Already exists”). Dato che stiamo utilizzando le versioni Alpine, probabilmente stiamo riutilizzando il layer del kernel Alpine da un’immagine scaricata in precedenza (qui).
Scarichiamo ora la versione 6-alpine con:

docker image pull redis:6-alpine

ottenendo questo output:

6-alpine: Pulling from library/redis
cbdbe7a5bc2a: Already exists 
dc0373118a0d: Already exists 
cfd369fe6256: Already exists 
e5396613619b: Pull complete 
6809b5ad2cd4: Pull complete 
386ecfe54d06: Pull complete 
Digest: sha256:2586f31f74ac1d7dc6f6c7eabca42f09bba5ec9911fc519d55fbd7508a9c4f01
Status: Downloaded newer image for redis:6-alpine
docker.io/library/redis:6-alpine

Qui il riuso diventa evidente. Alcuni “frammenti” della seconda immagine sono stati recuperati dalla cache del repository locale.

C’è da dire che un utilizzatore di Docker alle prime armi, avrebbe potuto lanciare diversi container senza essere consapevole di tale aspetto. Docker rende tale aspetto assolutamente trasparente, ma è indispensabile conoscerlo per evitare situazioni spiacevoli.

Come vengono aggregati i layer?

L’aggregazione dei livelli (layer) avviene mediante il concetto di Union File System.

Mi piacerebbe andare più a fondo sulla questione (parlando di aufs, overlay2, ecc), ma non vorrei andare troppo fuori tema.

Quello che dobbiamo portarci a casa è che ogni layer può aggiungere file, cartelle o metadati al prodotto dei layer precedenti. 

I layer vengono applicati uno alla volta, in ordine. Al termine dell’applicazione di un layer X, la struttura file risultante sarà la fusione di tutte le modifiche apportate da tutti i layer precedenti e dal layer X. 

Per il container, la struttura file su cui si poggia può essere intesa come un’entità singola.

—
Prosegui su: Analizzare la struttura di un’immagine

Immagine: Viaggio foto creata da freepik – it.freepik.com

L'articolo Cosa succede quando scarichiamo un’immagine proviene da Docker Tutorial.