Uso de contenedores para aplicar el rigor de la ingeniería de software a las cargas de trabajo de inteligencia artificial

A medida que las cargas de trabajo de inteligencia artificial pasan de los prototipos experimentales a los entornos de producción, las empresas enfrentan un desafío conocido: ¿cómo proteges, gestionas y controlas estos nuevos componentes con el mismo rigor que aplicas a las aplicaciones de software tradicionales? Una pieza clave del rompecabezas radica en algo que tu organización probablemente ya utiliza ampliamente: los contenedores, específicamente los contenedores de Open Container Initiative (OCI).

¿Qué es la Open Container Initiative?

La Open Container Initiative define especificaciones open source para los formatos de imagen, los tiempos de ejecución de los contenedores y la distribución, lo cual ayuda a las organizaciones a evitar la dependencia de un solo proveedor.  Los contenedores OCI son un formato estándar del sector para empaquetar aplicaciones de software, de modo que puedan ejecutarse de manera uniforme en diferentes entornos, motores de contenedores (como Docker o Podman) y plataformas de nube.

Un artefacto de OCI es similar a un contenedor, pero en lugar de imágenes ejecutables, los artefactos almacenan otro contenido, como archivos y directorios.  Los repositorios de artefactos compatibles con OCI (incluidos Quay, Artifactory, Docker Hub y los registros de los principales proveedores de nube) pueden almacenar y gestionar el control de versiones de los contenedores y los artefactos de OCI.

OCI ofrece una forma estandarizada y portátil de empaquetar y distribuir software. Al empaquetar tus modelos de inteligencia artificial, los servidores Model Context Protocol (MCP) y los agentes de inteligencia artificial con contenedores OCI, puedes utilizar tus procesos de seguridad de la cadena de suministro de software, los canales de CI/CD y la infraestructura de orquestación de contenedores actuales. Este enfoque aporta a tu stack de inteligencia artificial el mismo control y capacidad de auditoría que ya aplicas a las cargas de trabajo de tus aplicaciones.

Modelos de inteligencia artificial en contenedores con ModelCar

Los modelos de lenguaje de gran tamaño (LLM) y otros modelos de inteligencia artificial presentan desafíos de empaquetado únicos. Estos constan de archivos binarios grandes, metadatos de configuración y requisitos específicos de estructura de archivos. En el pasado, las organizaciones dependían del almacenamiento de objetos compatible con S3 para distribuir los modelos, pero este enfoque crea fricción con los flujos de trabajo basados en contenedores y los procesos de seguridad actuales. Recomendamos compilar tus modelos de inteligencia artificial en contenedores OCI con una estructura de archivos específica que llamamos ModelCar.

¿Qué es un contenedor ModelCar?

Un contenedor ModelCar es sencillo: los archivos del modelo de inteligencia artificial se colocan en una carpeta /models dentro del contenedor. No se necesitan paquetes ni componentes de tiempo de ejecución adicionales; el contenedor simplemente almacena los artefactos del modelo en un formato compatible con OCI.

Los beneficios de este enfoque son importantes. Una vez que empaquetas tu modelo como contenedor, puedes gestionarlo utilizando los mismos procesos de seguridad de la cadena de suministro de software que ya utilizas para tus contenedores de aplicaciones. Puedes generar una lista de materiales de software (SBOM) y una lista de materiales de inteligencia artificial (AI-BOM) para el contenedor como una tarea en tu canal de CI/CD. También puedes firmar y validar el contenedor, generar certificaciones de procedencia que demuestren que tu sistema de compilación de confianza diseñó el contenedor, almacenar el contenedor en tu repositorio interno de artefactos de OCI y configurar tus políticas de implementación para extraer contenedores solo de repositorios aprobados.

Red Hat Trusted Artifact Signer te permite firmar modelos y validar su autenticidad y transparencia con Sigstore y Rekor. 

Red Hat OpenShift AI 2.14 y las versiones posteriores admiten la distribución de modelos directamente desde los contenedores de ModelCar con KServe, lo cual elimina por completo la dependencia del almacenamiento compatible con S3. Esto simplifica la implementación, mejora los tiempos de inicio del servidor de inferencia, especialmente cuando el contenedor se almacena en caché en un nodo, y proporciona un enfoque unificado para la gestión de artefactos en toda tu organización.

