Presentamos NGINX Plus R15

Liam CrillyDirector sénior de Gestión de Producto

Nos complace anunciar que ya está disponible la decimoquinta versión de NGINX Plus, nuestro producto estrella. Desde nuestro lanzamiento inicial en 2013, NGINX Plus ha crecido enormemente, tanto en funcionalidades como en atractivo comercial. Actualmente 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 Open Source, NGINX Plus es la única solución integral que combina equilibrador de carga, caché de contenido, servidor web y puerta de enlace de API. NGINX Plus incluye funciones avanzadas exclusivas diseñadas para reducir la complejidad de la arquitectura de aplicaciones modernas, además de un servicio de asistencia galardonado.

NGINX Plus R15 incorpora compatibilidad con gRPC, inserción de servidor HTTP/2, compatibilidad mejorada con clústeres, funcionalidad optimizada de puerta de enlace de API y mucho más:

• Compatibilidad nativa con gRPC – gRPC es el nuevo estándar de llamada a procedimiento remoto (RPC) desarrollado por Google. Es una forma ligera y eficiente de comunicación entre clientes y servidores. Gracias a esta nueva funcionalidad, NGINX Plus puede finalizar conexiones SSL, enrutar y equilibrar la carga del tráfico gRPC hacia sus servidores backend.
• Envío push del servidor HTTP/2 – Con el envío push del servidor HTTP/2, NGINX Plus puede enviar recursos antes de que los clientes los soliciten, lo que mejora el rendimiento y reduce los viajes de ida y vuelta.
• Uso compartido del estado en un clúster – Con esta versión, los datos de memoria compartida utilizados para la persistencia de sesiones Sticky Learn se pueden compartir entre todas las instancias de NGINX Plus de un clúster. Las próximas versiones de NGINX Plus ampliarán nuestras capacidades de agrupación en clústeres e incorporarán nuevas funciones compatibles con clústeres.
• Integración con OpenID Connect – Ahora puede proporcionar inicio de sesión único (SSO) a cualquier aplicación web con NGINX Plus mediante el flujo de código de autorización de OpenID Connect y la emisión de 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 en los módulos JavaScript (njs) de NGINX – Los módulos njs (anteriormente nginScript) permiten ejecutar código JavaScript durante el procesamiento de solicitudes de NGINX Plus. El módulo njs para HTTP ahora permite realizar subsolicitudes HTTP independientes de la solicitud del cliente y asíncronas con respecto a ella. Esto resulta útil en casos de uso de puertas de enlace de API, ya que ofrece la flexibilidad necesaria para modificar y consolidar llamadas a API mediante JavaScript. Los módulos njs para HTTP y TCP/UDP ahora también incluyen bibliotecas criptográficas que permiten implementar funciones hash habituales.

La versión se completa con más funciones nuevas, entre ellas una nueva variable ALPN, actualizaciones de varios módulos dinámicos y mucho más.

Cambios de comportamiento

• NGINX Plus R13 introdujo la API de NGINX Plus completamente nueva, que permite realizar funciones que antes se implementaban en API independientes, como la configuración dinámica de grupos de servidores ascendentes y las métricas ampliadas. Las API anteriores, configuradas con las directivas upstream_conf y status, están obsoletas. Le recomendamos que compruebe si su configuración contiene estas directivas y que migre a la nueva directiva api en cuanto sea posible (para obtener más información, consulte Presentación de NGINX Plus R13 en nuestro blog). A partir de la próxima versión, NGINX Plus R16, las API obsoletas dejarán de incluirse.
• La API de NGINX Plus se ha actualizado a la versión 3 en esta versión. Las versiones anteriores siguen siendo compatibles. Si está pensando en actualizar sus clientes de API, consulte la documentación sobre compatibilidad de la API.
• Los paquetes de NGINX Plus disponibles en el repositorio oficial ahora utilizan un nuevo esquema de numeración. El paquete de NGINX Plus y todos los módulos dinámicos indican ahora el número de versión de NGINX Plus. La versión de cada paquete se corresponde ahora con la versión de NGINX Plus, lo que permite identificar con mayor claridad qué versión está instalada y simplifica las dependencias de los módulos. Este cambio no tendrá ningún efecto, salvo que utilice sistemas automatizados que hagan referencia a los paquetes por su número de versión. En ese caso, pruebe primero el proceso de actualización en un entorno que no sea de producción.

Características de NGINX Plus R15 en detalle

Compatibilidad con gRPC

