Cómo organizar imágenes Docker propias y de terceros

Introducción

Organizar imágenes Docker propias y de terceros significa saber de dónde procede cada imagen, qué versión se utiliza, quién la mantiene, cómo se valida, dónde se almacena y cuándo debe retirarse. Una infraestructura Docker puede estar perfectamente ordenada en proyectos, redes y volúmenes y, aun así, depender de imágenes cuyo origen nadie revisa, etiquetas ambiguas, construcciones locales no reproducibles o versiones antiguas que permanecen indefinidamente en producción.

Las imágenes son una de las piezas más importantes del modelo Docker porque constituyen la base desde la que se crean los contenedores. Una misma imagen puede ejecutarse muchas veces con configuraciones diferentes, mientras que una actualización de esa imagen puede cambiar librerías, dependencias, versiones de aplicación o comportamientos internos sin modificar aparentemente la estructura del proyecto.

El problema no es utilizar imágenes de terceros. Gran parte del valor de Docker procede precisamente de poder reutilizar imágenes mantenidas por fabricantes, proyectos y comunidades. El problema aparece cuando se descargan por nombre sin comprobar procedencia, se utiliza siempre una etiqueta genérica, se desconoce qué versión está realmente en producción o se construyen imágenes propias sin una fuente reproducible.

Una pequeña empresa no necesita construir una cadena de suministro de software propia de una gran organización, pero sí necesita unas reglas simples para aceptar, versionar, construir y conservar imágenes. Debe ser posible responder qué imagen utiliza cada proyecto, qué confianza merece, cómo se reconstruye si es propia y qué versión anterior puede recuperarse si una nueva release falla.

Este artículo explica cómo organizar ese ciclo de vida. Parte de la diferencia entre imágenes oficiales, de terceros y propias; analiza tags, digests, registros, Dockerfiles, imágenes base, etiquetado, almacenamiento, seguridad, limpieza y documentación. La estrategia de actualización de contenedores se aborda por separado: aquí el foco es construir un catálogo de imágenes controlado antes de decidir cuándo desplegar cada nueva versión.

Índice

• Qué papel tiene una imagen dentro de Docker
• Tres grupos: oficiales, de terceros y propias
• Criterios para aceptar una imagen de terceros
• Cómo tratar las imágenes oficiales
• Cómo evaluar imágenes mantenidas por terceros
• Cuándo tiene sentido construir una imagen propia
• El Dockerfile como fuente de verdad
• Elegir y controlar la imagen base
• Entender correctamente los tags
• Por qué latest no es una estrategia de versionado
• Cuándo utilizar digests
• Definir una nomenclatura propia
• Organizar registros públicos y privados
• Proteger el acceso al registro
• Hacer construcciones reproducibles
• Controlar capas y tamaño
• Evitar secretos dentro de las imágenes
• Controlar dependencias incorporadas
• Imágenes y arquitecturas de CPU
• Mantener un inventario de imágenes
• Relacionar imagen y versión desplegada
• Separar imágenes de desarrollo, pruebas y producción
• Seguridad y confianza
• Qué hacer con vulnerabilidades conocidas
• Definir una política de retención
• Limpiar imágenes sin perder capacidad de reversión
• Documentar el catálogo de imágenes
• Procedimiento para incorporar una imagen nueva
• Errores frecuentes
• Lista de comprobación
• Preguntas frecuentes
• Conclusión

Qué papel tiene una imagen dentro de Docker

Una imagen es la plantilla a partir de la cual Docker crea contenedores. Incluye el sistema de archivos necesario para la aplicación y puede incorporar binarios, librerías, paquetes, configuraciones base y metadatos de ejecución.

El artículo qué es un contenedor y por qué está cambiando los servidores modernos desarrolla esta diferencia básica entre imagen y contenedor. Para organizar una infraestructura hay que añadir una tercera idea: la imagen es también un artefacto versionable que debe tener procedencia y ciclo de vida.

Por tanto, una referencia como:

nginx:1.27

no debe verse solo como un nombre que Docker puede descargar. Representa una dependencia concreta del proyecto.

Tres grupos: oficiales, de terceros y propias

