Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
MXC separa l'intento del carico di lavoro dal meccanismo della piattaforma che esegue il carico di lavoro. L'app host usa .NET, TypeScript o Rust SDK per descrivere le autorizzazioni delle risorse e l'esecuzione delle richieste. MXC converte la richiesta nelle operazioni del backend di containment sull'host corrente.
Questa progettazione offre alle app un'area di integrazione coerente senza dichiarare che ogni back-end fornisce le stesse funzionalità o proprietà di isolamento.
Livelli di architettura
Un'integrazione MXC ha quattro livelli principali:
| Livello | Responsabilità |
|---|---|
| Esecuzione dell'app host o dell'agente | Classifica l'attività, seleziona le impostazioni predefinite dei criteri attendibili, fornisce input e gestisce l'output e l'approvazione |
| MXC SDK e contratto di criteri | Individua le risorse supportate, converte l'intento del workload in una configurazione con controllo delle versioni, avvia le sandbox ed espone il ciclo di vita e la diagnostica |
| Livello di esecuzione MXC | Convalida la configurazione, risolve un back-end e traduce il contratto supportato in operazioni della piattaforma |
| backend di contenimento | Crea l'ambiente di esecuzione e applica e fa rispettare le funzionalità dei criteri supportate dalla piattaforma e dal back-end |
L'app host rimane responsabile delle decisioni relative ai criteri. Un agente di codifica può suggerire un modello o una concessione di risorse, ma non deve scegliere o espandere la propria autorità senza logica attendibile o approvazione umana. Il codice eseguito dall'host all'esterno di MXC rimane al di fuori del contenimento del carico di lavoro.
Impostazioni di criterio, configurazione e runtime
Il criterio descrive a cosa può accedere il carico di lavoro. La richiesta di esecuzione aggiunge cosa eseguire, dove eseguirlo e quale contenitore usare. Le impostazioni di runtime forniscono i valori necessari per l'esecuzione, ad esempio un endpoint del proxy già in esecuzione.
Gli SDK V1 contengono queste impostazioni in un singolo oggetto ContainerRequest. Le proprietà del file system, della rete e dell'interfaccia utente descrivono l'accesso e le sue proprietà di comando, directory di lavoro, ambiente, timeout e contenimento descrivono l'esecuzione. L'SDK converte la richiesta nel contratto dello schema stabile 1.0.0 , quindi non si specifica una versione dello schema.
La configurazione di esecuzione JSON non è intercambiabile con un oggetto SDK serializzato. Ad esempio, le proprietà timeoutMs e ui.allowInputInjection della richiesta corrispondono alle impostazioni process.timeout e ui.injection della configurazione. Usare i tipi di SDK o lo schema per la versione di configurazione che si redige.
Cicli di vita one-shot e consapevoli dello stato
MXC supporta due modelli di ciclo di vita.
L'esecuzione one-shot crea la sandbox, esegue un workload e smantella la sandbox. Usalo per strumenti indipendenti dell'agente di programmazione, comandi generati, compilazioni, test e script. Una nuova sandbox stretta per ogni azione limita lo stato mantenuto e riduce la pressione per creare una policy generale.
L'esecuzione basata sullo stato espone cinque fasi: provisioning, avvio, esecuzione, arresto e deprovisioning. Il provisioning restituisce un opaco ContainerId, che il chiamante passa invariato alle fasi successive e il chiamante può eseguire più comandi prima della chiusura. Usare questo modello solo quando il carico di lavoro dipende da uno stato persistente, ad esempio un profilo agente, strumenti installati, configurazione o un ambiente del sistema operativo. In MXC 1.0 le API del ciclo di vita dell'SDK V1 supportano IsolationSession e WSLc.
L'esecuzione con riconoscimento dello stato non rende MXC il proprietario dello stato. Il back-end è proprietario della risorsa sandbox e il chiamante archivia l'identificatore e ne gestisce il ciclo di vita. L'arresto dell'esecuzione e il deprovisioning delle risorse sono operazioni diverse; esattamente quale stato sopravvive a un arresto dipende dal back-end.
L'esecuzione, la creazione e l'esecuzione PTY descrivono come l'host interagisce con un processo in esecuzione, non per quanto tempo esiste l'ambiente. Una chiamata run restituisce l'output acquisito al termine dell'esecuzione. Una chiamata spawn fornisce all'host stream standard di input, output ed errore in tempo reale durante l'esecuzione del carico di lavoro. Una chiamata PTY connette il carico di lavoro a uno pseudoterminale che l'host controlla, incluse le dimensioni. Controllare l’SDK selezionato e il backend per verificare le combinazioni supportate.
Responsabilità dell'host
Impostare un timeout di esecuzione e gestire separatamente l'errore del workload, l'errore di avvio e l'annullamento. L'annullamento dell'attesa dell'SDK non coincide necessariamente con la terminazione del carico di lavoro. Seguire il contratto di terminazione e rilascio dell'SDK e completare l'attesa necessaria in modo che l'esecuzione e l'acquisizione facoltativa del rifiuto possano finalizzare.
Per l'esecuzione che tiene conto dello stato, disporre la pulizia anche quando una fase successiva ha esito negativo. Un arresto non riuscito non dovrebbe impedire un tentativo di deprovisioning delle risorse di proprietà dell'app.
Lo smantellamento della sandbox in genere non annulla le scritture nelle directory host o le azioni eseguite tramite i servizi di rete consentiti. Scegliere deliberatamente i percorsi di output e decidere quali risultati conservare prima che le attività successive li utilizzino.
Scegli un tipo di contenitore
Iniziare con gli obiettivi e i vincoli del carico di lavoro, ad esempio:
| Esigenze del carico di lavoro | Tipo di avvio | Perché |
|---|---|---|
| Comandi che richiedono strumenti host e percorsi selezionati con costi di avvio ridotti | Isolamento del processo | Viene eseguito nell'ambiente host con autorizzazioni limitate all'attività |
| Carico di lavoro che richiede un profilo di Windows separato o una sessione interattiva | Isolamento della sessione | Separa lo stato utente e di sessione del carico di lavoro dall'ambiente dell'utente interattivo, senza filtro dei file MXC, della rete o dell'interfaccia utente |
| Carico di lavoro che richiede un kernel o un ambiente operativo guest separato | Ambiente virtualizzato | Usa un isolamento di macchina virtuale o di micro-VM, soggetto alle funzionalità del back-end selezionato |
In Windows l'isolamento dei processi è un tipo comune perché corrisponde a molti carichi di lavoro che necessitano di risorse host selezionate con costi di avvio ridotti.
L'isolamento della sessione separa gli utenti e le sessioni, ma non limita ciò a cui il carico di lavoro può accedere. In Windows, IsolationSession rifiuta i criteri del file system e dell'interfaccia utente. La richiesta deve anche impostare egress, ingress e host loopback su allow, senza regole di rete o proxy. Se il carico di lavoro richiede tali restrizioni, scegliere un back-end che possa applicarle. Per informazioni dettagliate, vedere Selezione e impostazioni del back-end.
Un intent astratto, ad esempio process, consente a MXC di risolvere un backend specifico della piattaforma. Selezionare un back-end concreto quando è necessario un particolare ambiente operativo o ciclo di vita. Si noti che né un intento astratto né un meccanismo di isolamento più forte garantiscono il supporto per ogni controllo di file, rete o dell'interfaccia utente.
Per indicazioni sulla selezione e collegamenti alla documentazione dettagliata del back-end, vedere Opzioni di isolamento MXC e supporto della piattaforma.
Modalità di apprendimento nell'architettura
La modalità di apprendimento consente di creare criteri e diagnostica per i carichi di lavoro ProcessContainer di Windows. Vedi Creare e perfezionare i criteri MXC con la modalità di apprendimento.
Linee guida per la progettazione per gli agenti di coding
Quando si usa un agente di coding per scegliere un tipo di contenitore, chiedere di valutare:
- Quali sistemi operativi e architetture di processore deve supportare l'app?
- Quali file, percorsi di rete, funzionalità dell'interfaccia utente, dispositivi e strumenti host sono necessari per il carico di lavoro?
- Ogni comando è indipendente oppure identità e stato devono persistere tra i comandi?
- Quali vincoli di avvio, uso delle risorse, distribuzione e interazione si applicano?
- Il carico di lavoro richiede Windows, Linux, un desktop completo o un altro ambiente operativo?
- Quale limite di isolamento è appropriato per le assunzioni di attendibilità e i dati del workload?
- Quali funzionalità dei criteri richiesti può applicare ogni back-end disponibile?
Il sistema deve confrontare i tipi di contenimento validi, dichiararne i presupposti e i compromessi e identificare i requisiti non supportati. È quindi possibile selezionare un tipo di contenimento appropriato e creare la policy.
Contenuti correlati
- Panoramica dei contenitori di esecuzione di Microsoft
- Avvio rapido: Eseguire un workload con MXC SDK
- Creare/redigere e convalidare un criterio/policy MXC
- Opzioni di contenimento MXC e supporto della piattaforma
- Crea e perfeziona i criteri MXC con la modalità di apprendimento
- Esempi di criteri MXC
- Release MXC
Collabora con noi su GitHub
L'origine di questo contenuto è disponibile in GitHub, in cui è anche possibile creare ed esaminare i problemi e le richieste pull. Per ulteriori informazioni, vedere la guida per i collaboratori.
