Anunciamos NGINX Plus R15

Nos complace anunciar que la decimoquinta versión de NGINX Plus, nuestro producto estrella, ya está disponible. Desde nuestro lanzamiento inicial en 2013 , NGINX Plus ha crecido enormemente, tanto en su conjunto de funciones como en su atractivo comercial. Ahora hay más de [ngx_snippet name='nginx-plus-customers'] clientes de NGINX Plus y [ngx_snippet name='number-sites'] usuarios de NGINX Open Source .

Basado en NGINX de código abierto, NGINX Plus es el único equilibrador de carga, caché de contenido, servidor web y puerta de enlace API todo en uno . NGINX Plus incluye características mejoradas exclusivas diseñadas para reducir la complejidad en la arquitectura de aplicaciones modernas, junto con un soporte galardonado.

NGINX Plus R15 presenta nuevo soporte para gRPC, inserción de servidor HTTP/2, soporte de agrupamiento mejorado, funcionalidad de puerta de enlace API mejorada y más:

• Compatibilidad nativa con gRPC : gRPC es el nuevo estándar de llamada a procedimiento remoto (RPC) desarrollado por Google. Es una forma liviana y eficiente para que los clientes y servidores se comuniquen. Con esta nueva funcionalidad, NGINX Plus puede finalizar mediante SSL, enrutar y equilibrar la carga del tráfico gRPC hacia sus servidores backend.
• Push de servidor HTTP/2 : con push de servidor HTTP/2, NGINX Plus puede enviar recursos antes de que los clientes realmente los soliciten, lo que mejora el rendimiento y reduce los viajes de ida y vuelta.
• Uso compartido de estado en un clúster : con esta versión, los datos de memoria compartida utilizados para la persistencia de la sesión de Sticky Learn se pueden compartir entre todas las instancias de NGINX Plus en un clúster. Las próximas versiones de NGINX Plus se basarán en nuestras capacidades de agrupamiento e introducirán nuevas funciones compatibles con agrupamientos.
• Integración con OpenID Connect : ahora puede proporcionar inicio de sesión único (SSO) a cualquier aplicación web con NGINX Plus, utilizando el flujo de código de autorización de OpenID Connect y emitiendo tokens web JSON (JWT) a los clientes. NGINX Plus se integra con CA Single Sign-On (anteriormente SiteMinder), ForgeRock OpenAM, Keycloak, Okta, OneLogin, Ping Identity y otros proveedores de identidad populares.
• Mejoras del módulo JavaScript (njs) de NGINX : los módulos njs (anteriormente nginScript) le permiten ejecutar código JavaScript durante el procesamiento de solicitudes de NGINX Plus. El módulo njs para HTTP ahora proporciona soporte para emitir subsolicitudes HTTP que son independientes y asincrónicas a la solicitud del cliente. Esto es útil en casos de uso de API Gateway, ya que le brinda la flexibilidad de modificar y consolidar llamadas API mediante JavaScript. Los módulos njs para HTTP y TCP/UDP ahora también incluyen bibliotecas de cifrado que permiten la implementación de funciones hash comunes.

Para completar el lanzamiento se incluyen más características nuevas , incluida una nueva variable ALPN, actualizaciones de múltiples módulos dinámicos y más.

Cambios en el comportamiento

