Presentamos NGINX Plus R20

Liam CrillyDirector sénior de Gestión de Producto

Nos complace anunciar que NGINX Plus Release 20 (R20) ya está disponible. NGINX Plus es el único equilibrador de carga, caché de contenido, servidor web y puerta de enlace de API todo en uno. Basado en NGINX Open Source, NGINX Plus incluye funciones avanzadas exclusivas y un servicio de asistencia galardonado.

NGINX Plus R20 se basa en las mejoras que introdujimos en la limitación de solicitudes y el almacén de clave-valor en R19. Entre las nuevas funciones se incluyen:

• Supervisión y registro en tiempo real del tráfico sujeto a limitación de velocidad – Cuando se configura la limitación de velocidad, la API de NGINX Plus indica cuántas solicitudes se procesan inmediatamente, se retrasan o se rechazan. También puede configurar el registro de acceso para que incluya información sobre el estado de limitación de velocidad de cada solicitud.
• Mejoras en la limitación de conexiones – Las mejoras en la limitación de solicitudes introducidas en R19 y en esta versión se han ampliado a la limitación de conexiones.
• Coincidencia de prefijos en el almacén de clave-valor – Las claves del almacén de clave-valor pueden buscar coincidencias con un prefijo especificado (caracteres situados al principio de una cadena). Un caso de uso importante es el enrutamiento dinámico de solicitudes.
• Resolución DNS por grupo de servidores upstream – Ahora puede designar un conjunto diferente de servidores DNS para cada grupo de servidores upstream que utilice un nombre de host resoluble para representar los servidores backend del grupo.
• Variables adicionales del protocolo PROXY – Las nuevas variables registran la dirección IP y el puerto del servidor proxy al que se conectó originalmente el cliente.
• Mejoras de seguridad para HTTP/2 – Varios cambios mejoran la seguridad general del tráfico HTTP/2, incluida una mejor detección de comportamientos incorrectos o no válidos de los clientes y una implementación más robusta de determinadas directivas.

Cambios importantes en el comportamiento

• API obsoletas – NGINX Plus R13 (publicado en agosto de 2017) introdujo la nueva API de NGINX Plus<.htmlspan> para recopilar métricas y reconfigurar dinámicamente los grupos de servidores ascendentes, en sustitución de las API Status y Upstream Conf, que anteriormente realizaban esas funciones. Como se anunció en su momento, las API obsoletas siguieron estando disponibles y recibiendo soporte durante un periodo considerable, que finalizó con NGINX Plus R16. Si su configuración incluye las directivas status o upstream_conf, debe sustituirlas por la directiva api como parte de la actualización a R20. Para obtener orientación y ayuda para migrar a la nueva API de NGINX Plus, consulte la guía de transición en nuestro blog o póngase en contacto con nuestro equipo de soporte.
• Nuevos sistemas operativos compatibles –
  • CentOS 8.0+
  • FreeBSD 12.1
  • Red Hat Enterprise Linux 8.1
  • Ubuntu 19.10 («Eoan Ermine»)

Para obtener más información sobre las plataformas compatibles, consulte las especificaciones técnicas de NGINX Plus y los módulos dinámicos.

Nuevas funcionalidades en detalle

Supervisión y registro en tiempo real del tráfico con limitación de tasa

NGINX Plus R20 incorpora funciones que facilitan a los equipos de Operaciones y DevOps la supervisión en tiempo real de la actividad de limitación de solicitudes y la identificación exacta de los clientes que han superado el límite.
NGINX Plus siempre ha ofrecido una gran flexibilidad a la hora de definir los tipos de solicitudes de clientes a los que se aplica la limitación y cómo se procesan las solicitudes excesivas. Cada solicitud se gestiona de una de las siguientes maneras:

• Procesada sin demora (porque la tasa de solicitudes está por debajo del límite o dentro del tamaño de ráfaga configurado)
• Retrasada hasta que permitirla no provoque que se supere el límite de velocidad (también conocido como «throttling»)
• Rechazada con un código de respuesta de error HTTP

En versiones anteriores, el registro de errores era el único lugar donde NGINX Plus dejaba constancia de que las solicitudes se habían retrasado o rechazado, mediante entradas estandarizadas como esta:

