Arquitetura MXC e modelos de contenção

O MXC separa a intenção da carga de trabalho do mecanismo da plataforma que executa a carga de trabalho. A sua aplicação anfitriã utiliza os SDKs .NET, TypeScript ou Rust para descrever permissões de recursos e solicitar a execução. O MXC traduz o pedido para as operações de um backend de contenção no host atual.

Este design oferece às aplicações uma superfície de integração consistente sem afirmar que todos os backends oferecem as mesmas capacidades ou propriedades de isolamento.

Camadas de arquitetura

Uma integração MXC tem quatro camadas principais:

Camada Responsabilidade
Runtime da aplicação anfitriã ou do agente Classifica a tarefa, seleciona políticas de confiança por defeito, fornece entradas e gere a saída e aprovação
SDK MXC e contrato de política Descobre suporte, converte a intenção da carga de trabalho numa configuração versionada, inicia ambientes isolados e expõe o ciclo de vida e o diagnóstico
Camada de execução MXC Valida a configuração, resolve um backend e traduz o contrato suportado para operações de plataforma
Infraestrutura de contenção Cria o ambiente de execução e aplica as funcionalidades de política que a plataforma e o backend suportam

A aplicação anfitriã continua responsável pelas decisões de política. Um agente de programação pode sugerir um modelo ou subsídio de recursos, mas não deve escolher ou expandir a sua própria autoridade sem lógica fiável ou aprovação humana. O código que o host executa fora do MXC permanece fora do confinamento da carga de trabalho.

Política, configuração e definições de tempo de execução

A política descreve o que a carga de trabalho pode acedecer. O pedido de execução acrescenta o que executar, onde executá-lo e que contentor usar. As definições de tempo de execução fornecem os valores necessários para a execução, como o endpoint de um proxy já em execução.

Os SDKs V1 transportam estas definições num único ContainerRequest. As suas propriedades de sistema de ficheiros, rede e interface descrevem o acesso, e as suas propriedades de comando, diretório de trabalho, ambiente, timeout e contenção descrevem a execução. O SDK converte o pedido para o contrato de esquema estável 1.0.0 , por isso não especificas uma versão do esquema.

A configuração de execução JSON não é intercambiável com um objeto SDK serializado. Por exemplo, as propriedades ui.allowInputInjection e timeoutMs do pedido correspondem às definições ui.injection e process.timeout da configuração. Use os tipos do SDK, ou o esquema da versão de configuração que cria.

Ciclos de vida one-shot e conscientes do estado

O MXC suporta dois padrões de ciclo de vida.

A execução one-shot cria o sandbox, executa uma carga de trabalho e desmonta o sandbox. Usa-o para ferramentas independentes de agente de programação, comandos gerados, builds, testes e scripts. Um novo sandbox estreito para cada ação limita o estado retido e reduz a pressão para criar uma política ampla.

A execução com reconhecimento do estado expõe cinco fases: provision, start, execute, paragem e desprovisionamento. O provisionamento devolve um opaco ContainerId, que o chamador passa inalterado para fases posteriores, e o chamador pode executar múltiplos comandos antes da desmontagem. Use este padrão apenas quando a carga de trabalho depende do estado persistente, como um perfil de agente, ferramentas instaladas, configuração ou um ambiente de sistema operativo. No MXC 1.0, as APIs do ciclo de vida do SDK V1 suportam o IsolationSession e o WSLc.

A execução sensível ao estado não faz da MXC o proprietário do estado. O backend detém o recurso sandbox, e o chamador armazena o seu identificador e gere o seu ciclo de vida. Parar a execução e desprovisionar recursos são operações diferentes; exatamente qual estado sobrevive a uma paragem depende do backend.

Execução, criação de processos e execução em PTY descrevem como o sistema anfitrião interage com um processo em execução, não durante quanto tempo o ambiente existe. Uma chamada de execução devolve a saída capturada quando a execução termina. Uma chamada de spawn dá ao teu host fluxos de entrada, saída e erro padrão em tempo real enquanto a carga de trabalho está a correr. Uma chamada PTY liga a carga de trabalho a um pseudoterminal, incluindo a definição do seu tamanho, que o seu host controla. Verifique o SDK selecionado e o backend para combinações suportadas.