La clasificación ayuda a asignar controles. Una imagen propia exige conservar Dockerfile y proceso de construcción. Una imagen de terceros exige evaluar al mantenedor. Una imagen oficial sigue necesitando control de versión.

Criterios para aceptar una imagen de terceros

Antes de incorporar una imagen a un proyecto conviene revisar varios aspectos.

• quién la publica;
• si existe documentación;
• si el proyecto continúa mantenido;
• frecuencia de nuevas versiones;
• relación con el fabricante del software;
• tags disponibles;
• arquitecturas soportadas;
• método de configuración;
• ubicación esperada de datos persistentes;
• usuario con el que ejecuta;
• permisos o capacidades especiales que solicita;
• mecanismo recomendado de actualización.

No elegir únicamente por popularidad

Muchas descargas pueden ser una señal útil, pero no sustituyen la revisión de procedencia y mantenimiento.

No elegir únicamente porque existe un ejemplo Compose

Un repositorio fácil de desplegar puede seguir siendo inadecuado para un entorno estable si no mantiene versiones o no documenta cambios.

Cómo tratar las imágenes oficiales

Las imágenes oficiales suelen ser un buen punto de partida para componentes ampliamente utilizados, pero también deben gestionarse con criterio.

Seleccionar la variante adecuada

Un mismo producto puede ofrecer variantes basadas en distintas distribuciones, versiones o arquitecturas.

Leer la documentación del tag

Un nombre parecido no garantiza el mismo comportamiento. Algunas variantes cambian librerías, herramientas disponibles o compatibilidad.

Registrar el origen

El inventario del proyecto debe identificar que se utiliza una imagen oficial y la referencia concreta empleada.

No dar por supuesta la estabilidad de una etiqueta móvil

Aunque el repositorio sea confiable, una etiqueta que cambia de contenido puede introducir una versión diferente en la siguiente descarga.

Cómo evaluar imágenes mantenidas por terceros

Muchas aplicaciones no disponen de una imagen oficial y dependen de imágenes mantenidas por proveedores o comunidades.

Comprueba la relación con el software original

Conviene saber si la imagen la publica el propio desarrollador, un socio conocido o una comunidad independiente.

Revisa el proceso de construcción

Si el Dockerfile es público, puede entenderse mejor qué contiene la imagen.

Comprueba actividad reciente

Una imagen abandonada puede seguir funcionando durante años, pero acumular dependencias obsoletas.

Evita repositorios sin identidad clara

El blog ya advierte de que utilizar imágenes desconocidas puede introducir vulnerabilidades o configuraciones inseguras. Esa advertencia debe convertirse en una regla de plataforma: ninguna imagen nueva entra en producción sin una procedencia identificada.

Cuándo tiene sentido construir una imagen propia

Crear una imagen propia aporta control, pero también convierte a la organización en responsable de mantenerla.

Puede tener sentido cuando:

• la aplicación es propia;
• se necesita añadir módulos o dependencias;
• la imagen disponible no cumple requisitos;
• se quiere fijar una configuración base;
• se necesita eliminar componentes innecesarios;
• se requiere un proceso de construcción reproducible;
• se quiere controlar exactamente qué versión se despliega.

No personalizar por costumbre

Si una imagen mantenida y adecuada ya resuelve el caso, mantener una variante propia puede añadir trabajo sin beneficio.

El Dockerfile como fuente de verdad

Una imagen propia debe poder reconstruirse a partir de un Dockerfile y los archivos necesarios.

El Dockerfile puede definir:

• imagen base;
• paquetes;
• dependencias;
• archivos copiados;
• variables base;
• usuario de ejecución;
• puertos documentales;
• comando de arranque.

Evitar cambios manuales sobre contenedores

Instalar algo dentro de un contenedor y después conservar esa instancia como referencia destruye reproducibilidad. El cambio debe incorporarse al Dockerfile o al mecanismo de configuración apropiado.

Versionar el Dockerfile

Debe formar parte de la fuente controlada del proyecto.

Elegir y controlar la imagen base

Una imagen propia hereda gran parte de su contenido y riesgo de la imagen base.

FROM python:3.13-slim

Esta línea ya establece una dependencia.

Elegir una base mantenida

