Configuración del NGINX LoadBalancer con el clúster de dos nodos de WSO2 EI

Este tutorial se centra en la configuración de NGINX como LoadBalancer para trabajar con el clúster de dos nodos de WSO2 Enterprise Integrator. Consiste en una guía sobre cómo escribir un archivo de configuración NGINX personalizado tanto para HTTP como para HTTPS. Incluye todos los conceptos fundamentales y explicaciones de tipo sintáctico que ayudan hasta al más principiante a realizar las configuraciones.

Seguiremos el siguiente índice:

1. ¿Qué son NGINX y WSO2 Enterprise Integrator?

Hablemos sobre NGINX. NGINX es un servidor web que también se puede utilizar como proxy inverso, balanceador de carga, proxy de correo electrónico y caché HTTP. El balanceador de carga distribuye de manera automática el tráfico de entrada entre varias instancias del WSO2. El puerto 80, por defecto, de NGINX está abierto para el tráfico HTTP y el puerto 443 para el del HTTPS.

Por otro lado, WSO2 Enterprise Integrator es una plataforma de integración de código abierto. Permite a los desarrolladores de integración empresarial crear soluciones de integración centralizada.

WSO2 EI utiliza tres puertos predeterminados para la gestión del tráfico:

• 8280 – tráfico http
• 8243 – tráfico https
• 9443 – consola de administración

2. ¿Por qué se necesita NGINX con WSO2 Enterprise Integrator?

WSO2 Enterprise Integrator soporta una alta funcionalidad. Por tanto, muchas veces puede haber muchos servidores en un clúster. Es necesario tener un balanceador de carga para distribuir el tráfico entre los servidores sin problemas. NGINX gestiona el tráfico entre los nodos. En este ejemplo, tenemos dos nodos EI en un clúster activo-activo. Los nodos son EI_1 y EI_2.

A continuación, se muestra la imagen de alto nivel de la configuración de NGINX y EI:

3. ¿Cómo se configura el NGINX Loadbalancer con WSO2 EI?

La configuración del WSO2 EI con NGINX es muy sencilla y fácil. Solo requiere tres archivos de configuración para la gestión del tráfico. En versiones anteriores de WSO2, estas configuraciones utilizaban un solo archivo de configuración. Más tarde se dividió en tres archivos de configuración para mantener el código limpio y fácil de usar.

En este manual, utilizaremos la versión 6.6.0 de WSO2 EI. En realidad, los tres archivos de configuración son para el manejo de solicitudes HTTP y HTTPS, y el acceso a la consola de administración. Los nombres de los archivos son:

• http.conf → Manejo de solicitudes HTTP;
• https.conf → Manejo de solicitudes HTTPS;
• ei.https.conf → acceso a la consola de administración.

Profundicemos en estos archivos de configuración.

3.1 Archivo ei.http.conf

El siguiente fragmento de código es la configuración para el tráfico HTTP. Cada bloque de configuración se describe en la última parte del artículo.

upstream ei.wso2.com {
        server ei1_ip:8280;
        server ei2_ip:8280;
}
 
server {
        listen 80;
        server_name ei.wso2.com;
        
        location / {
          proxy_set_header X-Forwarded-Host $host;
          proxy_set_header X-Forwarded-Server $host;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header Host $http_host;
          proxy_read_timeout 5m;
          proxy_send_timeout 5m;
          proxy_pass http://ei.wso2.com;
 
          proxy_http_version 1.1;
          proxy_set_header Upgrade $http_upgrade;
          proxy_set_header Connection "upgrade";
        }
}

ei1_ip y ei1_ip son las direcciones IP de cada nodo EI. Por ejemplo, si ei1_ip es 172.42.42.40 y ei2_ip es 172.42.42.50, el archivo de configuración debe ser.

upstream ei.wso2.com {
        server 172.42.42.40:8280;
        server 172.42.42.50:8280;
}

4. ¿Qué es un upstream?

Upstream define los servidores en el clúster para el balance de carga. Los servidores definidos en upstream pueden ser un clúster de servidores web para el balance de carga o un clúster de servidores de aplicaciones para el enrutamiento/balance de carga. Pero aquí, en WSO2 EI el clúster upstream define los nodos de clúster EI y entonces podremos hacer un proxy de las solicitudes entrantes.

