¿Cómo configurar el balanceo de carga para los servicios de proxy en NginxProxyManager?
NginxProxyManager (NPM) es una potente herramienta de gestión de proxy inverso basada en Nginx, pero configurar el equilibrio de carga del lado del servidor puede ser un poco complicado.
Renderizando...
NginxProxyManager (NPM), como una potente herramienta de gestión de proxy inverso basada en Nginx, es muy apreciada por los usuarios por su intuitiva interfaz web. Aunque NPM se utiliza principalmente para gestionar el proxy de servicios de backend individuales, al combinar hábilmente las capacidades de configuración personalizada de Nginx, también podemos lograr una potente funcionalidad de balanceo de carga.
Este artículo detallará cómo configurar el balanceo de carga para sus servicios proxy modificando/añadiendo archivos de configuración personalizados y combinándolos con la configuración de "Custom Nginx Configuration" en el panel de NginxProxyManager. Nos centraremos en esta solución y no abordaremos otras formas de implementación.
## 1. Preparación
Antes de comenzar la configuración, asegúrese de haber completado la siguiente preparación:
* **NginxProxyManager instalado y funcionando correctamente**: Puede instalarlo a través de Docker o directamente.
* **Múltiples instancias de servicios de backend**: Necesitará al menos dos o más servidores backend que proporcionen el mismo servicio (por ejemplo, instancias de aplicaciones web ejecutándose en diferentes IP o puertos).
* **Permisos de acceso al directorio de datos de NPM**: Necesitará poder acceder al directorio `/data/nginx/` dentro del contenedor de NPM, lo que generalmente se logra mediante el montaje de volúmenes de Docker.
## 2. Operación central de la solución
La idea central de esta solución es:
1. Crear un archivo de configuración de Nginx personalizado en el directorio de datos de NPM para definir uno o más "grupos de servidores upstream" (`upstream`).
2. En la configuración del host proxy de NPM, utilizar la opción "Custom Nginx Configuration" para proxyar las solicitudes a nuestro grupo de servidores upstream personalizado.
### 2.1. Creación de un archivo de configuración de servidores upstream personalizado
Primero, necesitamos crear un archivo personalizado en el directorio de configuración de Nginx de NPM para definir el grupo de servidores upstream para el balanceo de carga.
1. **Acceder al directorio de datos de NPM**:
Normalmente, la configuración de Nginx de NPM se encuentra en `/etc/nginx/conf.d/` o `/data/nginx/` dentro de su contenedor Docker. Para la persistencia y la facilidad de gestión, NPM cargará las configuraciones personalizadas desde el directorio `/data/nginx/custom/`.
Si utiliza Docker para ejecutar NPM, puede acceder a este directorio montando un volumen. Por ejemplo, si su contenedor NPM monta el directorio local `./npm_data` en `/data` dentro del contenedor, entonces debería crear el archivo en la ruta `./npm_data/nginx/custom/`.
2. **Crear o modificar el archivo de configuración**:
Cree un nuevo archivo `.conf` en el directorio `/data/nginx/custom/`, por ejemplo, llamado `http_upstream.conf`.
```bash
# Ejemplo: Si está en el host y npm_data es el directorio montado
cd /path/to/your/npm_data/nginx/custom/
touch http_upstream.conf
```
3. **Editar el archivo `http_upstream.conf`**:
Abra `http_upstream.conf` con su editor de texto preferido y añada el siguiente contenido:
```nginx
# Define un grupo de servidores upstream llamado 'my_backend_servers'
upstream server_cluster {
# Servidor backend 1: dirección IP y puerto, peso 5
server 192.168.1.100:8080 weight=5 max_fails=3 fail_timeout=30s;
# Servidor backend 2: dirección IP y puerto, peso 3
server 192.168.1.101:8080 weight=3 max_fails=3 fail_timeout=30s;
# Servidor backend 3: dirección IP y puerto, peso predeterminado 1
server 192.168.1.102:8080;
# Servidor de respaldo: Cuando todos los servidores principales no están disponibles, el tráfico se reenvía a este servidor
# server 192.168.1.103:8080 backup;
# Marcado como no disponible: generalmente utilizado para mantenimiento temporal
# server 192.168.1.104:8080 down;
# Algoritmo de balanceo de carga (opcional, por defecto es round-robin):
# round-robin (por defecto)
# least_conn; # Menor número de conexiones
# ip_hash; # Hash basado en la IP del cliente, para persistencia de sesión
# hash $request_uri consistent; # Hash basado en URI
}
# Si tiene otros servicios que necesitan balanceo de carga, puede definir más bloques upstream
# upstream server_cluster {
# server 192.168.1.200:9000;
# server 192.168.1.201:9000;
# }
```
**Explicación de los parámetros**:
* `upstream my_backend_servers { ... }`: Define un grupo de servidores upstream llamado `my_backend_servers`. Este nombre se utilizará en la configuración personalizada de NPM.
* `server IP:PORT`: Especifica la dirección IP y el puerto del servidor backend.
* `weight=N`: Establece el peso del servidor. Cuanto mayor sea el peso, más solicitudes le reenviará Nginx. El peso predeterminado es 1.
* `max_fails=N`: Dentro del tiempo `fail_timeout`, si Nginx falla al comunicarse con el servidor backend N veces, se considera que el servidor no está disponible. El valor predeterminado es 1.
* `fail_timeout=Ns`: En N segundos, si el número de fallos del servidor alcanza `max_fails`, el servidor se marcará como no disponible y se intentará de nuevo después del tiempo `fail_timeout`. El valor predeterminado es 10 segundos.
* `backup`: Marca el servidor como un servidor de respaldo. Las solicitudes solo se reenviarán al servidor `backup` cuando todos los servidores que no son `backup` no estén disponibles.
* `down`: Marca el servidor como permanentemente no disponible. Generalmente se utiliza para deshabilitar temporalmente un servidor.
* **Algoritmos de balanceo de carga**:
* `round-robin` (por defecto): Distribuye las solicitudes a cada servidor en secuencia.
* `least_conn`: Envía la solicitud al servidor con el menor número de conexiones activas.
* `ip_hash`: Distribuye las solicitudes a los servidores basándose en el valor hash de la dirección IP del cliente, asegurando que las solicitudes del mismo cliente siempre se envíen al mismo servidor, logrando la persistencia de sesión.
### 2.2. Configuración del host proxy en NginxProxyManager
A continuación, crearemos un nuevo host proxy en la interfaz web de NPM y utilizaremos su función "Custom Nginx Configuration" para referenciar el grupo de servidores upstream que hemos definido.
1. **Iniciar sesión en NginxProxyManager**:
Abra su interfaz web de NPM e inicie sesión.
2. **Añadir nuevo host proxy**:
Navegue a la página "Proxy Hosts" y haga clic en "Add Proxy Host".
3. **Rellenar la pestaña "Details"**:
* **Domain Names**: Ingrese el nombre de dominio a través del cual desea acceder al servicio con este proxy (por ejemplo: `myapp.example.com`).
* **Scheme**: Seleccione `http` o `https`, dependiendo del protocolo que escuche su servicio backend.
* **Forward Hostname / IP**: **Aquí, simplemente ingrese un marcador de posición, como `127.0.0.1`.** Debido a que sobrescribiremos el destino de reenvío real en "Custom Nginx Configuration", esta configuración no tendrá efecto, pero NPM requiere que este campo se complete.
* **Forward Port**: **De manera similar, ingrese un marcador de posición, como `80`.**
* Según sus necesidades, marque las opciones `Cache Assets`, `Block Common Exploits`, `Websockets Support`, etc.
4. **Configurar la pestaña "SSL"**:
Configure el certificado SSL según su dominio y situación del certificado. Se recomienda utilizar Let's Encrypt para la solicitud automática.
5. **Configurar "Advanced"**:
Este es el paso más crítico. En la pestaña Advanced, busque `Custom Nginx Configuration`. En este cuadro de texto, ingrese el siguiente código de configuración de Nginx:
```nginx
location / {
proxy_pass http://server_cluster;
proxy_set_header Host $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;
}
```
**Explicación**:
* `proxy_pass http://my_backend_servers;`: Esta directiva le dice a Nginx que reenvíe todas las solicitudes que lleguen a este host proxy al grupo de servidores upstream llamado `my_backend_servers`. Nginx distribuirá las solicitudes según el algoritmo de balanceo de carga y la lista de servidores que haya definido en `http_upstream.conf`.
* `proxy_set_header ...`: Estas directivas se utilizan para establecer las cabeceras de la solicitud HTTP, asegurando que el servidor backend pueda identificar correctamente la dirección IP real del cliente, el nombre de dominio de la solicitud original y la información del protocolo. Esto es crucial para el registro, las políticas de seguridad y el funcionamiento normal de ciertas aplicaciones.
6. **Guardar el host proxy**:
Haga clic en el botón "Save" para guardar la configuración de su host proxy. NPM recargará automáticamente la configuración de Nginx para que los cambios surtan efecto.
### 2.3. Verificación de la configuración del balanceo de carga
Una vez completada la configuración, debe verificar que el balanceo de carga funciona correctamente.
1. **Acceder a su dominio**:
Acceda a su dominio configurado en el navegador (por ejemplo, `http://myapp.example.com` o `https://myapp.example.com`).
2. **Comprobar la respuesta del servidor backend**:
Si su servicio backend puede mostrar la identificación de su servidor (por ejemplo, IP del servidor, nombre de host o contenido de una página única), puede actualizar la página varias veces para observar si las solicitudes se distribuyen a diferentes servidores backend.
3. **Verificar los registros de NginxProxyManager**:
Revise los registros de NPM para confirmar que no hay errores de configuración.
4. **Registros del servidor backend**:
Revise los registros de acceso de los servidores backend para confirmar que las solicitudes provienen de NPM y que se distribuyen a diferentes servidores.
## 4. Resumen y consideraciones
A través de los pasos anteriores, ha configurado con éxito el balanceo de carga para los servicios proxy en NginxProxyManager. Este método aprovecha al máximo la conveniencia de la interfaz de gestión de NPM y la flexibilidad de la configuración subyacente de Nginx.
**Consideraciones**:
* **Persistencia de sesión (Session Stickiness)**: Si su aplicación necesita mantener la sesión del usuario conectada a un servidor backend específico (por ejemplo, después de que un usuario inicia sesión, debe acceder al mismo servidor), es posible que deba usar el algoritmo de balanceo de carga `ip_hash` o implementar el uso compartido de sesiones a nivel de aplicación (como usar Redis).
* **Verificación de estado (Health Checks)**: `max_fails` y `fail_timeout` de Nginx proporcionan funciones básicas de verificación de estado. Para verificaciones de estado más avanzadas (por ejemplo, verificar el contenido de la respuesta de una URL específica), es posible que deba combinar otras herramientas o configuraciones de Nginx más complejas.
* **Actualización de la configuración**: Cuando modifique el archivo `http_upstream.conf`, NPM no recargará automáticamente la configuración de Nginx. Deberá ingresar a la interfaz web de NPM, buscar cualquier host proxy, editarlo y guardarlo (sin necesidad de realizar ninguna modificación real), y NPM recargará todas las configuraciones de Nginx. O, si opera directamente con Docker, puede reiniciar el contenedor de NPM.
> ¿Tiene alguna otra solución?Comentario
Inicia sesión para ver y publicar comentarios
Ir a iniciar sesión