Cómo crear un catálogo interno de aplicaciones Docker

Introducción

Crear un catálogo interno de aplicaciones Docker significa disponer de un registro claro, estable y consultable de todas las aplicaciones que una organización ejecuta mediante contenedores, indicando no solo qué componentes técnicos existen, sino para qué sirve cada aplicación, quién la utiliza, dónde está desplegada, de qué depende, cómo se protege y en qué estado se encuentra.

Cuando una infraestructura Docker es pequeña, resulta relativamente fácil recordar qué hay instalado. Un servidor con tres o cuatro aplicaciones puede entenderse revisando los directorios de proyectos, los archivos Compose o la salida de varios comandos. El problema aparece cuando la plataforma crece: se añaden servicios internos, herramientas de automatización, paneles, gestores documentales, bases de datos, aplicaciones de pruebas y utilidades auxiliares. En ese momento, conocer los contenedores ya no equivale a comprender el conjunto de aplicaciones.

Una misma aplicación puede estar formada por varios contenedores: frontend, backend, base de datos, caché, proxy o tareas programadas. A su vez, ciertos componentes pueden compartirse entre distintas aplicaciones. Por eso conviene separar dos conceptos: el inventario técnico de recursos Docker y el catálogo funcional de aplicaciones. El primero responde qué contenedores, imágenes, redes y volúmenes existen. El segundo explica qué servicios proporciona la plataforma y qué importancia tienen para quienes los utilizan.

Este artículo explica cómo diseñar ese catálogo interno, qué información debe contener, cómo relacionarlo con Docker sin duplicar documentación, qué estados y responsabilidades conviene registrar, cómo mantenerlo actualizado y cómo utilizarlo para mejorar decisiones de mantenimiento, seguridad, copias, actualización y retirada de aplicaciones.

Índice

• Qué es un catálogo interno de aplicaciones Docker
• Catálogo, inventario y documentación: diferencias
• Por qué conviene crear el catálogo antes de que la plataforma crezca
• Qué debe considerarse una aplicación dentro del catálogo
• Campos mínimos que debería incluir cada aplicación
• Información operativa que añade verdadero valor
• Cómo clasificar criticidad e impacto
• Estados y ciclo de vida de una aplicación Docker
• Cómo asignar responsabilidad sin crear burocracia
• Cómo representar dependencias entre aplicaciones y servicios
• Datos, persistencia y copias de seguridad
• Versiones y estrategia de actualización
• Seguridad, exposición y accesos
• Cómo estructurar el catálogo en la práctica
• Ejemplo de ficha de una aplicación
• Qué información puede obtenerse automáticamente de Docker
• Cómo mantener el catálogo actualizado
• Cómo utilizar el catálogo para tomar decisiones
• Errores frecuentes al crear un catálogo de aplicaciones Docker
• Conclusión
• Preguntas frecuentes

Qué es un catálogo interno de aplicaciones Docker

Un catálogo interno es una relación organizada de las aplicaciones que forman parte de una plataforma tecnológica. Su propósito es permitir que una persona autorizada pueda conocer, sin inspeccionar todos los servidores, qué aplicaciones existen, qué función cumplen, quién depende de ellas y cómo están gestionadas.

En Docker, esa visión es especialmente útil porque la unidad visible para el motor de contenedores no siempre coincide con la unidad que entiende el usuario. Docker ve contenedores, imágenes, redes y volúmenes. La organización, en cambio, utiliza aplicaciones y servicios.

Por ejemplo, una aplicación de gestión documental podría estar formada por:

• un contenedor con la interfaz web;
• un contenedor con la lógica de aplicación;
• una base de datos;
• un servicio de caché;
• un proxy inverso compartido;
• uno o varios volúmenes persistentes.

Registrar cada componente de forma aislada es necesario desde el punto de vista técnico, pero no explica inmediatamente que todos ellos forman una aplicación concreta utilizada para una finalidad empresarial determinada.

