¿Por qué un alias de red de Compose deja de resolverse después de recrear la pila con un nombre de proyecto nuevo?
Un alias de Compose puede dejar de resolverse después de recrear un servicio cuando este se conecta a una red con un alcance de proyecto diferente o cuando el alias ya no está asociado a ella.
Los alias de Docker están limitados a la red; no son nombres globales. Recrear una pila desde un directorio nuevo, con un nombre de proyecto explícito, un nombre de pila de Portainer o un proyecto de Compose puede crear una nueva red predeterminada mientras otra aplicación permanece en la anterior. El servicio puede estar sano y ser accesible mediante el puerto publicado, pero su alias interno falla porque el solicitante y el destino ya no comparten la misma red o porque un proxy inverso seleccionó una conexión diferente.
Compara los nombres de los proyectos de Compose antiguo y nuevo
Registra el nombre del proyecto anterior y el actual, el directorio de trabajo, el nombre de la pila, los nombres de las redes y las etiquetas de los contenedores. Compara el servicio solicitante y el servicio de destino después de recrearlos.
Docker Compose utiliza el nombre del proyecto para agrupar y nombrar recursos. Su precedencia del nombre del proyecto explica por qué cambiar el directorio o el nombre de implementación puede crear una red nueva en lugar de reutilizar la red anterior del proyecto.
Si el solicitante sigue conectado a oldproject_default mientras el destino se conecta a newproject_default, el alias anterior ya no tiene un ámbito DNS compartido.
Verifica el alias en la red compartida exacta
Inspecciona ambos contenedores y enumera todas las redes conectadas, los puntos de conexión, las direcciones IPv4 o IPv6 y los alias. Prueba el DNS desde dentro del contenedor solicitante.
La especificación de Compose define los alias como nombres limitados a la red, por lo que un alias declarado en una red no existe automáticamente en otra conexión.
Mueve la declaración del alias a la red que realmente comparten los servicios. No dependas de container_name como sustituto de un descubrimiento de servicios planificado.
Comprueba los nombres de redes externas y la sustitución durante la implementación
Compara la clave lógica de la red de Compose con su name externo explícito. Comprueba la sustitución de variables de entorno y las variables de la interfaz de la pila utilizadas durante la implementación.
Portainer documenta que las pilas pueden usar redes de Docker existentes, que deben seleccionarse de forma coherente cuando las pilas implementadas de manera independiente necesitan resolverse entre sí.
Una red externa evita los cambios en el prefijo del proyecto solo cuando todas las pilas hacen referencia al mismo nombre de red real. Un error tipográfico puede crear o seleccionar una red diferente sin cambiar el puerto publicado del servicio.
Confirma que el solicitante usa el DNS de Docker y no una dirección almacenada en caché
Realiza una búsqueda nueva desde el solicitante, inspecciona su configuración del resolvedor y reinicia únicamente el proceso que almacena el DNS en caché cuando sea necesario. Compara la resolución del alias con una búsqueda directa del nombre del servicio.
El modelo de espacios de nombres de red de Linux aísla los recursos de red, por lo que el éxito del DNS del host no demuestra que el contenedor solicitante comparta la red de Docker del destino.
No añadas la IP actual del contenedor de destino a /etc/hosts. Los contenedores recreados pueden recibir una dirección diferente, lo que deja otra dependencia obsoleta.
Comprueba qué red utiliza el proxy inverso
Inspecciona las conexiones de red del proxy y de la aplicación, las etiquetas del proveedor y la red seleccionada para enrutar al backend. Prueba el alias desde el contenedor del proxy.
El proveedor de Docker de Traefik permite especificar la red de Docker utilizada para las conexiones al backend.
Si el proxy está conectado a varias redes, la selección automática puede cambiar después de recrearlo. Define explícitamente la red compartida prevista y mantén estable su nombre real.
Elimina los puntos de conexión obsoletos sin borrar la red equivocada
Enumera los contenedores conectados a las redes antigua y nueva. Identifica los puntos de conexión huérfanos, los contenedores detenidos y los servicios activos que aún dependen de la red antigua del proyecto.
La guía de redes de contenedores de Red Hat describe la conexión de contenedores a redes definidas por el usuario como parte del estado del entorno de ejecución de contenedores, no del contenido de los archivos de la aplicación.
Elimina una red antigua solo después de demostrar que ninguna pila activa la utiliza. Borrar ambas redes y recrearlo todo a la vez destruye las pruebas que muestran qué conexión era incorrecta.
Recrea un servicio y verifica el DNS desde cada solicitante
Estandariza el nombre del proyecto o la red externa, recrea únicamente el servicio afectado y prueba el nombre del servicio y el alias desde cada contenedor dependiente.
El artículo de ZimaSpace sobre las dependencias del entorno de ejecución del contenedor ofrece la regla relacionada: una prueba de conectividad desde el host no valida el espacio de nombres ni la ruta de descubrimiento de servicios del contenedor.
El problema se resuelve cuando el alias se resuelve en el punto de conexión actual desde cada solicitante previsto después de recrear la pila y reiniciar el sistema, sin direcciones IP codificadas manualmente.
Preguntas frecuentes
¿Los alias de red de Docker son globales?
No. Un alias existe únicamente en la red donde está configurado y solo resulta útil para los contenedores que comparten esa red.
¿Cambiar el nombre de la carpeta de Compose puede romper el DNS?
Sí. La carpeta puede afectar al nombre predeterminado del proyecto, que a su vez afecta a los nombres de red generados, a menos que se fije el nombre del proyecto o de la red externa.
¿Debo usar container_name para mantener estable el DNS?
Por lo general, no. Los nombres de servicio estables y las redes compartidas explícitas mantienen la capacidad de escalado de Compose y evitan conflictos de nombres globales.
Productos recomendados
Soporte y Consejos
Más para leer
¿Por qué restaurar un volumen de Docker recrea el contenido de los archivos, pero elimina los atributos extendidos?
Un diagnóstico de restauración de volúmenes que abarca el inventario de atributos extendidos, las opciones de tar y Rsync, los espacios de nombres, la...
¿Por qué un contenedor en ejecución mantiene su antiguo límite de memoria después de cambiar el archivo de Compose?
Un diagnóstico del límite de memoria que abarca los cgroups activos, el reinicio frente a la recreación, los campos de Compose, los límites estrictos...
¿Por qué reiniciar un proxy inverso invalida todas las sesiones de una aplicación autoalojada?
Un diagnóstico de pérdida de sesión que abarca el alcance del reinicio, la propiedad de las cookies, la rotación de secretos, las sesiones respaldadas...
