Cómo inventariar todos los contenedores Docker de una empresa

Introducción

Inventariar todos los contenedores Docker de una empresa significa construir un registro fiable de qué servicios existen, para qué sirven, dónde se ejecutan, qué imágenes utilizan, qué datos conservan, con qué otros componentes se comunican y cómo deben mantenerse o recuperarse. Un inventario no es simplemente una captura de docker ps. Ese comando muestra una parte del estado actual, pero no explica el propósito del servicio, su criticidad, sus dependencias ni qué ocurriría si desapareciera.

La necesidad de inventariar suele hacerse evidente cuando la plataforma ha crecido durante meses o años. Se añaden aplicaciones, pruebas, proxies, bases de datos, herramientas de automatización y servicios auxiliares. Algunos se actualizan; otros quedan abandonados; ciertos contenedores dependen de volúmenes o redes externas; y algunos solo los comprende la persona que los desplegó.

Un inventario bien diseñado permite responder a preguntas básicas sin investigar el servidor desde cero: ¿qué contenedores son críticos?, ¿qué imagen ejecuta cada uno?, ¿qué puertos publica?, ¿qué datos deben copiarse?, ¿qué redes comparte?, ¿qué servicio puede retirarse?, ¿qué proyecto depende de una base de datos concreta?, ¿qué contenedor debe arrancar primero tras un fallo?

Este artículo explica cómo crear y mantener un inventario Docker práctico, orientado a operación, mantenimiento y recuperación. El objetivo no es construir una base de datos gigantesca, sino reunir la información mínima que permita comprender la plataforma y tomar decisiones con seguridad.

La documentación general de arquitectura se desarrolla en cómo documentar una infraestructura basada en Docker. Aquí el foco es más concreto: crear un registro estructurado y actualizado de todos los contenedores y sus dependencias.

Índice

• Qué debe contener un inventario Docker
• Para qué sirve realmente el inventario
• Definir el alcance antes de empezar
• Descubrir todos los contenedores existentes
• Relacionar contenedores con proyectos
• Registrar nombre, función y responsable
• Inventariar imágenes y versiones
• Registrar puertos y exposición
• Inventariar redes y comunicaciones
• Inventariar volúmenes y datos persistentes
• Registrar dependencias entre servicios
• Registrar dependencias externas
• Clasificar criticidad
• Registrar copia y recuperación
• Registrar mantenimiento y actualización
• Añadir información mínima de seguridad
• Registrar consumo y límites relevantes
• Distinguir activo, temporal, prueba y obsoleto
• Elegir la fuente oficial del inventario
• Diseñar una tabla de inventario útil
• Automatizar la recogida sin perder contexto
• Validar el inventario contra la realidad
• Definir una frecuencia de revisión
• Usar el inventario para retirar servicios
• Usar el inventario durante una incidencia
• Ejemplo de inventario
• Errores frecuentes
• Procedimiento paso a paso
• Lista de comprobación
• Preguntas frecuentes
• Conclusión

Qué debe contener un inventario Docker

Un inventario Docker debe combinar información técnica y operativa.

Como mínimo, conviene registrar:

• nombre del contenedor;
• proyecto al que pertenece;
• función;
• imagen y versión;
• host donde se ejecuta;
• estado operativo;
• puertos publicados;
• redes;
• volúmenes y bind mounts;
• dependencias internas;
• dependencias externas;
• criticidad;
• responsable o referencia de administración;
• procedimiento de actualización;
• procedimiento de backup;
• procedimiento de recuperación.

El inventario no necesita almacenar secretos ni contraseñas. Debe registrar su existencia y la referencia al mecanismo donde se custodian.

Para qué sirve realmente el inventario

El inventario aporta valor en varias situaciones.

Mantenimiento

Permite saber qué servicios deben actualizarse y qué versiones están desplegadas.

Incidencias

Ayuda a identificar rápidamente dependencias y recursos afectados.

Recuperación

Permite reconstruir el orden de restauración y localizar datos persistentes.

Seguridad

Facilita identificar servicios expuestos, imágenes antiguas y permisos especiales.

Capacidad

Permite relacionar servicios con consumo de recursos y crecimiento.

Retirada

Ayuda a eliminar un servicio completo sin dejar redes, volúmenes o alertas abandonados.

Definir el alcance antes de empezar

Antes de crear el inventario conviene decidir qué se considera parte de la plataforma.

