Virtualisierung auf Betriebssystemebene (Container) für OS X


31

Ich frage mich, warum es abgesehen von der guten alten Chroot keine Implementierung von Virtualisierung auf Betriebssystemebene (oder von Containern, wenn Sie dies vorziehen) für Mac OS X gibt.

Könnte es an Kernel- oder Lizenzbeschränkungen liegen? Oder hat einfach noch niemand ein ähnliches Projekt ins Leben gerufen?

Antworten:


16

Ein Schlüsselelement für die Containerisierung ist die Isolierung von Netzwerken und anderen Diensten, aber nicht nur die Isolierung, sondern auch die Virtualisierung . FreeBSD-Jails, Linux- "Container" (oder genauer gesagt "Namespaces") und Solaris / Illumos-Zonen bieten alle einen gewissen Grad an "Virtualisierung" dieser Betriebssystemdienste.

Durch die Virtualisierung bedeutet dies, dass diese Server für Dinge innerhalb des "Containers" verfügbar (oder potenziell verfügbar ) sind, aber auf eine Weise, die die anderen Dinge auf demselben Host außerhalb des Containers schützt. (Beispielsweise kann ein Container einen eigenen TCP / IP-Stack mit eigener IP-Adresse, ARP-Cache usw. haben.)

Unter Betriebssystemvirtualisierung versteht man im Allgemeinen diese Art der "leichten" Virtualisierung, bei der Prozesse den Eindruck haben, dass sie einen virtuellen Kernel sehen, sich aber alle denselben realen Kernel unter der Haube teilen. Dieser Kernel fungiert als eine Art Hypervisor, der sicherstellt, dass die Container- / Virtualisierungsgrenzen nicht überschritten werden. (Anders ausgedrückt, die Betriebssystemdienste werden virtualisiert.) Vergleichen Sie dies mit der Hardwarevirtualisierung, bei der die Hardware virtualisiert wird - z. B. werden Geräte in Software emuliert und einem im Container ausgeführten Betriebssystem präsentiert. Dies ist sehr leistungsfähig, aber sehr ressourcenintensiv. Jede virtuelle Maschine muss über eine eigene Kopie des Betriebssystems verfügen.

Neuere Versionen von macOS bieten native Hypervisor-Unterstützung über Hypervisor.framework, mit der Software wie "XHyve" (ein Port von FreeBSDs BHyve) (Docker unter macOS verwendet dies) unterstützt wird. Es fehlen jedoch die erforderlichen Dienste, um die Betriebssystemdienste vollständig zu virtualisieren.

In der Tat ist wahrscheinlich bereits viel von dem vorhanden, was benötigt wird, da die Arbeit zur Bereitstellung von Sandkästen bedeutet, dass es bereits logische Punkte gibt, an denen Systemaufrufe für verschiedene Anwendungen unterschiedlich abgefangen und behandelt werden. Das ist jedoch noch lange nicht alles - die Implementierung eines echten separaten Netzwerks, IPCs und anderer Namespaces ist ziemlich aufwändig.

Der beste Grund, warum Apple dies nicht getan hat, ist wahrscheinlich derselbe Grund, warum Apple seit vielen Jahren keine geeignete Plattform für den Betrieb von macOS im Rechenzentrum herausgebracht hat - mangelnde Marktnachfrage oder vermeintlich mangelnde Marktnachfrage durch die Apple-Führung. Der Desktop- und Mobile-Fokus, auf den sie ihre Aufmerksamkeit gerichtet haben, erfordert einfach nicht so viele virtuelle macOS-Instanzen. (Das ist traurig, weil ich gerne virtuelle macOS-Unterstützung hätte - zum Beispiel ist das Ausführen von macOS auf VMs bei Travis CI im Vergleich zu Linux-Containern sehr zeitaufwendig.)