Conviene utilizar variantes con soporte y procedencia conocida.

Evitar bases enormes sin necesidad

Más paquetes significan más superficie y más contenido que mantener.

No elegir la imagen más pequeña de forma automática

Una base mínima puede complicar diagnóstico o compatibilidad. El objetivo es equilibrio entre simplicidad, soporte y tamaño.

Registrar la versión

Una actualización de la base puede modificar muchas capas aunque la aplicación propia no haya cambiado.

Entender correctamente los tags

Un tag es una etiqueta legible asociada a una imagen.

Ejemplos:

app:1
app:1.4
app:1.4.2
app:stable
app:latest

La semántica depende del mantenedor. Docker no obliga a que stable sea estable ni a que 1.4 permanezca siempre apuntando al mismo contenido.

Versiones mayores

Ofrecen flexibilidad para recibir cambios menores, pero pueden variar.

Versiones específicas

Facilitan reproducibilidad.

Tags internos

En imágenes propias pueden reflejar una release, build o commit de forma consistente.

Por qué latest no es una estrategia de versionado

latest es simplemente una etiqueta. No significa necesariamente “última versión segura”, “última estable” ni “recomendada para producción”.

Problema de reproducibilidad

Dos despliegues realizados en fechas distintas pueden descargar contenidos diferentes usando la misma referencia.

Problema de diagnóstico

Si aparece una incidencia, resulta más difícil saber qué versión exacta se desplegó.

Uso razonable

Puede resultar cómodo en pruebas o experimentos donde se acepta variación. Para servicios importantes conviene una referencia más controlada.

Cuándo utilizar digests

Un digest identifica de forma inmutable un contenido concreto.

imagen@sha256:...

Mientras un tag puede cambiar de destino, un digest permite referirse al mismo artefacto.

Ventaja

Aumenta reproducibilidad y permite comprobar que dos entornos utilizan exactamente la misma imagen.

Coste operativo

Hay que actualizar deliberadamente la referencia cuando se desea una nueva versión.

Uso proporcional

No todos los laboratorios necesitan fijar digests. En producción crítica puede ser útil cuando se quiere controlar exactamente qué artefacto se despliega.

Definir una nomenclatura propia

Las imágenes internas deben seguir nombres previsibles.

registro.local/aplicaciones/portal:1.8.3
registro.local/herramientas/importador:2.1.0

El nombre debe identificar función

Evita referencias como:

app-nueva
imagen-final
prueba-buena
docker2

El tag debe expresar una regla

Si se utilizan versiones semánticas, fechas o identificadores de build, la convención debe aplicarse a todas las imágenes propias.

Organizar registros públicos y privados

Un registry almacena y distribuye imágenes.

Registro público

Puede utilizarse para imágenes oficiales y proyectos públicos.

Registro privado

Puede resultar útil para:

• aplicaciones propias;
• imágenes personalizadas;
• artefactos que no deben publicarse;
• control interno de versiones;
• reducir dependencia de una copia local concreta.

No desplegar desde el portátil de una persona

Una imagen propia que solo existe localmente en el equipo de quien la construyó no es una fuente empresarial fiable.

El registro debe convertirse en una fuente controlada de artefactos.

Proteger el acceso al registro

El registro puede contener código empaquetado y versiones de producción.

Separar lectura y escritura

Los hosts productivos pueden necesitar descargar imágenes sin tener permiso para publicar nuevas versiones.

Usar cuentas técnicas

Las credenciales deben corresponder a la función y no depender de cuentas personales cuando se trate de automatizaciones.

Rotar credenciales

La documentación debe indicar dónde se custodian y cómo se sustituyen.

Hacer construcciones reproducibles

Construir dos veces el mismo Dockerfile debería producir entornos equivalentes, aunque algunos elementos externos pueden cambiar si no están versionados.

Fijar dependencias relevantes

Si durante la construcción se instala siempre “la última versión” de una librería, el resultado puede cambiar sin modificar el Dockerfile.

Controlar origen de paquetes

Debe saberse qué repositorios utiliza la construcción.

Automatizar cuando sea estable

Una pipeline puede construir y publicar una imagen siguiendo una secuencia repetible.