En el repositorio de GitHub hay un catálogo de ejemplos de contenedores de ModelCar que ofrece plantillas y prácticas recomendadas para empaquetar varios tipos de modelos.

Consideraciones sobre el tamaño del modelo

Si bien la especificación OCI no impone límites estrictos en el tamaño de las imágenes, existen restricciones prácticas. Por lo general, los registros de contenedores admiten imágenes que van desde varios GB hasta decenas de GB, y la mayoría de los registros empresariales manejan imágenes de hasta 15-20 GB sin problemas. Para los modelos muy grandes que superan estos límites prácticos, es posible que debas considerar técnicas de cuantificación de modelos para reducir el tamaño de los archivos o mecanismos de distribución alternativos. Sin embargo, para la mayoría de los modelos de producción, especialmente las variantes cuantificadas como la coma flotante de 8 bits (FP8) o el entero de 4 bits (INT4), la creación de contenedores con ModelCar es práctica y recomendada.

Artefactos de OCI para modelos

ModelCar utiliza contenedores OCI para lograr la máxima compatibilidad con los sistemas más antiguos que no son totalmente compatibles con los artefactos OCI, pero podría decirse que los artefactos OCI son una opción mejor y más eficiente para el almacenamiento de modelos. 

Los ingenieros de diseño pueden empaquetar sus modelos en artefactos de OCI en lugar de contenedores y almacenarlos en su repositorio de artefactos de OCI. En el momento de la implementación, puedes montar el artefacto OCI directamente en tu pod de distribución de modelos como almacenamiento, utilizando un volumen de imagen de Kubernetes. El montaje de artefactos OCI se implementa en las versiones recientes de podman y el tiempo de ejecución de contenedores CRI-O en la actualidad, y se está trabajando para otros tiempos de ejecución, incluido Containerd.

Creación de contenedores de servidores MCP para la implementación empresarial

MCP surgió como una forma estándar de conectar a los asistentes y los agentes de inteligencia artificial con herramientas externas, fuentes de datos y API. Los servidores MCP actúan como puentes entre los sistemas de inteligencia artificial y tus recursos empresariales, por lo que su seguridad y gobernanza son fundamentales.

Para los servidores MCP que compartirás entre equipos o implementarás en entornos de producción, te recomendamos integrarlos en contenedores con las mismas herramientas y procesos de diseño que utilizas para tus otras aplicaciones. Este enfoque brinda uniformidad a la hora de gestionar, implementar y proteger estos componentes. El proceso es familiar para cualquiera que haya creado aplicaciones en contenedores: escribe un Containerfile, crea la imagen, envíala a tu registro e impleméntala con Red Hat OpenShift, Kubernetes, Podman o Docker.  Puedes usar tus herramientas de compilación habituales para firmar y verificar los servidores MCP, generar una lista de materiales de software (SBOM, software bill of materials), almacenarlos en repositorios de artefactos de OCI, etc.

Al igual que con cualquier otro software, es posible que un código malicioso ingrese a un servidor MCP. Analiza y valida permanentemente tus servidores MCP con Red Hat Trusted Profile Analyzer para identificar vulnerabilidades, dependencias maliciosas e infracciones de las políticas.

Ventajas de los servidores MCP en contenedores

Los servidores MCP en contenedores pueden escalarse horizontalmente para gestionar el aumento de la carga, supervisarse con herramientas de observabilidad estándar y controlarse mediante tus políticas de seguridad existentes.

El servidor MCP de OpenShift Kubernetes muestra este patrón. Puede ejecutarse localmente para el desarrollo o implementarse en un clúster con el transporte HTTP Streamable para el acceso del equipo. El servidor admite modos de acceso configurables (solo lectura, no destructivo o acceso completo) y se integra con el control de acceso basado en funciones (RBAC, role-based access control) de Kubernetes para la autorización.

Ya se está desarrollando un ecosistema en torno a los servidores MCP en contenedores. Por ejemplo, el operador de ciclo de vida de MCP (MCP lifecycle operator) facilita la implementación de servidores MCP en contenedores y su conexión con tus agentes a través de una configuración nativa de Kubernetes. La puerta de enlace de MCP (MCP Gateway) de Kuadrant ofrece funciones avanzadas de seguridad empresarial. Otras herramientas conocidas, como Docker, también funcionan con servidores MCP en contenedores.

