Inicio > Empresas > Guía completa: Reverse Proxy con NGINX y Docker en pocos pasos

Guía completa: Reverse Proxy con NGINX y Docker en pocos pasos

Funcionamiento de NGINX como proxy inverso para gestionar el tráfico entre usuarios y servidores"

Nginx reverse-proxy y docker,¿Por qué perder tiempo y esfuerzo?

Responder a la pregunta previa es tan simple como escribir «Seguridad, Escalabilidad y Resiliencia»

En este artículo veremos que implementar la idea es igual de simple. Sólo pondremos unas mínimas configuraciones técnicas orientativas.

Cómo configurar NGINX como reverse proxy con Docker

Mejor empezamos afinando más una parte de la pregunta, ¿por qué un reverse-proxy?

Hablar de NGiNX hoy día es lo normal, su uso está muy extendido como servidor web. ¡Quién no lo conoce sirviendo blogs!.

Bien sean entornos corporativos o personales, compatible con todo tipo de herramientas como Wordpress, Magento, Prestashop, Moodle … Hablar de Docker tampoco es nada raro, los containers han llegado para ayudarnos a desplegar aplicaciones con el mínimo esfuerzo.

Hoy vamos a ver un uso diferente, tan extendido como el de web server, y todo ello se debe a su versatilidad y potencia. La idea es usar NGiNX como un reverse-proxy para containers Docker.

Primero, vamos a definir mejor un poco ¡qué es cada cosa!

NGiNX 

Servidor web que además puede actuar como balanceador, proxy mail y caché HTTP además de actuar como «reverse proxy». Como servidor web puede servir tanto contenido estático como contenido dinámico, soportando protocolos HTTP/1.1, HTTP/2 y HTTP/3

Docker 

Herramienta que permite el despliegue automático de aplicaciones en containers ligeros proporcionando entornos eficientes, ligeros y suficientemente aislados. Esos entornos puede cohabitar en el mismo espacio manteniendo su aislamiento/seguridad independientemente del resto de aplicaciones desplegadas.

Reverse Proxy

Con este nombre nos referimos a un servidor proxy que aunque parece un servidor web ordinario a los ojos de un usuario navegando, realmente es un intermediario entre el usuario y el servidor web. La idea detrás de su uso es aumentar seguridad, escalabilidad, rendimiento y resiliencia de una aplicación. Eso se consigue inspeccionando cabeceras HTTP, ocultando la naturaleza de los servidores web, filtrando las requests desde las IP’s de Internet, distribuyendo la carga, o cacheando contenido estático/dinámico.

Por tanto la idea subyacente es combinarlo todo. Como ejemplo podría poner un entorno CI/CD integrado por Jenkins/SonarQube/GitLab/Nexus. Cada una de las aplicaciones está en su container, con su configuración, su servidor web preparado para su configuración. La idea es usar el NGiNX de reverse proxy para dar acceso a esas aplicaciones haciendo pasar todas las peticiones por ahi.

 

La idea: montar un Reverse Proxy con NGINX y Docker paso a paso

Continuando con el ejemplo anterior, cada aplicación tiene su propia configuración en su contenedor docker, cada aplicación usa el servidor web especificado en los requirements del container. Eso nos ayuda a abstraernos de esa capa, no vamos a tener que configurar nada dentro del container. Sí tendremos que configurar por ejemplo los puertos en los que responderá el servicio, la URL bajo la que responderá, requisitos de memoria, acceso a otras aplicaciones o bases de datos.

> Una vez hecho esto ¿y ahora qué? ¿lo cuelgo directamente en internet? ¿es eso seguro? ¿si muevo los servicios a otra VM tengo que cambiar la configuración?

La idea en este caso es usar un reverse proxy, concretamente NGiNX reverse proxy. Con ello se responde a todas esas preguntas. Facilitando la gestión, resiliencia, seguridad y escalabilidad.

Es interesante cuando tengamos múltiples servicios, cada uno con su container docker, cada uno con su propia configuración y muy probablemente cada uno en su instancia o VM propia. Como ya comentamos, uno de los grandes beneficios de usar un NGiNX reverse proxy es incrementar la seguridad, ya que será el único punto de contacto exterior, desde ahí se controlará el tráfico entrante, todas las peticiones. Por tanto podremos filtrar todo ese tráfico, pudiendo minimizar ataques DDoS, podremos escalar mejor la infraestructura, balanceando la carga de manera dinámica y simple.

