Presentamos NGINX Plus R18

Liam CrillyDirector sénior de Gestión de Producto

Nos complace anunciar que NGINX Plus Release 18 (R18) ya está disponible. NGINX Plus es la única solución todo en uno que integra un equilibrador de carga, una caché de contenido, un servidor web y una puerta de enlace de API. Basado en NGINX Open Source, NGINX Plus incluye funciones avanzadas exclusivas y un servicio de asistencia galardonado. R18 simplifica los flujos de trabajo de configuración para DevOps y mejora la seguridad y la fiabilidad de sus aplicaciones a gran escala.

Más del 87 % de los sitios web utilizan ahora SSL/TLS para cifrar las comunicaciones a través de Internet, frente al 66 % de hace tan solo tres años. El cifrado de extremo a extremo es ahora el modelo de implementación predeterminado para sitios web y aplicaciones, y el enorme aumento de certificados SSL/TLS implica que algunas empresas gestionan decenas de miles de certificados en entornos de producción. Esto exige un enfoque más flexible para implementar y configurar certificados.

Esta versión incorpora compatibilidad con la carga dinámica de certificados. Con miles de certificados, no resulta escalable definir manualmente cada uno en la configuración para cargarlo desde el disco: el proceso no solo es tedioso, sino que la configuración adquiere un tamaño inmanejable y el inicio de NGINX Plus se vuelve inaceptablemente lento. Con NGINX Plus R18, los certificados SSL/TLS ahora pueden cargarse bajo demanda sin tener que enumerarlos individualmente en la configuración. Para simplificar aún más las implementaciones automatizadas, los certificados pueden aprovisionarse mediante la API de NGINX Plus y ni siquiera tienen que almacenarse en el disco.

Otras funciones nuevas de NGINX Plus R18 incluyen:

• Mejoras de OpenID Connect – Seguimos mejorando nuestra implementación de referencia compatible con OpenID Connect, publicada originalmente en NGINX Plus R15. En esta versión, hemos añadido compatibilidad con tokens de sesión opacos, tokens de actualización y una URL de cierre de sesión.
• Intervalos de puertos para servidores virtuales – Ahora los servidores virtuales de NGINX Plus se pueden configurar para escuchar en un intervalo de puertos, por ejemplo, 80‑90. Esto permite que NGINX Plus sea compatible con una gama más amplia de aplicaciones, como FTP pasivo, que requieren reservar intervalos de puertos.
• Definición de pares clave-valor en la configuración – El almacén de pares clave-valor de NGINX Plus permite implementar soluciones para una amplia variedad de casos de uso, como la inclusión dinámica de direcciones IP en listas de bloqueo y la mitigación dinámica de ataques DDoS. Ahora puede crear pares clave-valor directamente mediante variables en la configuración de NGINX Plus, lo que amplía aún más los casos de uso posibles.
• Mayor flexibilidad para las comprobaciones de estado activas – Las comprobaciones de estado activas de NGINX Plus son una potente herramienta para supervisar el estado de los sistemas backend. Con NGINX Plus R18, ahora puede comprobar el valor de cualquier variable de NGINX y cerrar automáticamente las conexiones TCP existentes con los servidores que hayan fallado.

Para completar esta versión se incluyen una configuración simplificada para entornos en clúster y módulos dinámicos nuevos y actualizados (incluido Brotli). Las actualizaciones del ecosistema NGINX Plus incluyen una organización modular del código con el módulo JavaScript de NGINX y la instalación directa mediante Helm del controlador de entrada oficial de NGINX para Kubernetes.

Cambios importantes en el comportamiento

