Opções de contenção MXC e suporte à plataforma

O MXC ajuda a gerir a complexidade da utilização de contentores: utiliza-se o MXC para descrever uma política e gerir o ciclo de vida de um contentor, mas o backend de isolamento selecionado faz a aplicação efetiva. Cada backend é construído sobre um mecanismo de sistema operativo diferente. Como resultado, os backends diferem na forma como isolam uma carga de trabalho e na forma como lidam com ficheiros, rede, interface e ciclo de vida.

Começa pelo que a tua carga de trabalho precisa e depois confirma que um backend pode entregá-lo nos hosts que pretendes. Só o nome ou a versão do sistema operativo não indicam se um backend é suportado.

Compreender os ambientes de host e carga de trabalho

Num pedido, pode pedir um tipo de ambiente, chamado intent de containment, ou pode nomear um backend específico. A process intenção mapeia para o backend nativo de isolamento de processos no host onde estás a correr. Como esse backend difere consoante o sistema operativo, a mesma intenção pode dar-te capacidades diferentes no Windows, Linux e macOS.

Host Backend do processo predefinido Outros ambientes
Windows ProcessContainer Uma sessão Windows separada, uma VM Windows ou cargas de trabalho Linux através do WSLc, quando suportado
Linux Plástico bolha Backends de virtualização LXC e especializados, quando suportados
macOS Cinto de segurança Verifique a release que instala para outras opções suportadas

A workload não tem de ser executada no mesmo sistema operativo que o anfitrião. Por exemplo, o WSLc executa uma carga de trabalho Linux num host Windows. Tem os seus próprios pré-requisitos e partilha recursos com o anfitrião de forma diferente de um sandbox de processos do Windows.

Verifique o estado do lançamento e a cobertura do SDK

O suporte do backend muda de versão para versão, por isso verifica a informação de suporte da versão do pacote que instalas.

No MXC v1.0.0, os SDKs V1 podem criar containers com estes backends:

  • Windows: ProcessContainer, IsolationSession e WSLc
  • Linux: Bubblewrap e LXC
  • macOS: Seatbelt

Windows Sandbox, MicroVM e Hyperlight são experimentais. Exigem autorização experimental explícita, e não se podem criar através das APIs do SDK V1. Se estiveres a considerar um destes ou outro ambiente especializado, consulta primeiro as notas de lançamento da tua versão.

Um backend disponível no host pode ainda não suportar a operação SDK que planeias invocar. Nos SDKs V1:

  • As APIs do ciclo de vida funcionam apenas com o IsolationSession e o WSLc.
  • A execução one-shot PTY funciona com IsolationSession, Bubblewrap, LXC e Seatbelt.
  • A execução do PTY num contentor existente funciona apenas com o IsolationSession.

Para detalhes, consulte as referências do SDK:

Se usares Rust, o suporte ao backend também depende das funcionalidades do crate que ativas. Para usar o IsolationSession ou WSLc, ative a funcionalidade isolation_session ou wslc da crate mxc-sdk. Para mais informações, consulte o guia do Rust SDK.

Comece com a descoberta em tempo de execução

Cada SDK pode dizer-te o que o host atual suporta antes de lançares qualquer coisa. Executa estas verificações primeiro, mas continua a lidar com erros de lançamento também, porque a configuração do host pode mudar entre a verificação e o lançamento.

Utilize o suporte da plataforma para descobrir se é sequer possível lançar contentores, os backends disponíveis para uma visão mais ampla do anfitrião e a sonda para testar uma requisição específica no Windows antes de a executar.