El alcance puede incluir:

• contenedores activos;
• contenedores detenidos que todavía forman parte de un proyecto;
• proyectos de prueba;
• servicios auxiliares;
• redes compartidas;
• volúmenes persistentes;
• imágenes propias;
• servicios del host imprescindibles para Docker.

En una primera versión es preferible incluir de más y clasificar después que olvidar componentes importantes.

Descubrir todos los contenedores existentes

El primer paso consiste en obtener el estado real.

docker ps -a

Una salida personalizada puede facilitar la exportación:

docker ps -a --format "table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}"

También conviene revisar proyectos Compose:

docker compose ls

No limitarse a los contenedores activos

Los detenidos pueden corresponder a servicios temporales, pruebas o componentes que deberían haberse retirado. Precisamente por eso deben aparecer en la revisión.

Relacionar contenedores con proyectos

El inventario debe agrupar contenedores por unidad lógica.

Un proyecto puede contener:

• web;
• base de datos;
• worker;
• caché;
• servicios auxiliares.

Conocer esta relación evita interpretar cada contenedor como una aplicación independiente.

La estructura de estas unidades se desarrolla en cómo organizar correctamente los proyectos Docker.

Registrar nombre, función y responsable

El nombre técnico no siempre explica la función.

Conviene registrar tres campos distintos:

• nombre técnico: el utilizado por Docker;
• función: qué servicio presta;
• responsable: quién o qué procedimiento mantiene el servicio.

Ejemplo:

El responsable puede ser una persona, un equipo o una referencia documental. No es necesario convertir el inventario en una agenda de contactos.

Inventariar imágenes y versiones

Cada contenedor debería poder asociarse a una imagen conocida.

docker inspect --format='{{.Config.Image}}' nombre_contenedor

Conviene registrar:

• repositorio;
• tag;
• origen;
• si es propia o de terceros;
• fecha o política de actualización;
• si existe una versión de reversión conocida.

La organización de imágenes se desarrolla en cómo organizar imágenes Docker propias y de terceros.

Registrar puertos y exposición

Los puertos publicados permiten saber qué servicios son accesibles desde el host o desde el exterior.

Conviene distinguir:

• puerto interno del contenedor;
• puerto publicado en el host;
• interfaz de escucha;
• si el acceso es interno o externo;
• si existe un proxy inverso.

Inventariar exposición ayuda a detectar excepciones

Una base de datos publicada al host por una prueba antigua puede descubrirse fácilmente cuando todos los puertos aparecen en una tabla común.

Inventariar redes y comunicaciones

Para cada contenedor conviene registrar qué redes utiliza.

docker inspect nombre_contenedor

Y para cada red:

docker network inspect nombre_red

El inventario debería indicar:

• red privada del proyecto;
• redes compartidas;
• propósito de cada red;
• servicios que necesitan comunicarse.

El diseño de esta capa se desarrolla en cómo diseñar redes Docker fáciles de mantener.

Inventariar volúmenes y datos persistentes

Esta es una de las partes más importantes.

Para cada contenedor registra:

• named volumes;
• bind mounts;
• ruta o nombre lógico;
• tipo de dato;
• criticidad;
• si existe backup;
• si puede regenerarse.

El comando:

docker inspect nombre_contenedor

permite revisar los montajes configurados.

La gestión de persistencia se desarrolla en cómo gestionar correctamente los volúmenes Docker.

Registrar dependencias entre servicios

Un inventario útil debe mostrar qué contenedores dependen de otros.

Ejemplos:

• web depende de db;
• worker depende de cola;
• proxy depende de web;
• monitorización consulta varios servicios;
• aplicación depende de cache.

No basta con registrar que dos contenedores comparten red. Debe conocerse el sentido de la dependencia.

Dependencias fuertes y débiles

Una base de datos puede ser imprescindible para arrancar. Un servicio de correo puede ser necesario solo para una función secundaria. Esta diferencia ayuda durante incidencias.

Registrar dependencias externas

Muchas aplicaciones Docker dependen de componentes que no están en el mismo host.

Conviene registrar:

• APIs;
• DNS;
• SMTP;
• almacenamiento remoto;
• bases de datos externas;
• servicios de identidad;
• repositorios privados;
• registros de imágenes.

Estas dependencias suelen olvidarse hasta que una recuperación se realiza en otro host y el servicio no funciona.

Clasificar criticidad