• API obsoletas – NGINX Plus R13 (agosto de 2017) introdujo la API de NGINX Plus completamente nueva para recopilar métricas y reconfigurar dinámicamente grupos de servidores upstream, en sustitución de las API Status y Upstream Conf que antes 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 R18. Para obtener asesoramiento 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.
• Directiva listen actualizada – Anteriormente, cuando la directiva listen especificaba un nombre de host que se resolvía en varias direcciones IP, solo se utilizaba la primera. Ahora se crea un socket de escucha para cada dirección IP devuelta.
• Cambios en el módulo JavaScript de NGINX (njs) – Se ha eliminado el objeto obsoleto req.response del módulo JavaScript de NGINX. Las funciones declaradas mediante la sintaxis function(req,res) que también hacen referencia a propiedades del objeto res generan errores en tiempo de ejecución, devuelven el código de estado HTTP 500 y crean la correspondiente entrada en el registro de errores:

YYYY/MM/DD hh:mm:ss [error] 34#34: js exception: TypeError: cannot get property "return" of undefined

• Dado que el código JavaScript se interpreta en tiempo de ejecución, el comando de validación sintáctica nginx -t no detecta la presencia de objetos y propiedades no válidos. Debe revisar detenidamente el código JavaScript y eliminar dichos objetos antes de actualizar a NGINX Plus R18. Además, los objetos JavaScript que representan el estado de NGINX (por ejemplo, r.headersIn) ahora devuelven undefined en lugar de una cadena vacía cuando una propiedad determinada no tiene ningún valor. Este cambio implica que los objetos JavaScript específicos de NGINX ahora se comportan igual que los objetos JavaScript integrados.
• Sistemas operativos antiguos eliminados o que se eliminarán:
  • Amazon Linux 2017.09 ya no es compatible; la versión compatible más antigua es ahora la 2018.03
  • CentOS/Oracle Linux/Red Hat Enterprise Linux 7.3 ya no es compatible; la versión más antigua compatible ahora es la 7.4
  • Debian 8.0 se eliminará en NGINX Plus R19
  • Ubuntu 14.04 dejará de ser compatible con NGINX Plus R19

Nuevas funcionalidades en detalle

Carga dinámica de certificados SSL/TLS

En versiones anteriores de NGINX Plus, el enfoque habitual para gestionar los certificados SSL/TLS de sitios y aplicaciones seguros consistía en crear un bloque server independiente para cada nombre de host y especificar de forma estática el certificado y la clave privada asociada como archivos en disco. (Para facilitar la lectura, a partir de ahora utilizaremos certificado para referirnos al conjunto formado por el certificado y la clave). Los certificados se cargaban al iniciarse NGINX Plus. Con NGINX Plus R18, los certificados pueden cargarse dinámicamente y, de forma opcional, almacenarse en el almacén de clave-valor en memoria de NGINX Plus en lugar de en disco.

Hay dos casos de uso principales para la carga dinámica de certificados:

• «Carga diferida» de certificados desde el disco
• Almacenamiento de certificados en memoria

En ambos casos, NGINX Plus puede cargar certificados dinámicamente en función del nombre de host proporcionado mediante la indicación del nombre del servidor (SNI) como parte del protocolo de enlace TLS. Esto permite que NGINX Plus aloje varios sitios web seguros con una única configuración de servidor y seleccione bajo demanda el certificado adecuado para cada solicitud entrante.

Carga diferida de certificados SSL/TLS desde el disco

Con la «carga diferida», los certificados SSL/TLS se cargan en memoria únicamente a medida que llegan solicitudes que especifican el nombre de host correspondiente. Esto simplifica la configuración (al eliminar la lista de certificados por nombre de host) y reduce el uso de recursos del host. Cuando hay una gran cantidad de certificados (muchos miles), leerlos todos del disco y cargarlos en memoria puede tardar varios segundos. Además, al recargar la configuración de NGINX se utiliza una gran cantidad de memoria, ya que el nuevo conjunto de procesos de trabajo carga en memoria una nueva copia de los certificados, además de los certificados cargados por el conjunto anterior de procesos de trabajo. Los certificados anteriores permanecen en memoria hasta que finaliza la última conexión establecida con la configuración antigua y se terminan los procesos de trabajo anteriores. Si la configuración se actualiza con frecuencia y las conexiones de los clientes son de larga duración, puede haber varias copias de los certificados en memoria, lo que podría provocar que esta se agote.

