Architektura MXC a modely kontejnmentu

MXC odděluje záměr workloadu od mechanismu platformy, který spouští workload. Vaše hostitelská aplikace používá sadu .NET, TypeScript nebo Rust SDK k popisu oprávnění prostředků a provádění požadavků. MXC přeloží požadavek na operace back-endu pro izolaci na aktuálním hostiteli.

Tento návrh poskytuje aplikacím konzistentní integrační rozhraní, aniž by tvrdil, že každý back-end poskytuje stejné možnosti nebo vlastnosti izolace.

Vrstvy architektury

Integrace MXC má čtyři hlavní vrstvy:

Vrstva Odpovědnost
Hostitelská aplikace nebo modul runtime agenta Klasifikuje úlohu, vybere výchozí nastavení důvěryhodných zásad, poskytuje vstupy a zpracovává výstup a schválení.
MXC SDK a smlouva o zásadách Zjišťuje podporu, převádí záměr úloh na konfiguraci s verzí, spouští sandboxy a zpřístupňuje životní cyklus a diagnostiku.
spouštěcí vrstva MXC Ověří konfiguraci, určí back-end a přeloží podporovaný kontrakt na operace platformy.
Backend kontejneru Vytvoří prostředí pro provádění a vynucuje funkce zásad, které platforma a back-end podporují.

Hostitelská aplikace zůstává zodpovědná za rozhodnutí o zásadách. Agent kódování může navrhnout model nebo udělení prostředků, ale nesmí zvolit ani rozšířit vlastní autoritu bez důvěryhodné logiky nebo lidského schválení. Kód, který hostitel spouští mimo MXC, zůstává mimo izolaci úlohy.

Nastavení zásad, konfigurace a běhového prostředí

Tyto zásady popisují, k čemu může úloha úloh přistupovat. Žádost o spuštění přidá, co se má spustit, kde se to má spustit a které omezení izolace se má použít. Nastavení modulu runtime poskytují hodnoty potřebné pro běh, jako je již spuštěný koncový bod proxy serveru.

Sady SDK V1 mají tato nastavení v jednom ContainerRequest. Jeho souborový systém, síť a vlastnosti uživatelského rozhraní popisují přístup a jeho příkaz, pracovní složka, prostředí, časový limit a vlastnosti izolace popisují provádění. Sada SDK převede požadavek na stabilní 1.0.0 kontrakt schématu, takže nemusíte zadávat verzi schématu.

Konfigurace spuštění JSON není zaměnitelná se serializovaným objektem sady SDK. Například vlastnosti požadavku timeoutMs a ui.allowInputInjection odpovídají nastavením konfigurace ui.injection a process.timeout. Použijte typy sady SDK nebo schéma pro verzi konfigurace, kterou vytváříte.

Jednorázové a stav zohledňující životní cykly

MXC podporuje dva vzorce životního cyklu.

Jednorázové spuštění vytvoří sandbox, spustí jednu úlohu a zruší sandbox. Používejte ho pro nástroje nezávislých kódovacích agentů, generované příkazy, sestavení, testy a skripty. Nové úzce vymezené izolované prostředí pro každou akci omezuje uchovávaný stav a snižuje tlak na vytvoření jedné široké politiky.

Provádění s podporou stavu zahrnuje pět fází: zřízení, spuštění, provedení, zastavení a zrušení zřízení. Zřizování vrátí neinterpretovatelnou ContainerIdhodnotu, kterou volající předá beze změny do pozdějších fází, a volající může před vyřazením spustit více příkazů. Tento vzor použijte pouze v případě, že úloha závisí na trvalém stavu, jako je profil agenta, nainstalované nástroje, konfigurace nebo prostředí operačního systému. V MXC 1.0 rozhraní API životního cyklu sady SDK V1 podporují IsolationSession a WSLc.

Provádění s podporou stavu nedělá z MXC vlastníka stavu. Back-end spravuje prostředek sandboxu a volající uloží jeho identifikátor a spravuje jeho životní cyklus. Zastavení běhu a zrušení přidělení prostředků jsou různé operace; přesně jaký stav po zastavení zůstane zachován, závisí na back-endu.

Spuštění, spuštění procesu a spuštění PTY popisuje, jak váš hostitel interaguje se spuštěným procesem, nikoli jak dlouho prostředí existuje. Volání run vrátí zachycený výstup po dokončení provádění. Volání spawn poskytuje vašemu hostiteli živé standardní vstupy, výstup a chybové streamy, zatímco úloha běží. Volání PTY připojí úlohu k pseudoterminálu, který řídí váš hostitel, včetně jeho velikosti. Zkontrolujte podporované kombinace vybrané sady SDK a vybraného back-endu.

