Modelos de contención y arquitectura MXC

MXC separa la intención del workload del mecanismo de la plataforma que ejecuta la carga de trabajo. La aplicación host usa el SDK de .NET, TypeScript o Rust para describir los permisos de recursos y la ejecución de solicitudes. MXC traduce la solicitud a las operaciones de un back-end de contención en el host actual.

Este diseño proporciona a las aplicaciones una superficie de integración coherente sin afirmar que cada back-end proporciona las mismas funcionalidades o propiedades de aislamiento.

Capas de arquitectura

Una integración MXC tiene cuatro capas principales:

Nivel Responsabilidad
Aplicación host o tiempo de ejecución del agente Clasifica la tarea, selecciona los valores predeterminados de la directiva de confianza, proporciona entradas y controla la salida y la aprobación.
SDK de MXC y contrato de directiva Detecta la compatibilidad, convierte la intención de la carga de trabajo en una configuración versionada, inicia los sandbox y expone el ciclo de vida y los diagnósticos
Capa de ejecución de MXC Valida la configuración, resuelve un back-end y traduce el contrato admitido a las operaciones de la plataforma
Back-end de contención Crea el entorno de ejecución y hace cumplir las características de directiva que admite la plataforma y el back-end.

La aplicación host sigue siendo responsable de las decisiones de directiva. Un agente de codificación puede sugerir un modelo o concesión de recursos, pero no debe elegir ni expandir su propia autoridad sin lógica de confianza ni aprobación humana. El código que el host ejecuta fuera de MXC permanece fuera de la contención de la carga de trabajo.

Directiva, configuración y configuración del tiempo de ejecución

La directiva describe a qué puede acceder la carga de trabajo. La solicitud de ejecución añade qué ejecutar, dónde ejecutarlo y qué contención usar. La configuración en tiempo de ejecución proporciona valores necesarios para la ejecución, como un punto de conexión del proxy que ya está en ejecución.

Los SDK V1 llevan estas configuraciones en un solo ContainerRequest. Sus propiedades de sistema de archivos, red y interfaz de usuario describen el acceso y sus propiedades de comando, directorio de trabajo, entorno, tiempo de espera y contención describen la ejecución. El SDK convierte la solicitud en el contrato de esquema estable 1.0.0 , por lo que no se especifica una versión de esquema.

La configuración de ejecución de JSON no es intercambiable con un objeto SDK serializado. Por ejemplo, las propiedades ui.allowInputInjection y process.timeout de la solicitud corresponden a los valores ui.injection y timeoutMs de la configuración. Use los tipos del SDK, o el esquema para la versión de configuración que cree.

Ciclos de vida de una sola vez y con estado

MXC admite dos patrones de ciclo de vida.

La ejecución de una sola vez crea el sandbox, ejecuta una carga de trabajo y desmonta el sandbox. Úselo para herramientas independientes de agente de codificación, comandos generados, compilaciones, pruebas y scripts. Un nuevo sandbox restringido para cada acción limita el estado retenido y reduce la presión por crear una directiva amplia.

La ejecución con estado expone cinco fases: provisionar, iniciar, ejecutar, detener y desprovisionar. El aprovisionamiento devuelve un objeto opaco ContainerId, que quien realiza la llamada pasa sin cambios a las fases posteriores, y quien realiza la llamada puede ejecutar varios comandos antes del cierre. Use este patrón solo cuando la carga de trabajo dependa del estado persistente, como un perfil de agente, herramientas instaladas, configuración o un entorno de sistema operativo. En MXC 1.0, las API del ciclo de vida del SDK V1 admiten IsolationSession y WSLc.

La ejecución con reconocimiento de estado no hace que MXC sea el propietario del estado. El back-end posee el recurso sandbox y el cliente almacena su identificador y administra su ciclo de vida. Detener la ejecución y desaprovisionar recursos son diferentes operaciones; exactamente qué estado sobrevive a una parada depende del back-end.

Ejecución de run, spawn y PTY describe cómo interactúa el host con un proceso en ejecución, no cuánto tiempo existe el entorno. Una llamada de ejecución devuelve la salida capturada cuando finaliza la ejecución. Una llamada spawn da al host los flujos activos de entrada estándar, salida y error mientras la carga de trabajo se ejecuta. Una llamada PTY conecta la carga de trabajo a un pseudoterminal que el host controla, incluido su tamaño. Compruebe el SDK y el back-end seleccionados para ver las combinaciones admitidas.

