Publicar una aplicación Docker

En el ejercicio de Dockerfile construiste una imagen e iniciaste la app con docker run. Si completaste el ejercicio opcional [[App with Compose Level 1 - Kjor og oppdater appen|de Compose]], puedes usar Compose en su lugar. Aquí debes lograr que la misma app responda a través de un nombre DNS y un proxy accesible. Puedes utilizar tu propia app o la app de prueba del ejercicio de Dockerfile.

Primero realiza la prueba directa y luego HTTP a través del proxy. La ruta principal está completa cuando el nombre devuelve la respuesta esperada de la app y puedes explicar los componentes involucrados. HTTPS y la instalación de un proxy propio son opciones adicionales con sus propios requisitos previos.

Cuando la aplicación Flask se ejecuta en un servidor con un puerto, un proxy inverso puede recibir las solicitudes en nombre de la aplicación y reenviarlas al contenedor correcto. De este modo, el usuario puede utilizar un nombre de dominio en lugar de dirección IP y número de puerto. Necesitas un nombre DNS y un proxy al cual tengas acceso para configurarlo, así como un certificado si el servicio debe usar HTTPS.

DNS responde con una dirección pero no transporta la página web. En la figura, el proxy finaliza la conexión HTTPS y utiliza HTTP posteriormente en una red interna acotada. El navegador recibe la respuesta a través del proxy.

Antes de comenzar

Necesitarás un contenedor funcional del ejercicio de Dockerfile (o del ejercicio de Compose) y esta información del entorno de pruebas:

• APP-VM-IP: la dirección de la máquina virtual que ejecuta la aplicación; aquí se utiliza el puerto 5000.
• PROXY-IP: la dirección donde el cliente debe acceder al proxy, con HTTP en el puerto 80.
• APP-NAME: un nombre DNS que apunte al proxy. La aplicación y el proxy pueden estar en máquinas virtuales diferentes.

Necesitas acceso para crear una Proxy Host en Nginx Proxy Manager y permiso para la conexión desde el proxy a la aplicación. Los marcadores de posición anteriores deben reemplazarse por tus valores. Si no hay disponible resolución DNS o acceso al proxy, realiza la prueba local y explica la figura. Esto no constituye una prueba de publicación completada.

1. Verifica la aplicación localmente

Trabaje en el directorio del proyecto de la máquina virtual (VM) de la aplicación. Los comandos a continuación utilizan el nombre de contenedor min-app del ejercicio de Dockerfile. Con la vinculación de puertos definida allí, esta prueba debe mostrar la página principal:

