Anunciamos NGINX Plus R20

Nos complace anunciar que NGINX Plus Release 20 (R20) ya está disponible. NGINX Plus es el único balanceador de carga, caché de contenido, servidor web y puerta de enlace API todo en uno . Basado en NGINX de código abierto, NGINX Plus incluye funciones mejoradas exclusivas y soporte galardonado.

NGINX Plus R20 se basa en las mejoras que realizamos en la limitación de velocidad y el almacén de valores clave en R19. Las nuevas características incluyen:

• Monitoreo y registro en tiempo real del tráfico con limitación de velocidad : cuando se configura la limitación de velocidad, la API NGINX Plus ahora informa cuántas solicitudes se pasan de inmediato, se retrasan o se rechazan. También puede configurar el registro de acceso para incluir información sobre el estado de velocidad limitada de las solicitudes individuales.
• Mejoras en la limitación de conexión : las mejoras en la limitación de velocidad introducidas en la versión R19 y esta versión se han extendido a la limitación de conexión.
• Coincidencia de prefijo en el almacén de clave-valor : las claves en el almacén de clave-valor pueden coincidir con un prefijo especificado (caracteres al comienzo de una cadena). Un caso de uso importante es el enrutamiento de solicitudes.
• Resolución de DNS por grupo ascendente : ahora puede designar un conjunto diferente de servidores DNS para cada grupo ascendente que use un nombre de host resoluble para representar los servidores back-end del grupo.
• Variables adicionales del protocolo PROXY : las nuevas variables capturan la dirección IP y el puerto del servidor proxy al que el cliente se conectó originalmente.
• Mejoras de seguridad para HTTP/2 : varios cambios mejoran la seguridad general del tráfico HTTP/2, incluida una mejor detección de comportamiento incorrecto o no válido del cliente y una implementación más sólida de ciertas directivas.

Cambios importantes en el comportamiento

• API obsoletas : NGINX Plus R13 (lanzado en agosto de 2017) introdujo la nueva API NGINX Plus<.htmlspan> para la recopilación de métricas y la reconfiguración dinámica de grupos ascendentes, reemplazando las API de estado y configuración ascendente que anteriormente implementaban esas funciones. Como se anunció en ese momento, las API obsoletas continuaron estando disponibles y recibiendo soporte durante un período de tiempo significativo, que finalizó con NGINX Plus R16 . Si su configuración incluye las directivas status o upstream_conf , debe reemplazarlas con la directiva api como parte de la actualización a R20.

  Para obtener asesoramiento y asistencia para migrar a la nueva API NGINX Plus , consulte la guía de transición en nuestro blog o comuníquese 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 Armiño”)

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 funciones en detalle

Monitoreo y registro en tiempo real del tráfico con velocidad limitada

NGINX Plus R20 presenta características que facilitan a los equipos de Operaciones y DevOps monitorear la actividad de limitación de velocidad en tiempo real y determinar exactamente qué clientes han excedido el límite de velocidad.
NGINX Plus siempre ha proporcionado un alto grado de flexibilidad a la hora de definir los tipos de solicitudes de clientes para limitar la velocidad y cómo se procesan las solicitudes excesivas. Cada solicitud se gestiona de una de las siguientes maneras:

• Pasó sin demora (porque la tasa de solicitud está por debajo del límite o dentro del tamaño de ráfaga configurado)
• Retrasado hasta pasarlo no provoca que se exceda el límite de velocidad (también conocido como estrangulamiento )
• Rechazado con un código de respuesta de error HTTP

En versiones anteriores, el registro de errores era el único lugar donde NGINX Plus registraba el hecho de que las solicitudes se retrasaban o rechazaban, en entradas estandarizadas como esta:

02/12/2019 11:42:12 [error] 57#57: *339 limitando solicitudes, exceso: 0.600 por zona "my_limit", cliente: 172.17.0.1, servidor: www.example.com, solicitud: "GET / HTTP/1.0", host: "www.ejemplo.com:80"

Extraer información útil del registro de errores puede ser un desafío, porque el formato del mensaje no está estructurado y no es configurable. Además, si el límite de velocidad está definido por una característica del mensaje distinta a las señaladas en la entrada del registro de errores (por ejemplo, encabezados HTTP o información de identidad), entonces debe buscar la entrada correspondiente en el registro de acceso para determinar exactamente qué cliente excedió el límite de velocidad. Las nuevas características abordan estos problemas.

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

Un nuevo punto final para la API NGINX Plus , /api/ versión /http/limit_reqs , mantiene contadores para todos los resultados de las decisiones de limitación de velocidad tomadas para cada zona definida por una directiva limit_req_zone . Estos contadores se pueden utilizar para supervisar las decisiones de limitación de velocidad en tiempo real o integrarse con soluciones APM para proporcionar paneles y alertas sobre la actividad de limitación de velocidad.

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

