Avessimo un euro per tutti gli appassionati di Linux ed open-source che usano macOS saremmo ricchi. Per quanto lo stile chiuso e proprietario di Apple sembri sulla carta in totale contrasto con l’etica open-source infatti, migliaia di sviluppatori in tutto il mondo programmano e sviluppano i propri software, magari proprio open-source, su macOS.

Questa incoerenza di fondo è giustificata tipicamente dal fatto che, a detta degli utilizzatori, l’hardware è più performante, i sistemi sono più stabili e poi, diamine, è Apple, vuoi mettere?

Scherzi (ma non troppo) a parte, a fronte di questa apertura non sorprende sentir parlare di Containerization, il progetto open-source di Apple che propone un nuovo approccio alla containerizzazione su macOS. Quello che sorprende, semmai, è che quelli che si possono creare con il comando CLI container (che è open-source, scritto in Swift e rilasciato sotto licenza Apache 2.0) anziché essere veri e propri container (ossia una tecnologia nativa Linux) questi sono… Macchine virtuali!

Il punto è che, a differenza di Linux dove i container condividono lo stesso Kernel e sono isolati mediante namespace e cgroups (elementi nativi del Kernel Linux), Apple ha scelto di lanciare una VM per ogni container. I benefici di questa via di mezzo sono che ogni istanza rimane completamente isolata e beneficia dello stesso livello di sicurezza di una macchina virtuale autonoma.

Probabilmente molti si staranno chiedendo: ma i container non erano mica stati creati proprio per risolvere il problema della sovrabbondanza di VM che venivano create per isolare un singolo processo?

Così pareva.

Eppure qui l’overhead pare non essere un problema. I tempi di avvio dichiarati sono sotto il secondo per ogni container grazie a una mini-VM essenziale, priva di core utility, libc e librerie dinamiche. Il sistema si basa su un init system minimale, vminitd, che si occupa di montare il filesystem e avviare i processi containerizzati all’interno della VM, ma non sono ancora stati pubblicati benchmark effettivi.

Nonostante poi il sistema funzioni già su macOS 15 “Sequoia”, ci sono alcune limitazioni: manca l’isolamento di rete e diversi bug (vedi questo articolo di DevClass) verranno corretti, a detta di Apple, solo in macOS 16 “Tahoe”, attualmente in beta (rilascio previsto per settembre 2025).

In ogni caso la CLI container consente di:

• Costruire immagini da Dockerfile.
• Eseguire container con configurazioni su memoria, CPU virtuali, volumi condivisi, ecc.
• Eseguire immagini arm64 e amd64, grazie a Rosetta, la tecnologia Apple per eseguire binari x86_64 su chip ARM (Apple Silicon).

Proprio Rosetta è al centro di un’altra questione tecnica, infatti Podman – il progetto sponsorizzato da Red Hat – non riesce a usare Rosetta con i Kernel più recenti (6.13), riscontrando crash sistematici. Risultato? I container Podman devono restare su una base Fedora più vecchia per poter funzionare correttamente.

Quindi a chi è rivolta questa tecnologia? Il target principale è chiaro: sviluppatori macOS che vogliono testare e costruire applicazioni Linux in modo sicuro ed efficiente. Ma, è altrettanto chiaro, si tratta più di uno strumento da dev che di una vera alternativa a Docker in produzione.

Difficile dire dove arriverà, ma di sicuro il lato più interessante di tutta questa tecnologia è il fatto che sia open-source e di questo non ci lamenteremo mai!