Abbiamo ridotto i tempi di deployment in ambienti multipli di un fattore 10 grazie all’utilizzo di Docker, risparmiando inoltre due posizioni di personale addetto alle operazioni di manutenzione per un team di 10 persone.

Il mese scorso, il nostro piccolo team di e-commerce SaaS a Singapore è quasi andato in tilt: prima di una grande promozione, abbiamo aggiornato la funzionalità di sincronizzazione degli stock per 3 siti in Southeast Asia. I test locali sono andati bene, ma non appena l’abbiamo implementato sui server cloud in Indonesia, abbiamo riscontrato problemi legati alla mancanza di dipendenze necessarie per il funzionamento del sistema. Due server backend e un operatore di rete hanno dovuto lavorare per 18 ore per risolvere il problema, causando un ritardo di 3 giorni nel piano di esecuzione dei test di stress.

Prima di tutto: cosa significa esattamente il deployment con Docker?

In parole povere, si tratta di impacchettare tutto il codice dell’applicazione, le librerie di cui ha bisogno, i file di configurazione e persino i parametri del kernel del sistema operativo in un “immagine containerizzata” standard. Quello che funziona sul tuo computer locale funziona esattamente allo stesso modo su qualsiasi server che abbia installato il motore Docker.20MB è possibile per un singolo specchio con un tempo di avvio inferiore a 1 secondo.。

Abbiamo utilizzato i rendimenti reali di 3 mesi.

Prima di tutto, il problema degli ambienti non coerenti è stato completamente risolto. In passato, era necessario dedicare molte ore solo per assegnare a ciascun sito una versione diversa di Node.js e i relativi driver di database. Ora, le immagini pronte per l’uso vengono semplicemente caricate nel repository di immagini, e i tre siti possono essere avviati con un solo clic. Il tempo di deployment è diminuito da una media di 4 ore a 24 minuti, e non è più necessario passare la notte per aggiornare le versioni in occasione delle promozioni.

In secondo luogo, l’efficienza nell’utilizzo delle risorse del server è aumentata del doppio. Prima, per ogni sito affittavamo separatamente un server cloud con 2 core (4G), il cui utilizzo della CPU in tempi di inattività era inferiore al 10%. Ora, utilizzando Docker, abbiamo raccolto tutte le applicazioni, i cache e i task programmati dei tre siti su un unico server con 4 core (8G), e le risorse sono sufficienti esattamente.Il costo mensile del server è stato risparmiato direttamente di 620 dollari.Non è una piccola somma per un piccolo team di meno di 10 persone.

Infine, la velocità di espansione è in grado di tenere il passo con il traffico improvviso. Lo scorso Black Friday, abbiamo dovuto aggiungere server in modo temporaneo e ci sono voluti quasi 2 ore per configurare l’ambiente correttamente; quest’anno, 10 minuti prima del picco di traffico, abbiamo avviato 12 copie dei container, riuscendo a gestire un traffico tre volte superiore a quello normale, senza più alcun problema di timeout delle richieste.

Non affrettarti a salire in macchina, abbiamo già superato quei problemi per te.

Il primo problema è che l’immagine creata era troppo ingombrante. All’inizio utilizzavamo direttamente l’immagine completa di Node.js fornita ufficialmente; un’immagine dell’applicazione aveva dimensioni pari a 1.2G, il che richiedeva più di 20 minuti per essere caricata nel repository di immagini all’estero. In seguito abbiamo passato a utilizzare un’immagine basata su Alpine, eliminando tutte le dipendenze non necessarie, e l’immagine finale aveva dimensioni pari a 90MB, il che ha aumentato la velocità di trasmissione di oltre 10 volte.

Il secondo problema è che i dati erano conservati all’interno di un contenitore. All’inizio non ce ne siamo accorti e abbiamo salvato le immagini dei prodotti caricati dagli utenti direttamente nella directory locale del contenitore. Quando il contenitore è stato riavviato, tutte le immagini sono scomparse; abbiamo impiegato un intero giorno per ripristinarle dalla copia di backup. Da allora, tutti i dati persistenti vengono montati nella directory locale del server o nell’object storage, e da allora non abbiamo più avuto problemi.

Il terzo problema è l’assenza di limitazioni sui risorse. All’inizio del lancio, non erano stati imposti limiti massimi per CPU e memoria per i container. Una volta, un bug in un task periodico di un sito ha occupato l’intera CPU del server, causando il blocco di altri due siti. In seguito, sono stati imposti limiti di risorse per ogni container, in modo che anche se un singolo servizio presentasse problemi, questo non influenzasse l’intera rete.

Dovremmo davvero utilizzare Docker? I nostri criteri di valutazione sono molto semplici.

Casi in cui è necessario utilizzarlo: Quando si deve distribuire lo stesso applicazione su più server, si ha la necessità di passare frequentemente tra ambienti di sviluppo, test e produzione, e il team è composto da più di tre persone ognuna con un ambiente di sviluppo diverso, l'uso di Docker aumenta notevolmente l'efficienza.

Casi in cui non dovresti usarlo: Se hai solo un piccolo blog, lo esegui su un solo server e aggiorni il codice solo una volta ogni sei mesi, non c’è assolutamente bisogno di dedicare del tempo all’apprendimento di Docker. È più semplice utilizzare piattaforme come Baota o effettuare il deployment manualmente.

3 consigli concreti per chi inizia per la prima volta

• Le prime 3 volte in cui si creano immagini, è meglio cercare direttamente i migliori template forniti ufficialmente, invece di scrivere il proprio Dockerfile a caso. Questo permette di evitare l’80% dei problemi legati all’ingombro delle immagini e agli errori di autorizzazione.
• All'inizio, non è necessario utilizzare strumenti di orchestrazione complessi come K8s; basta usare Docker Compose per gestire fino a 3 servizi, il che è più che sufficiente.
• Per il repository delle immagini, utilizza i nodi esteri forniti dal provider di cloud: non creartelo da solo, il tempo risparmiato ti permetterà di sviluppare altre funzionalità.

Risposte unificate a comuni piccoli problemi

Domanda: Docker consuma ulteriormente molta risorsa di sistema (performance del server)? Abbiamo effettuato dei test e il calo delle prestazioni è inferiore al 5%, il che è completamente impercettibile per la stragrande maggioranza delle piccole e medie aziende.

Domanda: È possibile migrare le vecchie applicazioni esistenti su Docker? Certo che sì! Abbiamo un progetto PHP vecchio di 3 anni che abbiamo migrato su Docker in soli 2 giorni, il che è molto più veloce che configurare l’ambiente da zero.