La carga diferida de certificados desde el disco es ideal para implementaciones con un gran número de certificados o en las que la configuración se recarga con frecuencia. Por ejemplo, las empresas de SaaS suelen asignar un subdominio independiente a cada cliente. Incorporar nuevos clientes resulta complicado porque hay que crear un nuevo servidor virtual para cada uno y, a continuación, copiar la nueva configuración y el certificado del cliente en cada instancia de NGINX Plus. La carga diferida elimina la necesidad de modificar la configuración: basta con implementar los certificados en cada instancia y listo.

Para admitir la carga diferida, las directivas ssl_certificate y ssl_certificate_key ahora aceptan parámetros variables. La variable debe estar disponible durante el procesamiento de SNI, que tiene lugar antes de que se lean la línea de solicitud y las cabeceras. La variable más utilizada es $ssl_server_name, que contiene el nombre de host extraído por NGINX Plus durante el procesamiento de SNI. El certificado y la clave se leen del disco durante el protocolo de enlace TLS al inicio de cada sesión de cliente y se almacenan en memoria en la caché del sistema de archivos, lo que reduce aún más el uso de memoria.

La configuración de un sitio seguro pasa a ser tan sencilla como esta:

Cargando ejemplo de código…

Esta misma configuración de «server» se puede utilizar para un número ilimitado de sitios seguros. Esto ofrece dos ventajas:

1. Elimina el bloque server independiente para cada nombre de host, lo que reduce considerablemente la configuración y facilita su lectura y gestión.
2. Elimina la necesidad de volver a cargar la configuración cada vez que se añade un nuevo nombre de host. Cuando es necesario volver a cargarla, el proceso es mucho más rápido porque NGINX Plus no carga todos los certificados.

Tenga en cuenta que la carga diferida hace que el protocolo de enlace TLS tarde entre un 20 % y un 30 % más, dependiendo del entorno, debido a las llamadas al sistema de archivos necesarias para recuperar el certificado del disco. Sin embargo, la latencia adicional solo afecta al protocolo de enlace: una vez establecida la sesión TLS, el procesamiento de las solicitudes tarda lo habitual.

Almacenamiento en memoria de certificados SSL/TLS

Ahora puede almacenar los datos de los certificados SSL/TLS en memoria, en el almacén de pares clave-valor de NGINX Plus, además de en archivos del disco. Cuando el parámetro de la directiva ssl_certificate o ssl_certificate_key comienza con el prefijo data:, NGINX Plus interpreta el parámetro como datos PEM sin procesar (proporcionados en forma de una variable que identifica la entrada del almacén de pares clave-valor donde residen realmente los datos).

Otra ventaja de almacenar los datos en el almacén de clave-valor en lugar de hacerlo en disco es que las imágenes de despliegue y las copias de seguridad dejan de incluir copias de la clave privada, que un atacante podría utilizar para descifrar todo el tráfico enviado al servidor y procedente de este. Las empresas con canalizaciones de despliegue altamente automatizadas se benefician de la flexibilidad que ofrece la API de NGINX Plus para insertar certificados mediante programación en el almacén de clave-valor. Además, las empresas que migran aplicaciones a un entorno de nube pública en el que no existe un módulo de seguridad de hardware (HSM) real para proteger las claves privadas se benefician de la seguridad adicional que supone no almacenar dichas claves en disco.

A continuación se muestra un ejemplo de configuración para cargar certificados desde el almacén de clave-valor:

Cargando ejemplo de código…

Una forma de cargar certificados y claves privadas en el almacén de clave-valor mediante la API de NGINX Plus es ejecutar el siguiente comando curl (solo se muestra el principio de los datos de la clave). Si utiliza el comando curl, recuerde hacer una copia de los datos PEM y sustituir cada salto de línea por \n; de lo contrario, los saltos de línea se eliminan de la carga útil JSON.