1
Gute Antwort ... Ich vermute, Apple vermeidet die Unterstützung von OSX auf dem Server, da dies den MBP-Markt einschränken würde, wenn iOS-Entwickler einen billigen, leistungsstarken Linux-Laptop verwenden und ihre Apk auf einem VPS-Hosting-Provider kompilieren könnten
Scott Stensland,

6

Sie würden überrascht sein - Container tatsächlich werden unterstützt - die OS X (und iOS) Sandbox hat sich weiterentwickelt , sie zu nutzen. Sie wurden in 10.7 eingeführt und sind jetzt in 10.10 und iOS 8 de facto Standard. In letzterem Fall werden sie strenger durchgesetzt (hauptsächlich aus Gründen der Anwendungssicherheit), bis zu dem Punkt, an dem eine App nur sich selbst sehen kann, und in früheren Versionen Methoden zum Auflisten von Prozessen oder Ressourcen geben jetzt container-basierte Ergebnisse zurück - ähnlich dem Linux-IPC-Namespace - aber leistungsfähiger.


2
Dies sind jedoch Sandboxen, keine Betriebssystemvirtualisierung (z. B. Container, Zonen, Jails), oder?
Smdvlpr

1
Docker ist auch keine Virtualisierung. Container! = VMs. Docker enthält im Grunde genommen eine Reihe verschiedener Kernel-Features, Cgroups, Chroot, Layered File-Systeme, Iptables-Routing usw., um eine Gruppe von Prozessen so zu isolieren, dass die App das System für sich selbst sieht, während diese Umgebungen zur Verbesserung der Sicherheit isoliert werden und die Fähigkeit von Behältern zu minimieren, sich miteinander und mit dem System einzumischen. OSX-Container bieten einen Teil dieser Funktionalität, jedoch nicht alle. Es ist jedoch wahrscheinlich etwas, das von einem geschickt genug programmierten Programmierer implementiert werden könnte.
Shayne

3
@Technologeeks, können Sie in OS X auf Referenzmaterial zu Containern / Sandkästen verweisen?
Ken Williams

3

Ich würde mir vorstellen, dass die Antwort so ist, dass niemand es wirklich will. Es scheint machbar zu sein. Diese Aufgaben werden hauptsächlich zu einem Zweck ausgeführt, um die Leistung der VPS-Anbieter zu erhalten. Und wirklich niemand möchte, dass eine VPS-Instanz auf OS X basiert.


5
Danke für deinen Punkt. IMHO gibt es zumindest einen anderen Anwendungsfall für Container, nämlich das Erstellen von Entwicklungsumgebungen. Übrigens, ich habe auch diese alte Flamme gefunden: groups.google.com/forum/#!topic/darwin-dev/6-FP9GCsBG4
Emyl

Erhöhte Dichte ist ein netter Nebeneffekt beim Isolieren von Prozessen in eigene Namespaces. Mit Containern können Sie mehrere Apps sicherer ausführen und haben mehr Kontrolle darüber, was sie auf dem Computer tun können. Diese Vorteile werden von iOS genutzt, um die Sicherheit zu erhöhen und Apps davon abzuhalten, aufeinander zu treten, was beispielsweise wenig mit der VPS-Dichte zu tun hat. Auch Single-Service-Maschinen können von Sicherheit profitieren. Es gibt keine Verbesserung der Dichte, aber Container können trotzdem nützlich sein.
GargantuChet

2

Während es "good old chroot (8)" verwendet, habe ich ein Projekt gestartet, das das Verhalten von Docker unter OS X und NetBSD nachahmt. Es ist redefrei und auf GitHub verfügbar . Wie in der README-Datei angegeben, geht es bei diesem Projekt weder um Sicherheit noch um Produktion, sondern um das Testen vollständiger Stapel auf Ihrer Workstation.


0

docker (so wie ich es verstehe) "virtualisiert" nur das Dateisystem und das Netzwerk (CPU / Mem sind nur begrenzt), daher sollte dasselbe Feature vorhanden sein, aber nicht auf die gleiche Weise vermarktet werden.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.