Con esta versión, NGINX Plus puede actuar como proxy y equilibrar la carga del tráfico gRPC, que muchas organizaciones ya utilizan para la comunicación con microservicios. gRPC es un framework de código abierto y alto rendimiento para llamadas a procedimientos remotos (RPC), diseñado por Google para ofrecer una comunicación entre servicios muy eficiente y de baja latencia. gRPC exige 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 bidireccional de tráfico con baja latencia— son idóneas para conectar microservicios a gran escala.

NGINX enruta el tráfico gRPC y finaliza sus conexiones SSL

La compatibilidad con gRPC se introdujo en NGINX Open Source 1.13.10 y ahora está incluida en NGINX Plus R15. Ahora puede inspeccionar y enrutar llamadas a métodos gRPC, lo que le permite:

• Aplique las funcionalidades de NGINX Plus —incluidos el cifrado TLS de 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 varios servicios gRPC a través de un único punto de conexión inspeccionando y redirigiendo mediante proxy las conexiones gRPC a servicios internos.
• Escale sus servicios gRPC cuando necesite capacidad adicional mediante el balanceo de carga de las conexiones gRPC entre los grupos de servidores backend ascendentes.
• Utilice NGINX Plus como puerta de enlace de API tanto para endpoints gRPC como RESTful.

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

Inserción de servidor HTTP/2

Las primeras impresiones son importantes, y el tiempo de carga de la página es un factor decisivo para que los usuarios vuelvan a visitar su sitio web. Una forma de ofrecer respuestas más rápidas a los usuarios es utilizar la inserción del servidor HTTP/2, que reduce el número de RTT (tiempos de ida y vuelta, es decir, el tiempo necesario para una solicitud y su respuesta) que el usuario debe esperar.

NGINX puede enviar recursos de forma anticipada a los clientes para mejorar el rendimiento

La inserción del servidor HTTP/2 era una funcionalidad muy solicitada y esperada por la comunidad de código abierto de NGINX, que se introdujo en NGINX Open Source 1.13.9. Ahora, incluida en NGINX Plus R15, permite que un servidor envíe de forma anticipada datos que probablemente sean necesarios para completar una solicitud anterior iniciada por el cliente. Por ejemplo, un navegador necesita una amplia variedad de recursos – hojas de estilo, imágenes, etc. – para renderizar una página web, por lo que puede ser conveniente enviar esos recursos inmediatamente cuando un cliente accede por primera vez a la página, 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 proporcionar de antemano al cliente las hojas de estilo y las imágenes que necesitará para renderizar la página web demo:

Cargando ejemplo de código…

Sin embargo, en algunos casos no es posible determinar el conjunto exacto de recursos que necesitan los clientes, por lo que no resulta práctico enumerar archivos específicos en el archivo de configuración de NGINX. En estos casos, NGINX puede interceptar las cabeceras HTTP Link y enviar los recursos marcados como preload en ellas. Para habilitar la interceptación de las cabeceras Link, establezca la directiva http2_push_preload en on.

Cargando ejemplo de código…

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

Uso compartido del estado en un clúster

Configurar varios servidores NGINX Plus en un clúster de alta disponibilidad aumenta la resiliencia de sus aplicaciones y elimina los puntos únicos de fallo en su pila de aplicaciones. Los clústeres de NGINX Plus están diseñados para implementaciones de producción críticas, en las que la resiliencia y la alta disponibilidad son primordiales. Existen muchas soluciones para implementar clústeres de alta disponibilidad con NGINX Plus.

La compatibilidad con clústeres se introdujo en versiones anteriores de NGINX Plus y ofrece dos niveles de agrupación en clúster:

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

NGINX Plus R15 introduce un tercer nivel de agrupación en clústeres: el uso compartido del estado durante la ejecución, lo que permite sincronizar los datos de las zonas de memoria compartida entre los nodos del clúster. En concreto, los datos almacenados en las zonas de memoria compartida para la persistencia de sesiones Sticky Learn ahora se pueden sincronizar entre todos los nodos del clúster mediante el nuevo módulo zone_sync para el tráfico TCP/UDP.

Nuevo módulo zone_sync Module

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

Un clúster de NGINX Plus con uso compartido del estado debe cumplir tres requisitos:

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

  Cargando ejemplo de código…

La directiva zone_sync permite sincronizar las zonas de memoria compartida en un clúster. La directiva zone_sync_server identifica las demás instancias de NGINX Plus del clúster. NGINX Plus admite la detección de servicios DNS, por lo que los miembros del clúster pueden identificarse mediante el nombre de host y la configuración es idéntica para todos ellos.

