MXC-architectuur en insluitingsmodellen

MXC scheidt de workloadintentie van het platformmechanisme waarmee de workload wordt uitgevoerd. Uw host-app maakt gebruik van de .NET-, TypeScript- of Rust-SDK om resourcemachtigingen te beschrijven en uitvoering aan te vragen. MXC vertaalt het verzoek in de bewerkingen van een containment-backend op de huidige host.

Dit ontwerp biedt apps een consistent integratieoppervlak zonder te beweren dat elke back-end dezelfde mogelijkheden of isolatie-eigenschappen biedt.

Architectuurlagen

Een MXC-integratie heeft vier hoofdlagen:

Laag Verantwoordelijkheid
Host-app of de agentruntime Classificeert de taak, selecteert standaardinstellingen voor vertrouwd beleid, levert invoer en verwerkt uitvoer en goedkeuring
MXC SDK en beleidsovereenkomst Detecteert beschikbare ondersteuning, converteert de workloadintentie naar een versieconfiguratie, start sandboxes en maakt levenscyclus en diagnostische gegevens beschikbaar
MXC-uitvoeringslaag Valideert de configuratie, bepaalt een backend en vertaalt het ondersteunde contract naar platformbewerkingen
Containment-backend Maakt de runtime-omgeving en dwingt de beleidsfuncties af die door het platform en de back-end worden ondersteund

De host-app blijft verantwoordelijk voor beleidsbeslissingen. Een coderingsagent kan een model of toekenning van resources voorstellen, maar mag geen eigen autoriteit kiezen of uitbreiden zonder vertrouwde logica of menselijke goedkeuring. Code die door de host buiten MXC wordt uitgevoerd, blijft buiten de isolatie van de werkbelasting.

Beleids-, configuratie- en runtime-instellingen

In het beleid wordt beschreven waartoe de workload toegang mag hebben. De uitvoeringsaanvraag voegt toe wat moet worden uitgevoerd, waar deze moet worden uitgevoerd en welke containment moet worden gebruikt. Runtime-instellingen leveren waarden die nodig zijn voor uitvoering, zoals het eindpunt van een al actieve proxy.

De V1 SDK's bevatten deze instellingen in één ContainerRequest. De eigenschappen ervan voor het bestandssysteem, het netwerk en de gebruikersinterface beschrijven de toegang, en de eigenschappen ervan voor de opdracht, werkmap, omgeving, time-out en insluiting beschrijven de uitvoering. De SDK converteert de aanvraag naar het stabiele 1.0.0 schemacontract, zodat u geen schemaversie opgeeft.

De JSON-uitvoeringsconfiguratie is niet verwisselbaar met een geserialiseerd SDK-object. De eigenschappen timeoutMs en ui.allowInputInjection van de aanvraag komen bijvoorbeeld overeen met de instellingen ui.injection en process.timeout van de configuratie. Gebruik de SDK-typen of het schema voor de configuratieversie die u ontwerpt.

Eenmalige en toestandsbewuste levenscycli

MXC ondersteunt twee levenscycluspatronen.

Eenmalige uitvoering maakt de sandbox aan, voert één workload uit en breekt de sandbox af. Gebruik het voor onafhankelijke hulpprogramma's voor coderingsagenten, gegenereerde opdrachten, builds, tests en scripts. Een nieuwe smalle sandbox voor elke actie beperkt de bewaarde status en vermindert de druk om één breed beleid te maken.

statusbewuste uitvoering omvat vijf fasen: inrichten, starten, uitvoeren, stoppen en ongedaan maken van de inrichting. Provisioning retourneert een ondoorzichtig ContainerId, wat de aanroeper ongewijzigd doorgeeft aan latere fasen, en de aanroeper kan meerdere opdrachten uitvoeren voordat de afbouw plaatsvindt. Gebruik dit patroon alleen wanneer de workload afhankelijk is van de persistente toestand, zoals een agentprofiel, geïnstalleerde hulpprogramma's, configuratie of een besturingssysteemomgeving. In MXC 1.0 ondersteunen de V1 SDK-levenscyclus-API's IsolationSession en WSLc.

Toestandsbewuste uitvoering maakt MXC niet de eigenaar van de toestand. De back-end beheert de sandbox-resource en de aanroeper slaat de id op en beheert de levenscyclus. Het stoppen van de uitvoering en deprovisioning van resources zijn verschillende bewerkingen; welke status precies behouden blijft na het stoppen, hangt af van de back-end.

Uitvoeren, spawn en PTY-uitvoering beschrijven hoe uw host interageert met een actief proces, niet hoe lang de omgeving bestaat. Een run-aanroep retourneert vastgelegde uitvoer wanneer de uitvoering is voltooid. Een spawn-aanroep geeft uw host live standaardinvoer, uitvoer en foutstromen terwijl de workload wordt uitgevoerd. Een PTY-aanroep verbindt de workload met een pseudoterminal die door uw host wordt bestuurd, waarvan uw host ook de grootte beheert. Controleer de geselecteerde SDK en back-end op ondersteunde combinaties.