$ curl -d '{"www.example.com":"-----BEGIN RSA PRIVATE KEY-----\n..."}' http://localhost:8080/api/4/http/keyvals/ssl_key

Usar el almacén de clave-valor para los certificados es ideal en las implementaciones en clúster de NGINX Plus, ya que basta con cargar el certificado una sola vez para que se propague automáticamente por todo el clúster. Para proteger los propios datos del certificado, utilice la directiva zone_sync_ssl para cifrar mediante TLS las conexiones entre los miembros del clúster. El almacén de clave-valor también es ideal para certificados de corta duración o para automatizar integraciones con emisores de certificados como Let’s Encrypt y Hashicorp Vault.

Al igual que ocurre con la carga diferida desde el disco, los certificados se cargan desde el almacén de clave-valor durante cada protocolo de enlace TLS, lo que afecta al rendimiento. Para que los protocolos de enlace TLS sean lo más rápidos posible, utilice las directivas ssl_certificate y ssl_certificate_key con un parámetro fijo que apunte a un archivo del disco. Además, los certificados ECC son más rápidos que los certificados RSA.

Tenga en cuenta que, aunque el almacén de clave-valor dificulta que un atacante obtenga los archivos de claves privadas en comparación con el almacenamiento en disco, un atacante con acceso al shell del host de NGINX Plus podría seguir teniendo acceso a las claves cargadas en memoria. El almacén de clave-valor no protege las claves privadas en la misma medida que un módulo de seguridad de hardware (HSM); para que NGINX Plus obtenga las claves de un HSM, utilice el parámetro engine:engine-name:key-id de la directiva ssl_certificate_key.

Mejoras de OpenID Connect

NGINX Plus admite la autenticación mediante OpenID Connect y el inicio de sesión único para aplicaciones de backend a través de nuestra implementación de referencia. Esta solución se ha simplificado y mejorado, ya que ahora el almacén de pares clave-valor se puede modificar directamente desde el módulo JavaScript mediante variables (véase más abajo).

La implementación de referencia de OpenID Connect ahora proporciona a los clientes tokens de sesión opacos en forma de cookie del navegador. Los tokens opacos no contienen información de identificación personal del usuario, por lo que no se almacena información confidencial en el cliente. NGINX Plus almacena el token de ID real en el almacén de clave-valor y lo sustituye por el token opaco que presenta el cliente. La validación del JWT se realiza en cada solicitud para rechazar los tokens caducados o no válidos.

La implementación de referencia de OpenID Connect ahora también admite tokens de actualización, de modo que los tokens de ID caducados se renuevan de forma transparente sin necesidad de que el usuario intervenga. NGINX Plus almacena el token de actualización enviado por un servidor de autorización en el almacén de pares clave-valor y lo asocia al token de sesión opaco. Cuando caduca el token de ID, NGINX Plus devuelve el token de actualización al servidor de autorización. Si la sesión sigue siendo válida, el servidor de autorización emite un nuevo token de ID, que se actualiza de forma transparente en el almacén de pares clave-valor. Los tokens de actualización permiten utilizar tokens de ID de corta duración, lo que mejora la seguridad sin causar molestias a los usuarios.

La implementación de referencia de OpenID Connect ahora proporciona una URL para cerrar sesión. Cuando los usuarios que han iniciado sesión acceden al URI /logout, sus tokens de ID y de actualización se eliminan del almacén de clave-valor, y deben volver a autenticarse cuando realicen una solicitud posterior.

Rangos de puertos para servidores virtuales

Un bloque server suele tener una única directiva listen que especifica el puerto en el que escucha NGINX Plus; si es necesario configurar varios puertos, se añade una directiva listen por cada uno de ellos. Con NGINX Plus R18, ahora también se pueden especificar rangos de puertos, por ejemplo, 80‑90, cuando no resulta práctico especificar un gran número de directivas listen individuales.

Se pueden especificar intervalos de puertos tanto para la directiva listen de HTTP como para la directiva listen de TCP/UDP (Stream). La siguiente configuración permite que NGINX Plus actúe como proxy de un servidor FTP en modo pasivo, donde el puerto de datos se elige de entre un amplio intervalo de puertos TCP.