La configuración mínima anterior carece de los controles de seguridad necesarios para proteger los datos de sincronización en un entorno de producción. El siguiente fragmento de configuración incorpora varias de estas medidas de protección:

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

Cargando ejemplo de código…

Uso compartido del estado para la persistencia de sesiones con Sticky Learn

La primera funcionalidad 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 sesión implica que las solicitudes de un cliente siempre se reenvían al servidor que atendió la primera solicitud del cliente, lo que resulta ú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 denominada «sessions». El parámetro «sync» permite compartir el estado en todo el clúster al indicar 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 los datos de estado funcione correctamente, la configuración de cada nodo de NGINX Plus del clúster debe incluir el mismo bloque upstream, con la directiva sticky learn, así como las directivas que habilitan el módulo zone_sync (descrito anteriormente).

Cargando ejemplo de código…

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

Integración con OpenID Connect

Muchas empresas utilizan soluciones de gestión de identidades y accesos (IAM) para administrar las cuentas de usuario y proporcionar un entorno de inicio de sesión único (SSO) para varias aplicaciones. A menudo buscan ampliar el SSO a aplicaciones nuevas y existentes para reducir al mínimo la complejidad y los costes.

«El uso de OpenID Connect con NGINX Plus nos permitió integrarnos rápida y fácilmente con nuestro proveedor de identidad y, al mismo tiempo, simplificar la arquitectura de nuestra aplicación». —Scott Macleod, ingeniero de software, NHS Digital

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

• Extender el SSO a aplicaciones heredadas sin modificarlas ni modernizarlas
• Integre el SSO en nuevas aplicaciones sin implementar el SSO ni la autenticación en el código de la aplicación
• Elimine la dependencia de un proveedor; obtendrá un SSO basado en estándares sin tener que implementar con la aplicación software de agente propietario del proveedor de IAM

La integración de OpenID Connect con NGINX Plus está disponible como implementación de referencia en GitHub. El repositorio de GitHub incluye una configuración de ejemplo con instrucciones para la instalación, la configuración y el ajuste preciso 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 consultar la lista completa, véase Casos de uso del módulo JavaScript de NGINX.

El código de esta sección se ha actualizado de la siguiente manera para reflejar los cambios realizados en la implementación de NGINX JavaScript desde la publicación original del blog:

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

]

Con el módulo JavaScript de NGINX, njs (anteriormente nginScript), puede incluir código JavaScript en 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 variedad de posibles casos de uso, como obtener un control más preciso del tráfico, consolidar funciones de JavaScript entre distintas aplicaciones y protegerse frente a amenazas de seguridad.

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

Subsolicitudes

Ahora puedes realizar solicitudes HTTP simultáneas que sean independientes de la solicitud del cliente y asíncronas con respecto a ella. Esto permite multitud de casos de uso avanzados.

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

Cargando ejemplo de código…

La directiva js_import de la configuración correspondiente de NGINX Plus lee el código JavaScript de fastest_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. El URI original con los parámetros de consulta se pasa a los servidores backend correspondientes. Ambas subsolicitudes ejecutan la función de devolución de llamada done. Sin embargo, dado que esta función incluye r.return(), solo la subsolicitud que se completa primero envía su respuesta al cliente.

Cargando ejemplo de código…

Funciones hash

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

• Funciones hash: MD5, SHA‑1, SHA‑256
• HMAC mediante: MD5, SHA‑1, SHA‑256
• Formatos de resumen: Base64, Base64URL, hexadecimal

Un ejemplo de uso de las funciones hash consiste en garantizar la integridad de los datos de las cookies de una aplicación. El siguiente ejemplo de código njs incluye una función signCookie() para añadir una firma digital a una cookie y una función validateCookieSignature() para validar las cookies firmadas.

Cargando ejemplo de código…

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

Cargando ejemplo de código…

Nuevas funciones adicionales de NGINX Plus R15

Variable ALPN para los módulos Stream

La negociación de protocolos de la 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 la conexión que se está estableciendo, evitando intercambios adicionales que podrían aumentar la latencia y empeorar la experiencia del usuario. El caso de uso más habitual de ALPN es actualizar automáticamente las conexiones de HTTP a HTTP/2 cuando tanto el cliente como el servidor son compatibles con HTTP/2.

La nueva variable de 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 durante la fase de lectura previa de ALPN. Con la siguiente configuración, un cliente XMPP puede identificarse mediante ALPN para que NGINX Plus enrute el tráfico XMPP al grupo de servidores ascendentes xmpp_backend, el tráfico gRPC a grpc_backend y todo el tráfico restante a http_backend, todo ello a través de un único punto de conexión.