2019/12/02 11:42:12 [error] 57#57: *339 limiting requests, excess: 0.600 by zone "my_limit", client: 172.17.0.1, server: www.example.com, request: "GET / HTTP/1.0", host: "www.example.com:80"

Extraer información útil del registro de errores puede resultar complicado, ya que el formato de los mensajes no está estructurado y no se puede configurar. Además, si el límite de solicitudes se basa en una característica del mensaje distinta de las indicadas en la entrada del registro de errores —por ejemplo, las cabeceras HTTP o la información de identidad—, deberá buscar la entrada correspondiente en el registro de acceso para determinar exactamente qué cliente superó el límite de solicitudes. Las nuevas funciones resuelven estos problemas.

Métricas de limitación de solicitudes de la API de NGINX Plus

Un nuevo endpoint de la API de NGINX Plus, /api/version/http/limit_reqs, mantiene contadores para todos los resultados de las decisiones de limitación de solicitudes tomadas en cada zona definida mediante una directiva limit_req_zone. Estos contadores pueden utilizarse tanto para supervisar en tiempo real las decisiones de limitación de solicitudes como para integrarse con soluciones de APM que proporcionen paneles y alertas sobre la actividad de limitación de solicitudes.

En el siguiente ejemplo, hay una zona definida, my_limit:

$ curl http://localhost/api/6/http/limit_reqs
{
 "my_limit": {
   "delayed": 540,
   "delayed_dry_run": 12162,
   "passed": 804541,
   "rejected": 63,
   "rejected_dry_run": 1209
 }
}

Tenga en cuenta que estos contadores también incluyen entradas correspondientes a solicitudes excesivas procesadas en modo de prueba, que se introdujo en NGINX Plus R19.

Registro de la actividad de limitación de solicitudes en el registro de acceso

Las métricas en tiempo real son muy útiles para saber cuándo NGINX Plus está procesando un número excesivo de solicitudes, pero no indican quién las está generando. Para resolver este problema, NGINX Plus R20 incorpora una nueva variable $limit_req_status. Esta registra el estado de limitación de la tasa de solicitudes: DELAYED, DELAYED_DRY_RUN, PASSED, REJECTED, o REJECTED_DRY_RUN.

A continuación, puede incluir otras variables en el formato de registro que identifiquen de forma unívoca al cliente, el URI y cualquier otra información relevante. En la siguiente configuración, se aplica un límite estricto de 10 solicitudes por segundo a cada cliente, basado en la validación de tokens web JSON (JWT) (línea 1). Las solicitudes excesivas se rechazan (línea 16) y se registran en un archivo de registro independiente (línea 21), que también incluye la variable $jwt_claim_sub para capturar la reclamación sub (línea 4).

Cargando ejemplo de código…

Ejemplos de entradas en el archivo reject.log:

time=1575289305.350 client=10.0.0.1 sub=adam uri=/ status=429 limit_req=REJECTEDtime=1575289305.395 client=10.0.0.1 sub=adam uri=/ status=429 limit_req=REJECTED
time=1575289305.402 client=10.0.0.1 sub=adam uri=/ status=429 limit_req=REJECTED

Mejoras en la limitación de conexiones

Además de limitar la tasa de solicitudes, NGINX Plus permite limitar las conexiones de los clientes mediante el módulo Limit Connections. Puede definir cuántas conexiones independientes puede abrir un cliente con NGINX Plus (o el número de solicitudes simultáneas cuando se utiliza HTTP/2). Normalmente, los clientes se identifican por su dirección IP remota (la variable $remote_addr o $binary_remote_addr), pero puede utilizar otra variable (como $jwt_claim_sub para el nombre de usuario de un JWT) cuando la dirección IP remota sea ambigua o pueda estar compartida por varios clientes.

NGINX Plus R20 amplía la limitación de conexiones con las mismas mejoras aplicadas a la limitación de la tasa de solicitudes que se introdujeron en NGINX Plus R19 y en esta versión:

• Modo de prueba con la directiva limit_conn_dry_run directive
• Monitorización en tiempo real en el endpoint de la API de NGINX Plus /api/version/http/limit_conns
• Una nueva variable, $limit_conn_status, que registra la decisión de limitación de conexiones para cada solicitud (PASSED, REJECTED o REJECTED_DRY_RUN) y que puede utilizarse como se describe en Registro de la actividad de limitación de la tasa en el registro de acceso para la variable $limit_req_status variable