Cargando ejemplo de código…

Esta configuración crea un servidor virtual para redirigir las conexiones al servidor FTP a través del mismo puerto por el que se recibieron.

Actualización del almacén de clave-valor mediante variables

Cuando el almacén de clave-valor está habilitado, NGINX Plus proporciona una variable para los valores almacenados en él en función de una clave de entrada (normalmente, una parte de los metadatos de la solicitud). Anteriormente, la única forma de crear, modificar o eliminar valores del almacén de clave-valor era mediante la API de NGINX Plus. Con NGINX Plus R18, puede cambiar el valor de una clave directamente en la configuración estableciendo la variable que contiene el valor.

En el siguiente ejemplo se utiliza el almacén de clave-valor para mantener una lista de las direcciones IP de los clientes que han accedido recientemente al sitio, junto con el último URI que solicitaron.

Cargando ejemplo de código…

La directiva set (línea 7) asigna un valor ($last_uri) a cada dirección IP de cliente ($remote_addr); crea una nueva entrada si no existe o modifica el valor para reflejar el $uri de la solicitud actual. De este modo, la lista actual de clientes recientes y de los URI que han solicitado está disponible mediante una llamada a la API de NGINX Plus:

$ curl http://localhost:8080/api/4/http/keyvals/recents{
  "10.19.245.68": "/blog/nginx-plus-r18-released/",
  "172.16.80.227": "/products/nginx/",
  "10.219.110.168": "/blog/nginx-unit-1-8-0-now-available"
}

Se pueden implementar casos de uso más avanzados mediante extensiones de scripting como el módulo JavaScript de NGINX (njs) y el módulo Lua. Cualquier configuración que utilice njs tiene acceso a todas las variables, incluidas las respaldadas por el almacén de clave-valor, por ejemplo, r.variables.last_uri.

Mayor flexibilidad para las comprobaciones de estado activas

Las comprobaciones de estado activas de NGINX Plus prueban periódicamente los sistemas backend para evitar que el tráfico se dirija a sistemas que se sabe que no funcionan correctamente. NGINX Plus R18 amplía esta importante función con dos capacidades adicionales.

• Compatibilidad con la comprobación de variables arbitrarias en las comprobaciones de estado
• Capacidad para finalizar sesiones TCP cuando falla la comprobación de estado

Comprobación de variables arbitrarias en las comprobaciones de estado

Al definir una comprobación de estado para una aplicación de backend, puede utilizar un bloque match para especificar el valor esperado de varios aspectos de la respuesta, incluidos el código de estado HTTP y las cadenas de caracteres de las cabeceras o el cuerpo de la respuesta. Cuando la respuesta incluye todos los valores esperados, el backend se considera en buen estado.

Para comprobaciones aún más complejas, NGINX Plus R18 incorpora ahora la directiva require para comprobar el valor de cualquier variable, tanto las variables estándar de NGINX como las que usted declare. Esto le ofrece más flexibilidad a la hora de definir comprobaciones de estado, ya que las variables se pueden evaluar mediante bloques map, expresiones regulares e incluso extensiones de scripting.

La directiva require dentro de un bloque match especifica una o varias variables, todas las cuales deben tener un valor distinto de cero para que la prueba se supere. La siguiente configuración de ejemplo define como servidor ascendente en buen estado aquel que devuelve encabezados que indican que la respuesta se puede almacenar en caché: un encabezado Expires con un valor distinto de cero o un encabezado Cache-Control.

Cargando ejemplo de código…

El uso de bloques map de esta forma es una manera habitual de incorporar la lógica OR en la configuración de NGINX Plus. La directiva require permite aprovechar esta técnica en las comprobaciones de estado, así como realizar comprobaciones de estado avanzadas. También se pueden definir comprobaciones de estado avanzadas mediante el módulo JavaScript (njs) para analizar atributos adicionales de las respuestas de cada servidor ascendente, como el tiempo de respuesta.

