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 ahí.
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.