• NGINX Plus R13 vio la introducción de la nueva API NGINX Plus, que habilita funciones que anteriormente se implementaron en API separadas, incluida la configuración dinámica de grupos ascendentes y métricas extendidas. Las API anteriores, configuradas con las directivas upstream_conf y status , están obsoletas. Le recomendamos que verifique su configuración para estas directivas y convierta a la nueva directiva api tan pronto como sea posible (para obtener detalles, consulte Anuncio de NGINX Plus R13 en nuestro blog). A partir de la próxima versión, NGINX Plus R16 , las API obsoletas ya no se enviarán.
• La API NGINX Plus se actualiza a la versión 3 en esta versión. Las versiones anteriores aún reciben soporte. Si está considerando actualizar sus clientes de API, consulte la documentación de compatibilidad de API .
• Los paquetes NGINX Plus disponibles en el repositorio oficial ahora tienen un nuevo esquema de numeración. El paquete NGINX Plus y todos los módulos dinámicos ahora indican el número de versión de NGINX Plus. Cada versión del paquete ahora corresponde a la versión NGINX Plus, para que quede más claro qué versión está instalada y para simplificar las dependencias del módulo. Este cambio es transparente a menos que estés utilizando sistemas automatizados que hagan referencia a los paquetes por número de versión. En ese caso, primero pruebe el proceso de actualización en un entorno que no sea de producción.

Características detalladas de NGINX Plus R15

Compatibilidad con gRPC

Con esta versión, NGINX Plus puede redirigir y equilibrar la carga del tráfico gRPC, que muchas organizaciones ya utilizan para la comunicación con microservicios. gRPC es un marco de trabajo de llamadas a procedimientos remotos (RPC) de código abierto y alto rendimiento, diseñado por Google para una comunicación entre servicios altamente eficiente y de baja latencia. gRPC utiliza HTTP/2, en lugar de HTTP 1.1, como mecanismo de transporte, ya que las características de HTTP/2 (control de flujo, multiplexación y transmisión de tráfico bidireccional con baja latencia) son ideales para conectar microservicios a escala.

El soporte para gRPC se introdujo en NGINX Open Source 1.13.10 y ahora está incluido en NGINX Plus R15 . Ahora puede inspeccionar y enrutar llamadas de métodos gRPC, lo que le permite:

• Aplique las características de NGINX Plus, incluido el cifrado TLS HTTP/2, la limitación de velocidad, las listas de control de acceso basadas en direcciones IP y el registro, a los servicios gRPC publicados.
• Publique múltiples servicios gRPC a través de un único punto final inspeccionando y enviando por proxy conexiones gRPC a servicios internos.
• Escale sus servicios gRPC cuando necesite capacidad adicional equilibrando la carga de las conexiones gRPC a los grupos de backend ascendentes.
• Utilice NGINX Plus como puerta de enlace API para puntos finales gRPC y RESTful.

Para obtener más información, consulte Presentación de la compatibilidad de gRPC con NGINX 1.13.10 en nuestro blog.

Push de servidor HTTP/2

Las primeras impresiones son importantes y el tiempo de carga de la página es un factor crítico para determinar si los usuarios volverán a visitar su sitio web. Una forma de proporcionar respuestas más rápidas a los usuarios es mediante el envío de notificaciones push al servidor HTTP/2, lo que reduce la cantidad de RTT (tiempos de ida y vuelta, el tiempo necesario para una solicitud y una respuesta) que el usuario debe esperar.

El envío de servidores HTTP/2 fue una característica muy solicitada y esperada por la comunidad de código abierto NGINX, introducida en NGINX Open Source 1.13.9. Ahora incluido en NGINX Plus R15 , permite que un servidor envíe de forma preventiva datos que probablemente sean necesarios para completar una solicitud previa iniciada por el cliente. Por ejemplo, un navegador necesita una amplia gama de recursos (hojas de estilo, imágenes, etc.) para representar una página web, por lo que puede tener sentido enviar esos recursos inmediatamente cuando un cliente accede a la página por primera vez, en lugar de esperar a que el navegador los solicite explícitamente.

En el siguiente ejemplo de configuración, utilizamos la directiva http2_push para preparar a un cliente con hojas de estilo e imágenes que necesitará para representar la página web de demostración :

Sin embargo, en algunos casos no es posible determinar el conjunto exacto de recursos que necesitan los clientes, lo que hace que no resulte práctico enumerar archivos específicos en el archivo de configuración de NGINX. En estos casos, NGINX puede interceptar los encabezados de enlace HTTP y enviar los recursos que están marcados como precargados en ellos. Para habilitar la intercepción de encabezados de enlace , configure la directiva http2_push_preload en activada .