La versión estable es actualmente  la 1.26 y el módulo que permite el uso de reverse proxy es el **ngx_http_proxy_module**.

 

Preparar el entorno para NGINX Reverse Proxy con Docker

Ya tenemos nuestros containers docker listos para Jenkins, GitLab, SonarQube y Nexus, este artículo no está orientado a montar una instalación/configuración de este tipo, sino que asumimos que esos servicios ya están configurados y lo que queremos es hacerlos accesibles/visibles. Para este ejemplo usaremos la aplicación Jenkins, configurada según las indicaciones oficiales de Installing Jenkins -> Docker

Partiendo de una configuración básica como la siguiente, iremos comentando la configuración de un reverse proxy. En este caso la parte que nos interesa es la del server escuchando en el 443 primer bloque server a continuación, el dominio suponemos que es *jenkins.example.com* y el servidor de Jenkins está instalado en un instancia con la IP interna *10.0.0.11*

«`nginx
http {

server {
listen 443 ssl;
listen [::]:443 ssl;
http2 on;
ssl_certificate /path/to/signed_cert_plus_intermediates;
ssl_certificate_key /path/to/private_key;

add_header Strict-Transport-Security «max-age=63072000″ always;
}

ssl_protocols TLSv1.3;
ssl_ecdh_curve X25519:prime256v1:secp384r1;
ssl_prefer_server_ciphers off;

ssl_session_timeout 1d;
ssl_session_cache shared:MozSSL:10m;

ssl_stapling on;
ssl_stapling_verify on;

ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

resolver 127.0.0.1;

server {
listen 80 default_server;
listen [::]:80 default_server;

return 301 https://$host$request_uri;
}
}
«`

La configuración previa fuerza la redirección a HTTPS de todo el tráfico recibido, vemos que tiene el certificado HTTPS configurado, siendo la configuración bastante segura al permitir TLS1.3 y cifrados modernos.

A continuación vemos la configuración para un NGiNX reverse proxy. Las directivas importantes son: *proxy_pass*, *proxy_redirect*, *proxy_http_version*, *proxy_set_header*, *proxy_max_temp_file_size*, *proxy_connect_timeout*, *proxy_send_timeout*, *proxy_read_timeout* y *proxy_request_buffering*.

De ellas hablaremos a continuación.

«`nginx
upstream jenkins {
keepalive 32;
server 10.0.0.11:8080;
}

map $http_upgrade $connection_upgrade {
default upgrade;
» close;
}

server {
listen 443 ssl;
listen [::]:443 ssl;

http2 on;
ssl_certificate /path/to/signed_cert_plus_intermediates;
ssl_certificate_key /path/to/private_key;

add_header Strict-Transport-Security «max-age=63072000» always;

server_name jenkins.example.com;

root /var/run/jenkins/war/;

access_log /var/log/nginx/jenkins.access.log;
error_log /var/log/nginx/jenkins.error.log;

ignore_invalid_headers off;

location ~ «^/static/[0-9a-fA-F]{8}\/(.*)$» {
rewrite «^/static/[0-9a-fA-F]{8}\/(.*)» /$1 last;
}

location /userContent {
root /var/lib/jenkins/;
if (!-f $request_filename){
rewrite (.*) /$1 last;
break;
}
sendfile on;
}

location / {
sendfile off;
proxy_pass http://jenkins;
proxy_redirect default;
proxy_http_version 1.1;

proxy_set_header Connection $connection_upgrade;
proxy_set_header Upgrade $http_upgrade;

proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_max_temp_file_size 0;

client_max_body_size 10m;
client_body_buffer_size 128k;

proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_request_buffering off; # Required for HTTP CLI commands
}
}
«`

Esta configuración tiene un par de cosas que necesitamos comentar antes de meternos en la parte relativa al reverse proxy. Esta configuración de Jenkins utiliza websockets (map + Connection + Upgrade) que usan *proxy_set_header* para configurar las cabeceras correctas con websockets.

También vemos un *upstream* que indica dónde está el Jenkins dockerizado.

La parte de *ssl* es similar a la previa, simplemente se finaliza el certificado HTTPS y se redirigen todas las peticiones a la instancia Jenkins instalada en Docker por el puerto previamente acordado.

 