Para que NGINX Plus pueda extraer información del mensaje ClientHello y asignarla a la variable $ssl_preread_alpn_protocols, también debe incluir la directiva ssl_preread on.

Cargando ejemplo de código…

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

Variable de tiempo en cola

NGINX Plus admite las colas de espera en los servidores upstream para que las solicitudes de los clientes no tengan que rechazarse inmediatamente cuando ninguno de los servidores del grupo upstream esté disponible para aceptar nuevas solicitudes.

Un caso de uso habitual de las colas de servidores upstream es proteger los servidores backend frente a sobrecargas sin tener que rechazar inmediatamente las solicitudes cuando todos los servidores están ocupados. Puede definir el número máximo de conexiones simultáneas para cada servidor upstream mediante el parámetro max_conns de la directiva server. La directiva queue pone las solicitudes en una cola cuando no hay ningún backend disponible, ya sea porque han alcanzado su límite de conexiones o porque no han superado una comprobación de estado.

En esta versión, la nueva variable de NGINX $upstream_queue_time, introducida por primera vez en NGINX Open Source 1.13.9, registra el tiempo que una solicitud permanece en la cola. La configuración siguiente incluye un formato de registro personalizado que recopila diversas métricas de tiempo para cada solicitud; posteriormente, estas métricas se pueden analizar sin conexión como parte del ajuste del rendimiento. Limitamos a 20 el número de solicitudes en cola para el grupo de servidores ascendentes my_backend. El parámetro timeout establece cuánto tiempo permanecen las solicitudes en la cola antes de devolver un mensaje de error al cliente (503 de forma predeterminada). En este caso, lo establecemos en 5 segundos (el valor predeterminado es de 60 segundos).

Cargando ejemplo de código…

Para obtener más información, consulte la documentación de la directiva «queue».

Registros de acceso sin escape

Ahora puede desactivar 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 aplique ningún escape a los caracteres especiales de 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 resolver problemas y corregir errores. Consúltala en GitHub.

Proxy transparente sin privilegios de root

Puede utilizar NGINX Plus como proxy transparente incluyendo el parámetro transparent en la directiva proxy_bind. Ahora los procesos de trabajo pueden heredar del proceso maestro la capacidad de Linux CAP_NET_RAW Linux capability, por lo que NGINX Plus ya no requiere privilegios especiales para funcionar como proxy transparente.

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

Período de gracia de JWT

Si un JWT incluye una declaración basada en el tiempo – nbf (fecha de inicio de validez), exp (fecha de caducidad) o ambas –, la validación del JWT por parte de NGINX Plus comprueba que la hora actual se encuentre dentro del intervalo de tiempo especificado. Sin embargo, si el reloj del proveedor de identidades no está sincronizado con el de la instancia de NGINX Plus, los tokens podrían caducar de forma inesperada o parecer que comienzan a ser válidos en el futuro. Para establecer el desfase máximo aceptable entre ambos relojes, utilice la directiva auth_jwt_leeway.

Módulo dinámico Cookie Flag

El módulo de terceros para configurar los atributos de las cookies ya está disponible como módulo dinámico Cookie-Flag en el repositorio de NGINX y está cubierto por su contrato de soporte de NGINX Plus. Puede instalarlo con su herramienta de gestión de paquetes:

$ 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
• Correcciones de fugas de memoria en ModSecurity-nginx

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

Actualice a NGINX Plus o pruébelo

NGINX Plus R15 incluye funciones de autenticación mejoradas para sus aplicaciones cliente, capacidades adicionales de agrupación en clústeres, mejoras de njs y correcciones de errores importantes.

Si utiliza NGINX Plus, le recomendamos encarecidamente que actualice a la versión 15 lo antes posible. Obtendrá diversas correcciones y mejoras, y la actualización nos permitirá ayudarle mejor cuando necesite abrir una incidencia de soporte. Las instrucciones de instalación y actualización de NGINX Plus R15 están disponibles en el portal del cliente.

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 utilizado NGINX Plus, le animamos a probarlo para acelerar sitios web, equilibrar cargas y distribuir aplicaciones, o como servidor web con soporte completo y API avanzadas de supervisión y gestión. Puede empezar hoy mismo de forma gratuita con una evaluación gratuita de 30 días. Compruebe por sí mismo cómo NGINX Plus puede ayudarle a distribuir y escalar sus aplicaciones.

Sobre el autor

Liam CrillyDirector sénior de Gestión de Producto

Más artículos de Liam Crilly