Docker

Docker es una plataforma de código abierto para crear, compartir y ejecutar aplicaciones en contenedores: procesos aislados que incluyen su propio sistema de archivos con código, bibliotecas y paquetes del sistema, pero comparten el kernel del sistema operativo del host. dotCloud, la empresa que más tarde pasó a llamarse Docker, Inc., publicó su código como software de código abierto en marzo de 2013, y su herramienta de línea de comandos, el formato de imágenes por capas y el registro público convirtieron los contenedores de Linux en una herramienta cotidiana para desarrolladores. En aprendizaje automático, una imagen de Docker fija la versión exacta de Python, las bibliotecas CUDA, la compilación de PyTorch y los pesos del modelo, para que el modelo se comporte igual en un portátil, un servidor con GPU, un ejecutor de integración continua y un dispositivo perimetral.

Cómo funciona Docker#

Un Dockerfile enumera los pasos para crear una imagen: una imagen base de partida, comandos para instalar paquetes, archivos que copiar y el comando que se ejecutará al iniciarse. Cada instrucción RUN, COPY o ADD añade una capa de solo lectura, y la siguiente compilación reutiliza las capas almacenadas en caché hasta que cambia una instrucción o uno de sus archivos de entrada. Así, las dependencias instaladas al principio permanecen en caché mientras el código de la aplicación se vuelve a compilar en segundos. Una imagen es esa pila de capas más los metadatos. Un contenedor es una instancia en ejecución de una imagen con una fina capa de escritura encima, que se elimina junto con el contenedor, salvo que los datos se guarden en un volumen montado.

El comando docker se comunica con Docker Engine, un daemon en segundo plano que delega cada contenedor a containerd y al entorno de ejecución de bajo nivel runc. Estos usan espacios de nombres de Linux para aislar los procesos, la red y el sistema de archivos de un contenedor, y cgroups para limitar su CPU y memoria. Las imágenes se comparten mediante registros como Docker Hub, GitHub Container Registry, NVIDIA NGC y el registro propio de cada proveedor de servicios en la nube. Siguen el formato de imágenes de la Open Container Initiative, por lo que Podman, containerd y Kubernetes las ejecutan sin cambios.

Ultralytics publica imágenes oficiales de Docker para cada plataforma de hardware, incluidas las GPU CUDA, las CPU, las placas ARM64, los dispositivos NVIDIA Jetson y las GPU AMD. Cada imagen también lleva una etiqueta con el número de versión de Ultralytics para permitir compilaciones reproducibles. La imagen ligera latest-python que se usa a continuación ya incluye Python, PyTorch, el paquete ultralytics y los pesos nano de YOLO26, por lo que el Dockerfile de un proyecto solo tiene que añadir su propio código:

# Official Ultralytics CPU image with Python, PyTorch, ultralytics, and yolo26n.pt
FROM ultralytics/ultralytics:latest-python

# Install extra dependencies in their own layer, cached until requirements.txt changes
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Copy the application last, so code edits rebuild only this layer
COPY app.py .

# Command every container runs when it starts
CMD ["python", "app.py"]

docker build -t yolo-app . convierte este archivo y los archivos que lo acompañan en una imagen, y docker run --rm yolo-app inicia un contenedor a partir de ella. Si subes la imagen a un registro, cualquier otro equipo podrá descargarla y ejecutar el mismo entorno, por ejemplo, como API de servicio de modelos o como tarea nocturna de inferencia.

Docker para el aprendizaje automático#

Los contenedores acceden a las GPU mediante el NVIDIA Container Toolkit. El controlador de NVIDIA permanece en el host y la imagen solo contiene bibliotecas CUDA de espacio de usuario, que deben ser compatibles con ese controlador. En Linux, Docker 28.2 y versiones posteriores habilitan CDI de forma predeterminada, por lo que --device nvidia.com/gpu=all solicita las GPU como dispositivos CDI y conserva el acceso a ellas en contenedores de larga duración, mientras que el indicador anterior --gpus all puede perderlo cuando el host vuelve a cargar systemd.

Hay otros dos ajustes importantes para el entrenamiento. Los trabajadores del cargador de datos de PyTorch envían lotes al proceso de entrenamiento a través de la memoria compartida en /dev/shm, que Docker limita a 64 MB de forma predeterminada. Por eso, los contenedores de entrenamiento se ejecutan con --ipc=host o con un valor mayor de --shm-size. Los conjuntos de datos y los resultados deben guardarse en volúmenes montados, ya que una ejecución de entrenamiento que escriba los puntos de control dentro del contenedor los perderá al eliminarlo. Fijar una etiqueta de versión o el resumen de una imagen en lugar de latest mantiene una tarea de entrenamiento distribuido o una implementación de modelos en la misma imagen en todos los equipos. Tanto los servidores de inferencia, como NVIDIA Triton Inference Server, como los servicios gestionados, como Vertex AI, ejecutan modelos como imágenes de contenedor.

Docker frente a las máquinas virtuales y Kubernetes#

• Máquinas virtuales: Un hipervisor emula el hardware y cada máquina virtual arranca su propio kernel de invitado, lo que aísla mejor las cargas de trabajo y permite usar cualquier sistema operativo invitado, a costa de una imagen completa del sistema operativo por máquina virtual y un arranque más lento. Como los contenedores comparten el kernel de Linux del host, Docker Desktop en macOS y Windows los ejecuta dentro de una máquina virtual ligera de Linux.
• Docker Compose: Define varios contenedores que se ejecutan juntos en un mismo host, como una API de inferencia, una caché y un recolector de métricas.
• Kubernetes: Programa contenedores en un clúster, reinicia los que fallan y escala las réplicas según el tráfico. Kubernetes 1.24 eliminó dockershim, su adaptador integrado para Docker Engine, así que los clústeres ejecutan contenedores mediante containerd o CRI-O. Las imágenes creadas con Docker siguen ejecutándose allí porque son imágenes OCI estándar.