Docker Compose 5.5: contenedores init nativos, ventanas de actualización de pull_policy y conciliación de digests

Las últimas versiones de Docker Compose (5.3-5.5.1) introducen la entrada de contenedores nativos, una gestión más inteligente de las actualizaciones de imagen y una reconciliación de los digestión que reduce reiniciaciones innecesarias: esto es lo que cambia para aquellos que administran entornos containerizzatos.

Docker Compose 5.5: contenedores init nativos, ventanas de actualización de pull_policy y conciliación de digests

Quien administra servidores Linux con aplicaciones containerizzate probablemente ya ha encontrado Docker Compose: la herramienta que permite describir, en un solo archivo YAML, todos los servicios que componen una aplicación (database, backend, reverse proxy, cache) y comenzar con un solo comando. En los últimos meses el proyecto ha lanzado una serie de actualizaciones (de la versión 5.3 de julio de 2026 a 5.5.1 de principios de septiembre) que introducen algunas características muy populares de la comunidad de administradores del sistema: las llamadasinit containernativos, una gestión más refinada de las actualizaciones de imagen a través depull_policyy unoconciliación de digestiónque evita reinicios innecesarios del contenedor. Veamos en detalle qué cambios y cómo explotar estas novedades con seguridad.

¿Qué es un contenedor init y por qué sirve

Ainit container(contenedor de inicialización) es un pequeño contenedor que se ejecuta antes del servicio real, para realizar operaciones preliminares: aplicar las migraciones de una base de datos, descargar archivos de configuración, establecer los permisos correctos en una carpeta compartida, esperar que una adicción esté lista. Antes de la versión 5.3 de Docker Compose (publicado el 2 de julio de 2026), los administradores tuvieron que recurrir a soluciones indirectas, tales como servicios de "uso y lanzamiento" reservados en el archivo docker-compose.ymly conectadosdepends_on, o scripts de shell ejecutados manualmente antes de arrancar.

Con la introducción de soporte nativo, los contenedores de entrada se configuran directamente dentro del servicio a través de la nueva directivapre_start. Cada paso enumeradopre_startse ejecuta en un contenedor temporal inmediatamente después de la creación del servicio principal pero antes de su inicio real; si un paso termina con un código de salida diferente de cero, el servicio no sale, evitando así una aplicación para comenzar en un estado incoherente (por ejemplo, con una base de datos aún no actualizada).

Un ejemplo práctico aclara mejor la operación:

services:
  app:
    image: myapp:latest
    user: "1000:1000"
    volumes:
      - data:/data
    depends_on:
      db:
        condition: service_healthy
    pre_start:
      - command: ["./manage.py", "migrate"]
      - image: busybox
        user: root
        command: sh -c 'chown -R 1000:1000 /data'

  db:
    image: postgres:18
    healthcheck:
      test: ["CMD-SHELL", "pg_isready"]

volumes:
  data:

En este ejemplo, antes del servicioappdos pasos se toman en secuencia: la migración de la base de datos a través del comando de la aplicación misma, y la corrección de permisos en la carpeta compartida/datausando una imagen mínimabusybox. Si no especifica una imagen diferente, cada paso por defecto hereda la imagen del servicio principal; todos los pasos también comparten las mismas redes y los mismos volúmenes del servicio, entonces los archivos preparados durante la inicialización son inmediatamente visibles al contenedor definitivo. Un detalle útil para aquellos que manejan entornos con recursos limitados: un pasopre_startque no ha cambiado en comparación con la ejecución anterior y que ya ha ido a buen fin se salta automáticamente en sucesivas ejecuciones.

pull_policy: actualizaciones de imagen más inteligente

La Directivapull_policyexiste durante mucho tiempo en Docker Compose y le permite comprobar cuando una imagen tiene que ser descargada de nuevo del registro: los valores más comunes sonsiempre(Siempre descargar la última versión),desaparecido(Descargar sólo si la imagen no está presente localmente),♪(nunca descarga, útil en entornos aislados) yconstrucción(construye la imagen localmente en lugar de descargarla). Con la versión 5.5.0, lanzada el 17 de agosto de 2026, el comandocompose pullse ha vuelto más consciente del tiempo pasado por la última actualización: respeta las ventanas de refresco configurables (por ejemplo, diariamente, semanal o cada ejecución N), evitando innecesariamente reconectar el registro remoto cuando la imagen ya se ha verificado recientemente. Para un administrador que administra docenas de contenedores en múltiples servidores, esto resulta en menos tráfico de red generado por controles automáticos y tiempos de implementación más predecibles, especialmente cuando las actualizaciones son lanzadas por un oleoducto de automatización o un trabajo de cron planeado.