Registrar el origen

El artefacto debería poder relacionarse con una versión del código o del Dockerfile que lo generó.

Controlar capas y tamaño

Docker construye imágenes por capas. Una mala organización puede generar imágenes innecesariamente grandes.

Copiar solo lo necesario

El contexto de build no debería incorporar backups, repositorios completos, temporales o secretos.

Evitar herramientas innecesarias en producción

Compiladores o dependencias utilizadas únicamente para construir pueden no necesitar permanecer en la imagen final.

Multi-stage builds

Permiten separar construcción y ejecución cuando la aplicación lo requiere.

Tamaño no es el único criterio

Una imagen algo mayor pero mantenible puede ser preferible a una variante mínima difícil de diagnosticar.

Evitar secretos dentro de las imágenes

Una imagen puede copiarse, almacenarse en caché, publicarse o permanecer durante años en un registro.

Por ello, no debe contener:

• contraseñas;
• tokens;
• claves privadas;
• archivos .env reales;
• credenciales de bases de datos;
• certificados privados innecesarios.

Eliminar después no siempre elimina el riesgo

Si un secreto se incorporó en una capa anterior, puede seguir presente en el historial de la imagen.

Proporcionar secretos en ejecución

La configuración sensible debe suministrarse mediante mecanismos diseñados para el entorno, separada de la imagen.

Controlar dependencias incorporadas

Una imagen propia incluye más que el código de la aplicación.

Puede depender de:

• imagen base;
• paquetes del sistema;
• librerías;
• runtime;
• módulos;
• binarios descargados;
• repositorios externos.

Una actualización indirecta sigue siendo un cambio

Si cambia una dependencia de construcción, la imagen cambia aunque el código principal permanezca igual.

Inventariar lo relevante

No es necesario documentar manualmente cada archivo, pero sí conocer las dependencias que condicionan soporte y seguridad.

Imágenes y arquitecturas de CPU

Una imagen puede estar disponible para una o varias arquitecturas.

Antes de estandarizar una imagen conviene comprobar si soporta las plataformas donde se espera ejecutarla.

Entornos mixtos

Una infraestructura con servidores x86_64 y equipos ARM necesita comprobar compatibilidad.

Imágenes multi-arquitectura

Pueden simplificar despliegues cuando el mismo tag proporciona variantes para varias arquitecturas.

Imágenes propias

Si se necesitan varias arquitecturas, el proceso de construcción debe contemplarlas y probarlas.

Mantener un inventario de imágenes

La documentación de la infraestructura Docker debería registrar las imágenes realmente utilizadas.

El inventario debe identificar también quién decide las actualizaciones y dónde se encuentra la documentación de la imagen.

Este control complementa cómo documentar una infraestructura basada en Docker.

Relacionar imagen y versión desplegada

Debe poder saberse qué artefacto está ejecutándose en producción.

No confiar en el nombre del contenedor

El contenedor puede llamarse igual después de una actualización.

Registrar la referencia desplegada

Compose, control de versiones y registro de cambios deben permitir reconstruir qué imagen se utilizó.

Evitar reconstrucciones invisibles

Si una misma etiqueta se vuelve a publicar con contenido diferente, la trazabilidad se reduce. En imágenes propias conviene evitar sobrescribir releases ya publicadas.

Separar imágenes de desarrollo, pruebas y producción

Las construcciones temporales no deberían confundirse con releases.

Desarrollo

Puede utilizar tags asociados a ramas o builds temporales.

Pruebas

Debe probar el mismo artefacto que se pretende promover a producción siempre que sea posible.

Producción

Debe consumir una referencia aprobada y trazable.

Promover, no reconstruir

Cuando sea viable, resulta preferible validar un artefacto y después promover ese mismo contenido que volver a construirlo de cero para producción.

Seguridad y confianza

Ejecutar una imagen significa ejecutar software dentro de la infraestructura.

Principio básico

No debe ejecutarse una imagen de procedencia que no se aceptaría para instalar software directamente en un servidor.

Revisar usuario de ejecución

Cuando una imagen puede ejecutarse con un usuario no privilegiado, es preferible evitar privilegios innecesarios.

Revisar montajes y capacidades