Finalización de conexiones de capa 4 cuando fallan las comprobaciones de estado

Cuando NGINX Plus actúa como equilibrador de carga de capa 4 (L4) para aplicaciones TCP/UDP, transmite los datos en ambas direcciones a través de la conexión establecida entre el cliente y el servidor backend. Las comprobaciones de estado activas son una parte importante de este tipo de configuración, pero, de forma predeterminada, el estado de un servidor backend solo se tiene en cuenta cuando un nuevo cliente intenta establecer una conexión. Si un servidor backend deja de estar disponible, los clientes que ya tengan una conexión establecida podrían experimentar un tiempo de espera agotado al enviar datos al servidor.

Con la directiva proxy_session_drop, incorporada en NGINX Plus R18, puede cerrar inmediatamente la conexión cuando se reciba el siguiente paquete del servidor sin conexión o se le envíe uno. El cliente se ve obligado a volver a conectarse, momento en el que NGINX Plus redirige sus solicitudes a un servidor backend en buen estado.

Cuando esta directiva está habilitada, hay otras dos condiciones que también provocan la finalización de las conexiones existentes: el fallo de una comprobación de estado activa y la eliminación del servidor de un grupo de servidores ascendentes por cualquier motivo. Esto incluye la eliminación mediante una consulta DNS, cuando un servidor backend se define mediante un nombre de host con varias direcciones IP, como las proporcionadas por un registro de servicios.

Otras mejoras de NGINX Plus R18

Configuración simplificada de clústeres

NGINX Plus admite la sincronización del estado de ejecución en todo el clúster desde NGINX Plus R15. Actualmente, el módulo Sincronización de zonas permite compartir datos de estado sobre sesiones persistentes, limitación de velocidad, y el almacén de clave-valor en una implementación en clúster de instancias de NGINX Plus.

Ahora se puede utilizar una única configuración de zone_sync para todas las instancias de un clúster. Antes, había que configurar explícitamente la dirección IP o el nombre de host de cada miembro, lo que implicaba que cada instancia tuviera una configuración ligeramente distinta. Ahora puede hacer que el servidor zone_sync escuche en todas las interfaces locales especificando un valor comodín para el parámetro dirección:puerto de la directiva listen. Esto resulta especialmente útil al implementar NGINX Plus en un clúster dinámico en el que la dirección IP de la instancia no se conoce hasta el momento de la implementación.

Usar la misma configuración en todas las instancias simplifica enormemente la implementación en entornos dinámicos (por ejemplo, con grupos de escalado automático o clústeres en contenedores).

Módulos dinámicos nuevos y actualizados

En esta versión se han añadido o actualizado los siguientes módulos dinámicos:

• Nuevo módulo de compresión Brotli – Brotli es un algoritmo de compresión de datos sin pérdida y de uso general que utiliza una variante del algoritmo LZ77, codificación Huffman y modelado de contexto de segundo orden.
• Nuevo módulo OpenTracing – Ahora puede instrumentar NGINX Plus con solicitudes compatibles con OpenTracing para diversos servicios de rastreo distribuido, como Datadog, Jaeger y Zipkin.
• Módulo de Lua actualizado : Lua es un lenguaje de scripting para NGINX Plus. El módulo ahora utiliza LuaJIT 2.1.

Actualizaciones del ecosistema de NGINX Plus

Mejoras en el módulo JavaScript de NGINX

El módulo JavaScript de NGINX (njs) se ha actualizado a la versión 0.3.0. La mejora más destacada es la compatibilidad con los módulos import y export de JavaScript, que permite organizar el código JavaScript en varios archivos específicos para cada función. Anteriormente, todo el código JavaScript tenía que estar en un único archivo.