Cuándo no crear contenedores de tus servidores MCP

No todos los servidores MCP se benefician de la creación de contenedores. La especificación MCP admite dos mecanismos de transporte principales: stdio (entrada/salida estándar) y transportes basados en HTTP (que incluyen Streamable HTTP y el transporte heredado de eventos enviados por el servidor [SSE, Server-Sent Events]). Esta distinción es importante para las decisiones de implementación.

Los servidores MCP basados en stdio se comunican a través de flujos de procesos, y el cliente de inteligencia artificial genera el servidor como un proceso secundario. Este modelo funciona bien para los casos de un solo usuario: el asistente de codificación de un desarrollador, una herramienta de productividad local o un script de automatización personal. En estos casos, el servidor MCP se ejecuta en la computadora portátil del usuario, accede a los archivos y recursos locales y termina cuando ya no se necesita. La organización en contenedores de los servidores MCP de stdio aumenta la complejidad sin ofrecer beneficios significativos para estos casos prácticos locales de un solo usuario.

Los servidores MCP basados en HTTP, por el contrario, se ejecutan como procesos independientes que pueden gestionar varias conexiones de clientes al mismo tiempo. Exponen los endpoints de la red y funcionan más como los servicios web tradicionales. Estos servidores son candidatos naturales para la organización en contenedores y se benefician de la implementación, el escalado y la gestión centralizados.

El marco de decisión es el siguiente: 

• Para entornos compartidos o de producción: Si tu servidor MCP se compartirá con un equipo, se accederá a él a través de una red o se implementará en un entorno de servidor, organízalo en contenedores.
• Para agentes en contenedores: Si tu agente se ejecuta en un contenedor, un servidor MCP basado en stdio debe ejecutarse en el mismo contenedor que el agente, mientras que un servidor MCP basado en HTTP debe ejecutarse en un contenedor separado.
• Para uso local de un solo usuario: Si un servidor MCP se ejecuta de forma local en la máquina de un solo desarrollador mediante el transporte stdio, la organización en contenedores es opcional y puede generar una sobrecarga innecesaria. 

Habilidades de los agentes en contenedores

Las habilidades de los agentes surgieron como una alternativa y un complemento para los servidores MCP. Son "carpetas de instrucciones, scripts y recursos que los agentes pueden descubrir y utilizar para hacer las cosas con mayor precisión y eficiencia". La especificación de las habilidades establece que se deben empaquetar como archivos zip. 

Puedes ampliar tu sistema de compilación para empaquetar tus habilidades en contenedores o artefactos de la OCI, al igual que los modelos y los servidores MCP. Luego, puedes firmar y verificar las habilidades, generar una lista de materiales de software (software bill of materials o SBOM), almacenarlas en los repositorios de artefactos de la OCI, descargarlas y adjuntarlas a los pods como si fueran modelos. Debido a que las habilidades pueden contener scripts que pueden ser específicos de una plataforma, la OCI también ofrece funciones para proporcionar un conjunto diferente de archivos para cada plataforma. Si tus aplicaciones que utilizan habilidades aún no pueden trabajar con contenedores o artefactos de la OCI, puedes usar la herramienta de línea de comandos ORAS command line para extraer una habilidad al directorio correcto. 

De manera alternativa, en el futuro, las habilidades podrían gestionarse con administradores de paquetes, de manera similar a como se gestionan otras bibliotecas compartidas para varios lenguajes de programación. En este caso, las habilidades se importarían y utilizarían dentro de los contenedores, pero no necesariamente se distribuirían como contenedores. 

Se trata de una tecnología emergente, así que mantente atento a los desarrollos futuros. 

Organización de los agentes de inteligencia artificial en contenedores

Los agentes de inteligencia artificial (sistemas autónomos que pueden planificar y ejecutar tareas de varios pasos con modelos de inteligencia artificial y otras herramientas) representan la próxima evolución de las aplicaciones de inteligencia artificial. A medida que los agentes pasan de los prototipos a la producción, las empresas necesitan un enfoque estructurado para diseñarlos, implementarlos y gestionarlos.