Responsabilidades del anfitrión

Establezca un tiempo de espera de ejecución y controle el fallo de la carga de trabajo, el error de inicio y la cancelación por separado. La cancelación de una espera del SDK no es necesariamente lo mismo que terminar la carga de trabajo. Siga el contrato de terminación y eliminación del SDK, y complete la espera requerida para que la ejecución y la captura opcional de denegaciones se finalicen.

Para la ejecución con reconocimiento de estado, organice la limpieza incluso cuando se produzca un error en una fase posterior. Una detención con error no debe impedir un intento de desaprovisionar los recursos que posee la aplicación.

El desmontaje del espacio aislado no suele deshacer las escrituras en directorios del host autorizados ni las acciones realizadas a través de los servicios de red permitidos. Elija las ubicaciones de salida con cuidado y decida qué resultados conservar antes de que las tareas posteriores los usen.

Elegir un tipo de contención

Comience con los objetivos y restricciones de la carga de trabajo, por ejemplo:

Necesidad de carga de trabajo Tipo de inicio Por qué
Comandos que necesitan herramientas y rutas de host seleccionadas con bajo coste de inicio Aislamiento de procesos Se ejecuta en el entorno del host con permisos en el ámbito de la tarea.
Carga de trabajo que necesita un perfil de Windows independiente o una sesión interactiva Aislamiento de sesión Separa el estado de usuario y de sesión de la carga de trabajo del entorno del usuario interactivo, sin filtrado de archivos, red ni interfaz de MXC
Carga de trabajo que requiere un entorno operativo invitado o kernel independiente Entorno virtualizado Usa un límite de máquina virtual o micro vm, sujeto a las funcionalidades del back-end seleccionado.

En Windows, el aislamiento de procesos es un tipo común porque coincide con muchas cargas de trabajo que necesitan recursos host seleccionados con un bajo costo de inicio.

El aislamiento de sesión separa los usuarios y las sesiones, pero no restringe a qué puede acceder la carga de trabajo. En Windows, IsolationSession rechaza las directivas de interfaz de usuario y del sistema de archivos. Su solicitud también debe establecer la salida, la entrada y el bucle de retorno del host en allow, sin reglas de red ni proxy. Si la carga de trabajo necesita esas restricciones, elija un back-end que pueda aplicarlas. Para obtener más información, consulte Configuración y selección de back-end.

Una intención abstracta, como process, permite a MXC resolver un back-end específico de la plataforma. Seleccione un back-end concreto cuando necesite un entorno operativo o un ciclo de vida concretos. Tenga en cuenta que ni una intención abstracta ni un mecanismo de aislamiento más fuerte garantizan la compatibilidad con cada control de archivos, red o interfaz.

Consulte opciones de contención de MXC y compatibilidad con la plataforma para obtener instrucciones de selección y vínculos a documentación detallada del back-end.

Modo de aprendizaje en la arquitectura

El Modo de aprendizaje ayuda con la creación de directivas y el diagnóstico para cargas de trabajo ProcessContainer de Windows. Consulte Creación y refinación de directivas MXC con el modo de aprendizaje.

Guía de diseño para agentes de programación

Al usar un agente de código para ayudar a elegir un tipo de contención, pídale que evalúe:

  1. ¿Qué sistemas operativos y arquitecturas de procesador deben admitir la aplicación?
  2. ¿Qué archivos, rutas de acceso de red, características de interfaz de usuario, dispositivos y herramientas de host necesita la carga de trabajo?
  3. ¿Cada comando es independiente o debe conservar la identidad y el estado entre los comandos?
  4. ¿Qué restricciones de tiempo de inicio, uso de recursos, implementación e interacción se aplican?
  5. ¿Necesita la carga de trabajo Windows, Linux, un escritorio completo u otro entorno operativo?
  6. ¿Qué límite de aislamiento es adecuado para las suposiciones sobre la confianza y los datos de la carga de trabajo?
  7. ¿Qué características de directiva solicitadas puede aplicar cada back-end disponible?

El agente debería comparar los tipos de contención viables, exponer sus suposiciones y compensaciones, e identificar los requisitos no admitidos. A continuación, puede seleccionar un tipo de contención adecuado y crear la directiva.

Contenido relacionado

  • Se actualizó por última vez el