Los servidores definidos pueden comunicarse con diferentes puertos. Por defecto, las solicitudes se distribuyen entre los servidores definidos mediante el algoritmo round-robin. Si se produce un error durante la comunicación con un servidor, la solicitud se pasa al siguiente servidor y así sucesivamente hasta que se encuentre un servidor responda. Si no se ha podido obtener una respuesta adecuada de ninguno de los servidores, el cliente recibirá el resultado de la comunicación con el último servidor. Sin embargo, hay algunas configuraciones adicionales aplicables a estos servidores.

• ip_hash: esta configuración se aplica a los servidores definidos para hacer que el balanceador de carga sea adherente, lo que significa que las solicitudes son distribuidas entre los servidores en función de las direcciones IP de los clientes. Por ejemplo:

upstream ei.wso2.com {
        server 172.42.42.40:8280;
        server 172.42.42.50:8280;
        ip_hash;
}

• weight: esta etiqueta se puede añadir a cada servidor. A modo de ejemplo, si se quiere enviar más cantidad de tráfico al nodo 01, digamos 2, todo lo que se tiene que hacer es actualizar el servidor como servidor 172.42.42.40:8280 weight=2;. De esta manera, cuando se envían 3 solicitudes, 2 de ellas van al nodo 01 y la otra va al nodo 02. Por defecto, cada miembro tiene un weight de 01. Por ejemplo:

upstream ei.wso2.com {
        server 172.42.42.40:8280 weight=2;
        server 172.42.42.50:8280;
}

Hay más configuraciones adicionales para los retardos o intervalos y los fallos, como max_fails, fail_timeout, etc. Consulte http://nginx.org/en/docs/http/ngx_http_upstream_module.html para configuraciones adicionales.

5. ¿Qué es un servidor?

El bloque de servidores es un subconjunto de las configuraciones de NGINX. Define el servidor virtual que se usa para gestionar las solicitudes de tipo definido. Se pueden definir varios servidores en un único archivo de configuración y decidir qué bloque debe gestionar cada conexión en función del nombre de dominio, el puerto y la dirección IP solicitados. Cada servidor tiene un nombre único. La directriz server_name establece el nombre del servidor.

Consulte  http://nginx.org/en/docs/http/server_names.html para obtener más información sobre la denominación de los servidores.

La directriz de conexión indica a NGINX el nombre host/IP y el puerto TCP en el que debe establecer las conexiones HTTP. Dentro del bloque del servidor, hay otro bloque de ubicación.

6. ¿Qué es la ubicación?

Se puede definir con la ruta de solicitud. Si la ubicación se define como /, todo el tráfico de solicitudes se dirige a ella. Pero también se puede especificar la ubicación con el contenido de la URL. A modo de ejemplo, el siguiente fragmento de configuración de ubicación es para el contenido de la URL de /servicios.  Así, responde a todas las peticiones que coincidan con /services, such as /services, /services/api, /services/home/index.html; etc.

En WSO2 EI, se pueden utilizar múltiples ubicaciones para diferentes rutas de solicitudes. A modo de ejemplo, las solicitudes HTTPS al puerto 9443 con la ruta de solicitud /carbon son para la consola de administración del EI. Para ese caso, la configuración es la siguiente. Pero como no hay otras rutas de solicitudes, el bloque de ubicación también se puede definir como /.

server ei.wso2.com {
  server1 172.42.42.40:9443;
}

location /carbon {
  proxy_set_header X-Forwarded-Host $host;
  proxy_set_header X-Forwarded-Server $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header Host $http_host;
  proxy_read_timeout 5m;
  proxy_send_timeout 5m;
  proxy_pass http://ei.wso2.com;
 
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";
}
Un hecho importante es que, cuando la solicitud entra en el bloque de ubicación, pasa al upstream por la directriz proxy_pass.

¡Atención! Como resumen, cuando una solicitud HTTP llega al servidor NGINX, entra en el bloque del servidor y coincide con la ubicación. Luego remite al proxy_pass. Y, por último, se dirige al bloque upstream y pasa la solicitud a los servidores definidos en él.

Consulte  https://www.digitalocean.com/community/tutorials/understanding-nginx-server-and-location-block-selection-algorithms para obtener más información sobre el bloque de servidores y ubicaciones.

6.1 Archivo ei.https.conf

El siguiente fragmento de código es la configuración para el tráfico HTTPS.

upstream ssl.ei.wso2.com {
    server ei1_ip:8243;
    server ei2_ip:8243;

}