Directivas clave de configuración

A continuación exponemos las directivas más utilizadas configurando un reverse proxy:

* proxy_pass -> Sintaxis: *proxy_pass URL;* Indica la protocolo y dirección. Puede ser estilo IP/dominio con el puerto como opcional. Ejemplos serían «`https://10.0.0.11:8080«` o «`http://jenkins.com:8080«`, es importante tener en cuenta que *proxy_pass «`http://jenkins«`;* y *proxy_pass «`http://jenkins/«`;* son dos configuraciones diferentes el */* al final se debe tener en cuenta.
* proxy_redirect -> La dejamos a default, no queremos cambiar nada en la Location ni refrescar campos de cabeceras
* proxy_http_version -> Configurado a 1.1 para configuraciones de keepalive
* proxy_set_header -> Diferentes configuraciones, una para cada cada header que se desea conservar. Connection + Upgrade son para los websockets que usa Jenkins. X-Real-IP, X-Forwarded-For y X-Forwarded-Proto conservan las cabeceras originales para Jenkins. Estas cabeceras son importantes para mantener los logs correctos en el Jenkins.
* proxy_max_temp_file_size -> Deshabilita el almacenamiento en buffers temporales, enviando los datos al Jenkins directamente.
* Timeouts: Se debe revisar los logs para ver si se producen timeouts. Si los comandos CLI que se envían requieren de tiempo para su ejecución, se deben adaptar los timeouts para que puedan acabar sin problema, de lo contrario existe la posibilidad de que el NGiNX corte la conexión antes de su finalización.
* proxy_connect_timeout -> se puede aumentar en caso de necesidad
* proxy_send_timeout -> se puede aumentar en caso de necesidad
* proxy_read_timeout -> se puede aumentar en caso de necesidad
* proxy_request_buffering -> Envía el request body al servidor proxizado (Jenkins en este caso) inmediatamente.

Es importante tener en cuenta que la configuración de un reverse proxy suele obligar a configurar un par de cosas en la aplicación, en este caso el Jenkins. Normalmente hay que indicarle a la aplicación que estará detrás de un reverse proxy, en el caso del Jenkins se configura en la sección **Jenkins Location** ahí se especifica la URL tal y cómo la recibirá el reverse proxy en este caso: https://jenkins.example.com

Ventajas de usar NGINX

Si configuramos de una manera similar al Jenkins tanto GitLab como Nexus como SonarQube tendremos un punto de entrada controlado para múltiples servicios, por tanto la parte de «Seguridad» está cubierta estando bajo nuestro control las peticiones para ser filtradas/limitadas/procesadas. Además los servicios están aislados del acceso directo de internet.

Podremos utilizar todas las funcionalidades normales como filtrar IP’s, hacer offloading de certificados, cachés varias, registro de logs…

Estando las aplicaciones en containers implica que se puede desplegar en diferentes máquinas/instancias, cada una con los recursos que necesita, además de permitirnos mantenerlas asiladas entre sí, lo que nos proporciona «Escalabilidad», por ejemplo podemos desplegar una nueva máquina con más recursos y en el momento adecuado cambiar el valor del **proxy_pass** apuntando al nuevo container, incluso podemos configurarlo para que haga un balanceo automático entre las instancias de cada aplicación.

Otra opción posible pasa por transformar los containers en un Docker Swarm y configurarlo para que balancee entre las instancias de cada servicio de manera dinámica, ganando así **Resiliencia**

En definitiva su uso nos permite una flexibilidad muy interesantes a la hora de configurar aplicaciones.

En pocas palabras

Como bien has podido comprobar el uso de un reverse proxy es algo de lo más cómodo y simple que nos permite aumentar el rendimiento de nuestras aplicaciones a la par que se gana en seguirdad, escalabilidad y en resiliencia.

El ejemplo desarrollado aún siendo una versión simplificada, se puede extrapolar a todo tipo de necesidades.

Y si en algún momento te resulta demasiado complejo, no te preocupes: en Grupo Aire estamos para ayudarte a configurar tu proxy inverso y adaptar la solución a lo que realmente necesitas.

 

Si te ha gustado, compártelo en redes sociales

Artículos relacionados

Pablo García

En Teradisk son consultores expertos en servicios gestionados para entornos cloud. Proveedores de infraestructura cloud con migración, monitorización, seguridad e integraciones; especializados en servicios de ciberseguridad con SOC propio, sistemas de misión crítica, alta disponibilidad y entornos web distribuidos y escalables, ofreciendo el servicio y operativa en formato 24/7.

Compañía dedicada a la provisión de servicios de conectividad y data center en las Islas Canarias, con una potente red y que orienta su negocio a clientes empresas, AAPP y Wholesale.

Carlos Cortés

Carlos descubrió que su pasión era la tecnología en el año 1997, cuando comenzó a trabajar para Motorola, el fabricante americano de tecnología, líder del mercado mundial durante décadas.

A partir de ahí, se sumergió en el sector tecnológico hasta que en 2018 encontró un proyecto que le apasionó y que le ofrecía la oportunidad de volver a trabajar en su tierra, Alicante.

Un proyecto que le permite desarrollar su pasión por las cosas bien hechas, en busca del crecimiento y mejora constante, buscando dar lo mejor de sí mismo y de la compañía, ofreciendo lo mejor a nuestros clientes.

Félix Nebreda

Félix inició su carrera como consultor en tecnología hace casi 30 años, trabajando para diversas compañías. Fue en Unisys España donde descubrió que su verdadera pasión era la relación con el cliente. Desde entonces, ha asumido responsabilidades de negocio en cuentas clave, tanto a nivel nacional como internacional, en multinacionales como Colt y Brocade.

Posteriormente, se embarcó en la emocionante tarea de participar en el lanzamiento de LCRcom, un nuevo operador para empresas en el ámbito nacional, con gran éxito. Desde el principio, en LCRcom ha sido responsable de la generación de negocio en diferentes territorios y de la gestión de equipos comerciales.

Actualmente, en Grupo Aire, Félix dirige el Área SME, donde se dedica a desarrollar y ejecutar estrategias de negocio que mantienen al Grupo Aire como líder en el sector a nivel nacional.

Joan Aniorte

Joan ve la tecnología como una palanca con la que accionar el acceso al conocimiento y posibilitar la comunicación entre personas en tiempo real. Desde sus inicios en Grupo Aire, cuando estaba en el último curso de universidad, se ha esforzado por superar los retos técnicos a los que se ha ido enfrentando, con la motivación de aprender y llegar al fondo de cada proyecto. Como CTO Staff, aplica esta experiencia, su visión, empuje y mimo por los detalles a distintas áreas de trabajo. Del proyecto destaca su vocación tecnológica y su equipo, por su calidad humana y su enfoque de resolución del problema.

Manuel Rivera
María Pérez Carrascosa

Tras el salto de la banca a las telecomunicaciones, María aporta su experiencia en el sector y una nueva visión de la función financiera estratégica, además de mejores prácticas y soporte a los accionistas y equipo directivo para la toma de decisiones. Todo ello con el objetivo de llevar a Grupo Aire hacia las metas propuestas en el plan de negocio.

Del Grupo Aire destaca su capacidad de adaptarse al mercado de las telecomunicaciones innovando; una infraestructura única en la península Ibérica y un capital humano cualificado y comprometido que, junto con el apoyo de Ardian, son clave para el éxito del proyecto.

Zigor Gaubeca

A pesar de criarse en un pequeño pueblo con menor facilidades de acceso a la tecnología, para Zigor no fue una barrera el sumergirse en el sector tecnológico desde muy joven, comenzando después la carrera de Ingeniería Informática con la intención de seguir profundizando sobre todo lo que había ido aprendiendo de forma autodidacta a lo largo de los años.

Su sueño de dedicarse al mundo de la conectividad se hizo realidad al llegar a la compañía, donde sintió el proyecto como suyo desde el primer momento, compartiendo triunfos y aprendiendo de los fracasos.

Con un gran sentido de equipo, Zigor trabaja diariamente para ayudar en la toma de decisiones aportando su visión y experiencia, asumiendo todos los retos que pueda encontrar en el camino y manteniendo ese ADN de la compañía en el que la tecnología, el trabajo en equipo y la innovación son esenciales.

Santi Magazù

Santi Magazù tiene más de 20 años de experiencia en el sector de telecomunicaciones y de servicios TI, habiendo ocupado puestos directivos en multinacionales como Telefónica, donde desempeñó varios cargos, como director de ingeniería de servicios TI para España y director comercial de Cloud Computing para todo el Grupo. También ha trabajado como director de Marketing en el operador regional Grapes, y como CEO y COO en startups de tecnología, entre ellas en PlayGiga, la primera compañía adquirida por Facebook en España. Inició su carrera como consultor de estrategia en Monitor Co., actualmente parte de Deloitte.

En cuanto a su formación, es ingeniero industrial por el Politécnico de Milán y MBA por INSEAD (Francia).

Ángel Blancas

Ángel Blancas tiene una carrera a nivel directivo de más de 30 años en compañías como Grupo SIA (Indra), donde estuvo liderando el área de Cloud Computing y Managed Services como Senior Director; Colt Technology dónde ocupo la posición de Regional General Manager en España y Portugal. Otras empresas en las que ha trabajado dentro del sector tecnológico son T-Systems Iberia, Dell Computer, Getronics y Sun Microsystems (Oracle). Recientemente, ocupó la posición de Regional Director en Claranet.

Estudió Ingeniería de Telecomunicaciones en la Universidad Politécnica de Madrid y tiene un máster en Inteligencia Artificial por la Universidad Internacional de Valencia. Llega a Grupo Aire para dar apoyo en la definición y estrategia de Producto.

Miguel Tecles

Consejero

Curiosidad y pasión por la tecnología son el motor imparable de una carrera profesional que empezó, nada menos que a los 4 años, arreglando el cable roto de una plancha que había dejado de funcionar. Desde ese precoz impulso, la biografía de Miguel Tecles está escrita con cables de colores, líneas de programación, ondas de radio, señales de internet cuando casi no existía, muchos voltios y algún calambre inesperado.

Hoy, con el cargo de Chief Technology Officer en Aire Networks, Miguel Tecles es uno de sus principales pilares.

Nadie mejor que él personifica el compromiso de la compañía con sus clientes: llevar la tecnología siempre al siguiente nivel, haciendo lo que nadie hace, como nadie lo hace y llegando hasta donde nadie llega, para ofrecer servicios que generen valor para todos.

Raúl Aledo

CEO

Apasionado de la tecnología y el funcionamiento interno de todo lo que le rodeaba desde muy temprana edad, Raúl empezó sus primeros pinitos en el mundo de la electrónica y la programación a los 14 años, cuando hizo su primer programa de facturación, contabilidad y gestión de almacén para la empresa familiar.

Con ello y la llegada de internet, comenzó su dedicación al mundo de las telecomunicaciones, estudiando Ingeniería Informática, donde conoció a su primer socio, Miguel Tecles, a través de lo que fue una de las primeras redes sociales, IRC. Tras más de dos años trabajando juntos y mejorando su know-how, conocieron a Emilio Gras, el tercer socio de la actual compañía, comenzando juntos en 1996 su primer proyecto de ServiHosting, e iniciando un camino que los llevaría hasta donde están hoy.

Raúl es pilar fundamental en el Grupo Aire, no solo a través de su experiencia, sino a través de los valores que aporta e implementa en la compañía, como la visión de futuro, aceptando retos y alcanzando metas; su compromiso con cada detalle y el sentimiento de equipo, fomentándolo día a día.

Configuración de las cookies

Las cookies y otras tecnologías similares son una parte esencial de cómo funciona nuestra web. El objetivo principal de las cookies es que tu experiencia de navegación sea más cómoda y eficiente y poder mejorar nuestros servicios y la propia web. Aquí podrás obtener toda la información sobre las cookies que utilizamos y podrás activar y/o desactivar las mismas de acuerdo con tus preferencias, salvo aquellas Cookies que son estrictamente necesarias para el funcionamiento de la web de Aire Networks. Ten en cuenta que el bloqueo de algunas cookies puede afectar tu experiencia en la web y el funcionamiento de la misma. Al pulsar “Guardar cambios”, se guardará la selección de cookies que has realizado. Si no has seleccionado ninguna opción, pulsar este botón equivaldrá a rechazar todas las cookies. Para más información puedes visitar nuestra Políticas de Cookies. Podrás cambiar en cualquier momento tus preferencias de cookies pinchando en el enlace “Preferencias de cookies” situado en la parte inferior de nuestra web.