El catálogo crea esa capa de significado. Permite pasar de una pregunta técnica —“¿qué contenedores están ejecutándose?”— a preguntas operativas como “¿qué aplicaciones son críticas?”, “¿cuáles están en pruebas?”, “¿qué servicio utiliza este departamento?”, “¿qué aplicación no tiene responsable?” o “¿qué herramienta puede retirarse sin afectar a otros procesos?”.

Catálogo, inventario y documentación: diferencias

Conviene distinguir claramente estos tres elementos para no acabar manteniendo tres copias de la misma información.

Inventario Docker

El inventario técnico registra recursos de la plataforma: contenedores, imágenes, redes, volúmenes, puertos, nombres de host, rutas, etiquetas y otros elementos. Si todavía no existe, puede servir como referencia el artículo sobre cómo inventariar todos los contenedores Docker de una empresa.

Su pregunta principal es: ¿qué existe técnicamente?

Documentación de infraestructura

La documentación explica arquitectura, relaciones, procedimientos de despliegue, recuperación, mantenimiento y decisiones técnicas. En cómo documentar una infraestructura basada en Docker se desarrolla esta capa con más detalle.

Su pregunta principal es: ¿cómo está construido y cómo se opera?

Catálogo de aplicaciones

El catálogo agrupa los componentes técnicos bajo servicios comprensibles y añade información funcional y de gestión: finalidad, usuarios, criticidad, responsable, estado, dependencia empresarial y ciclo de vida.

Su pregunta principal es: ¿qué aplicaciones proporciona la plataforma y qué papel desempeña cada una?

Los tres elementos deben relacionarse, pero no duplicarse. Una ficha del catálogo puede enlazar al proyecto Docker, al inventario correspondiente y a la documentación detallada en lugar de copiar todo su contenido.

Por qué conviene crear el catálogo antes de que la plataforma crezca

El momento más fácil para crear un catálogo es cuando parece que todavía no hace falta. Con cinco aplicaciones, reunir la información puede llevar poco tiempo. Con treinta aplicaciones acumuladas durante varios años, descubrir su finalidad, dependencias y responsables puede convertirse en un trabajo de arqueología tecnológica.

Una plataforma sin catálogo tiende a desarrollar varios problemas.

Dependencia de la memoria

Las aplicaciones se identifican por nombres de directorios, nombres de contenedor o recuerdos informales. Si la persona que montó el servicio no está disponible, entenderlo requiere inspeccionar configuración y registros.

Servicios olvidados

Un contenedor puede seguir funcionando durante años aunque nadie recuerde si sigue siendo necesario. Esto consume recursos, amplía superficie de mantenimiento y dificulta distinguir producción de pruebas antiguas.

Actualizaciones sin contexto

Saber que una imagen tiene una versión nueva no indica automáticamente si debe actualizarse. Para decidir hace falta conocer criticidad, usuarios, dependencia de datos, ventana de mantenimiento y capacidad de reversión.

Copias incompletas

Puede existir una política de backup de determinados volúmenes sin que nadie haya verificado qué aplicación depende de ellos o si también necesita una base de datos, archivos de configuración y claves externas para recuperarse.

Dificultad para simplificar

Una plataforma madura no solo añade aplicaciones; también debe poder retirarlas. Sin catálogo es difícil detectar duplicidades, servicios infrautilizados o herramientas que ya no justifican su mantenimiento.

Crear el catálogo desde el principio ayuda a que el crecimiento de Docker siga siendo deliberado en lugar de convertirse en una acumulación de contenedores.

Qué debe considerarse una aplicación dentro del catálogo

Una de las decisiones más importantes es definir qué representa una fila o una ficha del catálogo. La regla práctica es sencilla: debe representar algo que tenga una finalidad reconocible para sus usuarios u operadores.

No es necesario crear una entrada independiente para cada contenedor. Si cuatro contenedores forman una única aplicación, normalmente deben aparecer agrupados bajo la misma ficha.

Aplicación de usuario