Reconciliación de digestión: reinicios menos innecesarios

También en la versión 5.5.0 se introdujo un nuevo mecanismoconciliación de imágenes digiere. En resumen, Docker Compose ahora compara con más precisión el digest (la huella única) de la imagen realmente utilizada por un contenedor con la de la imagen disponible más reciente, evitando recrear un contenedor cuando, en realidad, no hay cambios sustanciales a aplicar. Quien trabaja con Docker sabe lo molesto que es ver un reinicio de servicio sin una razón aparente durante una simpledocker compose up: Este cambio reduce este tipo de interrupciones innecesarias. Pero es bueno saber que, como se informó en notas oficiales de liberación,la primera vezque usted realizacompose upDespués de actualizar a esta versión, algunos contenedores existentes todavía podrían ser recreados, porque los digestión se revalorizan una vez con la nueva lógica. Por lo tanto, es aconsejable planificar este primer reinicio en una ventana de mantenimiento, especialmente para los servicios de producción.

La otra noticia de 5.5.1

La versión más reciente, 5.5.1 (3 de septiembre de 2026), se centra principalmente en mejoras menores pero útiles en la depuración:ciclo de vida gancho(los comandos ejecutados automáticamente al inicio o cierre de un servicio) ahora capturan y muestran su salida directamente en el terminal, lo que simplifica el diagnóstico cuando algo sale mal durante estas etapas. Los errores de seguimiento de OpenTelemetry también se han mejorado al utilizar la bandera--debug, útil para aquellos que integran Compose en entornos de observabilidad más complejos. Entre las correcciones de fallos también reportamos una mejor gestión de sincronización de directorios vinculados (funciónwatch) y un apoyo más fuerte a las opciones IPAM en la creación de redes.

Cómo actualizar Docker Compose de forma segura

Antes de actualizar, es bueno comprobar la versión instalada actualmente con el comandodocker compose version. En la mayoría de las distribuciones Linux, Docker Compose se instala como un plugin de cliente Docker y actualizaciones con el paquetedocker-compose-plugina través del administrador del paquete del sistema (por ejemplo,apt update && apt upgrade docker-compose-pluginen Debian y Ubuntu). Alternativamente, aquellos que han instalado el plugin manualmente pueden descargar la última pista directamente desde la página oficial de lanzamiento en GitHub.

Algunas sugerencias prácticas para quienes administran servidores en producción:

Prueba primero en un entorno de estancamiento.Como se ve, el nuevo mecanismo de reconciliación del digestión puede causar la recreación de algunos contenedores al principio siguiente de la actualización: descubrirlo mejor en un entorno no crítico.
Siempre lee notas oficialesantes de actualizar a la producción, para ver si hay cambios de comportamiento que afectan sus archivosdocker-compose.yml.
Utilice el contenedor de entradapara reemplazar cualquier script de inicialización externa ya en uso: además de simplificar el mantenimiento, esto hace que el comportamiento de la aplicación sea más predecible y documentado directamente en el archivo de configuración.
Evaluar las ventanas de actualización pull_policysi administra muchos anfitriones y desea reducir la carga en los registros privados Docker de la empresa.

En general, estas innovaciones confirman una clara tendencia en la evolución de Docker Compose: haciendo cada vez más adecuado para escenarios de producción reales, reduciendo la necesidad de scripts externos y mejorando la previsibilidad de las actualizaciones, dos aspectos particularmente apreciados por los sistemas Linux diariamente.

Fuentes oficiales

Notas oficiales de Docker Compose sobre GitHub
Documentación oficial Docker: Use contenedores de entrada en Compose
Documentación oficial Docker: Docker Compose pull

Compartir

¿Cuál es tu reacción?

Me gusta Me gusta 0
No me gusta No me gusta 0
Me encanta Me encanta 0
Divertido Divertido 0
Enfadado Enfadado 0
Triste Triste 0
¡Vaya! ¡Vaya! 0