El proyecto Kagenti proporciona un marco nativo de Kubernetes exactamente para este propósito. Kagenti funciona con cualquier marco de agente o kit de desarrollo de software (software development kit o SDK) y ofrece elementos modulares para la implementación en producción. Básicamente, Kagenti trata a los agentes como cargas de trabajo organizadas en contenedores que se pueden definir de forma declarativa con los recursos personalizados de Kubernetes.

Kagenti utiliza Shipwright y Buildah para compilar agentes en contenedores. Si tu organización utiliza Tekton o Jenkins para CI/CD, puedes agregar una tarea de Buildah similar a tus pipelines actuales. Al igual que con los modelos de inteligencia artificial y los servidores MCP, puedes usar tus herramientas de compilación habituales para firmar y verificar los contenedores de agentes, generar un SBOM, almacenarlos en repositorios de artefactos OCI, etc.

Al igual que los servidores MCP, los agentes en contenedores se pueden escalar horizontalmente para gestionar el aumento de la carga, supervisar con herramientas de observabilidad estándar y controlar mediante tus políticas de seguridad actuales.  También puedes analizar y validar continuamente tus agentes con Red Hat Trusted Profile Analyzer para identificar vulnerabilidades, dependencias maliciosas e infracciones de las políticas.

Agentes y subagentes de usuario único

Al igual que los servidores MCP, no todos los agentes requieren contenedores. Es posible que los agentes que se ejecutan localmente en la computadora portátil de un solo usuario (como los subagentes generados por un asistente de codificación o los agentes de automatización personales) no necesiten la sobrecarga del empaquetado de contenedores y la implementación en Kubernetes. Estos agentes ligeros suelen ejecutarse como procesos secundarios de una aplicación principal y comparten el contexto de seguridad de dicha aplicación.

En estos escenarios de usuario único, el enfoque debe centrarse en verificar que la aplicación principal (el IDE, el asistente de codificación o la herramienta de automatización) esté protegida adecuadamente, en lugar de poner en contenedores cada subcomponente. La gestión empresarial de estos agentes locales es un área en evolución, y las organizaciones deben supervisar los avances en los marcos de trabajo y las herramientas de los agentes.

Contenedores para sandboxing

Dado que los agentes, los servidores MCP y los modelos que escriben y ejecutan código introducen nuevas vulnerabilidades, una práctica recomendada es restringir su acceso a los sistemas y contener el daño que puedan causar. Esto a veces se denomina "sandbox de agentes" o "sandbox de código". 

El software en contenedores se puede implementar con políticas de red que restrinjan la comunicación con servicios externos, desde abrir y bloquear puertos hasta incluir sitios web y servicios específicos en listas de permitidos. Las capacidades de RBAC de Kubernetes y service mesh proporcionan un control detallado sobre el acceso. Los contenedores de OpenShift normalmente se ejecutan sin permisos de root, lo que restringe su acceso a los datos y a los recursos de cómputo.  

Los contenedores también tienen límites en su uso de CPU y memoria. En las estaciones de trabajo de los desarrolladores, Podman ejecuta sus contenedores sin permisos de root de forma predeterminada y también restringe el acceso del contenedor a tu red y sistema de archivos. OpenShift ofrece aislamiento de contenedores desde hace mucho tiempo, y la Red Hat build of Podman Desktop también permite el aislamiento de contenedores en las estaciones de trabajo de los desarrolladores.

Otra preocupación es el procesamiento descontrolado por parte de los agentes, lo que puede provocar un ataque de denegación de servicio. Con OpenShift, los administradores de clústeres pueden establecer resource_quotas para cada espacio de nombres, lo que limita los recursos de GPU, CPU, memoria y almacenamiento que puede consumir cualquier proyecto. Con cuotas de recursos razonables, un agente descontrolado no puede dejar a otras cargas de trabajo sin recursos del clúster.

Si bien pueden ejecutarse en una computadora portátil personal, hemos comprobado que ejecutar asistentes de codificación y agentes personales en un contenedor suele valer la pena. Cuando un agente se ejecuta en un contenedor en un sandbox, no puede dañar los documentos valiosos de tu computadora portátil ni acceder a los datos que no quieras que utilice. Esto significa que puedes preaprobar acciones comunes como la lectura y escritura de archivos, dejar que el agente se ejecute con menos supervisión y simplemente revisar el resultado final de la tarea asignada.

