¿Puedes cambiar el puerto publicado de un contenedor sin reconstruir su base de datos?
Sí, puedes cambiar el puerto publicado de un contenedor sin reconstruir su base de datos cuando esta permanece en el mismo almacenamiento persistente verificado.
En un NAS doméstico o un host de Docker, el puerto visible normalmente pertenece al contenedor de la aplicación, que es desechable, mientras que los registros, las cuentas y la configuración se almacenan en un volumen con nombre, un montaje enlazado o un servicio de base de datos independiente. Por tanto, el cambio seguro consiste en conservar la definición del despliegue y las rutas persistentes, modificar únicamente la regla de publicación del lado del host, recrear el servicio de la aplicación afectado y, después, verificar todos los proxies, marcadores, callbacks, reglas del firewall y comprobaciones de estado que aún hagan referencia al puerto anterior.
Separa el puerto publicado del host del puerto de escucha del contenedor
Anota la asignación actual como dos puntos finales diferentes antes de cambiarla. En 8080:80, los clientes se conectan al puerto 8080 del host de Docker, mientras que la aplicación sigue escuchando en el puerto 80 dentro del contenedor. Cambiar el lado izquierdo no modifica automáticamente el proceso de la aplicación ni su conexión a la base de datos.
Un caso de resolución de problemas de la comunidad de Docker destaca que la asignación del host y el puerto de escucha interno son independientes, y que un nuevo puerto publicado no puede funcionar cuando no hay nada escuchando internamente en el puerto de destino.
Inspecciona los puertos publicados y los sockets de escucha del contenedor en ejecución; después, prueba el punto final interno desde dentro del contenedor o de su red. Mantén sin cambios el puerto interno, salvo que la propia aplicación deba cambiarlo. Esta primera prueba evita que un simple cambio de puerto del host se convierta en una reconfiguración innecesaria de la aplicación.
Protege la ruta actual de la base de datos antes de recrear el servicio
Registra el archivo de Compose, la etiqueta o el resumen de la imagen, los archivos de entorno, los volúmenes con nombre, los montajes enlazados, los nombres de red, los secretos y el nombre de host de la base de datos. El objetivo es demostrar qué objeto contiene el estado persistente antes de que Docker sustituya el contenedor de la aplicación.
Cambiar la publicación del puerto requiere una nueva configuración del contenedor, pero no una nueva compilación de la imagen ni una nueva base de datos. Una respuesta práctica de Docker distingue entre la recreación del contenedor y la reconstrucción de la imagen de la aplicación cuando cambian los ajustes de puertos.
Haz una copia de seguridad o una instantánea coherente con la aplicación de la base de datos actual cuando el servicio sea importante y, después, verifica que la ruta de la base de datos no se encuentre dentro de la capa de escritura del contenedor. Detente si la lista de montajes no es clara, si cambió el nombre del volumen o si la aplicación actual parece estar utilizando una base de datos vacía inesperada.
Cambia solo la asignación del lado del host y recrea el servicio de la aplicación
Edita el servicio de la aplicación para cambiar una asignación como 8080:80 por 8081:80. Mantén sin cambios la imagen, el puerto interno, los volúmenes, la URL de la base de datos, el nombre del servicio, las redes y la asignación de usuario, salvo que exista otro requisito verificado.
La sintaxis de puertos de Compose se interpreta del host al contenedor, por lo que cambiar el lado del host deja el proceso escuchando en su puerto interno existente. Un ejemplo del foro de Docker explica por qué el lado izquierdo es el puerto del host y el derecho aún debe coincidir con el puerto de escucha de la aplicación.
Recrea únicamente el servicio de la aplicación con la definición actualizada. No uses un comando de pila que elimine volúmenes, no vuelvas a inicializar la base de datos y no añadas --build salvo que haya cambiado la imagen. Después de recrearlo, inspecciona los montajes efectivos y la asignación de puertos antes de permitir que se ejecuten migraciones o tareas en segundo plano.
Actualiza todas las rutas de cliente que dependan del puerto anterior
Un marcador del navegador es solo uno de los consumidores del puerto publicado. Los proxies inversos, los redireccionamientos del router, los firewalls locales, las sondas de monitorización, las aplicaciones móviles, los destinos de webhooks, los callbacks de OAuth, las listas de permitidos de CORS y las URL públicas generadas aún pueden apuntar al punto final anterior.
Algunas aplicaciones autoalojadas realizan solicitudes de bucle local o construyen las URL de callback a partir de su dirección pública configurada. Un debate sobre un contenedor de WordPress muestra cómo un cambio en la asignación externa puede revelar un comportamiento de bucle local condicionado por el puerto incluso cuando la base de datos sigue funcionando correctamente.
Busca el puerto anterior en el proyecto de Compose, la configuración del proxy, los archivos de entorno y los ajustes de la aplicación. Actualiza únicamente las capas que realmente utilicen el punto final del host. Normalmente, los contenedores internos deben seguir usando el nombre del servicio y el puerto interno, en lugar del nuevo puerto publicado del host.
Mantén la base de datos en su ruta privada del contenedor
No cambies ni publiques el puerto de la base de datos simplemente porque haya cambiado el puerto del host de la aplicación web. Una base de datos utilizada únicamente por contenedores de la misma pila puede seguir siendo accesible mediante su nombre de servicio y su puerto interno sin ninguna publicación en el host.
Confundir el punto final público de la aplicación con la conexión de la base de datos puede provocar una segunda interrupción: es posible que la aplicación se dirija a la dirección del NAS y a un puerto del host aunque la base de datos deba permanecer en una red privada de Docker. Ese cambio añade variables de firewall, NAT y autenticación sin ayudar al navegador a acceder al servicio web.
Desde el contenedor recreado de la aplicación, resuelve el nombre del servicio de la base de datos, abre su puerto TCP interno, autentícate y ejecuta una lectura inocua. Si esa ruta no ha cambiado, déjala sin cambios. Si la prueba de la base de datos falla, restaura la definición original de la aplicación antes de investigar el problema independiente de red o credenciales.
Verifica el nuevo puerto sin tocar los datos persistentes
Prueba directamente el nuevo puerto del host y, después, el nombre de host normal o la ruta del proxy inverso. Confirma el inicio de sesión, la lectura de registros, una escritura reversible, las cargas de archivos, las tareas programadas, las integraciones y un reinicio controlado del contenedor.
La guía de ZimaSpace sobre cómo hacer coincidir las comprobaciones de estado con las rutas reales de la aplicación es el siguiente paso cuando el nuevo punto final del navegador funciona, pero Docker sigue informando que el servicio no está saludable.
El cambio solo se completa cuando el nuevo puerto publicado sobrevive a la recreación y al reinicio, el proxy y los clientes ya no utilizan el punto final anterior, la aplicación se reconecta a la misma base de datos persistente y la copia de seguridad de la base de datos sigue disponible. Revierte la asignación de puertos si la aplicación se inicia con un estado nuevo y vacío o intenta realizar una migración inesperada.
Productos recomendados
Soporte y Consejos
Más para leer
¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...
Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...
Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...
