Opciones de contención de MXC y compatibilidad con la plataforma

MXC le ayuda a administrar la complejidad del uso de contenedores: usa MXC para describir una directiva y administrar el ciclo de vida de un contenedor, pero el back-end de contención seleccionado realiza la aplicación real. Cada back-end se basa en un mecanismo de sistema operativo diferente. Como resultado, los back-end difieren en cómo aíslan una carga de trabajo y en cómo controlan archivos, redes, interfaz de usuario y ciclo de vida.

Empiece por lo que necesita la carga de trabajo y confirme que un back-end puede proporcionarlo en los hosts a los que se dirige. El nombre o la versión del sistema operativo no le indicarán si se admite un back-end.

Comprender los entornos del host y de la carga de trabajo

En una solicitud, puede pedir un tipo de entorno, llamado intención de contención, o puede nombrar un back-end específico. El process intent se asigna al back-end nativo de aislamiento de procesos en el host en el que se ejecuta. Dado que el back-end difiere según el sistema operativo, la misma intención puede proporcionar funcionalidades diferentes en Windows, Linux y macOS.

Host Back-end de proceso predeterminado Otros entornos
Windows ProcessContainer Una sesión de Windows independiente, una VM de Windows o cargas de trabajo de Linux a través de WSLc, donde se admita
Linux Bubblewrap LXC y back-ends de virtualización especializados, donde se admitan
macOS Cinturón de seguridad Compruebe la versión que instala para otras opciones admitidas

La carga de trabajo no tiene que ejecutarse en el mismo sistema operativo que el host. Por ejemplo, WSLc ejecuta una carga de trabajo de Linux en un host de Windows. Tiene sus propios requisitos previos y comparte recursos con el host de forma diferente a lo que hace un espacio aislado de proceso de Windows.

Comprobación del estado de la versión y cobertura del SDK

La compatibilidad del back-end cambia de una versión a otra, por lo que compruebe la información de soporte técnico de la versión del paquete que instale.

En MXC v1.0.0, los SDK V1 pueden crear contenedores con estos back-end:

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

Windows Sandbox, MicroVM e Hyperlight son experimentales. Requieren autorización experimental explícita y no se pueden crear a través de las API del SDK V1. Si está considerando uno de estos u otro entorno especializado, consulte las notas de la versión de su versión en primer lugar.

Es posible que un back-end que esté disponible en el host todavía no admita la operación del SDK a la que planea llamar. En los SDK V1:

  • Las API de ciclo de vida solo funcionan con IsolationSession y WSLc.
  • La ejecución de PTY de una sola vez funciona con IsolationSession, Bubblewrap, LXC y Seatbelt.
  • La ejecución de PTY en un contenedor existente solo funciona con IsolationSession.

Para obtener más información, consulte las referencias del SDK:

Si usa Rust, la compatibilidad con back-end también depende de las funciones del crate que habilite. Para usar IsolationSession o WSLc, habilite la característica isolation_session o wslc del crate mxc-sdk. Para más información, consulte la guía del SDK de Rust.

Comience con la detección en tiempo de ejecución

Cada SDK puede indicarle qué admite el host actual antes de iniciar cualquier cosa. Ejecute primero estas comprobaciones, pero siga controlando los errores de inicio, ya que la configuración del host puede cambiar entre la comprobación y el inicio.

Use la compatibilidad de plataforma para averiguar si puede lanzar contenedores en absoluto, los back-ends disponibles para una vista más amplia del host y la sonda para probar una solicitud específica en Windows antes de ejecutarla.