Es el caso más evidente: un gestor documental, una wiki, un panel de análisis o una herramienta interna. Tiene usuarios concretos y una finalidad funcional clara.

Servicio de infraestructura

Algunos elementos no son aplicaciones visibles para usuarios, pero merecen ficha propia porque tienen suficiente importancia: un proxy inverso compartido, un sistema de autenticación, una plataforma de monitorización o un servicio central de copias.

Componente interno de otra aplicación

Una base de datos exclusiva, una caché o un worker normalmente no necesitan ficha independiente si solo existen como parte de una aplicación. Deben documentarse dentro de la ficha y del inventario técnico.

Entorno temporal

Las pruebas relevantes también pueden catalogarse, pero marcadas como tales. El problema no es tener entornos temporales; el problema es que se conviertan en permanentes sin que nadie lo advierta.

Esta forma de agrupar encaja con una organización por proyectos como la descrita en cómo organizar correctamente los proyectos Docker: el proyecto proporciona la estructura técnica y el catálogo aporta el significado operativo.

Campos mínimos que debería incluir cada aplicación

Un catálogo útil no necesita empezar con decenas de campos. Es preferible tener quince datos actualizados que cincuenta abandonados.

Como base, cada aplicación debería registrar:

• Nombre de la aplicación: denominación humana y estable.
• Identificador: código corto o nombre canónico si se necesita distinguirla inequívocamente.
• Finalidad: para qué existe y qué necesidad cubre.
• Estado: propuesta, pruebas, producción, retirada prevista, retirada u otro estado definido.
• Criticidad: importancia operativa y consecuencias de una interrupción.
• Usuarios o ámbito: quién la utiliza o qué proceso depende de ella.
• Responsable: persona, función o procedimiento que gobierna su mantenimiento.
• Ubicación: host, nodo o plataforma donde se ejecuta.
• Proyecto Docker: referencia al directorio, repositorio o definición Compose correspondiente.
• URL o forma de acceso: cuando proceda.
• Datos persistentes: indicación de si conserva datos y dónde se documentan.
• Backup: estado de protección y referencia al procedimiento.
• Versión: versión funcional de la aplicación o referencia de imagen relevante.
• Última revisión: fecha en que la ficha fue validada.
• Documentación: enlace o ruta hacia documentación técnica detallada.

Estos campos permiten responder a la mayoría de preguntas habituales sin convertir el catálogo en una réplica del sistema de monitorización.

Información operativa que añade verdadero valor

Cuando el catálogo básico funciona, pueden añadirse campos que permitan tomar mejores decisiones.

Entorno

Indicar si la aplicación está en desarrollo, pruebas, preproducción o producción evita confundir instancias aparentemente iguales.

Exposición

Conviene registrar si es interna, accesible por VPN, publicada en Internet o disponible únicamente desde una red determinada.

Dependencia externa

Algunas aplicaciones dependen de servicios que no están dentro de Docker: DNS, correo, almacenamiento externo, APIs, certificados, autenticación o proveedores de identidad.

Ventana de mantenimiento

Una herramienta usada de forma esporádica puede actualizarse casi en cualquier momento. Una aplicación crítica necesita conocer cuándo puede detenerse y quién debe validar su recuperación.

Objetivo de recuperación

No hace falta convertir el catálogo en un plan de continuidad completo, pero sí puede indicar si una aplicación debe volver a estar disponible inmediatamente, durante la jornada o simplemente cuando haya tiempo.

Procedencia

Puede resultar útil distinguir entre aplicación propia, proyecto open source, imagen mantenida por terceros o componente desarrollado internamente.

Coste asociado

Aunque Docker sea software libre, la aplicación puede requerir infraestructura, almacenamiento, licencias, servicios externos o tiempo significativo de operación. Registrar esa relación facilita revisar posteriormente si sigue aportando valor.

Cómo clasificar criticidad e impacto

La criticidad no debería asignarse por intuición ni por lo sofisticada que sea la aplicación. Debe basarse en el impacto que tendría su indisponibilidad o pérdida.

