Docker Nginx Proxy: Redirecciona el puerto a 80 según el dominio a un docker u otro sin morir

docker

#1

En el curro me he puesto a «dockerizar» todos los servicios webs de gestión que teníamos (y de paso a integrarlos con LDAP) y una de las cosas que he me encontrado es como tener el puerto 80 para todos y reenviar el usuario a un docker u otro simplemente por la URL a la que acceda.

He pensado que a más de uno le pondría interesar, así que os lo comento porque es una herramienta sencilla, bonita, fácil con multitud de opciones.

Pues bien, esto se hace en cuestión de segundos usando Nginx Proxy. Simplemente instalamos este docker ocupando el puerto 80/443 para que todas las peticiones vayan a él.

Ahora, a cada docker le añadimos una variable de entorno con el dominio (o dominios) con los que queramos acceder, lo recreamos y listo.

Los servicios no tienen que tener el puerto 80/443 abierto. Solo lo debe tener el proxy, y como accederemos a través de él no habrá problema.

Además, permite configurar que dockers estarán accesibles desde cualquier sitio y cuales solo desde una IP interna, por ejemplo.

¿Queréis rizar más el rizo? Con LetsEncrypt Nginx Proxy Companion activaremos el HTTPS firmado con Lets Scripts de forma automática. Sin hacer nada.

Os pongo un docker compose de ejemplo:

    version: "2"

    services:
      gitlab:
        container_name: gitlab
        image: gitlab/gitlab-ce:latest
        environment:
          VIRTUAL_HOST: gitlab.ejemplo.com
          LETSENCRYPT_HOST: gitlab.ejemplo.com

    phpldap:
        image: osixia/phpldapadmin
        container_name: phpldap
        environment:
         - VIRTUAL_HOST=ldap.ejemplo.com
         - NETWORK_ACCESS=internal 

      letsencrypt:
        container_name: letsencrypt
        image:  jrcs/letsencrypt-nginx-proxy-companion
        volumes_from: 
          - nginx-proxy
        volumes:
          - /var/run/docker.sock:/var/run/docker.sock:ro

En este ejemplo tendríamos que según si entramos a ldap.ejemplo.com o gitlab.ejemplo.com iríamos a un servicio u otro. En el caso de Gitlab, nos crearía un certificado HTTPS con LetScript y el de LDAP solo estaría accesible desde una red local al servidor.

Por limitaciones propias de LetScript no podríamos tener un certificado para un sistema que solo está en red local. Sé que hay formas manuales de obtenerlo, pero no es precisamente sencillo…


#2

Sabía que se podía hacer, pero nunca me había puesto a intentarlo.

Ahora, que la idea de hacerlo con Nginx Proxy, me ha gustado.


#3

gracias por compartir :kissing_heart:


#4

Poder claro que se podía, lo que yo no sabía es que podía ser tan fácil «y limpio».

Quizás lo más interesante es que puedes añadir dockers nuevos sin tener que reiniciar ningún servicio de los ya configurados, ni siquiera el propio proxy.


#5

Aunque sea sencillo, creo que el mundo empresarial tiende a PaaS tipo Openshift porque recubren docker y facilitan este tipo de cosas.

Y para los que presumen de trabajar a pelo con Kubernetes (que ya es un gran paso por encima de Docker) https://twitter.com/kelseyhightower/status/1099726594808168453?s=20

"Perception: I’m using pure Kubernetes; I don’t need a platform.

Reality: Everything you do above kubectl is proof you need a platform and you’re actually building one"

Esa configuración de nginx es sencilla hoy, pero mañana los proyectos querrán ser independientes y publicar su ruta ellos mismos, querrás tener SNI para servir un certificado u otro o incluso querrás a veces que el proxy sea el punto de terminación TLS y en otros sea el contenedor de la aplicación sirviendo un certificado gestionado directamente por el equipo responsable de la aplicación. O querrás que las rutas pasen por tu F5 o balanceador/waf externo

No todo el mundo tiene una organización tan compleja como para necesitar un PaaS, pero tengo la sensación de que trabajar a pelo con Docker o incluso Kubernetes es muy duro.


#6

Ups, me releo y creo que el mensaje parece querer vender Openshift y nada más lejos de la realidad.

Sólo que leyendo el hilo me ha venido a la cabeza clientes que nos dicen que quieren usar docker a pelo y no entienden porque necesitan algo más. El caso que se expone en el hilo me va a servir cómo ejemplo. No todas las empresas tienen administradores tan buenos, proactivos ni con tiempo para mantener este tipo de configuraciones a escala


#7

Ten en cuenta que esto es un servidor interno nuestro. No es un servicio que tenemos en el Cloud ni nada. Es nuestro pequeño server propio.


#8

Si, si, lo entiendo. Me parece fantástico como lo has solucionado y es suficiente para vuestro caso.


#9

También hay operativas imágenes docker para HAProxy.


#10

Este tema se cerró automáticamente 10 días después del último post. No se permiten nuevas respuestas.