Riprendiamo alcuni concetti dal post precedente. Nell’ultima parte, per amore di sintesi, sono stato arido di dettagli nel rispondere alla Domanda: “Quando usare Docker?”.
Per cercare di essere più esplicito, qui di seguito descriverò casi in cui adottare Docker da vantaggi e contro-esempi dove l’uso dei container è peggiorativo o impossibile. Per semplificare l’esposizione classifico i casi parafrasando il t-shirt sizing usato nelle board kanban, cioè andando da problemi small (S) a problemi extra-large (XL).
Problemi S: lo studio di un DBMS come MySQL o MongoDB, l’uso di un tool di building complesso come Maven. Sono strutture chiuse, usate in casi con basse necessità di performance e che non devono essere sempre accessibili come dei servizi. Docker e i Docker Toolbox consentono di fare rapidi deploy, shutdown e remove senza “sporcare” il sistema operativo del proprio pc, usando un hypervisor installato localmente. Al contrario, ambienti che richiedono una GUI per funzionale, Eclipse ad esempio, richiedono un lavoro di setup eccessivo, se confrontato con quello necessario per una VM con sistema operativo desktop a bordo.
Problemi M: rimanendo confinati all’interno della propria workstation, cresciamo verso strutture più complesse rispetto l’architettura a container singolo degli (S). Sono: i fullstack come: LAMP, MEAN e MERN; gli application server come: Tomcat o JBoss e le applicazioni web a più servizi come WordPress. Con Docker è facile costruire aggregazioni di singoli container con cui comporre lo stack richiesto, arricchirlo con dati di test e distribuirlo ai developer senza troppi “sbattimenti”. Anche in questo caso GUI o dati di test superiori al GByte rendono più vantaggiose le VM rispetto i container.
Problemi L: passiamo a strutture multi-host. Un buon esempio è la scomposizione di un’architettura monolitica costruita da un host fisico per il server web e un host fisico per il DBMS che con: virtual-host, db e utenti eroga 5, 10, n applicazioni web distinte. Scomponendo e riorganizzando i monoliti in stack di container per singola applicazione, aumentiamo: velocità ed efficacia dei backup e ripristini e l’efficienza nell’uso delle risorse. Un’altro effetto ottenibile è l’espandere orizzontalmente l’architettura, usando nodi meno performanti e più economici per costo e consumo, aumentando contemporaneamente la ridondanza della struttura. Di contro perdiamo la possibilità di avere punti centralizzati da cui ricavare metriche o generare informazioni. In alcuni casi, la presenza di una business-logic integrata e trasversale ai vari repository complica a tal punto l’approccio a containers da impedirne l’uso.
Problemi XL: aggiunge il rapporto tra l’on-premise ed il cloud, oltre il disaster recovery. Mettere a riparo da eventi disastrosi un’infrastruttura complessa e pesante non è semplice. Scomporla in blocchi singoli riduce la quantità di MByte da sincronizzare tra due site, seguendo la filosofia del comando rsync o di robocopy, con cui replichiamo solo gli elementi modificati nelle cartelle del fileserver. Anche per questa classe di problemi, come nelle precedenti, avere dei boundary contents aiuta molto nella migrazione verso architetture basate sui containers, grazie alle proprietà di isolation di cui essi dispongono. Torniamo al caso di MySAP, accennato nell’articolo precedente. Se tutta o una parte della logica è trasversale, rispetto i confini che dividono i dati e le applicazioni, essa “rompe” il concetto di comunicazione esclusiva attraverso interfacce TCP. Così l’architettura non è dockerizzabile, a meno di costosi e complessi refactoring dell’applicazione e nell’organizzazione dei dati. In parole povere, il gioco non vale la candela, mentre rimane più vantaggioso il classico backup “a caldo” spedendo poi il supporto all’altro site.
Visti capitelli, curve e forme scolpibili; iniziamo a maneggiare gli scalpelli nel nostro toolbox, per capire come possiamo sbozzare il blocco di marmo a nostra disposizione. Docker Toolbox è una raccolta di strumenti messi a disposizione per renderci la vita più facile, su piattaforme Windows e OSX.
Gli strumenti principali che prendiamo in considerazione sono: docker, docker-machine e docker-compose.
Docker Engine: il comando docker, è la command-line-interface che permette di pilotare un docker-host locale o remoto attraverso chiamate ad API remote via HTTPS. Con essa: creiamo, distruggiamo, manipoliamo i containers e le immagini presenti in un docker-host.
Docker-machine: gestisce il docker-host. Crea, distrugge o consente l’accesso al nodo su cui gira il daemon docker. Tramite una serie di driver d’interfaccia verso soluzioni cloud e on-premises come: Microsoft Azure, Hyper-V, Parallel, VirtualBox, AWS. Docker-machine svolge il “lavoro sporco” nell’installare il nodo ed aiuta a focalizzare velocemente l’attenzione della Docker Engine verso un altro docker-host.
Docker-compose: assembla lo stack di container, realizzando soluzioni composite che sarebbe scomodo assemblare tramite docker. Grazie a ricette scritte in .yml, docker-machine scarica e collega tramite pipe TCP o mount-point i vari container; fra loro e al docker-host su cui è running il docker composto.
In fondo alla cassetta, ancora in beta, rimane Kitematic. E’ una GUI con cui gestire le proprie soluzioni locali e il collegamento autenticato con il docker-hub pubblico, il repository contenente le immagini da scaricare, già pronte e messe a disposizione da sviluppatori e volontari.
Nel prossimo articolo affronteremo in modo articolato Docker Engine così da eseguire e costruire containers ed immagini, prendendo confidenza pratica con questa nuova tecnologia.