Qualche giorno fa si è celebrato il 4° compleanno di Docker. Presentato al PyCon 2013 (la conferenza di sviluppatori Python) da Solomon Hykes in una presentazione di 5 minuti, ha scatenato immediatamente lo stupore del pubblico

Ai tempi era poco più che un sistema per lavorare più comodamente sugli LXC (LinuX Container), presenti sulla scena già da tempo (sono stati introdotti nel kernel 2.6.24, ad Agosto del 2008), ma poco utilizzati poichè non propriamente comodi.

Ai temi, Hykes lavorava per dotCloud, un’azienda che si occupava di fornire l’erogazione di servizi PaaS (Platform As A Service). Proprio la necessità di fornire questo servizio cercando il modo migliore per contenere i costi ha portato gli ingegneri a pensare all’utilizzo dei container Linux e, di conseguenza, a sviluppare un metodo per lavorare comodamente con essi. Il tool nato da questa necessità è stato proprio Docker, rilasciato -fortunatamente- come open source.

Fino al 2014 Docker risultava ancora sviluppato, nonostante la sua natura, interamente da dotCloud; durante quell’anno l’azienda cambiò nome in Docker, Inc. e, tutti i rimasugli di dotCloud furono venduti ad una azienda tedesca di nome cloudControl. Questa dichiarò bancarotta l’anno scorso, portando dietro di se la chiusura anche quel che rimaneva di dotCloud; fortunatamente Docker era salvo.

Quell’anno fu quello che segnò una grandissima esplosione nel mondo di Docker: separatasi ha potuto rafforzare la sua offerta (sia commerciale che non), e molte grosse aziende hanno visto un’opportunità in questo mondo. RedHat ha iniziato a costruire una piattaforma per erogare container Docker, Microsoft ha annunciato di lavorare per rendere Docker compatibile con Windows, e orchestrator di container come Kubernetes hanno iniziato a nascere, dando la possibilità di scalare molto bene i container.

Sempre nel 2014 ci fu un grosso cambiamento: Docker abbandonò i container Linux in favore di libcontainer, un runtime dedicato per l’esecuzione di questi particolari “pezzetti” di infrastruttura.

E da qui nacquero i primi problemi: con la necessità di definirsi meglio come soluzione “a tutto tondo”, Docker ha iniziato ad includere sempre più funzionalità, culminato nell’estate scorsa quando ha annunciato l’inclusione del sistema di orchestration Swarm all’interno del core di Docker stesso.

Questo ha creato attriti con gli altri grandi utilizzatori di Docker: RedHat (che ha preferito Kubernetes alla soluzione integrata), Amazon che spingeva poichè gli utenti facessero girare i container nel cloud AWS utilizzando la loro implementazione specifica di Docker, etc.
La situazione era così “delicata” che si è pensato addirittura di fare un fork di Docker!

Non si è mai arrivato a tanto, ma Red Hat ha comunque preferito lanciare il progetto OCID, un’alternativa all’interfaccia a runtime di Docker basata su runC.

Fortunatamente negli ultimi mesi la situazione si è calmata; nonostante i continui attriti con i “grandi player” dei container, è diventato chiaro che Docker non stava lavorando espressamente per ignorare l’intero ecosistema creando una soluzione incompatibile con tutti.

Il rilascio di parte del suo codice di core alla Cloud Native Computing Foundation ed il relativo impegno che ha pubblicamente dichiarato verso la comunità open source e gli standard aperti.

Insomma, dopo i primi anni di vita abbastanza rocamboleschi, sembrerebbe che si sia trovato il giusto equilibrio per consentire a tutti di utilizzare Docker (o uno dei suoi componenti) come soluzione o come base per costruirsi la propria, affermando il fatto che -probabilmente- continueremo a parlare di questa simpatica balena ancora per molto tempo.

Tanti auguri!

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.