La siguiente configuración aplica un ancho de banda reducido a los clientes que abren más de diez conexiones simultáneas.

Cargando ejemplo de código…

Coincidencia de prefijos en el almacén de clave-valor

Con el almacén de clave-valor en memoria de NGINX Plus, puede utilizar la API de NGINX Plus para configurar dinámicamente la gestión del tráfico en función de los atributos de la solicitud. Algunos ejemplos de uso son la inclusión dinámica de direcciones IP en listas de bloqueo, la limitación dinámica del ancho de banda y el almacenamiento en caché de tokens de autenticación.

NGINX Plus R20 incorpora compatibilidad para comparar claves con un prefijo especificado (caracteres situados al principio de una cadena), lo que permite nuevos casos de uso para el almacén de clave-valor. Por ejemplo, la posibilidad de comparar claves con prefijos de URI (rutas base), en lugar de con URI exactos, permite crear una tabla de enrutamiento dinámica que asigne cada ruta base a un grupo de servidores ascendentes, sustituyendo o complementando las asignaciones estáticas definidas mediante las directivas location.

Para habilitar la coincidencia de prefijos, incluya el nuevo parámetro type=prefix en la directiva keyval_zone. En la siguiente configuración, la directiva keyval asocia una directiva Cache-Control (como max-age o no-cache) a cada prefijo de URI, y la directiva add_header establece la cabecera de respuesta Cache-Control en ese valor cuando NGINX Plus reenvía la solicitud al servidor ascendente.

Cargando ejemplo de código…

Usamos la API de NGINX Plus para definir el valor de la cabecera de respuesta Cache-Control para cada ruta base (en este caso, las rutas que comienzan por /images/ o /reports/) en el almacén de clave-valor:

$ curl -i -X POST --data '{"/images/":"max-age=3600", "/reports/":"no-cache"}' http://localhost:8080/api/6/http/keyvals/pathsHTTP/1.1 201 Created
Server: nginx/1.17.6
Date: Mon, 2 Dec 2019 12:36:31 GMT
Content-Length: 0
Location: http://localhost:8080/api/6/http/keyvals/paths/
Connection: keep-alive

Cuando hacemos una solicitud con una ruta base que existe en el almacén de clave-valor, la respuesta incluye la cabecera «Cache-Control» que hemos configurado:

$ curl -I http://localhost/images/sample.jpgHTTP/1.1 200 OK
Server: nginx/1.17.6
Date: Mon, 2 Dec 2019 12:27:39 GMT
Content-Type: image/jpeg
Content-Length: 120847
Connection: keep-alive
Cache-Control: max-age=3600

Dado que el almacén de pares clave-valor se puede sincronizar en un clúster de instancias de NGINX Plus, solo es necesario realizar cada llamada a la API en una instancia. Esto simplifica mucho más el proceso de automatización de los cambios en la configuración del clúster que coordinar los cambios en los archivos de configuración.

Resolución DNS por grupo de servidores upstream

Al utilizar NGINX Plus para equilibrar la carga entre varios servidores ascendentes, puede definir los miembros del grupo de servidores ascendentes especificando un nombre de host que se resuelva en varias direcciones IP. Esto resulta especialmente útil en entornos dinámicos o de escalado automático, donde los miembros del grupo de servidores ascendentes pueden cambiar con frecuencia.

Para completar la configuración de estos grupos de servidores ascendentes dinámicos, también debe incluir la directiva resolver para designar el servidor o los servidores DNS que NGINX Plus consulta a fin de obtener las direcciones IP asociadas al nombre de host. En versiones anteriores, una directiva resolver se aplicaba a todos los grupos de servidores ascendentes a los que hacían referencia las directivas proxy_pass en el contexto (http, server o location) que contenía la directiva. Con NGINX Plus R20, ahora puede especificar un solucionador DNS diferente para cada grupo de servidores ascendentes.

Esta nueva flexibilidad resulta especialmente útil en un entorno DevOps, ya que permite a los equipos de aplicaciones asumir un mayor control sobre su infraestructura de entrega de aplicaciones, incluidos los servidores DNS y los registros de servicios, en lugar de depender de servicios centralizados y compartidos.