Una imagen que exige acceso al socket Docker, modo privilegiado o rutas sensibles del host necesita una evaluación especial.

Firmas y mecanismos de confianza

Cuando el entorno lo justifique, pueden utilizarse mecanismos adicionales para verificar procedencia e integridad. La política debe ser proporcional al riesgo.

Qué hacer con vulnerabilidades conocidas

Una imagen puede contener vulnerabilidades en su aplicación, runtime, sistema base o librerías.

No interpretar cualquier hallazgo de la misma forma

La prioridad depende de:

• severidad;
• componente afectado;
• si el componente se utiliza;
• exposición;
• existencia de parche;
• criticidad del servicio.

Reconstruir imágenes propias

Una nueva versión de la base o de una dependencia puede requerir reconstruir incluso si el código de aplicación no ha cambiado.

No confundir escaneo con mantenimiento

Detectar vulnerabilidades no sirve si nadie revisa resultados ni existe un proceso para sustituir imágenes afectadas.

Definir una política de retención

Con el tiempo se acumulan releases, builds de pruebas y capas antiguas.

Una política sencilla puede distinguir:

• versión actual de producción;
• una o varias versiones anteriores necesarias para reversión;
• releases todavía soportadas;
• builds temporales;
• imágenes obsoletas;
• imágenes de proyectos retirados.

El registro no debe convertirse en un vertedero

Conservar todo indefinidamente aumenta almacenamiento y dificulta distinguir artefactos útiles.

La retención debe considerar auditoría y recuperación

No se debe borrar una release aún necesaria para reconstruir o investigar un entorno.

Limpiar imágenes sin perder capacidad de reversión

En los hosts Docker también se acumulan imágenes locales.

Antes de limpiar

• identificar contenedores activos;
• identificar imágenes necesarias para rollback;
• confirmar que las imágenes importantes siguen disponibles en el registro;
• revisar proyectos detenidos temporalmente.

No usar limpieza agresiva como rutina ciega

Eliminar todo lo que parece no utilizado puede complicar una reversión o una recuperación sin conexión al registro.

Separar caché de artefactos

Las cachés de construcción pueden limpiarse con criterios diferentes a las releases publicadas.

Documentar el catálogo de imágenes

Para cada imagen relevante conviene conservar:

• nombre;
• tipo;
• mantenedor;
• registro;
• tag o digest utilizado;
• arquitecturas;
• proyectos que dependen de ella;
• Dockerfile si es propia;
• imagen base;
• método de construcción;
• criterio de actualización;
• fecha de revisión.

Evitar duplicar datos automáticos

No es necesario copiar toda la información que Docker o el registry ya muestran. La documentación debe aportar contexto y responsabilidad.

Procedimiento para incorporar una imagen nueva

1. Identificar la necesidad.

   Definir qué aplicación o componente requiere la imagen.

2. Clasificarla.

   Oficial, tercero o propia.

3. Revisar procedencia.

   Identificar mantenedor, documentación y registro.

4. Revisar versiones.

   Elegir un tag suficientemente controlado.

5. Comprobar arquitectura.

   Validar compatibilidad con el host.

6. Revisar ejecución.

   Usuario, puertos, volúmenes, privilegios y configuraciones necesarias.

7. Probar fuera de producción.

   Validar arranque, logs y función principal.

8. Registrar la imagen.

   Añadirla al inventario del proyecto.

9. Definir actualización.

   Establecer cómo se detectarán y evaluarán nuevas versiones.

10. Definir retirada.

    Evitar que versiones antiguas permanezcan indefinidamente.

Errores frecuentes

Usar cualquier imagen que aparece en una búsqueda

La disponibilidad no garantiza confianza.

Utilizar latest en todos los proyectos

Reduce reproducibilidad y dificulta saber qué se desplegó.

Creer que imagen oficial significa actualización automática segura

La procedencia puede ser buena y el cambio seguir siendo incompatible con la aplicación.

Sobrescribir tags de releases propias

Hace que una misma referencia represente contenidos diferentes.

Construir solo en el portátil del administrador

La organización pierde capacidad de reproducir el artefacto.

No versionar el Dockerfile

Impide reconstruir de forma fiable.