The provided input does not contain any comments (lines starting with # or inline remarks) to translate. It consists entirely of executable commands. Therefore, no changes are required based on the translation rules.

docker ps
curl --fail --show-error http://127.0.0.1:5000/

Puede usar /status como un punto de control fijo. Si esta ruta no existe previamente, agréguela después de las demás funciones de ruta completas y antes de if __name__ == "__main__": en app.py:

@app.route("/status")
def status():
    return {"status": "ok"}

Construir, iniciar y probar de nuevo:

docker build -t min-app .
docker rm -f min-app
docker run -d --name min-app -p 127.0.0.1:5000:5000 min-app
curl --fail --show-error http://127.0.0.1:5000/status

Si usas Compose, sustituye las tres primeras comandos por docker compose up -d --build.

Espera un HTTP 200 y un JSON con "status": "ok". Si la aplicación ya tiene /status, usa su respuesta documentada en lugar de crear una nueva ruta con el mismo nombre. Esto controla la ruta, no todas las funciones de la aplicación.

2. Hacer la aplicación accesible para el proxy

La receta continúa utiliza la dirección de red del VM de la aplicación. Si el puerto solo está unido a 127.0.0.1, reinicia el contenedor con la dirección real del VM en la asignación de puertos. Restringe el acceso a la red a las fuentes necesarias; una unión de direcciones por sí sola no limita qué clientes pueden conectarse.

docker rm -f min-app
docker run -d --name min-app -p APP-VM-IP:5000:5000 min-app
curl --fail --show-error http://APP-VM-IP:5000/status

Si utiliza Compose, reemplace la línea de puerto bajo app en compose.yaml por "APP-VM-IP:5000:5000" y ejecute docker compose up -d.

Ejecute la prueba en el VM de la aplicación y desde el entorno de red del proxy, o bien desde un cliente de pruebas con los mismos permisos de acceso permitidos. La conexión real del proxy también se controla mediante el nombre indicado en la siguiente sección. Tras modificar la unión (binding), pruebe la dirección IP del VM, no 127.0.0.1. No abra el puerto hacia toda Internet. [[Segmentación Nivel 1 - VLAN y segmentación de redes|Segmentación]] proporciona soporte para las reglas de acceso.

De dominio a contenedor

Suceden varias cosas cuando un usuario abre un nombre como https://app.example.test. Este es un nombre de ejemplo; reemplázalo con el nombre que realmente esté configurado en tu entorno de pruebas:

sequenceDiagram
    participant B as Navegador
    participant D as DNS
    participant P as Nginx Proxy Manager
    participant F as Contenedor de Flask

    B->>D: Encuentra la dirección IP del dominio
    D-->>B: Dirección IP del proxy
    B->>P: Solicitud al dominio
    P->>P: Encuentra el host de proxy correcto
    P->>F: Reenviar a puerto interno 5000
    F-->>P: Devolver página HTML
    P-->>B: Devolver respuesta

Por lo tanto, es aconsejable probar una capa a la vez, en lugar de depurar simultáneamente el DNS, el proxy y Flask.

Nginx Proxy Manager

Nginx Proxy Manager es una interfaz web para Nginx. Aquí utilizas una instalación disponible y creas un solo Proxy Host. No necesitas instalar un nuevo proxy para cada aplicación.

Crea un Proxy Host:

1. Escribe APP-NAVN, el nombre que realmente está configurado para el servicio.
2. Selecciona http como esquema de la conexión desde Nginx Proxy Manager hasta el contenedor.
3. Escribe APP-VM-IP como nombre de host reenviado (forward hostname). 127.0.0.1 dentro de un contenedor de proxy se refiere al propio contenedor de proxy.
4. Escribe el puerto publicado del contenedor, por ejemplo, 5000.
5. Guarda y abre http://APP-NAVN/status desde el cliente.

El nombre debe resolverse a PROXY-IP. Puedes verificar la resolución con nslookup APP-NAVN en el cliente. La prueba HTTP debería dar la misma respuesta de estado que la prueba directa. Ver la página predeterminada del proxy no indica que la solicitud haya llegado a la aplicación.

Reelección: HTTPS

Cuando HTTP funcione y tengas un certificado válido para el nombre, abre la pestaña SSL, selecciona el certificado y prueba https://APP-NAME/status. Un nombre de ejemplo interno como app.example.test no puede obtener un certificado público de Let’s Encrypt; en ese caso necesitas un certificado de una autoridad interna que el cliente confíe. La consulta de DNS por sí sola no configura HTTPS. La ruta base de HTTP es práctica local; al procesar inicio de sesión u otros datos sensibles se requiere HTTPS.

El proxy debe poder alcanzar el puerto del servidor. Si el contenedor se ejecuta en otra máquina virtual (VM), la red y el cortafuegos deben permitir el tráfico entre las VMs. No es necesario exponer directamente el puerto de Flask a toda Internet cuando Nginx Proxy Manager sea el punto de entrada; limita el acceso mediante el cortafuegos según la configuración de la escuela.

Reelección: Proxy propio

Instale un proxy propio solo cuando realmente lo necesite y tenga su propio entorno de pruebas. Utilice la guía de instalación de Nginx Proxy Manager. A continuación, regrese a la creación del host de proxy anterior. Esta es una configuración independiente, no un requisito previo para utilizar un proxy existente.

Solución de problemas

docker ps
docker logs -f min-app
ss -tulpn

Si usa Compose, los dos primeros son docker compose ps y docker compose logs -f. Ejecute los comandos uno a la vez en el VM de la aplicación. Finalice logs -f con Ctrl+C. ps muestra el estado del contenedor, el registro muestra los mensajes de la aplicación y ss puede ayudar a investigar los puertos de escucha. Use el resultado de la prueba HTTP específica para verificar el acceso.

Pruebe en este orden:

1. En el VM de la aplicación después de cambiar la unión: curl --fail --show-error http://IP-VM-APP:5000/status.
2. Desde el entorno de red del proxy: misma dirección, puerto y ruta. Un cliente arbitrario podría tener reglas de acceso diferentes.
3. Desde el cliente mediante el nombre: nslookup NOMBRE-APP, luego http://NOMBRE-APP/status. Pruebe HTTPS por separado si está configurado.

Si el punto 1 falla, investigue la aplicación, el estado del contenedor, la dirección y la unión del puerto. Si el punto 1 funciona y el punto 2 falla, investigue la conexión y las reglas de acceso desde el proxy. Si el punto 2 funciona y el punto 3 falla, investigue DNS, Proxy Host y el protocolo seleccionado. El código 404 significa que un servidor HTTP respondió, pero la ruta podría estar incorrecta; un 502 desde el proxy apunta hacia la conexión o la respuesta de la aplicación. Anote qué limita la prueba antes de realizar cualquier cambio.

Siguiente paso

Muestra la respuesta de estado a través del nombre y explica la diferencia entre la resolución de DNS y el reenvío en el proxy. Señala también al cliente, el proxy y la aplicación en la figura o en un boceto propio. Puedes explicarlo oralmente o por escrito. Indica la dirección de prueba, la respuesta esperada/real y si has probado con HTTP o HTTPS. En caso de desviación, usa el orden de pruebas anterior antes de continuar.

Cuando la ruta base funcione, puedes usar la configuración más adelante en el proyecto. [[Docker Nível 4 - Publicar contenedor con flujo de trabajo|Docker - Publicar contenedor con flujo de trabajo]] es una formación adicional para automatizar la compilación y publicación de la imagen.

Fuentes: Docker: enlace de puerto, Nginx Proxy Manager y Flask: rutas y respuestas.