Container vuol dire Docker, giusto? A guardare implementazioni pratiche, siti di settore e documentazione dei vendor sembrerebbe decisamente di sì, ma in realtà questa visione è la fotografia di sviluppi relativamente recenti. Docker è un progetto che prende le mosse da una tecnologia di virtualizzazione che esisteva già da diverso tempo ed era integrata in Linux, tanto che senza troppa originalità si chiamava – e si chiama ancora – LXC, ossia Linux Containers.
La concezione di base di LXC è ovviamente analoga a quella che conosciamo di Docker: adottare la virtualizzazione per arrivare a eseguire più istanze isolate di Linux “dentro” un unico sistema host, sempre basato su Linux e puntando sulla sicurezza di cgroup e namespace. Da questa breve descrizione si intuisce già una prima differenza tra le due tecnologie, sottile ma importante. Da un lato (LXC) si parla di sistemi Linux virtualizzati, dall’altro di applicazioni.
È il motivo principale per cui si sente molto più parlare di Docker che non di LXC. L’approccio della prima tecnologia è molto più “specializzato” e questo ha portato in definitiva più flessibilità di utilizzo. Ma ha anche portato una distinzione man mano sempre più netta fra le due tecnologie, per cui non è detto che una sia sempre la migliore. I principali punti di distinzione sono in definitiva tre, se consideriamo i modelli concettuali originali.
La gestione dei processi
Nel modello di Docker un container è un singolo processo. Se la nostra applicazione ha bisogno di far girare contemporaneamente più processi – ad esempio un web server e il database che lo supporta – allora dobbiamo attivare altrettanti container, uno per supportare ciascun processo. Un container LXC non ha questo limite e può attivare più processi.
Seguendo la logica attuale delle applicazioni scomposte in microservizi, la concezione di Docker in realtà non è un limite e può addirittura essere un vantaggio. C’è una stretta parentela concettuale tra container e microservizi, più in generale avere container specifici per processi distinti permette spesso più efficienza. Ad esempio diventa possibile bloccare un processo e modificarlo senza disattivare anche gli altri.
L’approccio stateless
I container Docker sono per definizione stateless, l’approccio di LXC non è così drastico. È vero che nel tempo sono nati diversi progetti open source e commerciali per offrire container Docker più o meno stateful, l’impostazione teorica però è stateless.
Qui il punto principale è che Docker (estensioni e sviluppi paralleli a parte) non supporta forme di storage persistente proprio, permette solo di montare volumi che sono parti dello storage dell’host (quindi elementi esterni al container). E senza storage dove salvare dati, un container non può mantenere un suo stato.
Altro punto: l’istanza di un container viene generata a partire da una immagine che non è modificabile, quindi tutti i container che nascono da quell’immagine sono uguali. Questo ovviamente non vuol dire che in fase di runtime tutti i processi di quei container evolveranno allo stesso modo, solo che l’evoluzione di uno specifico container viene persa alla sua chiusura.
Docker prevede una operazione di commit che genera una nuova immagine di un container proprio a partire dal suo stato in runtime, ma si tratta appunto di una immagine diversa da quella originale.
La portabilità
Il livello di astrazione di Docker è molto più elevato di quello di LXC, quindi un’applicazione containerizzata con Docker è effettivamente indipendente dalla configurazione sottostante dell’host per quanto riguarda i componenti hardware e software. Questo permette di spostare senza problemi un container in esecuzione dall’ambiente Docker di un host a quello di un host anche molto diverso. Fintanto che si passa “da Docker a Docker”, tutto funziona.
Con LXC questa flessibilità non è garantita. Il passaggio da un host (ad esempio il server di sviluppo) a un altro (il server di produzione o anche un ambiente cloud) non è scontato che accada senza problemi. E se questi si verificano bisogna capire quale differenza fra i due host impedisce al container di operare, una operazione spesso tutt’altro che banale.
