Cos’è Docker?

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