Para obtener más información, consulte Presentación de HTTP/2 Server Push con NGINX 1.13.9 en nuestro blog.

Intercambio de estados en un clúster

Configurar varios servidores NGINX Plus en un clúster de alta disponibilidad hace que sus aplicaciones sean más resistentes y elimina puntos únicos de falla en su pila de aplicación . La agrupación en clústeres NGINX Plus está diseñada para implementaciones de producción de misión crítica donde la resiliencia y la alta disponibilidad son primordiales. Existen muchas soluciones para implementar agrupaciones en clústeres de alta disponibilidad con NGINX Plus .

La compatibilidad con agrupaciones en clústeres se introdujo en versiones anteriores de NGINX Plus, proporcionando dos niveles de agrupación en clústeres:

• Resiliencia de red mediante el paquete keepalived : maneja la conmutación por error si un servidor NGINX Plus deja de funcionar.
• Sincronización de la configuración mediante el paquete nginx-sync : garantiza que la configuración esté sincronizada en todos los servidores NGINX Plus.

NGINX Plus R15 presenta un tercer nivel de agrupamiento: intercambio de estado durante el tiempo de ejecución, lo que le permite sincronizar datos en zonas de memoria compartida entre los nodos del clúster. Más específicamente, los datos almacenados en zonas de memoria compartida para la persistencia de la sesión Sticky Learn ahora se pueden sincronizar en todos los nodos del clúster utilizando el nuevo módulo zone_sync para el tráfico TCP/UDP.

Nuevo módulo zone_sync

Al compartir el estado, no hay un nodo principal: todos los nodos son pares e intercambian datos en una topología de malla completa . Además, la solución de agrupamiento con intercambio de estados es independiente de la solución de alta disponibilidad para la resiliencia de la red. Por lo tanto, un clúster que comparte estados puede abarcar ubicaciones físicas.

Un clúster de intercambio de estados NGINX Plus debe cumplir tres requisitos:

• Conectividad de red entre todos los nodos del clúster
• Relojes sincronizados
• La configuración en cada nodo habilita el módulo zone_sync , como se muestra a continuación:

La directiva zone_sync habilita la sincronización de zonas de memoria compartida en un clúster. La directiva zone_sync_server identifica las otras instancias de NGINX Plus en el clúster. NGINX Plus admite el descubrimiento de servicios DNS para que los miembros del clúster puedan identificarse por nombre de host y la configuración sea idéntica para cada miembro del clúster.

La configuración mínima anterior carece de los controles de seguridad necesarios para proteger los datos de sincronización en una implementación de producción. El siguiente fragmento de configuración emplea varias de estas protecciones:

• Cifrado SSL/TLS de datos de sincronización
• Autenticación de certificado de cliente, de modo que cada nodo del clúster se identifica ante los demás (TLS mutuo)
• Listas de control de acceso (ACL) que utilizan direcciones IP, de modo que solo los nodos NGINX Plus en la misma red física puedan conectarse para la sincronización

Uso compartido de estados para la persistencia de sesiones de aprendizaje persistentes

La primera característica compatible de NGINX Plus que utiliza datos de estado compartidos en un clúster es la persistencia de sesión Sticky Learn . La persistencia de la sesión significa que las solicitudes de un cliente siempre se reenvían al servidor que cumplió la primera solicitud del cliente, lo que es útil cuando el estado de la sesión se almacena en el backend.

En la siguiente configuración, la directiva sticky learn define una zona de memoria compartida llamada sessions . El parámetro de sincronización permite compartir el estado de todo el clúster al indicarle a NGINX Plus que publique mensajes sobre el contenido de su zona de memoria compartida en los demás nodos del clúster.

