Acaba eski chroot dışında Mac OS X için neden işletim sistemi düzeyinde sanallaştırma (ya da tercih ederseniz kapsayıcılar) uygulanmıyor.
Çekirdek sınırlamaları veya lisans kısıtlamaları nedeniyle olabilir mi? Ya da hiç kimse henüz benzer bir proje başlatmadı?
Yanıtlar:
Konteynırlaştırma için gerekli anahtar unsur, ağların ve diğer hizmetlerin yalıtılmasıdır , ancak yalnızca yalıtım değil, aynı zamanda sanallaştırmadır . FreeBSD Hapishaneleri, Linux "konteynırları" (veya daha doğru "isim alanları") ve Solaris / illumos bölgelerinin tümü, bu işletim sistemi sistem hizmetlerinin bir dereceye kadar "sanallaştırma" özelliğini sunar.
Sanallaştırma ile, bu, bu sunucuların "kapsayıcı" içindeki nesnelere erişilebilir (ya da potansiyel olarak kullanılabilir ), ancak kapsayıcı dışındaki aynı ana bilgisayardaki diğer şeyleri koruyacak şekilde olduğu anlamına gelir. (Örneğin, bir kapsayıcı, kendi IP adresi, ARP önbelleği vb. İle birlikte kendi TCP / IP yığınına sahip olabilir.)
İşletim sistemi (işletim sistemi) sanallaştırması, genellikle işlemlerin sanal bir çekirdek gördüklerini düşündükleri ancak hepsinin aynı gerçek çekirdeği başlık altında paylaştığı bu tür "hafif" sanallaştırmaya gönderme yaptığımız şeydir; Bu çekirdek, konteyner / sanallaştırma sınırlarının aşılmamasını sağlamada bir çeşit hiper yönetici olarak hareket eder. (Başka bir deyişle, işletim sistemi hizmetleri sanallaştırılmıştır.) Bunu donanım sanallaştırması olan donanım sanallaştırmasıyla karşılaştırın. Örneğin, aygıtlar yazılımda öykünür ve kapta çalışan bir işletim sistemine sunulur. Bu çok güçlü, ancak oldukça kaynak yoğundur - her sanal makinenin işletim sisteminin kendi kopyası olmalıdır.
Yeni macOS, "XHyve" [FreeBSD'nin BHyve limanı] (macOS üzerindeki docker bunu kullanıyor) gibi yazılımlara izin veren Hypervisor.framework aracılığıyla yerel hiper yönetici desteğine sahip (macOS'ta docker kullanıyor), ancak işletim sistemi hizmetlerini tamamen sanallaştırmak için gerekli hizmetler bulunmuyor.
Aslında, ihtiyaç duyulanların çoğu muhtemelen zaten mevcuttur, çünkü sanal alan sağlama çalışması, sistem çağrılarının yakalandığı ve farklı uygulamalar için farklı şekilde ele alındığı halihazırda mantıklı noktalar olduğu anlamına gelir. Ancak, bu hikayenin tamamından uzak - gerçek ayrı ağ, IPC ve diğer ad alanlarını uygulamak oldukça fazla iş.
Apple'ın bunu yapmamasının en iyi nedeni, Apple'ın uzun süredir veri merkezinde macOS'u çalıştırmak için uygun bir platform yayınlamamasının aynı nedeni - pazar talebinin eksikliği veya Apple liderliği tarafından algılanan pazar talebinin olmamasıydı. Dikkatlerini yoğunlaştırdıkları masaüstü ve mobil odak, sanal macOS örneklerine pek de ihtiyaç duymuyor. (Bu üzücü, çünkü sanal macOS desteğine sahip olmak isterdim - örneğin Travis CI’de VM’lerde macOS çalıştırmak gerçekten Linux kapsayıcılarına kıyasla zaman alıcıdır).
Sen şaşıracaksınız - Konteynerleri aslında edilir destekli - OS X (ve iOS) Sandbox bunları kullanmak için gelişmiştir. 10.7'de tanıtıldılar ve şimdi 10.10 ve iOS 8'de fiili standart haline geldiler. İkincisinde, bir uygulamanın yalnızca kendisini ve daha önce görebileceği noktaya kadar (özellikle uygulama güvenliği nedeniyle) daha sıkı bir şekilde uygulanmaktadırlar. işlemleri veya kaynakları sayma yöntemleri, artık Linux ipc ad alanına benzer - ancak daha güçlü olan kap tabanlı sonuçlar döndürüyor.
Cevabını, kimsenin gerçekten istemediğine inanırdım. Yapılabilir görünüyor. Bu şeyler, temel olarak VPS satıcılarının performansını koruyarak tek bir amaç için yapılır. Ve gerçekten hiç kimse bir VPS örneğinin OS X tabanlı olmasını istemez.
"Eski güzel chroot'u (8)" kullanırken, makinenin OS X ve NetBSD'deki davranışını taklit etme eğiliminde olan bir projeye başladım. Konuşma kadar ücretsizdir ve GitHub'da mevcuttur . README'nin dediği gibi, bu proje ne güvenlikle ne de üretimle ilgili değildir, ancak iş istasyonunuzda doğal olarak tam yığınları test etmenize yardımcı olacaktır.