Docker e la nuova separazione dei servizi

Se c'è una cosa che mi piace, nell'ambito informatico, è il trovare nuove soluzioni a vecchi problemi. O nuovi problemi a vecchie soluzioni, ma allo scopo di risolvere eventuali punti lasciati in sospeso da tempo, per mancanza di tempo o per mancanza di soluzioni a disposizione.

Una delle questioni più annose, per chi lavora nel settore (ma non solo) è sempre la vecchia scelta operativa: accentrare i servizi su un server o separarli il più possibile?

Alla domanda non esiste una risposta semplice. Dipende dalle risorse a disposizione, da come uno è abituato a gestire e, nel complesso, da quanto tempo si avrà poi per fare la manutenzione del tutto. Più semplice (e più rischioso) fare manutenzione o aggiornamenti ad un singolo server piuttosto che ad uno stuolo di macchine più piccole.

La mia filosofia, per quanto possibile, è sempre stata similare al concetto principale dei sistemi Unix: K.I.S.S. (ovvero Keep It Simple and Stupid), separazione massima per ottimizzare la resa e frammentare eventuali criticità future. Già nei primi anni 2000 utilizzavo OpenVZ e, successivamente, lxc anche su piccoli server Atom domestici per tenere tutto separato. Un container come file server, un altro come mail server, un altro come media server, un altro come backup server, ecc. Il vantaggio è sempre stato quello di separare il più possibile i servizi e ridurre le possibilità di guai in caso di aggiornamenti fasulli o, peggio, compromissione di una delle macchine.

Ho per questo osservato con interesse (e ne ho già scritto in passato) l'avvento di Docker, anche se inizialmente non ho avuto un grosso impatto emotivo. Non mi piaceva o, per lo meno, lo reputavo estremamente immaturo. Tutto è corso e il risultato è che oggi, finalmente, riesco ad avere la separazione che ho tanto sognato. Non più una macchina virtuale per servizio, ma un contenitore per servizio, con tutte le sue dipendenze all'interno. Un overhead inferiore, un risultato equivalente.

Questo approccio, apparentemente complesso, rende in realtà semplicissima la gestione successiva delle risorse. Non dovendomi preoccupare di non incrociare dipendenze, librerie, distribuzioni, servizi, ecc., sarà semplicemente necessario sapere quali sono le richieste di un contenitore ed, eventualmente, collegarlo ad un altro. Stop, il risultato è presto detto: servizio attivo, isolato, aggiornabile, sicuro. E, non da sottovalutare, migrabile da un server all'altro senza particolari problemi.

Mi è recentemente capitato di dover installare un sito che necessitasse di mysql 5.7 su un server con mysql 5.5. Aggiornare il secondo non l'ho neanche preso in considerazione (preferisco restare fedele ai repository ufficiali della distribuzione), far andare il primo su una versione più vecchia sarebbe stato un hack sporco e inaffidabile. Risultato: ho tirato su un bel container con mysql 5.7 e fatto puntare ad esso il CMS. Ho inoltre potuto installare un bel PhpMyAdmin solo per esso e il tutto è stabile e aggiornabile.

Uno dei vantaggi, inoltre, del setup docker-style è quello di non dover perdere più troppo tempo con la macchina da installare. Il sistema operativo del server che farà girare Docker, infatti, servirà ad interfacciarsi con l'hardware (fisico o virtuale) e a gestire gli eventuali backup. Il risultato è presto detto: semplicità di gestione in quanto il centro del tutto non è più il server, fisico o virtuale, ma il singolo servizio.