Opcje izolacji MXC i obsługa platformy

MXC ułatwia zarządzanie złożonością korzystania z kontenerów: używasz kontrolera MXC do opisywania zasad i zarządzania cyklem życia kontenera, ale wybrany backend izolacji faktycznie egzekwuje te zasady. Każdy backend jest oparty na innym mechanizmie systemu operacyjnego. W związku z tym backendy różnią się sposobem izolowania obciążenia roboczego oraz obsługą plików, sieci, interfejsu użytkownika i cyklu życia.

Zacznij od tego, czego wymaga Twoje obciążenie, a następnie upewnij się, że backend może to zapewnić na hostach docelowych. Sama nazwa lub wersja systemu operacyjnego nie będzie określać, czy backend jest obsługiwany.

Poznaj środowiska hostów i obciążeń

W żądaniu możesz poprosić o rodzaj środowiska, nazywany containment intent, lub nazwać konkretny backend. Mapowanie intencji process jest mapowane na natywny backend izolacji procesów na hoście, na którym działasz. Ponieważ backend różni się w zależności od systemu operacyjnego, ta sama intencja może zapewnić różne możliwości w systemach Windows, Linux i macOS.

Host Domyślny backend procesu Inne środowiska
Windows ProcessContainer Oddzielna sesja Windows, maszyna wirtualna Windows lub obciążenia systemu Linux za pośrednictwem usługi WSLc, tam, gdzie jest to obsługiwane
Linux Bubblewrap LXC i wyspecjalizowane zaplecza wirtualizacji, jeśli są obsługiwane
macOS Pas bezpieczeństwa Sprawdź wersję, którą instalujesz, pod kątem innych obsługiwanych opcji

Obciążenie robocze nie musi działać w tym samym systemie operacyjnym co host. Na przykład WSLc uruchamia obciążenie systemu Linux na hoście Windows. Ma własne wymagania wstępne i współdzieli zasoby z hostem inaczej niż piaskownica procesu Windows.

Sprawdź stan wydania i zakres SDK

Obsługa komponentów backendowych zmienia się z wydania na wydanie, dlatego sprawdź informacje o obsłudze dla zainstalowanej wersji pakietu.

W MXC v1.0.0 pakiety SDK V1 mogą tworzyć kontenery przy użyciu następujących zapleczy:

  • Windows: ProcessContainer, IsolationSession i WSLc
  • Linux: Bubblewrap i LXC
  • macOS: Seatbelt

Windows Sandbox, MicroVM i Hyperlight są eksperymentalne. Wymagają wyraźnego zezwolenia eksperymentalnego i nie można ich utworzyć za pośrednictwem interfejsów API zestawu SDK w wersji 1. Jeśli rozważasz jedno z tych lub innych wyspecjalizowanych środowisk, najpierw sprawdź informacje o wersji dla używanej wersji.

Backend dostępny na hoście może nadal nie obsługiwać operacji zestawu SDK, którą planujesz wywołać. W pakietach SDK V1:

  • Interfejsy API cyklu życia działają tylko z IsolationSession i WSLc.
  • Jednorazowe wykonywanie PTY działa z IsolationSession, Bubblewrap, LXC i Seatbelt.
  • Wykonywanie PTY w istniejącym kontenerze działa tylko z IsolationSession.

Aby uzyskać szczegółowe informacje, zobacz dokumentację zestawu SDK:

Jeśli używasz Rusta, obsługa backendu zależy również od włączonych funkcji crate’a. Aby użyć IsolationSession lub WSLc, włącz funkcję wslc lub isolation_session crate’a mxc-sdk. Aby uzyskać więcej informacji, zobacz Przewodnik po zestawie Rust SDK.

Rozpocznij od wykrywania środowiska uruchomieniowego

Każdy zestaw SDK może poinformować Cię o tym, co obsługuje bieżący host przed uruchomieniem czegokolwiek. Najpierw uruchom te testy, ale zachowaj obsługę błędów uruchamiania, ponieważ konfiguracja hosta może ulec zmianie między sprawdzaniem a uruchomieniem.

Użyj obsługi platformy, aby sprawdzić, czy w ogóle można uruchamiać kontenery, użyć dostępnych mechanizmów zaplecza do uzyskania szerszego obrazu hosta oraz użyć narzędzia diagnostycznego do przetestowania określonego żądania w systemie Windows przed jego uruchomieniem.