Puede seguir definiendo un solucionador global en el contexto http de nivel superior, así como en los bloques server y location. Si un bloque upstream no incluye una directiva resolver, hereda la configuración de resolver del contexto o bloque que incluye una directiva proxy_pass que hace referencia al grupo de servidores upstream, como en versiones anteriores.

En el siguiente ejemplo, el grupo de servidores upstream website utiliza el resolver global, mientras que mobile_app utiliza su propio resolver:

Cargando ejemplo de código…

Observe que incluimos el parámetro status_zone (introducido en NGINX Plus R19) en ambas directivas resolver, para recopilar métricas de errores y de otro tipo sobre la actividad del solucionador.

Variables para los metadatos del servidor del protocolo PROXY

El protocolo PROXY es un mecanismo mediante el cual un proxy de capa 4 puede transmitir información sobre la conexión original del cliente al siguiente proxy o balanceador de carga que gestione la solicitud del cliente. Esto es especialmente importante en casos de uso en los que se necesita conocer la dirección IP del cliente; por ejemplo, para limitar el número de conexiones realizadas por cada cliente (con la directiva least_conn) o simplemente para registrar la dirección IP real del cliente. Al igual que en versiones anteriores, la variable $proxy_protocol_addr recopila esta información.

Cuando hay varios proxies de capa 4 implementados en un entorno de aplicaciones, a veces es importante que NGINX Plus también conozca la dirección IP y el puerto del servidor proxy al que se conectó originalmente el cliente. Los metadatos del protocolo PROXY incluyen esta información, y NGINX Plus R20 añade variables para capturarla:

• $proxy_protocol_server_addr
• $proxy_protocol_server_port

Las variables están disponibles tanto para el módulo HTTP como para el módulo Stream (TCP/UDP), y son compatibles con las versiones 1 y 2 del protocolo PROXY. Tenga en cuenta que, antes de utilizar las variables, debe habilitar explícitamente NGINX Plus para que gestione el protocolo PROXY añadiendo el parámetro «proxy_protocol» a la directiva «listen».

Mejoras de seguridad para HTTP/2

NGINX Plus R18 P1 solucionó tres vulnerabilidades de seguridad en HTTP/2 que se anunciaron en agosto. NGINX Plus R20 incluye cambios adicionales que mejoran la seguridad general de nuestra implementación de HTTP/2:

• Detección mejorada de comportamientos incorrectos o no válidos del cliente
• Mejora del envío de respuestas de error HTTP/2 antes de que se haya leído el cuerpo de la solicitud del cliente
• Se ha mejorado la robustez de la directiva worker_shutdown_timeout para conexiones HTTP/2 de larga duración
• Se ha mejorado la robustez de la directiva proxy_request_buffering para clientes HTTP/2

Si utiliza HTTP/2 en producción con NGINX Plus R18 (sin parches) o una versión anterior, le recomendamos actualizar a NGINX Plus R20 lo antes posible.

Actualizaciones del ecosistema de NGINX Plus

Módulo JavaScript de NGINX

El módulo JavaScript de NGINX (njs) se ha actualizado a la versión 0.3.7, que añade compatibilidad con más objetos JavaScript:

• Function() constructor
• Object.assign() método
• Number métodos: toFixed(), toPrecision(), y toExponential()
• Array.prototype.copyWithin() método
• Parámetro de etiqueta del método console.time() method

Para obtener más información sobre njs, consulta la página de inicio del proyecto y nuestro blog<.htmla>.

Actualice a NGINX Plus o pruébelo

Si utiliza NGINX Plus, le recomendamos encarecidamente que actualice a NGINX Plus R20 lo antes posible. También obtendrá varias correcciones y mejoras adicionales, y facilitará que NGINX pueda ayudarle cuando necesite abrir una incidencia de soporte.

Revise detenidamente las nuevas funcionalidades y los cambios de comportamiento descritos en esta entrada del blog antes de proceder con la actualización.

Si aún no ha probado NGINX Plus, le animamos a hacerlo, ya sea para la seguridad, el balanceo de carga y la puerta de enlace de API, o como servidor web con soporte completo y API mejoradas de supervisión y gestión. Puede empezar hoy mismo con una prueba gratuita de 30 días. Compruebe por sí mismo cómo NGINX Plus puede ayudarle a desplegar y escalar sus aplicaciones.

Sobre el autor

Liam CrillyDirector sénior de Gestión de Producto

Más artículos de Liam Crilly