server {
    listen 443 ssl;
    server_name ssl.ei.wso2.com;
    ssl_certificate /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;

    location / {
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_read_timeout 5m;
        proxy_send_timeout 5m;
        proxy_pass https://ssl.ei.wso2.com;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Al igual que en el archivo ei.http.conf, este también consta de bloques upstream, de servidor y de ubicación. En el bloque upstream, los servidores se definen con el puerto 8243 que se utiliza para llamar a las solicitudes HTTPS de las API, proxies, etc. Aparte de este cambio en este archivo de configuración, las claves deberían estar definidas.

Por lo general, las claves se encuentran en el directorio /etc/nginx/ssl. Estas claves se pueden generar o pueden utilizar las claves que ya tiene. Por lo general, este ssl no está disponible en un servidor NGINX que se acaba de instalar. Todo lo que tiene que hacer es crear una carpeta como ssl en el directorio /etc/nginx y poner las claves.

Si utiliza un nombre diferente para la carpeta, asegúrese de mencionar la ruta correcta de la carpeta en el archivo de configuración del tráfico HTTPS.

¡Dato! No se puede poner un nombre upstream dos veces. A modo de ejemplo, utilizamos ei.wso2.com para el upstream en el archivo de configuración HTTP. Por lo tanto, para upstream HTTPS utilizamos ssl.ei.wso2.com. De igual forma, puedes cambiar el nombre del upstream en el archivo de configuración, pero especifique el upstream correcto en la directriz proxy_pass.

6.2 Archivo ui.ei.https.conf

El último archivo de configuración es el archivo ui.ei.https.conf. Este archivo se utiliza para dirigir todo el tráfico HTTPS a la consola de administración. A continuación, se muestran las configuraciones del archivo.

upstream ui.ssl.ei.wso2.com {
    server ei1_ip:9443;
    server ei2_ip:9443;
}

server {
    listen 443 ssl;
    server_name ui.ei.wso2.com;
    ssl_certificate /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;
 
    location / {
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_read_timeout 5m;
        proxy_send_timeout 5m;
        proxy_pass https://ui.ssl.ei.wso2.com/;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
    error_log  /var/log/nginx/ui-error.log ;
    access_log  /var/log/nginx/ui-access.log;
}

Este archivo también contiene la misma configuración que en el archivo de configuración del tráfico HTTPS. La diferencia es que los servidores definidos en el upstream se dirigen al puerto 9443 que accede a la consola de administración de WSO2 EI.

Ahora, tenemos todos los archivos de configuración para conectar NGINX loadbalancer con WSO2 EI.

7. Configuraciones predeterminadas de NGINX

El archivo de configuración predeterminado de NGINX es nginx.conf, ubicado en el directorio /etc/nginx. Aquí está el archivo de configuración predeterminado.

# For more information on configuration, see:
#   * Official English Documentation: http://nginx.org/en/docs/
#   * Official Russian Documentation: http://nginx.org/ru/docs/

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;

pid /run/nginx.pid;
# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.

include /usr/share/nginx/modules/*.conf;

events {
    worker_connections 1024;
}

http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;
    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;
    keepalive_timeout   65;
    types_hash_max_size 2048;
    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

    # Load modular configuration files from the /etc/nginx/conf.d directory.
    # See http://nginx.org/en/docs/ngx_core_module.html#include
    # for more information.
    include /etc/nginx/conf.d/*.conf;
    
    server {
        listen       80 default_server;
        listen       [::]:80 default_server;
        server_name  _;
        root         /usr/share/nginx/html;
        # Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

        location / {
        }
        error_page 404 /404.html;
            location = /40x.html {
        }
        error_page 500 502 503 504 /50x.html;
           location = /50x.html {
        }
    }
}

Este archivo de configuración contiene un bloque de servidor predeterminado para las solicitudes HTTP. Por lo tanto, si utiliza un archivo de configuración personalizado para HTTP, debe eliminar este bloque del servidor del archivo nginx.conf, o editarlo con las configuraciones. Para una mejor práctica, utilice un archivo separado para configurar el tráfico HTTP.

Al utilizar la directriz include, puede incluir sus archivos de configuración en el archivo de configuración predeterminado de NGINX. Aunque include /etc/nginx/conf.d/*.conf; (línea 35) está configurado para incluir todos los archivos con la extensión .conf a veces no toma todos los archivos. Para solucionar estos problemas, puede indicar los archivos exactos que deben incluirse como se muestra a continuación.

include /etc/nginx/conf.d/ui.ei.https.conf;
include /etc/nginx/conf.d/ei.https.conf;
include /etc/nginx/conf.d/ei.http.conf;

Consulte  https://nginx.org/en/docs/dirindex.html para obtener más información sobre las directrices de NGINX.

8. Configuración de NGINX con clúster WSO2 Activo-Pasivo

Si se configura un clúster activo-pasivo, se necesita configurar tanto el nodo pasivo como el nodo de respaldo. Por defecto, NGINX proporciona 10 segundos para que el nodo de respaldo responda a la solicitud del usuario y en un solo fallo. Si no hay respuesta, el nodo se marcará como no disponible. Después, NGINX comprueba de nuevo cada 10 segundos si el servidor está en fase de ejecución otra vez. Pero estas configuraciones predeterminadas se pueden cambiar al usar las directrices max_fails y fail_timeouts.

A continuación, se muestra un ejemplo de todas las configuraciones que se comentaron para un clúster activo-pasivo:

upstream ui.ssl.ei.wso2.com {
    server ei1_ip:9443 backup;
    server ei2_ip:9443 max_fails=3 fail_timeouts=20s;
}

9. Configuración de NGINX con clúster WSO2 EI

Empiece a configurar NGINX con el clúster WSO2 EI. En este caso, hay un nodo clusterizado de dos EI y un nodo NGINX. En total hay tres nodos que se ubican, por separado. Supongamos:

• LB vm IP → 172.42.42.60
• EI_1 vm IP → 172.42.42.50
• EI_1 vm IP → 172.42.42.40

Los nodos EI_1 y EI_2 están clusterizados.

9.1 Paso 1 – Configurar NGINX

1. Instale NGINX en la VM.
2. Abra el archivo etc/nginx/nginx.conf y elimine o comente la sección http.
3. Cree los siguientes archivos de configuración en el directorio /etc/nginx/conf.d/
   1. http.conf
   2. https.conf
   3. ei.https.conf
4. Agregue las configuraciones mencionadas antes en cada archivo.
5. Elimine el bloque del servidor en el archivo de configuración predeterminado de NGINX y añada la siguiente configuración /etc/nginx/conf.d/*.conf; en lugar de include

include /etc/nginx/conf.d/ui.ei.https.conf;
include /etc/nginx/conf.d/ei.https.conf;
include /etc/nginx/conf.d/ei.http.conf;

9.2 Paso 2 – Generación de claves

1. Cree una carpeta como ssl en el directorio de instalación de NGINX (etc/nginx).
2. Ahora, ejecute los siguientes comandos dentro de la carpeta creada. Introduzca wso2.com como nombre común y wso2carbon como contraseña.

• Cree la clave del servidor:

sudo openssl genrsa -des3 -out server.key 1024

• Indique el registro:

sudo openssl req -new -key server.key -out server.csr

• Elimine las contraseñas:

sudo cp server.key server.key.org 
sudo openssl rsa -in server.key.org -out server.key

• Indique su registro SSL:

sudo openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
keytool -import -trustcacerts -alias server -file server.crt -keystore client-truststore.jks

Reemplace el archivo <EI_HOME>/repositorio/recursos/seguridad/cliente-truststore.jks en ambos nodos EI con el archivo generado client-truststore.jks.

9.3 Paso 3 – acceder a NGINX

Ahora, reinicie NGINX. A continuación, abra el navegador y vaya a la página principal de NGINX utilizando la IP de la VM de NGINX.

Por último, acceda a la consola de administración de EI a través de NGINX. Abra otra pestaña y vaya a https://<LB_IPADDRESS>/carbon. En este caso, es https://172.42.42.60/carbon/admin/login.jsp

Ahora, puede acceder a WSO2 EI a través del LB sin exponer la dirección IP del EI. De manera sencilla, configuramos NGINX para trabajar con el clúster de dos nodos de WSO2 EI. A continuación, acceda a la consola de administración del EI a través del NGINX Loadbalancer.

10. Conclusiones del NGINX Loadbalancer

Podemos configurar los productos WSO2 con NGINX Loadbalancer en pocos minutos con solo utilizar tres archivos de configuración. Es muy simple y sencillo de hacer para cualquier persona incluso con un conocimiento medio sobre las configuraciones de NGINX.

WSO2 EI puede integrarse con muchas tecnologías de primer nivel como NGINX, Kubernetes, Docker; etc.

Como colaboradores, Chakray proporciona soluciones completas de transformación digital, que incluyen Identity & Access Management, API Management, Integrationes y Analítica.