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 consente di gestire la complessità dell'uso dei contenitori: si usa MXC per descrivere una politica e gestire il ciclo di vita di un contenitore, ma il back-end di contenimento selezionato esegue l'applicazione effettiva. Ogni back-end si basa su un differente meccanismo del sistema operativo. Di conseguenza, i back-end differiscono nel modo in cui isolano un carico di lavoro e nel modo in cui gestiscono file, rete, interfaccia utente e ciclo di vita.
Parti dalle esigenze del carico di lavoro e quindi verifica che un back-end possa fornirlo negli host di destinazione. Il nome o la versione del sistema operativo da soli non indicano se supportano un back-end.
Comprendere gli ambienti host e del carico di lavoro
In una richiesta è possibile richiedere un tipo di ambiente, denominato containment intent, oppure assegnare un nome a un back-end specifico. L'process intent viene mappato al back-end nativo di isolamento del processo sull'host in uso. Poiché tale back-end varia a seconda del sistema operativo, la stessa finalità può offrire funzionalità diverse in Windows, Linux e macOS.
| Host | Back-end di processo predefinito | Altri ambienti |
|---|---|---|
| Windows | ProcessContainer | Una sessione di Windows separata, una macchina virtuale Windows o carichi di lavoro Linux tramite WSLc, se supportato |
| Linux | Bubblewrap | LXC e backend di virtualizzazione specializzati, ove supportato |
| macOS | Cintura di sicurezza | Controllare la release che si installa per altre opzioni supportate |
Il carico di lavoro non deve necessariamente essere eseguito nello stesso sistema operativo dell'host. Ad esempio, WSLc esegue un carico di lavoro Linux in un host Windows. Ha i propri prerequisiti e condivide le risorse con l'host in modo diverso rispetto a una sandbox del processo di Windows.
Controllare lo stato di rilascio e la copertura dell’SDK
Il supporto back-end cambia da una release all'altra, quindi controllare le informazioni di supporto per la versione del pacchetto installata.
In MXC v1.0.0 gli SDK V1 possono creare contenitori con questi back-end:
- Windows: ProcessContainer, IsolationSession e WSLc
- Linux: Bubblewrap e LXC
- macOS: Seatbelt
Windows Sandbox, MicroVM e Hyperlight sono sperimentali. Richiedono l'autorizzazione sperimentale esplicita e non è possibile crearli tramite le API V1 SDK. Se si sta valutando uno di questi o un altro ambiente specializzato, controllare prima le note sulla versione per la propria versione.
Un back-end disponibile nell'host potrebbe comunque non supportare l'operazione SDK che si prevede di chiamare. Negli SDK V1:
- Le API del ciclo di vita funzionano solo con IsolationSession e WSLc.
- L'esecuzione PTY a colpo singolo funziona con IsolationSession, Bubblewrap, LXC e Seatbelt.
- L'esecuzione PTY in un contenitore esistente funziona solo con IsolationSession.
Per informazioni dettagliate, vedere i riferimenti dell’SDK:
- Scegliere un'operazione di avvio .NET
- Scegliere un'operazione di avvio di TypeScript
- Scegliere un'operazione di avvio di Rust
- Ciclo di vita del contenitore MXC
Se si usa Rust, il supporto back-end dipende anche dalle funzionalità di crate abilitate. Per usare IsolationSession o WSLc, abilitare la funzionalità mxc-sdk o isolation_session del crate wslc. Per altre informazioni, vedere la guida di Rust SDK.
Inizia con il rilevamento del runtime
Ogni SDK può indicare cosa supporta l'host corrente prima di avviare qualsiasi elemento. Eseguire prima questi controlli, ma continuare a gestire gli errori di avvio, perché la configurazione dell'host può cambiare tra il controllo e l'avvio.
Usa il supporto della piattaforma per scoprire se puoi avviare i contenitori, i back-end disponibili per avere una visione più ampia dell'host e la sonda per testare una richiesta specifica su Windows prima di eseguirla.
| SDK | API Discovery | Controlli da eseguire |
|---|---|---|
| .NET | MxcPlatform.GetPlatformSupport() |
IsSupported, Reason e AvailableMethods, che insieme elencano i back-end che l'SDK può avviare |
| .NET | MxcPlatform.GetAvailableBackends() |
Disponibilità host, funzionalità facoltative e avvisi. Alcune API di esecuzione non possono usare ogni back-end elencato qui. |
| .NET | MxcContainer.Probe() |
In Windows, il livello di isolamento ProcessContainer che la richiesta otterrebbe e la diagnostica di compatibilità specifica della richiesta, senza creare un contenitore |
| TypeScript | getPlatformSupport() |
isSupported, reasonavailableMethods, e qualsiasi avviso specifico dell'host e campo di funzionalità |
| TypeScript | getAvailableBackends() |
Disponibilità host, funzionalità facoltative e avvisi. Alcune API di esecuzione non possono usare ogni back-end elencato qui. |
| TypeScript | probe() |
In Windows, il livello di isolamento ProcessContainer che la richiesta otterrebbe e la diagnostica di compatibilità specifica della richiesta, senza creare un contenitore |
| Rust | v1::platform_support() |
is_supported, reason, available_methods e, su Linux, la funzionalità di rete di Bubblewrap |
| Rust | v1::available_backends() |
Disponibilità host, funzionalità facoltative e avvisi. Alcune API di esecuzione non possono usare ogni back-end elencato qui. |
| Rust | v1::probe() |
In Windows, il livello di isolamento ProcessContainer che la richiesta otterrebbe e la diagnostica di compatibilità specifica della richiesta, senza creare un contenitore |
I campi che non si applicano o non possono essere rilevati potrebbero non essere presenti nei risultati. L'individuazione è un primo controllo utile, ma non convalida l'intera policy. Per assicurarsi, creare la richiesta che si prevede di eseguire e verificare che il back-end selezionato possa applicare ogni controllo richiesto.
Alcuni host richiedono componenti aggiuntivi o la configurazione da parte dell'amministratore prima che un back-end funzioni. I risultati dell'individuazione e gli errori di avvio possono indicare cosa manca, ma ciò non concede all'app o a un agente di codifica l'autorizzazione per modificare l'host. Chiedere alla persona che gestisce l'host di seguire i passaggi di configurazione documentati del back-end.
Per Windows, vedere supporto dei criteri relativi alla versione del sistema operativo. Una versione Windows può essere supportata da MXC e non disporre comunque di una funzionalità di criteri specifica, quindi verifica entrambi gli aspetti.
Controllare le restrizioni richieste dal tuo carico di lavoro
Due back-end possono accettare la stessa sintassi dei criteri e applicarla in modo diverso. Prima di scegliere un backend, considera aree come:
| Area | Domande da porsi |
|---|---|
| File | Il back-end può esprimere le autorizzazioni di lettura, scrittura e negazione dell'accesso necessarie, incluse quelle sovrapposte? Condivide i file con l'host, li monta o li copia? |
| Network | Può applicare il tuo modello di rete, direttamente o tramite un proxy, incluse le regole di rete privata e di host-loopback? |
| Interfaccia utente | Può applicare le restrizioni necessarie alla finestra, agli Appunti e all'input? |
| Lifecycle | Esegue ogni comando in modo indipendente o può mantenere l'ambiente tra i comandi? Cosa viene mantenuto dopo un arresto? |
| Modalità di apprendimento | L'host supporta l'acquisizione dei rifiuti di ProcessContainer? In caso contrario, quale flusso di lavoro di diagnosi fornisce il back-end? |
Le guide MXC in GitHub elencano le funzionalità supportate, le build del sistema operativo e i requisiti per ogni back-end.
Scegli un back-end in base ai tuoi requisiti
Prima di selezionare un back-end, annotare:
- I sistemi operativi host e le architetture del processore supportati dalla tua app.
- L'ambiente guest o degli strumenti necessario al carico di lavoro.
- Gli accessi a file, rete, interfaccia utente, dispositivo e strumento host richiesti dal carico di lavoro.
- Indica se ogni comando viene eseguito autonomamente o richiede lo stato dei comandi precedenti.
- Limiti relativi al tempo di avvio, alle risorse, alla distribuzione e all'interazione dell'utente.
- Quanto sia forte un limite di isolamento che il carico di lavoro e i relativi dati richiedono.
- Se il back-end può applicare ogni controllo dei criteri necessario.
Testare quindi ogni configurazione host supportata, con test positivi e negativi. Un avvio riuscito mostra solo che MXC ha accettato la configurazione. I test negativi, ad esempio un tentativo di scrivere al di fuori dei percorsi concessi, indicano se le restrizioni sono effettivamente applicate.
Contenuti correlati
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.