El siguiente ejemplo muestra cómo se pueden utilizar los módulos de JavaScript para organizar y simplificar el código necesario para un caso de uso relativamente sencillo. En este caso, utilizamos JavaScript para aplicar el enmascaramiento de datos para proteger la privacidad del usuario de modo que se registre una versión con hash (enmascarada) de la dirección IP del cliente en lugar de la dirección real. Una dirección IP enmascarada concreta siempre representa al mismo cliente en el registro, pero no se puede convertir de nuevo en la dirección IP real.

[Editor – El ejemplo de esta sección es solo uno de los muchos casos de uso del módulo JavaScript de NGINX. Para consultar la lista completa, consulte Casos de uso del módulo JavaScript de NGINX.

El código se ha actualizado para usar la js_import directiva, 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 – la sección Configuración de ejemplo muestra la sintaxis correcta para los archivos de configuración de NGINX y JavaScript.

En NGINX Plus R22 y versiones posteriores, además de los módulos de JavaScript import y export, puede utilizar la directiva de njs js_import para organizar el código JavaScript en varios archivos específicos para cada función.]

Incluimos las funciones necesarias para enmascarar direcciones IP en un módulo de JavaScript que exporta una única función, maskIp(). La función exportada depende de funciones privadas que solo están disponibles dentro del módulo y que no pueden invocarse desde otro código JavaScript.

Cargando ejemplo de código…

Ahora se puede importar este módulo en el archivo JavaScript principal (main.js) y hacer referencia a las funciones exportadas.

Cargando ejemplo de código…

Como resultado, main.js es muy sencillo, ya que solo contiene las funciones a las que hace referencia la configuración de NGINX. La instrucción import especifica una ruta relativa o absoluta al archivo del módulo. Cuando se proporciona una ruta relativa, puede utilizar la nueva directiva js_path para especificar rutas adicionales en las que buscar.

Cargando ejemplo de código…

Las nuevas funcionalidades mejoran considerablemente la legibilidad y el mantenimiento, especialmente cuando se utiliza un gran número de directivas njs o hay una gran cantidad de código JavaScript. Ahora, los distintos equipos pueden mantener su propio código JavaScript sin necesidad de realizar una fusión compleja con el archivo JavaScript principal.

Instalación directa mediante Helm de NGINX Ingress Controller para Kubernetes

Ahora puede instalar NGINX Ingress Controller para Kubernetes directamente desde nuestro nuevo repositorio de Helm, sin necesidad de descargar los archivos fuente del chart de Helm (aunque esta opción sigue siendo compatible). Para obtener más información, consulte el repositorio de GitHub.

Correcciones de errores destacadas

Límites de ancho de banda para aplicaciones UDP

Las directivas proxy_upload_rate y proxy_download_rate ahora funcionan correctamente con los datagramas UDP.

El TLV del protocolo PROXY con comprobación de estado provoca el bloqueo de NGINX

Anteriormente, NGINX Plus podía bloquearse cuando la directiva health_check se incluía en una ubicación que hacía referencia a la variable $proxy_protocol_tlv_0xEA, por ejemplo, en un entorno de AWS PrivateLink.

El balanceo de carga por menor tiempo ignoraba el servidor upstream más lento

Anteriormente, si un servidor ascendente respondía con suficiente lentitud durante un periodo prolongado, podía no volver a seleccionarse nunca, ya que su valor para la métrica de tiempo especificada era muy alto en comparación con el de otros servidores ascendentes. Ahora, los servidores ascendentes que antes eran lentos acaban reincorporándose al proceso de selección del equilibrador de carga a medida que las nuevas mediciones permiten reducir la media móvil.

Esto se aplica a los algoritmos de balanceo de carga que utilizan el tiempo de respuesta del servidor ascendente como métrica de selección, concretamente least_time y random con el parámetro least_time.

Actualice o pruebe NGINX Plus

Si utiliza NGINX Plus, le recomendamos encarecidamente que actualice a NGINX Plus R18 lo antes posible. También obtendrá varias correcciones y mejoras adicionales, y facilitará que NGINX, Inc. 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 avanzadas de supervisión y gestión. Puede empezar hoy mismo 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