Containerization

La contenerización es una forma de empaquetar software en la que una aplicación y todo lo que necesita para ejecutarse —incluidos su entorno de ejecución, bibliotecas, paquetes del sistema y configuración— se agrupan en una imagen que se ejecuta como un proceso aislado llamado contenedor. Cada contenedor tiene su propio sistema de archivos, árbol de procesos e interfaces de red, mientras que todos los contenedores de un host comparten el núcleo del sistema operativo de ese host, por lo que son mucho más ligeros que las máquinas virtuales. En aprendizaje automático (ML), la contenerización elimina los conflictos entre proyectos que necesitan distintas versiones de Python, CUDA o PyTorch, y permite ejecutar sin cambios en un servidor, un clúster o un dispositivo de computación en el borde un modelo entrenado en una estación de trabajo.

Cómo funcionan los contenedores#

Los contenedores de Linux se basan principalmente en dos funciones del núcleo. Los espacios de nombres controlan lo que puede ver un proceso y le proporcionan sus propios identificadores de proceso, pila de red, puntos de montaje y usuarios; los grupos de control, o cgroups, controlan lo que puede utilizar al limitar la CPU, la memoria y la E/S. La idea surgió de chroot en 1979 y de las jaulas de FreeBSD en 2000; cgroups se incorporó al núcleo de Linux en 2008, y Docker popularizó los contenedores en 2013. La Open Container Initiative (OCI), fundada en 2015, estandarizó los formatos de imagen y de ejecución, de modo que una imagen creada con una herramienta también se ejecuta con otra.

Un entorno de ejecución de contenedores hace el trabajo. Los entornos de alto nivel, como containerd y CRI-O, descargan imágenes y gestionan los ciclos de vida de los contenedores; un entorno OCI de bajo nivel, como runc, crea los espacios de nombres y los grupos de control, e inicia el proceso. Como los contenedores de Linux necesitan un núcleo de Linux, macOS y Windows los ejecutan dentro de una pequeña máquina virtual de Linux.

Imágenes, capas y registros#

Una imagen es una pila de capas de solo lectura más una configuración que indica qué comando ejecutar. Al iniciarse, el entorno de ejecución fusiona las capas en un único sistema de archivos, normalmente con OverlayFS, y añade una fina capa de escritura para ese contenedor, de modo que muchos contenedores comparten una sola copia de la imagen en el disco. Los registros, como Docker Hub, GitHub Container Registry y el registro de cada proveedor de nube, almacenan imágenes con etiquetas como latest y con resúmenes de contenido: hashes SHA-256 que siempre identifican los mismos bytes. Las compilaciones reutilizan las capas que no han cambiado, por eso los Dockerfiles instalan las dependencias antes de copiar el código que se edita con frecuencia:

Contenerización en los flujos de trabajo de ML#

En las canalizaciones de MLOps, los contenedores llevan un proyecto del experimento a producción. Las imágenes de frameworks, como las del catálogo NVIDIA NGC, fijan las versiones de CUDA, cuDNN y los frameworks para que todos los nodos de un trabajo de entrenamiento distribuido ejecuten el mismo software; el host solo proporciona el controlador de la GPU, que el NVIDIA Container Toolkit pone a disposición del contenedor. Las pruebas de integración continua se ejecutan en la misma imagen que se publicará más adelante; los servidores de inferencia para el servicio de modelos se ejecutan como imágenes que Kubernetes replica y escala según el tráfico; y los dispositivos de IA perimetral, como las placas NVIDIA Jetson, actualizan un modelo descargando una nueva etiqueta de imagen.

La integración local de Ultralytics Platform para espacios de trabajo Enterprise instala Docker si hace falta y ejecuta un contenedor de trabajo desde la imagen oficial de Ultralytics que corresponda al hardware ARM64, CPU o GPU NVIDIA del host. El trabajador monta la carpeta del conjunto de datos en modo de solo lectura, de modo que las imágenes originales permanecen en ese ordenador, mientras que las métricas de entrenamiento y el mejor punto de control de cada ejecución de YOLO26 se envían a Platform.

Contenedores y máquinas virtuales#

Una máquina virtual ejecuta un sistema operativo invitado completo con su propio núcleo sobre un hipervisor, por lo que cada máquina virtual incluye una imagen del sistema operativo de varios gigabytes y se inicia como un ordenador independiente. Un contenedor es un proceso normal que se ejecuta sobre el núcleo compartido del host, por lo que se inicia tan rápido como su aplicación y solo añade sus propios archivos. Compartir el núcleo también implica que una vulnerabilidad en este podría dejar expuestos todos los contenedores de un host, así que a menudo se combinan ambos enfoques: las nubes públicas ejecutan los contenedores de los clientes dentro de máquinas virtuales, y los entornos aislados añaden una segunda barrera para el código no confiable, como el que escriben y ejecutan los agentes de IA en entornos aislados para agentes. gVisor de Google intercepta las llamadas al sistema de un contenedor mediante su propio núcleo en espacio de usuario. Kata Containers ejecuta cada contenedor dentro de una máquina virtual ligera, y AWS creó sus microVM Firecracker para aislar de la misma manera las funciones de AWS Lambda.