Capire Docker

Prima di vedere come installare Docker, iniziamo col capire quali problemi questa tecnologia intende risolvere.

Sviluppatori

L’azienda che ha creato Docker, ha sempre descritto il programma come la soluzione al problema del “sul mio computer funziona”.

Questo problema è stato perfettamente riassunto da un’immagine basata sul meme della Disaster Girl, con la didascalia:
“Funzionava in sviluppo, ora è un problema dell’operatore” — un’immagine che ha iniziato a comparire in presentazioni, forum e canali Slack qualche anno fa.

Anche se fa sorridere, rappresenta un problema fin troppo reale.

Il problema

Anche in un mondo in cui si seguono le migliori pratiche DevOps, è ancora fin troppo facile che l’ambiente di lavoro di uno sviluppatore non corrisponda a quello reale di produzione.

Ad esempio, uno sviluppatore che utilizza la versione macOS di PHP probabilmente non avrà esattamente la stessa versione del PHP installata sul server Linux che ospita il codice in produzione.

E anche se le versioni coincidono, bisogna comunque affrontare differenze nella configurazione e nell’ambiente in cui PHP viene eseguito.

Un esempio concreto? La gestione dei permessi sui file, che varia notevolmente tra sistemi operativi.

Tutto questo porta a un punto critico: quando arriva il momento di distribuire il codice sul server… e non funziona.

Allora ci si chiede:

• Dovremmo configurare l’ambiente di produzione per farlo somigliare a quello dello sviluppatore?

• Oppure gli sviluppatori dovrebbero lavorare solo su ambienti che rispecchiano quelli di produzione?

In un mondo ideale, tutto dovrebbe essere coerente, dal laptop dello sviluppatore fino ai server di produzione.

Tuttavia, questa utopia è sempre stata difficile da realizzare. Ognuno ha il proprio modo di lavorare e le proprie preferenze personali — mantenere la coerenza tra diverse piattaforme è già difficile con un solo ingegnere, figuriamoci con un team di ingegneri e centinaia di sviluppatori.

La Soluzione di Docker

Utilizzando Docker per Mac o Docker per Windows, uno sviluppatore può impacchettare rapidamente il proprio codice in un container, definito autonomamente o creato tramite un Dockerfile, magari in collaborazione con un sysadmin o con il team operativo.

Gli sviluppatori possono continuare a usare il loro ambiente di sviluppo preferito (IDE) e mantenere intatto il proprio flusso di lavoro quotidiano mentre lavorano sul codice.

Installare e utilizzare Docker non è complicato; anzi, considerando quanto fosse faticoso in passato mantenere ambienti coerenti, anche con l’automazione, Docker sembra quasi troppo facile da usare — quasi come barare.

Operatori

Immagina di occuparti della gestione di cinque server: tre server web bilanciati (load-balanced) e due server database in configurazione master/slave, dedicati all’esecuzione dell’Applicazione 1.

Stai usando strumenti come Puppet o Chef per gestire automaticamente lo stack software e la configurazione su questi cinque server.

Tutto va alla grande… finché non ti viene detto che bisogna distribuire anche l’Applicazione 2 sugli stessi server che già eseguono l’Applicazione 1.

A prima vista, non sembra un problema: puoi modificare la configurazione di Puppet o Chef per aggiungere nuovi utenti, configurare virtual host, scaricare il codice aggiornato, ecc.

Ma ecco l’inghippo:
l’Applicazione 2 richiede una versione più recente dello stack software rispetto a quella attualmente utilizzata per l’Applicazione 1.

E peggio ancora:

• L’Applicazione 1 rifiuta categoricamente di funzionare con la nuova versione,

• L’Applicazione 2 non è compatibile all’indietro con quella vecchia.

A questo punto, ti restano solo opzioni problematiche, nessuna delle quali è davvero soddisfacente:

• Chiedere altri server?
  È probabilmente la scelta tecnicamente più sicura, ma non è detto che ci sia budget disponibile per nuove risorse.

• Riprogettare l’architettura?
  Potresti estrarre uno dei server web e uno dei database dal bilanciamento o dalla replica, e riconfigurarli per l’Applicazione 2.
  Tuttavia, così facendo introduci punti singoli di guasto per l’Applicazione 2, e riduci la ridondanza per l’Applicazione 1 – che era probabilmente il motivo per cui avevi tre server web e due database fin dall’inizio.