Tenga en cuenta que para que la sincronización de datos de estado funcione correctamente, la configuración en cada nodo NGINX Plus del clúster debe incluir el mismo bloque ascendente con la directiva sticky learn , así como las directivas que habilitan el módulo zone_sync (descrito anteriormente ).

Nota : La compatibilidad con clústeres y la persistencia de sesiones Sticky Learn son exclusivas de NGINX Plus.

Integración de OpenID Connect

Muchas empresas utilizan soluciones de gestión de acceso (IAM) para administrar cuentas de usuario y proporcionar un entorno de inicio de sesión único (SSO) para múltiples aplicaciones. A menudo buscan extender el SSO a aplicaciones nuevas y existentes para minimizar la complejidad y los costos.

NGINX Plus R10 introdujo soporte para validar tokens OpenID Connect . En esta versión ampliamos esa capacidad para que NGINX Plus también pueda controlar el flujo del código de autorización para la autenticación con OpenID Connect 1.0 , comunicándose con el proveedor de identidad y emitiendo el token de acceso al cliente. Esto permite la integración con la mayoría de los principales proveedores de identidad, incluidos CA Single Sign-On (anteriormente SiteMinder), ForgeRock OpenAM, Keycloak, Okta, OneLogin y Ping Identity. La nueva capacidad ampliada también le permite:

• Amplíe el SSO a aplicaciones heredadas sin modificarlas ni aplicaciones
• Integre SSO en nuevas aplicaciones sin implementar SSO o autenticación en el código de la aplicación
• Elimine el bloqueo del proveedor; obtenga SSO basado en estándares sin tener que implementar software de agente de proveedor de IAM propietario con la aplicación

La integración de OpenID Connect con NGINX Plus está disponible como una implementación de referencia en GitHub. El repositorio de GitHub incluye una configuración de muestra con instrucciones de instalación, configuración y ajuste para casos de uso específicos.

Mejoras en el módulo JavaScript de NGINX

[ Editor : Los siguientes ejemplos son solo algunos de los muchos casos de uso del módulo JavaScript de NGINX. Para obtener una lista completa, consulte Casos de uso del módulo JavaScript NGINX .

El código de esta sección se actualiza de la siguiente manera para reflejar los cambios en la implementación de JavaScript de NGINX desde que se publicó originalmente el blog:

• Para utilizar el objeto de sesión refactorizado ( s ) para el módulo Stream, que se introdujo en NGINX JavaScript 0.2.4 .
• Para utilizar la directiva js_import , que reemplaza la directiva js_include en NGINX Plus R23 y posteriores. Para obtener más información, consulte la documentación de referencia del módulo JavaScript de NGINX : la sección Configuración de ejemplo muestra la sintaxis correcta para la configuración de NGINX y los archivos JavaScript.

]

Con el módulo JavaScript de NGINX, njs (anteriormente nginScript), puede incluir código JavaScript dentro de su configuración de NGINX para que se evalúe en tiempo de ejecución, a medida que se procesan las solicitudes HTTP o TCP/UDP. Esto permite una amplia gama de casos de uso potenciales, como obtener un control más preciso sobre el tráfico, consolidar funciones de JavaScript en todas las aplicaciones y defenderse contra amenazas a la seguridad.

NGINX Plus R15 incluye dos actualizaciones importantes para njs: subsolicitudes y funciones hash .

Subsolicitudes

Ahora puede emitir solicitudes HTTP simultáneas que sean independientes y asincrónicas con respecto a la solicitud del cliente. Esto permite una multitud de casos de uso avanzados.

El siguiente código JavaScript de ejemplo emite una solicitud HTTP a dos backends diferentes simultáneamente. La primera respuesta se envía a NGINX Plus para reenviarla al cliente y la segunda respuesta se ignora.

