Che Docker sia una delle tecnologie più “calde” di questi ultimi anni è oramai appurato, come si può notare anche dalla quantità di notizie che settimanalmente girano intorno a questo progetto.

Molti lo usano per avere velocemente un ambiente di test il più simile alla produzione, altri hanno accelerato ed ottimizzato gli ambienti di produzione grazie all’uso massivo di questa tecnologia (come nel caso di Visa).

Alcuni ricercatori hanno fatto uno studio interessante, facendo uscire un articolo intitolato “How does Docker affect energy consumption? Evaluating workloads in and out of Docker containers” (che potremmo tradurre in “Come Docker affligge il consumo energetico? Valutazione dei carichi di lavoro dentro e fuori i container Docker).

Il professore Abram Hindle, insieme ad un team di colleghi ricercatori, hanno osservato che la comodità di Docker c’è, ma ha dei costi.

This work suggests that there is no free lunch for containerization in terms of energy consumption. Containerization implies a trade-off between energy and maintainability, and it is up to the individuals or teams in charge of deployment to determine which is more costly in their particular scenario.

Questo lavoro suggerisce che la containerizzazione non è completamente gratuita in termini di consumo energetico. I container implicano dei compromessi tra l’energia e la mantenibilità, e sta ai vari team che si occupando del rilascio determinare cos’è più conveniente per il loro particolare scenario

In pratica è stato calcolato il consumo energetico in Watt moltiplicati per il tempo necessario a completare il lavoro, ed è risultato che eseguire lo stesso comando in un ambiente Docker consuma di più rispetto che lanciarlo semplicemente sul sistema.

Se ci fermiamo un attimo a capire le differenze tra un processo qualsiasi ed un processo fatto girare in un container, già salta all’occhio che nell’ultimo caso si aggiunge -seppur minimo- un po’ì di overhead all’operazione:

processo normale
- viene lanciato il processo, lo scheduler del kernel inizia ad occuparsi anche di quello fino al termine della sua esecuzione

processo in un container
- vengono creati i cgroup per definire le risorse per quel processo
- vengono creati diversi namespace (filesystem, network, etc.) specifici per quel processo
- viene lanciato il processo; al termine della sua esecuzione
- vengono distrutti i namespace
- vengono distrutti i cgroup

[giusto per puntualizzare, ho mantenuto la situazione più semplice; è giusto dire che in casi di container multipli alcuni di questi overhead si riducono, ad esempio potrebbe non essere necessario creare e distruggere i namespace per ogni container]

Ora, se pensiamo al fatto che sia i cgroup che i namespace sono feature fornite direttamente dal kernel Linux, possiamo immaginare quanto siano “rapide e leggere” le operazione di creazione e distruzione degli stessi, ma comunque sicuramente stiamo introducendo latenze che -seppur nell’ordine dei microsecondi- in un analisi accurata portano inevitabilmente l’operazione che vogliamo eseguire, nella sua totalità, ad impiegare più tempo; e questo vuol dire, semplicemente, utilizzare più energia.

Se a questo aggiungiamo che per eseguire i container dobbiamo tenere avviato il demone di Docker (che, è stato stimato, in media la sua sola presenza induce una differenza di 2 Watt), allora abbiamo il risultato dei paper: usare Docker costa di più (in termini di risorse energetiche) che non usarlo.

C’è da dire che è sempre stato “pubblicizzato” il fatto che Docker è molto meglio (in termini di overhead generale sul sistema) rispetto alla virtualizzazione, e non rispetto ad un sistema normale; e questa affermazione ancora non è stata smentita.

Alla fine, quello che conta è cosa ci dobbiamo fare: se la necessità è quella di eseguire operazioni molto complesse, il più rapidamente possibile, e riducendo al minimo i costi, forse possiamo fare a meno della comodità che l’ambiente dei container ci porta ed utilizzare i normali processi sul sistema (come abbiamo sempre fatto).

Se quel poco overhead introdotto, invece, risulta nulla confronto la separazione e l’agilità che l’utilizzo di queste soluzioni introducono, allora possiamo continuare a dormire sereni anche se abbiamo uno Swarm od un Kubernetes che lavorano per noi.

A voi la scelta.

Matteo Cappadonna

Utente Linux/Unix da più di 20 anni, cerco sempre di condividere il mio know-how; occasionalmente, litigo con lo sviluppatore di Postfix e risolvo piccoli bug in GNOME. Adoro tutto ciò che può essere automatizzato e reso dinamico, l’HA e l’universo container. Autore dal 2011, provo a condividere quei piccoli tips&tricks che migliorano il lavoro e la giornata.