SDK Discovery API Co należy sprawdzić?
.NET MxcPlatform.GetPlatformSupport() IsSupported, Reason i AvailableMethods, który zawiera listę backendów, które SDK może uruchomić
.NET MxcPlatform.GetAvailableBackends() Dostępność hosta, opcjonalne możliwości i ostrzeżenia. Niektóre interfejsy API wykonawcze nie mogą używać każdego zaplecza wymienionego tutaj.
.NET MxcContainer.Probe() W systemie Windows, w warstwie izolacji ProcessContainer, żądanie otrzyma diagnostykę zgodności specyficzną dla żądania bez tworzenia kontenera
TypeScript getPlatformSupport() isSupported, reason, availableMethodsi wszelkie ostrzeżenia oraz pola funkcji specyficzne dla hosta
TypeScript getAvailableBackends() Dostępność hosta, opcjonalne możliwości i ostrzeżenia. Niektóre interfejsy API wykonawcze nie mogą używać każdego backendu wymienionego tutaj.
TypeScript probe() W systemie Windows, na poziomie izolacji ProcessContainer, żądanie otrzyma diagnostykę zgodności specyficzną dla żądania bez tworzenia kontenera
Rust v1::platform_support() is_supported, reason, available_methods oraz w systemie Linux obsługa sieci Bubblewrap
Rust v1::available_backends() Dostępność hosta, opcjonalne możliwości i ostrzeżenia. Niektóre interfejsy API uruchamiania nie mogą używać każdego zaplecza wymienionego tutaj.
Rust v1::probe() W systemie Windows na poziomie izolacji ProcessContainer żądanie otrzyma diagnostykę zgodności specyficzną dla żądania bez tworzenia kontenera

W wynikach mogą brakować pól, które nie mają zastosowania lub których nie można wykryć. Discovery jest przydatne podczas pierwszego sprawdzania, ale nie weryfikuje całej polityki. Aby mieć pewność, utwórz żądanie, które chcesz uruchomić, i upewnij się, że wybrany backend może wymusić wszystkie mechanizmy kontroli wymagane przez to żądanie.

Niektóre hosty wymagają dodatkowych składników lub konfiguracji administratora, zanim backend zacznie działać. Wyniki odnajdywania i błędy uruchamiania mogą powiedzieć, czego brakuje, ale to nie daje aplikacji ani agentowi kodowania uprawnienia do zmiany hosta. Poproś osobę, która zarządza hostem systemu, aby postępowała zgodnie z udokumentowanymi krokami konfiguracji zaplecza.

W przypadku systemu Windows zobacz Obsługa zasad wersji systemu operacyjnego. Wersja Windows może być obsługiwana przez usługę MXC i nadal nie mieć określonej funkcji zasad/polityki, więc sprawdź oba te elementy.

Sprawdź ograniczenia wymagane przez obciążenie

Dwa backendy mogą akceptować tę samą składnię zasad i nadal egzekwować ją na różne sposoby. Zanim zdecydujesz się na backend, rozważ następujące obszary:

Area Pytania, które warto zadać
Files Czy backend może wyrazić potrzebne uprawnienia odczytu, zapisu i odmowy, w tym nakładające się? Czy udostępnia pliki hostowi, montuje je lub kopiuje?
Sieć Czy może wymusić Twój model sieci, zarówno bezpośrednio, jak i za pośrednictwem serwera proxy, w tym reguły sprzężenia zwrotnego typu private-network i host-loopback?
interfejs użytkownika Czy można zastosować wymagane ograniczenia dotyczące okien, schowka i danych wejściowych?
Lifecycle Czy każde polecenie jest uruchamiane niezależnie, czy może zachować środowisko między poleceniami? Co pozostaje po zatrzymaniu?
Tryb uczenia Czy host obsługuje rejestrowanie odmów ProcessContainer? Jeśli nie, jaki proces diagnostyczny udostępnia backend?

Przewodniki MXC na GitHubie zawierają listę obsługiwanych funkcji, kompilacji systemu operacyjnego i wymagań dla każdego backendu.

Wybierz backend na podstawie swoich wymagań

Przed wybraniem backendu zapisz:

  • Obsługiwane przez aplikację architektury hostowanych systemów operacyjnych i procesorów.
  • Środowisko gościa lub narzędzia, którego wymaga obciążenie robocze.
  • Obciążenie wymaga dostępu do plików, sieci, interfejsu użytkownika, urządzenia i narzędzia hosta.
  • Niezależnie od tego, czy każde polecenie jest uruchamiane samodzielnie, czy wymaga stanu z wcześniejszych poleceń.
  • Limity czasu uruchamiania, zasobów, wdrożenia i interakcji użytkownika.
  • Jak silnej granicy izolacji wymagają obciążenie i jego dane.
  • Czy zaplecze może wymuszać każdą wymaganą kontrolę zasad.

Następnie przetestuj każdą obsługiwaną konfigurację hosta przy użyciu testów dodatnich i ujemnych. Pomyślne wysłanie pokazuje tylko, że aplikacja MXC zaakceptowała konfigurację. Testy ujemne, takie jak próba zapisania poza przyznanymi ścieżkami, pokazują, czy ograniczenia rzeczywiście obowiązują.

Treści powiązane

  • Ostatnia aktualizacja o