SDK API de descubrimiento Elementos que se deben comprobar
.NET MxcPlatform.GetPlatformSupport() IsSupported, Reason y AvailableMethods, que enumera los back-ends que el SDK puede lanzar
.NET MxcPlatform.GetAvailableBackends() Disponibilidad del host, funcionalidades opcionales y advertencias. Algunas API de ejecución no pueden usar todos los back-end que se enumeran aquí.
.NET MxcContainer.Probe() En Windows, el nivel de aislamiento ProcessContainer que obtendría la solicitud y los diagnósticos de compatibilidad específicos de la solicitud, sin crear un contenedor
TypeScript getPlatformSupport() isSupported, reason, availableMethods y cualquier advertencia y campo de capacidad específicos del host
TypeScript getAvailableBackends() Disponibilidad del host, funcionalidades opcionales y advertencias. Algunas API de ejecución no pueden usar todos los back-end que se enumeran aquí.
TypeScript probe() En Windows, el nivel de aislamiento ProcessContainer que obtendría la solicitud y los diagnósticos de compatibilidad específicos de la solicitud, sin crear un contenedor
Rust v1::platform_support() is_supported, reason, available_methods y, en Linux, capacidad de red Bubblewrap
Rust v1::available_backends() Disponibilidad del host, funcionalidades opcionales y advertencias. Algunas API de ejecución no pueden usar todos los back-end que se enumeran aquí.
Rust v1::probe() En Windows, el nivel de aislamiento ProcessContainer que obtendría la solicitud y los diagnósticos de compatibilidad específicos de la solicitud, sin crear un contenedor

Es posible que falten campos que no se apliquen o que no se puedan detectar en los resultados. La detección es una comprobación inicial útil, pero no valida toda su directiva. Para asegurarse, cree la solicitud que planea ejecutar y confirme que el back-end seleccionado puede imponer cada control que requiera.

Algunos hosts necesitan componentes adicionales o configuración de administrador antes de que funcione un back-end. Los resultados de la detección y los errores de inicio pueden indicar lo que falta, pero eso no concede permiso a la aplicación ni a un agente de codificación para cambiar el host. Pida a la persona que administra el host que siga los pasos de configuración documentados del back-end.

Para Windows, vea Compatibilidad de la directiva de la versión del sistema operativo. MXC puede admitir una versión de Windows y seguir sin tener una característica de directiva determinada, por lo que debe comprobar ambas cosas.

Comprobar las restricciones que necesita su carga de trabajo

Dos back-end pueden aceptar la misma sintaxis de directiva y aplicarla de forma diferente. Antes de decidirse por un backend, considere áreas como:

Area Preguntas que debe formularse
Archivos ¿Puede el back-end expresar los permisos de lectura, escritura y denegación que necesita, incluidos los superpuestos? ¿Comparte archivos con el host, los monta o los copia?
Red ¿Puede imponer su modelo de red, ya sea directa o a través de un proxy, incluidas las reglas de red privada y de bucle de retorno del host?
Interfaz de usuario ¿Puede aplicar las restricciones de ventana, portapapeles y entrada que necesita?
Lifecycle ¿Ejecuta cada comando de forma independiente o puede mantener el entorno entre los comandos? ¿Qué se conserva tras una detención?
Modo de aprendizaje ¿Admite el host la captura de denegaciones de ProcessContainer? Si no es así, ¿qué flujo de trabajo de diagnóstico proporciona el back-end?

Las guías de MXC sobre GitHub enumeran las funcionalidades admitidas, las compilaciones del sistema operativo y los requisitos de cada back-end.

Elija un back-end según sus requisitos

Antes de elegir un back-end, anote:

  • Los sistemas operativos host y las arquitecturas de procesador que admite la aplicación.
  • El entorno de invitado o de herramienta que necesita la carga de trabajo.
  • El acceso a archivos, red, interfaz, dispositivo y herramienta del host que necesita la carga de trabajo.
  • Si cada comando se ejecuta por sí mismo o necesita el estado de los comandos anteriores.
  • Tus límites en el tiempo de inicio, los recursos, la implementación y la interacción del usuario.
  • La solidez del límite de aislamiento que requieren la carga de trabajo y sus datos.
  • Si el back-end puede aplicar cada control de directiva que necesite.

A continuación, pruebe cada configuración de host que admita, con pruebas positivas y negativas. Un inicio correcto solo muestra que MXC aceptó la configuración. Las pruebas negativas, como un intento de escribir fuera de las rutas de acceso concedidas, muestran si las restricciones realmente se cumplen.

Contenido relacionado

  • Se actualizó por última vez el