Incluir secretos durante la construcción

Pueden permanecer en capas o registros.

Instalar paquetes sin controlar versiones

La imagen puede cambiar aunque el Dockerfile no cambie.

Optimizar únicamente por tamaño

Puede producir imágenes difíciles de mantener o diagnosticar.

No registrar la imagen base

Oculta una dependencia importante.

No comprobar arquitectura

Puede impedir despliegues en otros hosts.

Conservar todas las imágenes indefinidamente

Aumenta almacenamiento y ruido operativo.

Limpiar todas las imágenes antiguas

Puede eliminar una versión necesaria para rollback.

Escanear vulnerabilidades sin proceso de actuación

Genera informes que no reducen riesgo.

No saber qué proyectos usan una imagen

Impide evaluar el impacto de una nueva versión o vulnerabilidad.

Lista de comprobación

• ¿Cada imagen tiene procedencia identificada?
• ¿Se distingue entre oficial, tercero y propia?
• ¿Existe un criterio para aceptar imágenes nuevas?
• ¿Los tags utilizados tienen una semántica conocida?
• ¿Se evita depender de latest en servicios importantes?
• ¿Se utilizan digests cuando la reproducibilidad lo justifica?
• ¿Las imágenes propias tienen nomenclatura estable?
• ¿Existe un registro controlado para imágenes propias?
• ¿Las credenciales del registro están protegidas?
• ¿Lectura y publicación están separadas cuando procede?
• ¿Cada imagen propia tiene Dockerfile?
• ¿El Dockerfile está versionado?
• ¿La imagen base está identificada?
• ¿Las dependencias de construcción están controladas?
• ¿Los secretos están fuera de las imágenes?
• ¿El contexto de build excluye archivos innecesarios?
• ¿Se conoce la arquitectura de CPU soportada?
• ¿Existe inventario de imágenes de producción?
• ¿Cada imagen puede relacionarse con sus proyectos?
• ¿Se sabe qué versión está desplegada?
• ¿Pruebas y producción utilizan artefactos trazables?
• ¿Las imágenes propias pueden reconstruirse?
• ¿Existe revisión de vulnerabilidades proporcionada?
• ¿Existe un procedimiento para actuar ante vulnerabilidades?
• ¿Hay una política de retención?
• ¿Se conservan las versiones necesarias para reversión?
• ¿La limpieza local se realiza con criterio?
• ¿El catálogo de imágenes está documentado?

Preguntas frecuentes

Conclusión

Organizar imágenes Docker propias y de terceros significa tratar cada imagen como un artefacto de software con procedencia, versión, responsable y ciclo de vida.

Las imágenes oficiales simplifican muchos despliegues, pero siguen necesitando control de tags y versiones. Las imágenes de terceros requieren evaluar mantenedor, actividad, documentación y proceso de construcción. Las imágenes propias aportan control, pero obligan a conservar Dockerfiles, dependencias y un mecanismo reproducible de construcción.

La referencia utilizada en producción debe ser trazable. Depender indiscriminadamente de etiquetas móviles dificulta reproducir un entorno y saber qué cambió. Tags específicos y, cuando sea necesario, digests permiten aumentar el control.

El registry forma parte de la infraestructura. Debe almacenar las imágenes propias de forma independiente de los ordenadores personales, proteger credenciales y conservar las versiones necesarias para operación y reversión.

También es necesario controlar el contenido de las imágenes. Secretos, archivos temporales y herramientas innecesarias no deberían incorporarse. Las imágenes base y dependencias forman parte del mantenimiento, aunque el código de la aplicación no cambie.

Finalmente, la plataforma necesita una política de retención. Conservar todas las imágenes para siempre genera residuos; eliminarlas sin criterio puede destruir la capacidad de rollback. El equilibrio consiste en saber qué artefactos siguen teniendo una función y retirar el resto de forma controlada.

Cuando las imágenes están inventariadas, versionadas y vinculadas a sus proyectos, Docker deja de depender de descargas oportunistas y se convierte en una plataforma reproducible. Esa disciplina prepara además el siguiente paso: diseñar actualizaciones de contenedores de forma controlada y con capacidad real de reversión.