Un esquema sencillo de cuatro niveles suele ser suficiente.

Nivel 1: auxiliar

Su interrupción apenas afecta al trabajo y puede permanecer parada durante un periodo prolongado. Ejemplos típicos serían herramientas de laboratorio o utilidades prescindibles.

Nivel 2: importante

Su ausencia dificulta determinadas tareas, pero existe una alternativa temporal o el proceso puede esperar.

Nivel 3: crítica

Su caída afecta directamente a un proceso importante y debe recuperarse con prioridad.

Nivel 4: esencial

La organización depende de ella para operar o para acceder a otros servicios. Su fallo puede bloquear múltiples procesos.

La clasificación debe considerar al menos:

• número de personas o procesos afectados;
• posibilidad de trabajar temporalmente sin la aplicación;
• impacto de perder datos;
• existencia de alternativas;
• dependencias de otras aplicaciones;
• tiempo razonable de recuperación.

Esta información permite priorizar backups, monitorización y actualizaciones en lugar de tratar todas las aplicaciones como si tuvieran la misma importancia.

Estados y ciclo de vida de una aplicación Docker

Una aplicación no debería aparecer en el catálogo únicamente como “activa” o “inactiva”. Definir un ciclo de vida ayuda a controlar qué se incorpora y qué debe desaparecer.

1. Propuesta: se estudia la aplicación pero todavía no forma parte de la plataforma.
2. Evaluación: se prueba con alcance limitado.
3. Pruebas: está desplegada para verificar funcionamiento, integración y mantenimiento.
4. Producción: forma parte de la operativa normal.
5. Revisión: sigue activa, pero se cuestiona su utilidad, coste o sostenibilidad.
6. Retirada prevista: existe una decisión de eliminarla o sustituirla.
7. Retirada: ya no está operativa, aunque puede conservarse temporalmente cierta información.
8. Archivada: solo se conserva documentación o datos históricos.

El catálogo se convierte así en una herramienta de ciclo de vida. No solo explica qué existe hoy, sino qué está entrando, qué debe revisarse y qué está saliendo.

Esto reduce un problema habitual en Docker: los experimentos que nunca se eliminan y terminan pareciendo servicios oficiales.

Cómo asignar responsabilidad sin crear burocracia

Registrar un responsable no significa que cada aplicación deba tener una persona dedicada. Significa que debe existir una referencia clara sobre quién decide o qué procedimiento se aplica cuando hay que actualizarla, restaurarla, cambiarla o retirarla.

En una organización pequeña, una misma persona puede ser responsable de toda la plataforma. Aun así, registrar esa responsabilidad evita ambigüedades y facilita futuras delegaciones.

Puede utilizarse una de estas fórmulas:

• persona concreta;
• rol técnico;
• área funcional;
• equipo responsable;
• proveedor externo, cuando corresponda;
• procedimiento documentado si la operación está suficientemente estandarizada.

También conviene distinguir entre responsable técnico y propietario funcional cuando la plataforma crece. El primero mantiene el servicio; el segundo decide si la aplicación sigue siendo necesaria y qué requisitos debe cumplir.

Cómo representar dependencias entre aplicaciones y servicios

Una aplicación puede funcionar correctamente por sí sola y, sin embargo, depender de varias piezas externas. El catálogo debe hacer visibles esas relaciones sin intentar sustituir un diagrama técnico detallado.

Para cada aplicación puede registrarse una lista breve de dependencias:

• base de datos dedicada o compartida;
• proxy inverso;
• DNS;
• autenticación central;
• almacenamiento externo;
• servidor de correo;
• API externa;
• servicio de colas;
• otra aplicación del propio catálogo;
• certificados o servicios de red específicos.

También debe registrarse la dirección contraria cuando sea importante: qué otras aplicaciones dependen de esta.

Este dato permite detectar componentes comunes que se han convertido en puntos centrales. Un proxy, una base compartida o un proveedor de identidad pueden tener más importancia real que muchas aplicaciones visibles.