No todos los contenedores tienen el mismo impacto.

Una clasificación sencilla puede ser:

• crítico: su caída interrumpe una función esencial;
• importante: afecta a la operación pero admite cierta indisponibilidad;
• auxiliar: presta soporte pero no bloquea funciones principales;
• prueba: no forma parte del servicio productivo.

La criticidad ayuda a priorizar:

• monitorización;
• backups;
• actualizaciones;
• recuperación;
• capacidad.

Registrar copia y recuperación

El inventario debería indicar qué debe recuperarse si el servicio desaparece.

Campos útiles:

• datos persistentes;
• último backup esperado;
• ubicación o referencia de la copia;
• orden de recuperación;
• dependencias previas;
• prueba funcional posterior.

La política de copia se desarrolla en cómo diseñar una política de copias de seguridad para Docker y la recuperación completa en cómo restaurar una plataforma Docker tras un fallo grave.

Registrar mantenimiento y actualización

El inventario puede incluir una referencia breve al procedimiento de actualización.

No hace falta copiar el manual completo. Bastan datos como:

• frecuencia de revisión;
• origen de la imagen;
• si requiere backup previo;
• si tiene migraciones;
• si existe rollback;
• enlace o referencia al procedimiento.

Esto permite detectar servicios que llevan demasiado tiempo sin revisión.

Añadir información mínima de seguridad

El inventario no debe convertirse en un repositorio de secretos, pero puede registrar señales relevantes.

Por ejemplo:

• usuario de ejecución;
• si utiliza privilegios elevados;
• si monta el socket Docker;
• si publica puertos;
• si requiere acceso a dispositivos;
• si usa secretos externos.

Estas columnas permiten localizar rápidamente excepciones de seguridad.

Registrar consumo y límites relevantes

No es necesario convertir el inventario en una plataforma de métricas.

Puede ser suficiente registrar:

• límites de memoria;
• límites de CPU;
• perfil de consumo aproximado;
• si la carga es intensiva;
• si necesita almacenamiento rápido.

La monitorización detallada se desarrolla en cómo monitorizar contenedores Docker de forma sencilla.

Distinguir activo, temporal, prueba y obsoleto

El inventario debe expresar el estado administrativo, no solo el estado técnico de Docker.

Una clasificación útil:

• producción;
• preproducción;
• prueba;
• temporal;
• pendiente de retirada;
• retirado con datos conservados.

Un contenedor en estado Up puede ser obsoleto desde el punto de vista operativo.

Esta clasificación ayuda a reducir complejidad, como se explica en cómo reducir la complejidad de una infraestructura Docker.

Elegir la fuente oficial del inventario

El inventario debe tener una ubicación oficial.

Puede mantenerse en:

• un archivo CSV;
• una hoja de cálculo;
• un repositorio;
• una base de datos interna;
• un sistema documental.

Evitar múltiples copias divergentes

Si existe una hoja, un documento y una tabla diferente en otro repositorio, pronto aparecerán contradicciones.

Separar datos automáticos y datos humanos

Docker puede proporcionar nombres, imágenes, redes y montajes. Pero función, criticidad, responsable y procedimiento de recuperación requieren contexto humano.

Diseñar una tabla de inventario útil

Una tabla básica puede contener:

No intentar meter todo en una única celda

Los procedimientos largos pueden mantenerse en documentación separada y enlazarse desde el inventario.

Automatizar la recogida sin perder contexto

Parte del inventario puede generarse automáticamente.

Docker permite extraer:

• nombre;
• imagen;
• estado;
• puertos;
• redes;
• montajes;
• labels.

Las labels pueden ayudar

Puede ser útil utilizar labels para almacenar metadatos operativos, por ejemplo:

labels:
  com.ejemplo.servicio: "facturacion"
  com.ejemplo.criticidad: "alta"
  com.ejemplo.entorno: "produccion"

Las claves deben adaptarse a una convención propia y mantenerse coherentes.

No automatizar información que requiere criterio

Un script no puede decidir de forma fiable si un servicio sigue siendo necesario o cuál es su impacto real si falla.

Validar el inventario contra la realidad

Un inventario desactualizado puede ser peor que no tener inventario porque genera confianza falsa.

Conviene comparar periódicamente:

docker ps -a
docker volume ls
docker network ls
docker image ls

con el registro oficial.

Buscar discrepancias