También puedes iniciar varios agentes al mismo tiempo y dejar que realicen su trabajo en paralelo sin interferir entre sí. Puedes implementar agentes de larga duración en tu espacio de nombres personal en OpenShift, cerrar tu computadora portátil e irte a casa mientras los agentes continúan trabajando por ti. Incluso puedes guardar el contenedor del agente para conservar su estado y reanudarlo más tarde. Dos proyectos emergentes en esta área son paude para agentes de codificación y openclaw-installer para OpenClaw.

Ventajas de organizar las cargas de trabajo de inteligencia artificial en contenedores

La organización en contenedores de tus elementos de inteligencia artificial (modelos, servidores MCP y agentes) aporta importantes beneficios que se combinan en toda tu organización.

Seguridad de la cadena de suministro de software

Puedes firmar, dar fe y verificar los contenedores antes de la implementación. Puedes solicitar que tus sistemas de CI/CD de confianza creen todos los elementos de inteligencia artificial, los analicen en busca de vulnerabilidades y los almacenen en registros aprobados. Las certificaciones de procedencia proporcionan un seguimiento de auditoría que muestra exactamente cómo se produjo cada artefacto.

Control de versiones y restauración

Las imágenes de contenedores son inmutables y están etiquetadas. Puedes implementar versiones específicas, volver a versiones anteriores si surgen problemas y mantener un historial claro de qué se implementó y cuándo.

Implementación uniforme

La misma imagen de contenedor se ejecuta de manera idéntica en los entornos de desarrollo, preparación y producción, lo cual reduce el riesgo de que los archivos no se copien correctamente de un entorno a otro.

Observabilidad

Las cargas de trabajo en contenedores se integran con la infraestructura de supervisión y registro existente. Kagenti, por ejemplo, admite el rastreo de OpenTelemetry (OTEL) de forma nativa, lo que te permite supervisar las operaciones de los agentes con tu stack de observabilidad estándar.

Aislamiento y control de acceso

Por último, los contenedores ofrecen funciones avanzadas para el aislamiento de procesos (sandboxing), lo cual ayuda a controlar el alcance de cualquier problema.

De cara al futuro: Identidad de las cargas de trabajo y confianza cero

La organización en contenedores también sienta las bases para patrones de seguridad más avanzados. En el proyecto de Kagenti, se analiza la integración con SPIFFE/SPIRE para la identidad de las cargas de trabajo y la arquitectura de confianza cero para los agentes y los servidores MCP . Si bien estas funciones aún están surgiendo, tener tus elementos de inteligencia artificial organizados en contenedores y ejecutándose en Kubernetes facilita considerablemente la adopción de estas funciones de seguridad a medida que maduran.

La identidad de la carga de trabajo garantiza que cada agente o servidor MCP tenga una identidad verificable mediante criptografía, lo cual permite una comunicación segura entre servicios sin secretos compartidos. Los principios de confianza cero (nunca confiar, siempre verificar) resultan prácticos de implementar cuando tus elementos de inteligencia artificial se organizan en contenedores y se pueden integrar con tu infraestructura de gestión de identidades y accesos existente.

Reflexiones finales

Los contenedores de OCI ofrecen un enfoque estandarizado y probado para empaquetar y distribuir software que se extiende naturalmente a las cargas de trabajo de inteligencia artificial. Al organizar en contenedores tus modelos de inteligencia artificial, servidores MCP y agentes, aportas a tu stack de inteligencia artificial el mismo control, seguridad y madurez operativa que ya aplicas a tus aplicaciones.

La clave es reconocer cuándo la organización en contenedores aporta valor. Los contenedores son esenciales para las implementaciones de producción compartidas y en red. Para el uso local de un solo usuario, los contenedores son opcionales, pero ofrecen aislamiento de procesos (sandboxing) y portabilidad entre dispositivos: se crean una vez y se ejecutan en cualquier lugar. Este enfoque pragmático te permite aplicar el nivel adecuado de control a cada elemento mientras evitas complejidades innecesarias.

Red Hat OpenShift AI, Red Hat Trusted Artifact Signer, Red Hat Trusted Profile Analyzer y Red Hat build of Podman proporcionan una base sólida para gestionar tus cargas de trabajo de inteligencia artificial, desde el prototipo hasta la producción. Red Hat añade soporte empresarial a las herramientas open source con comunidades activas para ayudarte a seguir el ritmo de los avances más recientes en inteligencia artificial.