Responsabilidades do anfitrião

Defina um timeout de execução e trate separadamente da falha da carga de trabalho, falha de lançamento e cancelamento. Cancelar a espera de um SDK não é necessariamente o mesmo que terminar o processamento. Siga o contrato de terminação e libertação de recursos do SDK e aguarde o tempo necessário para que a execução e o registo opcional de negação possam ser finalizados.

Para uma execução sensível ao estado, organize a limpeza mesmo quando uma fase posterior falhar. Uma falha ao parar não deve impedir uma tentativa de desprovisionamento dos recursos que a sua aplicação possui.

A desmontagem sandbox geralmente não reverte escritas em diretórios de host concedidos nem ações realizadas através de serviços de rede autorizados. Escolha deliberadamente as localizações de saída e decida quais os resultados reter antes de as tarefas seguintes os utilizarem.

Escolha um tipo de contentor

Comece pelos objetivos e restrições da sua carga de trabalho, por exemplo:

Carga de trabalho necessária Tipo de arranque Porquê
Comandos que necessitam de ferramentas e caminhos selecionados para o host com baixa sobrecarga no arranque Isolamento de processos Executa-se perto do ambiente anfitrião com permissões atribuídas à tarefa
Carga de trabalho que necessita de um perfil Windows separado ou de uma sessão interativa Isolamento da sessão Separa o estado do utilizador e da sessão da carga de trabalho do ambiente interativo do utilizador, sem filtragem de ficheiros MXC, de rede ou da IU
Carga de trabalho que requer um kernel separado ou um sistema operativo convidado Ambiente virtualizado Utiliza um isolamento de VM ou micro-VM, sujeito às capacidades do backend selecionado

No Windows, o isolamento de processos é um tipo comum porque corresponde a muitas cargas de trabalho que necessitam de recursos selecionados do host com baixo custo de arranque.

O isolamento de sessão separa utilizadores e sessões, mas não restringe o acesso aos recursos a que a carga de trabalho pode aceder. No Windows, IsolationSession rejeita políticas do sistema de ficheiros e da interface. O seu pedido deve também definir egress, ingress, and host loopback para allow, sem regras de rede ou proxy. Se a carga de trabalho precisar dessas restrições, escolha um backend que as possa fazer cumprir. Para mais detalhes, consulte Seleção e definições do backend.

Uma intenção abstrata, como process, permite ao MXC resolver um backend específico da plataforma. Escolha um backend concreto quando precisar de um determinado ambiente operacional ou ciclo de vida. Note que nem uma intenção abstrata nem um mecanismo de isolamento mais forte garantem suporte para todos os controlos de ficheiro, de rede ou da interface.

Consulte as opções de contenção MXC e o suporte da plataforma para orientações de seleção e links para documentação detalhada do backend.

Modo de Aprendizagem na arquitetura

Learning Mode ajuda na criação de políticas e diagnósticos para cargas de trabalho do Windows ProcessContainer. Veja Criar e refinar políticas MXC com o Modo de Aprendizagem.

Orientação de conceção para agentes de programação

Ao usar um agente de código para ajudar a escolher um tipo de contenção, peça-lhe que avalie:

  1. Que sistemas operativos e arquiteturas de processadores deve a aplicação suportar?
  2. De que ficheiros, caminhos de rede, funcionalidades da interface de utilizador, dispositivos e ferramentas de host necessita a carga de trabalho?
  3. Cada comando é independente, ou a identidade e o estado têm de persistir entre comandos?
  4. Que restrições de tempo de arranque, uso de recursos, implantação e interação se aplicam?
  5. A carga de trabalho precisa de Windows, Linux, um ambiente de trabalho completo ou outro ambiente operativo?
  6. Qual o limite de isolamento apropriado para as suposições de confiança e dados da carga de trabalho?
  7. Que funcionalidades de política solicitadas pode aplicar cada backend disponível?

O agente deve comparar tipos de contenção viáveis, declarar as suas suposições e trade-offs, e identificar requisitos não suportados. Pode então selecionar um tipo de contenção apropriado e construir a diretiva.

Conteúdo relacionado

  • Última atualização a