$ curl http://localhost/api/6/http/limit_reqs { "mi_límite": { "retrasado": 540, "ejecución en seco retrasada": 12162, "pasado": 804541, "rechazado": 63, "ejecución en seco rechazada": 1209 } }

Tenga en cuenta que estos contadores también incluyen entradas para solicitudes excesivas procesadas en modo de ejecución en seco , que se introdujo en NGINX Plus R19 .

Registro de actividad de limitación de velocidad en el registro de acceso

Las métricas en tiempo real son muy útiles para comprender cuándo NGINX Plus está procesando solicitudes excesivas, pero no indican quién las está generando. Para abordar este desafío, NGINX Plus R20 proporciona una nueva variable $limit_req_status . Registra el estado de limitación de velocidad de la solicitud: RETRASADO , EJECUCIÓN EN SECO RETARDADA , APROBADO , RECHAZADO o EJECUCIÓN EN SECO RECHAZADA .

Luego puede incluir otras variables en el formato de registro que identifiquen de forma única al cliente, la URI y cualquier otra información relevante. En la siguiente configuración, se aplica un límite de velocidad estricto de 10 solicitudes por segundo para cada cliente, según la validación del token web JSON (JWT) (línea 1). Las solicitudes excesivas se rechazan (línea 16) y se registran en un archivo de registro separado (línea 21), que también incluye la variable $jwt_claim_sub para capturar la sub- reclamo (línea 4).

Entradas de muestra en el archivo reject.log :

hora=1575289305.350 cliente=10.0.0.1 sub=adam uri=/ estado=429 límite_solicitud=RECHAZADO hora=1575289305.395 cliente=10.0.0.1 sub=adam uri=/ estado=429 límite_solicitud=RECHAZADO
hora=1575289305.402 cliente=10.0.0.1 sub=adam uri=/ estado=429 límite_solicitud=RECHAZADO

Mejoras en la limitación de conexión

Además de la limitación de velocidad para las solicitudes, NGINX Plus admite la limitación de las conexiones de clientes con el módulo Limitar conexiones . Puede definir cuántas conexiones independientes puede abrir un cliente a NGINX Plus (o la cantidad de solicitudes simultáneas cuando se usa HTTP/2). Un cliente normalmente se identifica por su dirección IP remota (la variable $remote_addr o $binary_remote_addr ), pero puede usar otra variable (como $jwt_claim_sub para el nombre de usuario en un JWT) cuando la dirección IP remota es ambigua o posiblemente compartida por varios clientes.

NGINX Plus R20 amplía la limitación de conexión con las mismas mejoras en la limitación de velocidad introducidas en NGINX Plus R19 y esta versión:

• Modo de ejecución en seco con la directiva limit_conn_dry_run
• Monitoreo en tiempo real en el punto final de la API NGINX Plus /api/ versión /http/limit_conns
• Una nueva variable, $limit_conn_status , que captura la decisión de limitación de conexión para cada solicitud ( PASSED , REJECTED o REJECTED_DRY_RUN ) y se puede usar como se describe en Registro de actividad de limitación de velocidad en el registro de acceso para la variable $limit_req_status

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

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

Con el almacén de valores clave en memoria para NGINX Plus, puede usar 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 casos de uso incluyen listas de denegación dinámicas de direcciones IP , limitación dinámica del ancho de banda y almacenamiento en caché de tokens de autenticación .

NGINX Plus R20 agrega soporte para hacer coincidir claves con un prefijo específico (caracteres al comienzo de una cadena), lo que permite un nuevo conjunto de casos de uso para el almacén de clave-valor. Por ejemplo, poder hacer coincidir claves con prefijos de URI (rutas base) en lugar de URI exactos significa que puede crear una tabla de enrutamiento dinámico para mapear cada ruta base a un grupo ascendente, reemplazando o aumentando las asignaciones estáticas definidas por directivas de ubicación .

Para habilitar la coincidencia de prefijo, 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 ) con cada prefijo de URI, y la directiva add_header establece el encabezado de respuesta Cache-Control en ese valor mientras NGINX Plus reenvía la solicitud al servidor ascendente.