• contenedores no inventariados;
• servicios inventariados que ya no existen;
• nuevas redes;
• volúmenes sin propietario;
• versiones diferentes;
• puertos añadidos.

Definir una frecuencia de revisión

El inventario debería actualizarse cada vez que exista un cambio relevante y revisarse periódicamente.

Momentos recomendables:

• nuevo despliegue;
• retirada de servicio;
• cambio de imagen;
• nuevo volumen;
• cambio de red;
• modificación de exposición;
• cambio de responsable;
• revisión trimestral o equivalente.

La frecuencia real depende de cuánto cambie la plataforma.

Usar el inventario para retirar servicios

El inventario facilita retirar un proyecto sin dejar residuos.

Antes de eliminarlo, permite revisar:

• contenedores;
• imágenes;
• volúmenes;
• redes;
• DNS;
• proxy;
• alertas;
• backups;
• secretos.

También ayuda a determinar si los datos deben conservarse aunque el servicio desaparezca.

Usar el inventario durante una incidencia

Durante un fallo grave, el inventario puede convertirse en una de las herramientas más valiosas.

Permite identificar:

• servicios críticos;
• orden de arranque;
• dependencias;
• volúmenes;
• versiones;
• puertos;
• responsables;
• pruebas de validación.

Un buen inventario reduce el tiempo dedicado a reconstruir conocimiento mientras el servicio está caído.

Ejemplo de inventario

La tabla real puede contener más campos, pero debe seguir siendo legible y útil durante una incidencia.

Errores frecuentes

Copiar docker ps y llamarlo inventario

Faltan función, dependencias, datos, criticidad y recuperación.

Registrar solo producción

Los entornos de prueba también consumen recursos y pueden introducir exposición.

Guardar contraseñas en el inventario

Debe registrarse la referencia al secreto, no su valor.

No registrar volúmenes

Se pierde la información más importante para recuperación.

No registrar dependencias externas

El servicio parece autosuficiente hasta que se migra.

No actualizar después de cambios

El inventario deja de representar la plataforma real.

Crear demasiados campos

Si mantener el inventario exige demasiado trabajo, terminará abandonándose.

Duplicar inventarios

Varias fuentes oficiales generan contradicciones.

No clasificar servicios obsoletos

Se mantiene complejidad innecesaria.

Automatizar sin contexto humano

La herramienta puede listar recursos, pero no su importancia ni propósito.

Procedimiento paso a paso

1. Define el alcance. Decide hosts, proyectos y entornos incluidos.
2. Lista contenedores. Incluye activos y detenidos.
3. Agrupa por proyecto. Identifica unidades funcionales.
4. Registra función y responsable. Añade contexto operativo.
5. Registra imagen y versión. Identifica origen y estado de actualización.
6. Registra puertos. Distingue exposición interna y externa.
7. Registra redes. Identifica comunicaciones y redes compartidas.
8. Registra persistencia. Volúmenes, bind mounts y datos.
9. Registra dependencias. Internas y externas.
10. Clasifica criticidad. Prioriza mantenimiento y recuperación.
11. Añade referencia de backup y restauración. Sin duplicar manuales completos.
12. Registra estado administrativo. Producción, prueba, temporal u obsoleto.
13. Selecciona una fuente oficial. Evita copias divergentes.
14. Automatiza datos técnicos repetitivos. Mantén el criterio humano.
15. Valida contra Docker. Busca discrepancias.
16. Define revisiones periódicas. Mantén el inventario vivo.

Lista de comprobación

Preguntas frecuentes

Conclusión

Inventariar todos los contenedores Docker permite convertir una plataforma en un sistema comprensible y administrable. La lista de procesos en ejecución es solo el punto de partida; el verdadero valor aparece al relacionar cada contenedor con su proyecto, función, imagen, redes, puertos, datos, dependencias, criticidad y recuperación.

Un inventario útil debe ser suficientemente completo para responder durante mantenimiento e incidencias, pero lo bastante sencillo para mantenerse actualizado. Parte de la información puede extraerse automáticamente desde Docker, mientras que el contexto operativo necesita criterio humano.

El inventario correcto permite saber qué existe, por qué existe, de qué depende y qué debe hacerse si falla o deja de ser necesario.

Cuando esa información está disponible, actualizar, monitorizar, simplificar, retirar y recuperar servicios deja de depender de memoria personal. El inventario se convierte así en una pieza central de una infraestructura Docker sostenible y reproducible.