Zastanawiam się, dlaczego poza dobrym starym chrootem nie istnieje implementacja wirtualizacji na poziomie systemu operacyjnego (lub kontenerów, jeśli wolisz) dla Mac OS X.
Czy może to być spowodowane ograniczeniami jądra lub licencjami? Czy po prostu nikt jeszcze nie rozpoczął podobnego projektu?
Odpowiedzi:
Kluczowym elementem wymaganym do konteneryzacji jest izolacja sieci i innych usług, ale nie tylko izolacja, ale także wirtualizacja . Więzienia FreeBSD, „kontenery” Linuksa (lub bardziej poprawnie „przestrzenie nazw”) oraz strefy Solaris / illumos oferują pewien stopień „wirtualizacji” tych usług systemu operacyjnego.
Przez wirtualizację oznacza to, że serwery te są dostępne (lub potencjalnie dostępne ) dla rzeczy w „kontenerze”, ale w sposób, który chroni inne rzeczy na tym samym hoście poza kontenerem. (Na przykład kontener może mieć własny stos TCP / IP, z własnym adresem IP, pamięcią podręczną ARP itp.)
Wirtualizacja systemu operacyjnego (systemu operacyjnego) to sposób, w jaki ogólnie mówimy o tego rodzaju „lekkiej” wirtualizacji, gdzie procesy uważają, że widzą wirtualne jądro, ale wszystkie dzielą to samo prawdziwe jądro pod maską; że jądro działa jak rodzaj hiperwizora, zapewniając, że granice kontenera / wirtualizacji nie zostaną przekroczone. (Innymi słowy, usługi systemu operacyjnego są zwirtualizowane). Porównaj to do wirtualizacji sprzętowej, gdzie zwirtualizowany jest sprzęt - np. Urządzenia są emulowane w oprogramowaniu i prezentowane systemowi operacyjnemu działającemu w kontenerze. Jest to bardzo wydajne, ale wymaga dużych zasobów - każda maszyna wirtualna musi mieć własną kopię systemu operacyjnego.
Najnowsze macOS ma natywną obsługę hypervisora za pośrednictwem Hypervisor.framework, która pozwala na oprogramowanie takie jak „XHyve” [port BHyve FreeBSD] (używa go doker na MacOS), ale brakuje mu niezbędnych usług pod maską, aby w pełni zwirtualizować usługi systemu operacyjnego.
W rzeczywistości wiele z potrzebnych rzeczy jest już prawdopodobnie obecnych, ponieważ praca nad udostępnieniem piaskownic oznacza, że istnieją już logiczne punkty, w których wywołania systemowe są przechwytywane i obsługiwane w różny sposób dla różnych aplikacji. To jednak dalekie od pełnej historii - wdrożenie prawdziwej oddzielnej sieci, IPC i innych przestrzeni nazw to sporo pracy.
Najlepszym powodem, dla którego Apple tego nie zrobił, jest prawdopodobnie ten sam powód, dla którego Apple nie wypuścił platformy odpowiedniej do obsługi macOS w centrum danych od wielu lat - brak popytu na rynku lub postrzegany brak popytu na rynku ze strony lidera Apple. Komputery i urządzenia mobilne, na których skupili swoją uwagę, po prostu nie potrzebują tak bardzo wirtualnych instancji macOS. (To smutne, ponieważ chciałbym mieć obsługę wirtualnego macOS - na przykład uruchamianie macOS na maszynach wirtualnych w Travis CI jest naprawdę czasochłonne w porównaniu do kontenerów Linux).
Zdziwiłbyś się - Kontenery są obsługiwane - piaskownica OS X (i iOS) ewoluowała, aby z nich korzystać. Zostały wprowadzone w wersji 10.7, a obecnie są de facto standardem w wersji 10.10 i iOS 8. W tych ostatnich są one bardziej rygorystycznie egzekwowane (głównie ze względu na bezpieczeństwo aplikacji), do tego stopnia, że aplikacja widzi tylko siebie, i poprzednie metody wyliczania procesów lub zasobów zwracają teraz wyniki oparte na kontenerach - podobnie jak w przestrzeni nazw Linux ipc - ale są bardziej wydajne.
Wyobraziłbym sobie odpowiedź, że nikt tak naprawdę tego nie chce. Wydaje się to wykonalne. Te rzeczy są wykonywane głównie w jednym celu, oszczędzając wydajność dla dostawców VPS. I naprawdę nikt nie chce, aby instancja VPS była oparta na systemie OS X.
Chociaż używa „dobrego starego chroota (8)”, rozpocząłem projekt, który ma tendencję do naśladowania zachowania dokera w OS X i NetBSD. Jest bezpłatny w mowie i jest dostępny na GitHub . Jak mówi README, ten projekt nie dotyczy bezpieczeństwa ani produkcji, ale pomoże przetestować pełne stosy natywnie na stacji roboczej.