Usamos la API NGINX Plus para definir el valor del encabezado de respuesta de Cache-Control para cada ruta base (en este caso, rutas que comienzan con /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/paths HTTP/1.1 201 Servidor creado: nginx/1.17.6 Fecha: Lun, 2 dic 2019 12:36:31 GMT Duración del contenido: 0 Ubicación: http://localhost:8080/api/6/http/keyvals/paths/ Conexión: keep-alive

Cuando realizamos una solicitud con una ruta base que existe en el almacén de clave-valor, la respuesta incluye el encabezado Cache-Control que configuramos:

$ curl -I http://localhost/images/sample.jpg HTTP/1.1 200 OK Servidor: nginx/1.17.6 Fecha: Lun, 2 Dic 2019 12:27:39 GMT Tipo de contenido: image/jpeg Longitud del contenido: 120847 Conexión: keep-alive Control de caché: edad máxima=3600

Debido a que el almacén de valores clave se puede sincronizar en un clúster de instancias NGINX Plus , debe realizar cada llamada de API a una sola instancia. Esto hace que el proceso de automatización de cambios en la configuración del clúster sea mucho más simple que coordinar cambios en los archivos de configuración .

Resolución de DNS por grupo ascendente

Al utilizar NGINX Plus para realizar el equilibrio de carga entre varios servidores ascendentes, puede definir los miembros del grupo ascendente especificando un nombre de host que se resuelva en múltiples direcciones IP . Esto es particularmente útil en entornos dinámicos o de escalamiento automático donde los miembros del grupo ascendente pueden cambiar con frecuencia.

Para completar la configuración de estos grupos ascendentes dinámicos, también incluya la directiva resolver para designar el servidor o servidores DNS que NGINX Plus consulta para las direcciones IP asociadas con el nombre de host. En versiones anteriores, una directiva de resolución se aplicaba a todos los grupos ascendentes referenciados por las directivas proxy_pass en el contexto ( http , servidor o ubicación ) que contenía la directiva. Con NGINX Plus R20 ahora puedes especificar un solucionador DNS diferente para cada grupo ascendente.

La nueva flexibilidad es especialmente útil en un entorno DevOps: permite a los equipos de aplicação poseer una mayor parte de su infraestructura de distribución de aplicação , incluidos los servidores DNS y los registros de servicios, en lugar de depender de servicios compartidos centralizados.

Aún es posible definir un solucionador global en el contexto http de nivel superior y en los bloques de servidor y ubicación . Si un bloque ascendente no incluye una directiva de resolución , hereda la configuración de resolución del contexto o bloque que incluye una directiva proxy_pass que hace referencia al grupo ascendente, como en versiones anteriores.

En el siguiente ejemplo, el grupo ascendente del sitio web utiliza el solucionador global, mientras que mobile_app utiliza su propio solucionador:

Tenga en cuenta que estamos incluyendo el parámetro status_zone ( introducido en NGINX Plus R19 ) en ambas directivas del solucionador , para recopilar errores y otras métricas sobre la actividad del solucionador.

Variables para metadatos del servidor de 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 maneja la solicitud del cliente. Esto es particularmente importante para los casos de uso en los que necesita conocer la dirección IP del cliente; por ejemplo, para limitar la cantidad de conexiones realizadas por cada cliente (con la directiva less_conn ) o simplemente para registrar la dirección IP del cliente real. Como en versiones anteriores, la variable $proxy_protocol_addr captura esta información.

Cuando hay varios servidores proxy de capa 4 implementados en un entorno de aplicação , 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 agrega variables para capturarla:

• $dirección_del_servidor_de_protocolo_proxy
• $puerto_del_servidor_de_protocolo_proxy

Las variables están disponibles para los módulos HTTP y Stream (TCP/UDP), y admiten las versiones 1 y 2 del protocolo PROXY. Tenga en cuenta que antes de usar las variables debe habilitar explícitamente NGINX Plus para manejar el protocolo PROXY, agregando el parámetro proxy_protocol a la directiva listen .

Mejoras de seguridad para HTTP/2

NGINX Plus R18 P1 abordó 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 HTTP/2:

• Detección mejorada de comportamientos incorrectos o no válidos del cliente
• Se mejoró el envío de respuestas de error HTTP/2 antes de leer el cuerpo de la solicitud del cliente
• Se mejoró la robustez de la directiva workers_shutdown_timeout para conexiones HTTP/2 de larga duración
• Se mejoró la robustez de la directiva proxy_request_buffering para clientes HTTP/2

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

Actualizaciones del ecosistema NGINX Plus

Módulo NGINX JavaScript

El módulo JavaScript de NGINX (njs) se ha actualizado a la versión0.3.7 , agregando soporte para más objetos JavaScript:

• Constructor de función()
• Método Object.assign()
• Métodos numéricos : toFixed() , toPrecision() y toExponential()
• Método Array.prototype.copyWithin()
• Parámetro de etiqueta para el método console.time()

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

Actualice o pruebe NGINX Plus

Si está utilizando NGINX Plus, le recomendamos encarecidamente que actualice a NGINX Plus R20 lo antes posible. También recibirás una serie de correcciones y mejoras adicionales, y ayudará a NGINX a ayudarte cuando necesites generar un ticket de soporte.

Revise atentamente las nuevas características y los cambios de comportamiento descritos en esta publicación del blog antes de continuar con la actualización.

Si aún no ha probado NGINX Plus, le recomendamos que lo haga por cuestiones de seguridad, equilibrio de carga y puerta de enlace de API, o como servidor web totalmente compatible con API de administración y monitoreo mejoradas. Puede comenzar hoy con una prueba gratuita de 30 días . Vea usted mismo cómo NGINX Plus puede ayudarle a entregar y escalar sus aplicações.