Cuando las relaciones sean complejas, el catálogo puede enlazar a la documentación de arquitectura en lugar de intentar describirlas todas dentro de una celda.

Datos, persistencia y copias de seguridad

Uno de los campos más útiles del catálogo es una respuesta clara a dos preguntas: ¿esta aplicación conserva datos importantes y esos datos están protegidos?

No es necesario almacenar en el catálogo todas las rutas y comandos de copia. Es más eficiente registrar:

• si la aplicación es con estado o sin estado;
• qué tipo de información persiste;
• si utiliza volúmenes, bind mounts, base de datos u otros almacenes;
• nivel de importancia de los datos;
• si existe backup;
• frecuencia o política aplicable;
• fecha de la última prueba de restauración cuando sea relevante;
• enlace al procedimiento detallado de recuperación.

Una aplicación marcada como crítica y sin backup debería destacar inmediatamente en una revisión del catálogo. Esa capacidad de detectar incoherencias es una de sus mayores ventajas.

La estrategia técnica de protección puede desarrollarse por separado siguiendo criterios como los explicados en cómo diseñar una política de copias de seguridad para Docker. El catálogo debe reflejar el resultado de esa política, no repetirla.

Versiones y estrategia de actualización

Registrar versiones puede parecer un detalle técnico, pero ayuda a saber qué aplicaciones están desactualizadas, cuáles siguen ramas estables y cuáles requieren especial precaución.

Conviene evitar dos extremos:

• no registrar ninguna referencia de versión;
• copiar manualmente cada digest y cada etiqueta de todos los contenedores en el catálogo.

La ficha debería contener la versión funcional relevante o la política utilizada, mientras que el inventario técnico puede conservar detalles exactos de imágenes y digests.

También resulta útil registrar el modelo de actualización:

• manual bajo revisión;
• periódica planificada;
• automatizada con validación;
• actualización solo por necesidad;
• versión fijada temporalmente por compatibilidad.

La política general puede apoyarse en una estrategia como la descrita en cómo diseñar una estrategia de actualización de contenedores Docker.

El catálogo permite después cruzar criticidad y política de actualización. Una aplicación crítica que actualiza automáticamente sin pruebas puede requerir revisión; una herramienta secundaria que lleva años bloqueada en una versión antigua también puede indicar deuda de mantenimiento.

Seguridad, exposición y accesos

El catálogo no debe guardar contraseñas, tokens ni secretos. Sí debe permitir saber qué superficie presenta cada aplicación y dónde se gestionan sus credenciales.

Los campos útiles pueden incluir:

• ámbito de acceso: local, red interna, VPN o Internet;
• método de autenticación;
• uso de cuentas locales o identidad centralizada;
• existencia de roles o permisos;
• responsable de revisar accesos;
• localización del gestor de secretos, sin revelar los valores;
• proxy o componente que publica el servicio;
• necesidad de certificados;
• restricciones especiales de red.

Una vista del catálogo filtrada por “expuesta a Internet” debería permitir revisar rápidamente qué aplicaciones necesitan especial atención de seguridad.

Cómo estructurar el catálogo en la práctica

No existe una herramienta obligatoria. Para una plataforma pequeña, una tabla bien diseñada puede ser suficiente. Lo importante es que haya una fuente oficial y que resulte sencillo actualizarla.

Hoja de cálculo

Es una opción práctica para empezar. Permite filtrar por estado, criticidad, responsable, host o exposición. Su principal riesgo aparece cuando se crean copias locales divergentes.

CSV o archivo estructurado

Puede almacenarse en un repositorio y versionarse. Facilita automatización, aunque es menos cómodo para usuarios no técnicos.

Markdown

Una ficha por aplicación resulta muy legible y puede mantenerse junto al código o en un repositorio de documentación.

Wiki o gestor documental

Resulta útil cuando se desea combinar catálogo, procedimientos y documentación contextual. Conviene evitar que la flexibilidad termine generando páginas con formatos completamente diferentes.

