CoreOS dona rkt alla Cloud Native Computing Foundation

Quando parliamo di container su Linux sono due le principali fazioni: da una parte abbiamo Docker, azienda che si occupa attualmente dello sviluppo di containerd, e dall'altra abbiamo CoreOS che, invece, sta sviluppando rkt.

Ma cosa sono containerd ed rkt? Entrambi si possono definire dei "container runtime", ovvero degli strati software che permettono di astrarre l'uso dei container.

Come abbiamo avuto modo di vedere in passato, un container può essere (anche se stiamo semplificando) definito come un gruppo di tre componenti:

• Un namespace che si occupa di gestire delle "separazioni logiche" sull'hardware di differenti processi
• Dei cgroup che definiscono i limiti che uno o più processi hanno nell'uso delle risorse di uno specifico hardware
• Il processo (o i processi, se preferite) che risiedono in un dato namespace limitati dai relativi cgroup

Tutti questi componenti sono essenzialmente forniti direttamente dal kernel Linux (ed altri Kernel, come quello di macOS o di Windows, forniscono feature similari).

Qui entrano in gioco i container runtime; questi, infatti permettono di astrarre queste feature del kernel, e di utilizzare i container in maniera indipendente da essi; saranno loro a tradurre quello che si vuole fare in modo che il kernel sottostante faccia esattamente quanto richiesto.

La Cloud Native Computing Foundation (o CNCF) è un'organizzazione no-profit che cerca, attraverso l'inclusione di diversi progetti legati al mondo dei container, standardizzarli e renderli una base comune ed interoperabile.

Come Docker ha offerto di donare il proprio runtime containerd alla CNCF, CoreOS ha recentemente deciso di fare lo stesso con rkt. Questo non può che portare benefici a chi usa i container, poichè la definizione di uno standard comune permette a noi utenti di poter scegliere l'una o l'altra tecnologia in base non solo alle preferenze, ma anche alle reali necessità.

Ad esempio, una fondamentale differenza tra containerd e rkt è che quest'ultimo funziona in modalità "deamonless" (non ha quindi bisogno di un demone per funzionare), ma questa è solo una delle differenze tra i progetti, molte altre possono essere determinanti per una preferenza.

Entrambe le offerte sono al momento al vaglio da parte della CNCF, ma l'obiettivo comune delle aziende fa ben sperare che, indipendentemente da questo, ci sia un lavoro integrato per definire uno standard a riguardo.

We work closely to establish shared specifications on how container images get downloaded and created by application developers. Containerd and rkt can be separate implementations but also work together and run the exact same applications. It’s very much like web browsers. Just because Firefox, Chrome, and Internet Explorer compete in the market place, they do come together on HTML5 and JavaScript.

Stiamo lavorando a stretto giro per stabilire delle specifiche condivise su come le immagini debbano essere scaricate e create dagli sviluppatori. Containerd e rkt posso essere implementazioni separate ma anche lavorare insieme ed eseguire le stesse applicazioni. E' molto simile ad un browser web. Solo perchè Firefox, Chrome ed Internet Explorer competono nella stessa area di mercato, non vuol dire che non si siano accordati su HTML5 e Javascript

Viva la collaborazione!

Leggi il contenuto originale su Mia mamma usa Linux!