Odpovědnosti hostitele

Nastavte časový limit spuštění a zpracujte selhání úloh, selhání spuštění a zrušení samostatně. Zrušení čekání sady SDK nemusí být nutně stejné jako ukončení zatížení. Postupujte podle postupu pro ukončení a uvolnění sady SDK a dokončete požadované čekání, aby bylo možné dokončit provádění a volitelné zaznamenání zamítnutí.

Pro spouštění zohledňující stav uspořádejte čištění i v případě, že dojde k selhání pozdější fáze. Neúspěšné zastavení by nemělo bránit pokusu o odebrání prostředků, které vaše aplikace vlastní.

Zrušení izolovaného prostoru (sandbox) obecně nevrací změny provedené zápisem do udělených adresářů hostitele ani akce provedené prostřednictvím povolených síťových služeb. Zvolte umístění výstupu záměrně a rozhodněte se, které výsledky se mají zachovat, než je následné úkoly použijí.

Volba typu omezení

Začněte s cíli a omezeními vaší úlohy, například:

Potřeba pracovní zátěže Počáteční typ Proč
Příkazy, které potřebují vybrané hostitelské nástroje a cesty s nízkou režií při spuštění Izolace procesů Běží v hostitelském prostředí nebo v jeho těsné blízkosti s oprávněními vymezenými pro úlohu.
Úloha, která potřebuje samostatný profil Windows nebo interaktivní relaci Izolace relace Odděluje uživatele úlohy a stav relace od prostředí interaktivního uživatele bez filtrování souborů MXC, sítě nebo uživatelského rozhraní.
Pracovní zátěž, která vyžaduje samostatné jádro nebo hostující provozní prostředí Virtualizované prostředí Používá hranice virtuálního počítače nebo mikro-VM, s ohledem na možnosti vybraného back-endu.

Na Windows je izolace procesů běžným typem, protože odpovídá mnoha úlohám, které potřebují vybrané hostitelské prostředky s nízkými náklady na spuštění.

Izolace relace odděluje uživatele a relace, ale neomezuje, k čemu má úloha přístup. V systému Windows IsolationSession odmítá zásady systému souborů a uživatelského rozhraní. Jeho požadavek musí také nastavit egress, ingress a hostitelský loopback na allow, bez síťových pravidel nebo proxy serveru. Pokud zátěž tato omezení potřebuje, zvolte back-end, který je může vynutit. Podrobnosti najdete v části Výběr a nastavení back-endu.

Abstraktní záměr, například process, umožňuje MXC určit back-end specifický pro platformu. Vyberte konkrétní implementaci backendu, pokud potřebujete konkrétní provozní prostředí nebo model životního cyklu. Všimněte si, že ani abstraktní intent ani silnější mechanismus izolace nezaručuje podporu pro každý soubor, síť nebo ovládací prvek uživatelského rozhraní.

Pokyny k výběru a odkazy na podrobnou dokumentaci k back-endu najdete v tématu Možnosti kontejnerizace MXC a podpora platforem.

Režim učení v architektuře

Režim učení pomáhá s vytvářením a diagnostikou zásad pro úlohy Windows ProcessContainer. Podívejte se na Vytváření a upřesňování zásad MXC pomocí výukového režimu.

Pokyny pro návrh pro kódovací agenty

Při použití programovacího agenta, který vám pomůže vybrat typ kontejneru, požádejte ho, aby vyhodnotil následující:

  1. Které operační systémy a architektury procesorů musí aplikace podporovat?
  2. Které soubory, síťové cesty, funkce uživatelského rozhraní, zařízení a hostitelské nástroje potřebuje úloha?
  3. Je každý příkaz nezávislý, nebo musí být mezi příkazy zachována identita a stav?
  4. Jaká omezení se vztahují na dobu spuštění, využití prostředků, způsob nasazení a interakci?
  5. Potřebuje úloha Windows, Linux, plné desktopové prostředí nebo jiné provozní prostředí?
  6. Která hranice izolace je vhodná pro předpoklady důvěry úlohy a její data?
  7. Které požadované funkce politik může každý dostupný backend vynutit?

Agent by měl porovnat přijatelné typy izolace, uvést své předpoklady a kompromisy a identifikovat nepodporované požadavky. Pak můžete vybrat odpovídající typ omezení a vytvořit zásadu.

Související obsah

  • Poslední aktualizace v