SDK API de descoberta O que deve verificar
.NET MxcPlatform.GetPlatformSupport() IsSupported, Reason e AvailableMethods, que apresentam a lista dos backends que o SDK pode iniciar
.NET MxcPlatform.GetAvailableBackends() Disponibilidade do host, capacidades opcionais e avisos. Algumas APIs de execução não conseguem usar todos os backends aqui listados.
.NET MxcContainer.Probe() No Windows, a camada de isolamento ProcessContainer que o pedido receberia, bem como diagnósticos de compatibilidade específicos do pedido, sem criar um contentor
TypeScript getPlatformSupport() isSupported, reason, availableMethods, e quaisquer avisos e campos de capacidade específicos do host
TypeScript getAvailableBackends() Disponibilidade do host, capacidades opcionais e avisos. Algumas APIs de execução não conseguem usar todos os backends aqui listados.
TypeScript probe() No Windows, o pedido receberia a camada de isolamento ProcessContainer e diagnósticos de compatibilidade específicos do pedido, sem criar um contentor
Ferrugem v1::platform_support() is_supported, reason, available_methods, e, no Linux, capacidade de rede Bubblewrap
Ferrugem v1::available_backends() Disponibilidade do anfitrião, capacidades opcionais e avisos. Algumas APIs de execução não conseguem usar todos os backends aqui listados.
Ferrugem v1::probe() No Windows, o pedido obteria a camada de isolamento ProcessContainer e diagnósticos de compatibilidade específicos do pedido, sem criar um contentor

Campos que não se aplicam ou que não podem ser detetados podem estar em falta nos resultados. O Discovery é uma primeira verificação útil, mas não valida toda a sua política. Para ter a certeza, crie o pedido que planeia executar e confirme que o backend selecionado pode aplicar todos os controlos necessários.

Alguns hosts precisam de componentes adicionais ou de uma configuração de administrador antes de funcionar um backend. Os resultados de descoberta e erros de lançamento podem indicar o que falta, mas isso não dá permissão à tua aplicação ou a um agente de codificação para mudar o host. Pede à pessoa responsável pelo host para seguir os passos de configuração documentados pelo backend.

Para Windows, veja suporte a políticas de versões do sistema operativo. Uma versão para Windows pode ser suportada pelo MXC e ainda assim não ter uma funcionalidade de política específica, por isso verifique ambos os aspetos.

Verifique as restrições de que a sua carga de trabalho necessita

Dois backends podem aceitar a mesma sintaxe da política e ainda assim aplicá-la de forma diferente. Antes de decidir por um backend, considere áreas como:

Area Perguntas a fazer
Ficheiros O backend consegue expressar as permissões de leitura, escrita e negação de que precisas, incluindo as sobrepostas? Partilha ficheiros com o anfitrião, monta-os ou copia-os?
Network Pode impor o seu modelo de rede, seja diretamente ou através de um proxy, incluindo regras de rede privada e de loopback do anfitrião?
IU Pode aplicar as restrições da janela, da área de transferência e de entrada de que precisa?
Lifecycle Executa cada comando de forma independente ou consegue manter o ambiente entre comandos? O que é mantido após uma paragem?
Modo de Aprendizagem O host suporta a captura de bloqueios do ProcessContainer? Se não, que fluxo de trabalho de diagnóstico oferece o backend?

Os guias MXC no GitHub listam as capacidades suportadas, builds do sistema operativo e requisitos para cada backend.

Escolha um backend dentro das suas necessidades

Antes de escolher um backend, escreva:

  • Os sistemas operativos anfitriões e as arquiteturas de processadores que a sua aplicação suporta.
  • O ambiente convidado ou de ferramentas de que a carga de trabalho precisa.
  • O acesso ao ficheiro, à rede, à interface, ao dispositivo e à ferramenta anfitriã de que a carga de trabalho necessita.
  • Se cada comando corre sozinho ou precisa de estado de comandos anteriores.
  • Os seus limites de tempo de arranque, recursos, implementação e interação com o utilizador.
  • Quão forte é o limite de isolamento que a carga de trabalho e os seus dados exigem.
  • Se o backend consegue fazer cumprir todos os controlos de política necessários.

Depois testa todas as configurações de host que suportas, com testes positivos e negativos. Um lançamento bem-sucedido mostra apenas que a MXC aceitou a configuração. Testes negativos, como uma tentativa de escrever fora dos caminhos concedidos, mostram se as restrições realmente se mantêm.

Conteúdo relacionado

  • Última atualização a