La directiva js_import en la configuración NGINX Plus correspondiente lee el código JavaScript de lowest_wins.js . Todas las solicitudes que coinciden con la ubicación raíz ( / ) se pasan a la función sendFastest() que genera subsolicitudes a las ubicaciones /server_one y /server_two . La URI original con los parámetros de consulta se pasa a los servidores back-end correspondientes. Ambas subsolicitudes ejecutan la función de devolución de llamada realizada . Sin embargo, dado que esta función incluye r.return() , solo la subsolicitud que se completa primero envía su respuesta al cliente.

Funciones hash

Los módulos njs para el tráfico HTTP y TCP/UDP ahora incluyen una biblioteca de cifrado con implementaciones de:

• Funciones hash: MD5, SHA-1, SHA-256
• HMAC utilizando: MD5, SHA-1, SHA-256
• Formatos de resumen: Base64, Base64URL, hex

Un ejemplo de caso de uso de funciones hash es agregar integridad de datos a las cookies de la aplicación . El siguiente ejemplo de código njs incluye una función signCookie() para agregar una firma digital a una cookie y una función validateCookieSignature() para validar las cookies firmadas.

La siguiente configuración de NGINX Plus utiliza el código njs para validar las firmas de cookies en solicitudes HTTP entrantes y devolver un mensaje de error al cliente si la validación falla. NGINX Plus envía la solicitud como proxy si la validación es exitosa o no hay ninguna cookie presente.

Nuevas funciones adicionales en NGINX Plus R15

Variable ALPN para los módulos de flujo

La negociación de protocolo de capa de aplicación (ALPN) es una extensión de TLS que permite que un cliente y un servidor negocien durante el protocolo de enlace TLS qué protocolo se utilizará para establecer la conexión, evitando viajes de ida y vuelta adicionales que podrían generar latencia y degradar la experiencia del usuario. El caso de uso más común para ALPN es actualizar automáticamente las conexiones de HTTP a HTTP/2 cuando tanto el cliente como el servidor admiten HTTP/2.

La nueva variable NGINX $ssl_preread_alpn_protocols , introducida por primera vez en NGINX Open Source 1.13.10, captura la lista de protocolos anunciados por el cliente en su mensaje ClientHello en la fase de prelectura de ALPN. Dada la siguiente configuración, un cliente XMPP puede presentarse a través de ALPN de modo que NGINX Plus enrute el tráfico XMPP al grupo ascendente xmpp_backend , el tráfico gRPC a grpc_backend y todo el resto del tráfico a http_backend , todo a través de un único punto final.

Para permitir que NGINX Plus extraiga información del mensaje ClientHello y complete la variable $ssl_preread_alpn_protocols , también debe incluir la directiva ssl_preread on .

Para obtener más información, consulte la documentación del módulo ngx_stream_ssl_preread .

Variable de tiempo de cola

NGINX Plus admite la puesta en cola ascendente para que las solicitudes de los clientes no tengan que rechazarse inmediatamente cuando todos los servidores del grupo ascendente no estén disponibles para aceptar nuevas solicitudes.

Un caso de uso típico para la cola ascendente es proteger a los servidores back-end de la sobrecarga sin tener que rechazar solicitudes inmediatamente si todos los servidores están ocupados. Puede definir el número máximo de conexiones simultáneas para cada servidor ascendente con el parámetro max_conns de la directiva del servidor . Luego, la directiva de cola coloca las solicitudes en una cola cuando no hay backends disponibles, ya sea porque han alcanzado su límite de conexión o porque han fallado una verificación de estado .

En esta versión, la nueva variable NGINX $upstream_queue_time , introducida por primera vez en NGINX Open Source 1.13.9, captura la cantidad de tiempo que una solicitud pasa en la cola. La siguiente configuración incluye un formato de registro personalizado que captura varias métricas de tiempo para cada solicitud; las métricas luego se pueden analizar sin conexión como parte del ajuste del rendimiento. Limitamos la cantidad de solicitudes en cola para el grupo ascendente my_backend a 20. El parámetro de tiempo de espera establece cuánto tiempo se mantienen las solicitudes en la cola antes de que se devuelva un mensaje de error al cliente (503 por defecto). Aquí lo establecemos en 5 segundos (el valor predeterminado es 60 segundos).