Hostverantwoordelijkheden

Stel een time-out voor de uitvoering in en handel workloadfouten, startfouten en annulering afzonderlijk af. Het annuleren van het wachten van een SDK is niet noodzakelijkerwijs hetzelfde als het beëindigen van de workload. Volg het contract voor beëindiging en opschoning van de SDK en neem de vereiste wachttijd in acht, zodat de uitvoering en optionele denial capture kunnen worden voltooid.

Voor toestandbewuste uitvoering moet u opschonen, zelfs wanneer een latere fase mislukt. Een mislukte stop mag niet voorkomen dat resources die eigendom zijn van uw app worden gedeprovisioneerd.

Bij het afbreken van de sandbox worden schrijfbewerkingen over het algemeen niet ongedaan gemaakt voor hostmappen waarvoor toegang is verleend of acties die worden uitgevoerd via toegestane netwerkservices. Kies doelbewust uitvoerlocaties en bepaal welke resultaten moeten worden bewaard voordat volgende taken deze gebruiken.

Een insluitingstype kiezen

Begin met de doelstellingen en beperkingen van uw workload, bijvoorbeeld:

Behoefte aan werklast Begintype Waarom
Opdrachten waarvoor geselecteerde hosthulpprogramma's en paden met lage opstartoverhead nodig zijn Procesisolatie Wordt uitgevoerd dicht bij de hostomgeving met machtigingen die zijn beperkt tot de taak
Workload die een afzonderlijk Windows profiel of interactieve sessie nodig heeft Sessieisolatie Scheidt de gebruikers- en sessiestatus van de workload van de interactieve gebruikersomgeving, zonder filtering van MXC-bestanden, netwerk of UI
Workload waarvoor een afzonderlijke kernel- of gastbesturingssysteemomgeving is vereist Gevirtualiseerde omgeving Maakt gebruik van een VM- of micro-VM-grens, beperkt door de mogelijkheden van de geselecteerde backend

Procesisolatie is in Windows een veelgebruikte vorm, omdat dit goed past bij veel workloads die geselecteerde hostbronnen nodig hebben met lage opstartkosten.

Sessieisolatie scheidt gebruikers en sessies, maar het beperkt niet waartoe de workload toegang heeft. Op Windows weigert IsolationSession bestandssysteem- en UI-beleid. Het verzoek moet ook uitgaand verkeer, inkomend verkeer en host-loopback instellen op allow, zonder netwerkregels of proxy. Als de workload deze beperkingen nodig heeft, kiest u een back-end die deze kan afdwingen. Zie Back-endselectie en -instellingen voor meer informatie.

Met een abstracte intentie, zoals process, kan MXC een platformspecifieke back-end oplossen. Selecteer een concrete back-end wanneer u een bepaalde operationele omgeving of levenscyclus nodig hebt. Houd er rekening mee dat noch een abstracte intentie noch een sterker isolatiemechanisme ondersteuning garandeert voor elk bestand, netwerk of UI-element.

Zie MXC-insluitingsopties en platformondersteuning voor selectierichtlijnen en koppelingen naar gedetailleerde back-enddocumentatie.

Leermodus in de Architectuur

De leermodus helpt bij het opstellen van beleid en diagnostiek voor Windows ProcessContainer-workloads. Zie MXC-beleid maken en verfijnen met de leermodus.

Ontwerprichtlijnen voor coderingsagenten

Wanneer u een coderingsagent gebruikt om een containmenttype te kiezen, vraagt u het volgende te evalueren:

  1. Welke besturingssystemen en processorarchitecturen moet de app ondersteunen?
  2. Welke bestanden, netwerkpaden, functies van de gebruikersinterface, apparaten en hosthulpprogramma's heeft de workload nodig?
  3. Is elke opdracht onafhankelijk of moet de identiteit en status tussen opdrachten behouden blijven?
  4. Welke opstarttijd, resourcegebruik, implementatie en interactiebeperkingen zijn van toepassing?
  5. Heeft de workload Windows, Linux, een volledig bureaublad of een andere besturingsomgeving nodig?
  6. Welke isolatiegrens passend is voor de vertrouwensveronderstellingen en gegevens van de workload?
  7. Welke aangevraagde beleidsfuncties kan elke beschikbare back-end afdwingen?

De agent moet levensvatbare insluitingstypen vergelijken, de veronderstellingen en compromissen vermelden en niet-ondersteunde vereisten identificeren. Vervolgens kunt u een geschikt containmenttype selecteren en het beleid opstellen.

Verwante onderwerpen

  • Laatst bijgewerkt om