Base de datos o herramienta específica

Puede tener sentido cuando existen muchas aplicaciones o se necesita relacionarlas con servidores, responsables, costes y activos. No debería implantarse únicamente porque sea técnicamente posible.

Para una plataforma pequeña, una buena regla es empezar con el formato más sencillo que permita:

• filtrar;
• buscar;
• enlazar documentación;
• registrar fecha de revisión;
• mantener una única fuente válida;
• exportar los datos si en el futuro cambia la herramienta.

Ejemplo de ficha de una aplicación

Una ficha sencilla podría estructurarse así:

El ejemplo evita datos sensibles y detalles técnicos excesivos. Una persona que lo consulte puede entender rápidamente qué es la aplicación y dónde debe buscar información adicional.

Qué información puede obtenerse automáticamente de Docker

Parte del catálogo puede alimentarse con información técnica obtenida desde Docker, aunque conviene mantener una frontera clara entre automatización y contexto humano.

Docker puede ayudar a obtener:

• contenedores en ejecución y detenidos;
• nombres de imágenes;
• etiquetas de versión;
• labels;
• puertos;
• redes;
• volúmenes;
• estado del contenedor;
• proyecto Compose;
• fecha aproximada de creación;
• información de salud cuando existe healthcheck.

Sin embargo, Docker no sabe por sí solo:

• para qué sirve realmente una aplicación;
• qué proceso empresarial depende de ella;
• si sigue siendo necesaria;
• quién debe decidir sobre su continuidad;
• qué impacto tendría una caída;
• si la copia existente es suficiente;
• si la herramienta está pendiente de sustitución;
• si su coste de mantenimiento sigue estando justificado.

Una estrategia interesante es utilizar labels consistentes en los proyectos Docker para identificar nombre de servicio, entorno, propietario o referencia documental. Después, un script puede comparar el estado real con el catálogo y detectar diferencias.

El objetivo de automatizar no debe ser eliminar la revisión humana, sino reducir la tarea mecánica de descubrir si el catálogo y la plataforma han dejado de coincidir.

Cómo mantener el catálogo actualizado

Un catálogo abandonado es peor que un catálogo pequeño, porque transmite una sensación falsa de control. La clave es incorporar su actualización a los cambios normales de la plataforma.

Alta de aplicación

Ninguna aplicación debería pasar a producción sin ficha mínima. Crear la entrada forma parte del propio despliegue.

Cambio relevante

Debe revisarse la ficha cuando cambian:

• host;
• URL;
• responsable;
• criticidad;
• método de backup;
• dependencias;
• exposición;
• modelo de actualización;
• estado del ciclo de vida.

Retirada

Eliminar contenedores no debería borrar la historia de la aplicación inmediatamente. La ficha puede pasar a retirada o archivada, indicando qué ocurrió con sus datos y por qué dejó de utilizarse.

Revisión periódica

Además de actualizar por evento, resulta útil realizar una revisión periódica. La frecuencia depende del ritmo de cambios. Una plataforma que cambia cada semana necesita más control que otra prácticamente estable.

La revisión puede responder cinco preguntas:

1. ¿La aplicación sigue existiendo?
2. ¿Sigue siendo necesaria?
3. ¿Su ficha coincide con la realidad?
4. ¿Su nivel de protección es coherente con su criticidad?
5. ¿Hay alguna decisión pendiente de actualización, sustitución o retirada?

Cómo utilizar el catálogo para tomar decisiones

El catálogo alcanza su verdadero valor cuando deja de ser un documento pasivo y se utiliza para dirigir la plataforma.

Planificar mantenimiento

Filtrar por criticidad y ventana de mantenimiento permite decidir qué servicios necesitan más preparación antes de una intervención.

Priorizar copias

Puede localizarse cualquier aplicación con datos persistentes que todavía no tenga protección adecuada o prueba de recuperación.

Revisar exposición a Internet

