Mi chiedo perché, a parte il vecchio chroot, non esiste alcuna implementazione della virtualizzazione a livello di sistema operativo (o dei container, se preferite) per Mac OS X.
Potrebbe essere dovuto a limitazioni del kernel o restrizioni di licenza? O semplicemente nessuno ha ancora lanciato un progetto simile?
Risposte:
Un elemento chiave richiesto per la containerizzazione è l'isolamento della rete e di altri servizi, ma non solo l' isolamento ma anche la virtualizzazione . FreeBSD Jail, Linux "container" (o più correttamente "namespace") e zone Solaris / illumos offrono tutti un certo grado di "virtualizzazione" di questi servizi del sistema operativo.
Per virtualizzazione, ciò significa che questi server sono disponibili (o potenzialmente disponibili ) a cose all'interno del "contenitore", ma in modo da proteggere le altre cose sullo stesso host all'esterno del contenitore. (Ad esempio, un contenitore può avere il proprio stack TCP / IP, con il proprio indirizzo IP, cache ARP, ecc.)
La virtualizzazione del sistema operativo (sistema operativo) è il modo in cui generalmente ci riferiamo a questo tipo di virtualizzazione "leggera", in cui i processi pensano di vedere un kernel virtuale, ma condividono tutti lo stesso kernel reale sotto il cofano; quel kernel agisce come una sorta di hypervisor nel garantire che i confini del contenitore / virtualizzazione non vengano superati. (In altri termini, i servizi del sistema operativo sono virtualizzati.) Confrontalo con la virtualizzazione dell'hardware, dove ciò che è virtualizzato è l'hardware, ad esempio i dispositivi vengono emulati nel software e presentati a un sistema operativo in esecuzione nel contenitore. Questo è molto potente, ma piuttosto dispendioso in termini di risorse: ogni macchina virtuale deve avere la propria copia del sistema operativo.
MacOS recente ha il supporto hypervisor nativo tramite Hypervisor.framework che consente software come "XHyve" [una porta di BHyve di FreeBSD] (la docker su macOS lo usa), ma manca i servizi necessari per virtualizzare completamente i servizi del sistema operativo.
In verità, molto di ciò che è necessario è probabilmente già presente, poiché il lavoro per fornire sandbox significa che ci sono già punti logici in cui le chiamate di sistema vengono intercettate e gestite in modo diverso per applicazioni diverse. Tuttavia, è ben lungi dall'essere la storia completa: l'implementazione di una vera rete separata, IPC e altri spazi dei nomi richiede molto lavoro.
Il miglior motivo per cui Apple non lo ha fatto è probabilmente lo stesso motivo per cui Apple non ha rilasciato una piattaforma adatta per l'esecuzione di macOS nel data center per molti anni: mancanza di domanda del mercato o percezione della mancanza di domanda del mercato da parte della leadership di Apple. Il focus desktop e mobile su cui hanno focalizzato la loro attenzione semplicemente non ha bisogno di istanze macOS virtuali così tanto. (Questo è triste, perché mi piacerebbe avere il supporto macOS virtuale, ad esempio l'esecuzione di macOS su VM su Travis CI richiede molto tempo rispetto ai container Linux).
Sareste sorpresi - i container in realtà sono supportati - OS X (e iOS) Sandbox si è evoluto per usarli. Sono stati introdotti in 10.7 e ora sono di fatto standard in 10.10 e iOS 8. In quest'ultimo caso sono applicati più rigorosamente (principalmente per motivi di sicurezza delle applicazioni), al punto in cui un'app può vedere solo se stessa e precedenti i metodi di enumerazione dei processi o delle risorse ora restituiscono risultati basati su container - simili allo spazio dei nomi ipc di Linux - ma più potenti.
Immagino che la risposta sia che nessuno lo vuole davvero. Sembra fattibile. Queste cose vengono fatte principalmente per uno scopo, preservando le prestazioni per i fornitori di VPS. E davvero nessuno vuole che un'istanza VPS sia basata su OS X.
Mentre utilizza "good old chroot (8)", ho avviato un progetto che tende a imitare il comportamento di Docker su OS X e NetBSD. È gratuito e è disponibile su GitHub . Come dice il README, questo progetto non riguarda né la sicurezza né la produzione, ma aiuterà a testare in modo nativo stack completi sulla workstation.