Para obtener más información, consulte la documentación de la directiva de cola .

Acceda a los registros sin escapar

Ahora puedes deshabilitar el escape en el registro de acceso de NGINX Plus. El nuevo parámetro escape=none de la directiva log_format , introducido por primera vez en NGINX Open Source 1.13.10, especifica que no se aplica escape a caracteres especiales en las variables.

Actualización de la implementación de referencia de autenticación LDAP

Nuestra implementación de referencia para autenticar usuarios mediante un sistema de autenticación LDAP se ha actualizado para abordar problemas y corregir errores. Compruébelo en GitHub .

Proxy transparente sin privilegios de root

Puede utilizar NGINX Plus como un proxy transparente incluyendo el parámetro transparent en la directiva proxy_bind . Los procesos de trabajo ahora pueden heredar la capacidad Linux CAP_NET_RAW del proceso maestro, de modo que NGINX Plus ya no requiere privilegios especiales para proxy transparente.

Nota : Esta función se aplica únicamente a plataformas Linux.

Período de gracia de JWT

Si un JWT incluye una afirmación basada en tiempo ( nbf (no antes de la fecha), exp (fecha de vencimiento) o ambas), la validación del JWT por parte de NGINX Plus incluye una verificación de que la hora actual esté dentro del intervalo de tiempo especificado. Sin embargo, si el reloj del proveedor de identidad no está sincronizado con el reloj de la instancia NGINX Plus, los tokens podrían expirar inesperadamente o parecer que comienzan en el futuro. Para establecer la desviación máxima aceptable entre los dos relojes, utilice la directiva auth_jwt_leeway .

Módulo dinámico de bandera de cookies

El módulo de terceros para configurar indicadores de cookies ahora está disponible como módulo dinámico Cookie-Flag en el repositorio NGINX y está cubierto por su acuerdo de soporte NGINX Plus. Puede utilizar su herramienta de gestión de paquetes para instalarlo:

$ apt-get install nginx-plus-module-cookie-flag # Ubuntu/Debian$ yum install nginx-plus-module-cookie-flag     # Red Hat/CentOS

Actualización del módulo WAF ModSecurity de NGINX

NGINX ModSecurity WAF , un módulo dinámico para NGINX Plus basado en ModSecurity 3.0, se ha actualizado con las siguientes mejoras:

• Mejoras de rendimiento en libmodsecurity
• Corrección de fugas de memoria en ModSecurity-nginx

[ Editor – NGINX ModSecurity WAF oficialmente dejó de venderse el 1 de abril de 2022 y está en transición al fin de su vida útil a partir del 31 de marzo de 2024 . Para obtener más detalles, consulte F5 NGINX ModSecurity WAF está en transición al final de su vida útil<.htmla> en nuestro blog.]

Actualice o pruebe NGINX Plus

NGINX Plus R15 incluye capacidades de autenticación mejoradas para sus aplicaciones cliente, capacidades de agrupamiento adicionales, mejoras de njs y correcciones de errores notables .

Si está ejecutando NGINX Plus, le recomendamos encarecidamente que actualice a la versión 15 lo antes posible. Recibirá una serie de correcciones y mejoras, y la actualización nos permitirá ayudarlo cuando necesite generar un ticket de soporte. Las instrucciones de instalación y actualización de NGINX Plus R15 están disponibles en el portal del cliente .

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 no ha utilizado NGINX Plus , le recomendamos que lo pruebe para aceleración web, equilibrio de carga y entrega de aplicación , o como un servidor web totalmente compatible con API de administración y monitoreo mejoradas. Puede comenzar hoy mismo de forma gratuita con una evaluación gratuita de 30 días . Vea usted mismo cómo NGINX Plus puede ayudarle a entregar y escalar sus aplicaciones.