• Installare i due stack software affiancati sugli stessi server?
  È tecnicamente possibile, e potrebbe sembrare una soluzione veloce per far partire il progetto.
  Ma rischi di creare un castello di carte, che potrebbe crollare alla prima patch critica di sicurezza necessaria per uno dei due stack.

La Soluzione di Docker

Ed è proprio qui che Docker dà il meglio di sé.

Se l’Applicazione 1 è in esecuzione sui tuoi tre server web all’interno di container, potresti già non avere solo tre container attivi — magari ne hai sei, raddoppiando i container per supportare deployment progressivi (rolling deployments) senza mai interrompere la disponibilità dell’applicazione.

In questo contesto, distribuire l’Applicazione 2 è semplice quanto avviare nuovi container sugli stessi tre host, e poi indirizzare il traffico verso la nuova applicazione tramite il bilanciatore di carico (load balancer).

Dal momento che stai lavorando con container, non devi più preoccuparti della complessità legata al deploy, alla configurazione o alla gestione di due versioni dello stesso stack software sullo stesso server.

Con Docker, tutto questo viene astratto e isolato, permettendoti di gestire facilmente più ambienti e versioni sullo stesso hardware.

Enterprise

Le aziende affrontano gli stessi problemi di sviluppatori e operatori, dal momento che impiegano entrambe le figure professionali —
con la differenza che lo fanno su una scala molto più ampia, e con molti più rischi in gioco.

Il problema

A causa del rischio e del fatto che ogni downtime può comportare perdite di vendite o danni alla reputazione, le imprese devono testare ogni distribuzione prima che venga rilasciata.

Questo significa che nuove funzionalità e correzioni rimangono bloccate in una sorta di limbo finché non vengono completati tutti i seguenti passaggi:

• Vengono create e configurate nuove ambienti di test;

• Le applicazioni vengono distribuite su questi nuovi ambienti;

• Si eseguono i piani di test, e si apportano modifiche all’applicazione o alla configurazione fino a quando tutti i test vengono superati;

• Vengono scritte, presentate e discusse le richieste di modifica (RFC) per distribuire l’aggiornamento in produzione.

Questo processo può durare da qualche giorno a diverse settimane, o perfino mesi, a seconda della complessità dell’applicazione e del livello di rischio introdotto dal cambiamento.

Sebbene il processo sia necessario per garantire continuità e disponibilità a livello tecnologico, può in realtà creare un nuovo tipo di rischio a livello di business.

Che succede se una nuova funzionalità rimane bloccata in questo “limbo” e un concorrente rilascia la stessa (o peggio, una versione migliore) prima? Uno scenario del genere potrebbe danneggiare vendite e reputazione tanto quanto il downtime che l’intero processo cercava di prevenire.

La Soluzione Docker

Docker non elimina la necessità di un processo come quello appena descritto, né suggerisce che si possa fare a meno di seguirlo.

Tuttavia, come abbiamo già accennato, rende tutto molto più semplice perché si lavora già con un ambiente coerente e uniforme. Gli sviluppatori stanno lavorando con la stessa configurazione di container che verrà eseguita in produzione.

Questo significa che non serve fare grossi salti per applicare questa metodologia anche alla fase di testing.

Quando uno sviluppatore effettua il commit del proprio codice, sapendo che funziona sul suo ambiente locale (perché lì ha fatto tutti i test), lo strumento di test può lanciare gli stessi container per eseguire i test automatici.

Una volta conclusi, i container possono essere eliminati per liberare risorse e far spazio ai test successivi. Il risultato?

• Il processo di test diventa molto più flessibile;

• Si può riutilizzare lo stesso ambiente invece di reinstallare o riconfigurare server ogni volta;

• Il flusso può essere ottimizzato fino al punto in cui i container dell’applicazione vengono distribuiti direttamente in produzione.

Più rapidamente si riesce a completare questo ciclo, più velocemente si possono lanciare nuove funzionalità o correzioni, mantenendosi un passo avanti rispetto alla concorrenza.

Ora abbiamo un quadro chiaro di quali problemi Docker può risolvere.