Un filtro por tipo de acceso permite obtener rápidamente la lista de aplicaciones publicadas y revisar si todas necesitan seguir expuestas.

Detectar aplicaciones sin responsable

Un servicio sin responsable tiende a quedar sin actualizar, sin revisar o sin una decisión clara cuando empieza a fallar.

Identificar duplicidades

Clasificar aplicaciones por finalidad puede mostrar que existen varias herramientas resolviendo el mismo problema.

Preparar migraciones

Antes de mover un host Docker, el catálogo permite saber qué aplicaciones dependen de él y en qué orden conviene planificar la transición.

Planificar renovaciones

Una aplicación con alta carga de mantenimiento, baja utilización y sustituto disponible puede convertirse en candidata a retirada.

Delegar administración

Una persona que recibe la responsabilidad de la plataforma puede empezar por el catálogo para comprender qué servicios existen y después profundizar en inventario y documentación.

También ayuda a mantener coherencia con tareas como monitorizar contenedores Docker de forma sencilla: la monitorización indica qué ocurre; el catálogo indica cuánto importa y quién debe actuar.

Errores frecuentes al crear un catálogo de aplicaciones Docker

Convertirlo en una copia de docker ps

Un listado de contenedores no es un catálogo de aplicaciones. Falta finalidad, agrupación, responsabilidad, criticidad y estado.

Crear una ficha por contenedor

Multiplica el ruido y oculta qué componentes forman una misma aplicación.

Duplicar toda la documentación técnica

El catálogo debe enlazar hacia procedimientos y arquitectura detallada. Copiarlos provoca versiones contradictorias.

Guardar secretos

Contraseñas, tokens y claves privadas no deben almacenarse en el catálogo. Debe indicarse dónde se gestionan de forma segura.

Utilizar campos que nadie mantiene

Cada campo tiene un coste de mantenimiento. Si un dato nunca se consulta ni sirve para tomar decisiones, probablemente no deba formar parte del catálogo.

No definir estados

Sin ciclo de vida, pruebas antiguas y aplicaciones oficiales terminan mezcladas.

No registrar la fecha de revisión

Un dato sin fecha puede ser correcto o llevar tres años desactualizado. La fecha permite valorar su fiabilidad.

Tener varios catálogos

Una hoja de cálculo, una wiki y un documento con listas diferentes crean más confusión que ausencia de catálogo. Debe existir una fuente principal.

Confundir catálogo con monitorización

El catálogo no necesita almacenar CPU, memoria o latencia en tiempo real. Esos datos pertenecen a herramientas de observabilidad.

Catalogar solo producción

Los entornos de pruebas y aplicaciones en evaluación también ocupan recursos y pueden quedar olvidados. Deben ser visibles, aunque claramente clasificados.

No utilizar el catálogo para retirar servicios

Si el catálogo solo crece, terminará reflejando una plataforma que también solo crece. Debe ayudar a detectar y cerrar ciclos de vida.

Conclusión

Un catálogo interno de aplicaciones Docker crea una capa de orden entre la infraestructura técnica y las necesidades reales que esa infraestructura cubre. Docker permite saber qué contenedores existen; el catálogo permite saber qué aplicaciones representan, por qué importan y cómo deben gestionarse.

La clave está en no convertir el catálogo en otra documentación gigantesca. Debe contener información estable y útil para decidir: finalidad, estado, criticidad, usuarios, responsable, ubicación, proyecto, datos, copias, actualización, exposición, dependencias y referencia documental.

Cuando se mantiene correctamente, el catálogo permite detectar servicios olvidados, dependencias críticas, aplicaciones sin backup, sistemas sin responsable, herramientas duplicadas y componentes pendientes de retirada. También facilita mantenimiento, migraciones, recuperación y delegación.

Una plataforma Docker deja de ser una colección de contenedores cuando cada aplicación puede identificarse, explicarse, mantenerse y retirarse con criterio. El catálogo es una de las herramientas más sencillas para conseguirlo.

Preguntas frecuentes