Anunciamos NGINX Plus R18

Nos complace anunciar que NGINX Plus Release 18 (R18) 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. R18 simplifica los flujos de trabajo de configuración para DevOps y mejora la seguridad y confiabilidad de sus aplicações a 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 apenas tres años. De extremo a extremo El cifrado es ahora el patrón de implementación predeterminado para sitios web y aplicações, y la explosión de los certificados SSL/TLS significa que algunas empresas están administrando miles de certificados en entornos de producción. Esto requiere un enfoque más flexible para implementar y configurar certificados.

Una novedad en esta versión es la compatibilidad con la carga dinámica de certificados . Con miles de certificados, no es escalable definir cada uno manualmente en la configuración para cargar desde el disco: el proceso no solo es tedioso, sino que la configuración se vuelve inmanejablemente grande y el inicio de NGINX Plus inaceptablemente lento. Con NGINX Plus R18 , los certificados SSL/TLS ahora se pueden cargar a pedido sin necesidad de enumerarlos individualmente en la configuración. Para simplificar aún más las implementaciones automatizadas, los certificados se pueden aprovisionar con la API NGINX Plus y ni siquiera tienen que estar en el disco.

Las nuevas características adicionales de NGINX Plus R18 incluyen:

• Mejoras de OpenID Connect : continuamos mejorando nuestra implementación de referencia compatible con OpenID Connect, lanzada originalmente en NGINX Plus R15 . En esta versión, hemos agregado soporte para tokens de sesión opacos, tokens de actualización y una URL de cierre de sesión.
• Rangos de puertos para servidores virtuales : los servidores virtuales NGINX Plus ahora se pueden configurar para escuchar en un rango de puertos, por ejemplo, 80-90 . Esto permite que NGINX Plus admita una gama más amplia de aplicações, como FTP pasivo, que requieren que se reserven rangos de puertos.
• Definición de valor clave en la configuración : el almacén de valor clave NGINX Plus permite soluciones para una amplia gama de casos de uso, incluida la lista negra dinámica de direcciones IP y la mitigación dinámica de DDoS. Ahora puede crear pares clave-valor directamente con variables en la configuración de NGINX Plus, lo que abre aún más casos de uso.
• Mayor flexibilidad para los controles de estado activo : los controles de estado activo de NGINX Plus son una herramienta poderosa para monitorear el estado de los sistemas backend. Con NGINX Plus R18 , ahora puede probar el valor de cualquier variable NGINX y apagar automáticamente las conexiones TCP existentes a los servidores fallidos.

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 la organización del código modular con el módulo JavaScript de NGINX y la instalación directa de Helm del controlador de ingreso oficial de NGINX para Kubernetes.

Cambios importantes en el comportamiento

• API obsoletas : NGINX Plus R13 (agosto de 2017) introdujo la nueva API NGINX Plus 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 y/o upstream_conf , debe reemplazarlas con la directiva api como parte de la actualización a R18.

  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.

• Directiva de escucha actualizada : anteriormente, cuando la directiva de escucha especificaba un nombre de host que se resolvía en múltiples direcciones IP, solo se usaba la primera dirección IP. Ahora se crea un socket de escucha para cada dirección IP devuelta.

• Cambios en el módulo JavaScript de NGINX (njs) : el objeto req.response obsoleto se ha eliminado 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 de tiempo de ejecución y devuelven un código de estado HTTP.500 y una entrada correspondiente en el registro de errores:

  AAAA / MM / DD hh : mm : ss [error] 34#34: excepción js: TypeError: no se puede obtener la propiedad "return" de 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 verificar cuidadosamente su 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 la cadena vacía cuando no hay ningún valor para una propiedad determinada. Este cambio significa que los objetos JavaScript específicos de NGINX ahora se comportan de la misma manera que los objetos JavaScript integrados.

• Sistemas operativos antiguos eliminados o que se eliminarán:

  • Amazon Linux 2017.09 ya no recibe soporte; la versión compatible más antigua ahora es 2018.03
  • CentOS/Oracle Linux/Red Hat Enterprise Linux 7.3 ya no recibe soporte; la versión compatible más antigua ahora es 7.4
  • Debian 8.0 se eliminará en NGINX Plus R19
  • Ubuntu 14.04 se eliminará en NGINX Plus R19

Nuevas funciones en detalle

Carga dinámica de certificados SSL/TLS

Con versiones anteriores de NGINX Plus, el enfoque típico para administrar certificados SSL/TLS para sitios y aplicações seguros era crear un bloque de servidor separado para cada nombre de host, especificando estáticamente el certificado y la clave privada asociada como archivos en el disco. (Para facilitar la lectura, de ahora en adelante utilizaremos certificado para referirnos al certificado y la clave emparejados). Luego se cargaron los certificados cuando se inició NGINX Plus. Con NGINX Plus R18 , los certificados se pueden cargar dinámicamente y, opcionalmente, almacenar en el almacén de clave-valor en memoria de NGINX Plus en lugar de en el 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 la memoria

En ambos casos, NGINX Plus puede realizar una carga dinámica de certificados según el nombre de host proporcionado por Server Name Indication (SNI) como parte del protocolo de enlace TLS. Esto permite que NGINX Plus aloje múltiples sitios web seguros bajo una única configuración de servidor y seleccione el certificado apropiado a pedido para cada solicitud entrante.

Carga diferida de certificados SSL/TLS desde el disco

Con la “carga diferida”, los certificados SSL/TLS se cargan en la memoria solo cuando llegan las solicitudes y especifican el nombre de host correspondiente. Esto simplifica la configuración (al eliminar la lista de certificados por nombre de host) y reduce la utilización de recursos en el host. Con una gran cantidad (muchos miles) de certificados, puede llevar varios segundos leerlos todos desde el disco y cargarlos en la memoria. Además, se utiliza una gran cantidad de memoria cuando se vuelve a cargar la configuración de NGINX, porque el nuevo conjunto de procesos de trabajo carga una nueva copia de los certificados en la memoria, junto con los certificados cargados por el conjunto anterior de procesos de trabajo. Los certificados anteriores permanecen en la memoria hasta que se complete la conexión final establecida bajo la configuración anterior y se finalicen los trabajadores anteriores. Si la configuración se actualiza con frecuencia y las conexiones del cliente son de larga duración, puede haber varias copias de los certificados en la memoria, lo que podría provocar un agotamiento de la memoria.

La carga diferida de certificados desde el disco es ideal para implementaciones con grandes cantidades de certificados y/o cuando las recargas de configuración son frecuentes. Por ejemplo, las empresas de SaaS comúnmente asignan un subdominio separado a cada cliente. La incorporación de nuevos clientes es difícil porque hay que crear un nuevo servidor virtual para cada uno y luego copiar la nueva configuración y el certificado del cliente en cada instancia de NGINX Plus. La carga diferida elimina la necesidad de realizar cambios de configuración: simplemente implemente 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 ocurre antes de que se lean la línea de solicitud y los encabezados. 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 desde el disco durante el protocolo de enlace TLS al comienzo de cada sesión de cliente y se almacenan en la memoria caché del sistema de archivos, lo que reduce aún más la utilización de la memoria.

Configurar un sitio seguro se vuelve tan simple como esto:

Esta misma configuración de servidor se puede utilizar para un número ilimitado de sitios seguros. Esto tiene dos beneficios:

1. Elimina el bloque de servidor separado para cada nombre de host, lo que hace que la configuración sea mucho más pequeña y, por lo tanto, más fácil de leer y administrar.
2. Elimina la necesidad de recargar la configuración cada vez que se agrega un nuevo nombre de host. Cuando es necesario recargar la configuración, 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, según el entorno, debido a las llamadas al sistema de archivos necesarias para recuperar el certificado del disco. Sin embargo, la latencia adicional afecta solo al protocolo de enlace: una vez que se establece la sesión TLS, el procesamiento de la solicitud toma el tiempo habitual.

Almacenamiento de certificados SSL/TLS en memoria

Ahora puede almacenar datos de certificados SSL/TLS en la memoria, en el almacén de clave-valor NGINX Plus, así como en archivos en el 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 en el almacén de valores clave donde residen realmente los datos).

Un beneficio adicional del almacenamiento en el almacén de clave-valor en lugar de en el disco es que las imágenes de implementación y las copias de seguridad ya no incluyen copias de la clave privada, que un atacante puede usar para descifrar todo el tráfico enviado hacia y desde el servidor. Las empresas con canales de implementación automatizada se benefician de la flexibilidad de poder usar la API NGINX Plus para insertar certificados de manera programada en el almacén de clave-valor. Además, las empresas que migran aplicações a un entorno de nube pública donde no hay un módulo de seguridad de hardware (HSM) real para la protección de claves privadas se benefician de la seguridad adicional de no almacenar claves privadas en el disco.

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

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

$ curl -d '{"www.ejemplo.com":"-----INICIO CLAVE PRIVADA RSA-----\n..."}' http://localhost:8080/api/4/http/keyvals/ssl_key

El uso del almacén de valores clave para certificados es ideal para implementaciones en clúster de NGINX Plus, porque se carga el certificado solo una vez para la propagación automática en el clúster. Para proteger los datos del certificado, utilice la directiva zone_sync_ssl para cifrar mediante TLS las conexiones entre los miembros del clúster. El uso del 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 con la carga diferida desde el disco, la carga de certificados desde el almacén de clave-valor ocurre durante cada protocolo de enlace TLS, lo que genera una penalización en el rendimiento. Para obtener los protocolos de enlace TLS más rápidos, utilice las directivas ssl_certificate y ssl_certificate_key con un parámetro codificado en un archivo en el disco. Además, los certificados ECC son más rápidos que los certificados RSA.

Tenga en cuenta que, si bien el almacén de clave-valor hace que sea más difícil para un atacante obtener archivos de clave privada que desde el almacenamiento en disco, un atacante con acceso de shell al host NGINX Plus aún podría acceder a las claves cargadas en la memoria. El almacén de valores clave no protege las claves privadas en la misma medida que un módulo de seguridad de hardware (HSM); para que NGINX Plus obtenga claves de un HSM, utilice el parámetro engine: engine-name : key-id en la directiva ssl_certificate_key .

Mejoras de OpenID Connect

NGINX Plus admite la autenticación OpenID Connect y el inicio de sesión único para aplicações backend a través de nuestra implementación de referencia . Esto se ha simplificado y mejorado ahora que el almacén de valores clave se puede modificar directamente desde el módulo JavaScript usando variables ( ver a continuación ).

La implementación de referencia de OpenID Connect ahora emite 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 sobre el usuario, por lo que no se almacena información confidencial en el cliente. NGINX Plus almacena el token de identificación real en el almacén de clave-valor y lo sustituye por el token opaco que presenta el cliente. La validación JWT se realiza para cada solicitud de modo que se rechacen los tokens vencidos o no válidos.

La implementación de referencia de OpenID Connect ahora también admite tokens de actualización para que los tokens de identificación vencidos se actualicen sin problemas sin necesidad de interacción del usuario. NGINX Plus almacena el token de actualización enviado por un servidor de autorización en el almacén de clave-valor y lo asocia con el token de sesión opaco. Cuando el token de identificación expira, NGINX Plus envía 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 identificación, que se actualiza sin problemas en el almacén de clave-valor. Los tokens de actualización permiten utilizar tokens de identificación de corta duración, lo que proporciona mayor seguridad sin incomodar a los usuarios.

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

Rangos de puertos para servidores virtuales

Un bloque de servidor normalmente tiene una directiva de escucha que especifica el puerto único en el que NGINX Plus escucha; si es necesario configurar varios puertos, hay una directiva de escucha adicional para cada uno de ellos. Con NGINX Plus R18 , ahora también puede especificar rangos de puertos, por ejemplo 80‑90 , cuando no es conveniente especificar una gran cantidad de directivas de escucha individuales.

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

Esta configuración configura un servidor virtual para realizar conexiones proxy al servidor FTP en el mismo puerto por el que entró la conexión.

Actualización del almacén de valores clave mediante variables

Cuando el almacén de valores clave está habilitado, NGINX Plus proporciona una variable para los valores almacenados allí 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 en el 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, configurando la variable que lo contiene.

El siguiente ejemplo utiliza el almacén de valores clave para mantener una lista de direcciones IP de clientes que accedieron recientemente al sitio, junto con la última URI que solicitaron.

La directiva de conjunto (línea 7) asigna un valor ( $last_uri ) para cada dirección IP de cliente ( $remote_addr ), creando una nueva entrada si está ausente o modificando el valor para reflejar el $uri de la solicitud actual. De esta forma, la lista actual de clientes recientes y sus URI solicitados está disponible con una llamada a la API NGINX Plus :

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

Se pueden lograr casos de uso más potentes con 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 aquellas respaldadas por el almacén de clave-valor, por ejemplo r.variables.last_uri .

Mayor flexibilidad para los controles de salud activos

Las comprobaciones de estado activo de NGINX Plus prueban de forma rutinaria los sistemas backend, de modo que el tráfico no se dirija a sistemas que se sabe que no funcionan correctamente. NGINX Plus R18 amplía esta importante característica con dos capacidades adicionales.

• Soporte para probar variables arbitrarias en controles de estado
• Capacidad de finalizar sesiones TCP en caso de fallo de la comprobación de estado

Prueba de variables arbitrarias en controles de salud

Al definir una comprobación de estado para una aplicação backend, puede utilizar un bloque de coincidencia para especificar el valor esperado para múltiples aspectos de la respuesta, incluido el código de estado HTTP y las cadenas de caracteres en los encabezados y/o el cuerpo de la respuesta. Cuando la respuesta incluye todos los valores esperados, el backend se considera saludable.

Para verificaciones aún más complejas, NGINX Plus R18 ahora proporciona la directiva require para probar el valor de cualquier variable, tanto las variables NGINX estándar como las variables que usted declare. Esto le brinda más flexibilidad al definir controles de estado porque las variables se pueden evaluar con bloques de mapas , expresiones regulares e incluso extensiones de scripts.

La directiva require dentro de un bloque match especifica una o más variables, todas las cuales deben tener un valor distinto de cero para que la prueba pase. La siguiente configuración de ejemplo define un servidor ascendente saludable como uno que devuelve encabezados que indican que la respuesta se puede almacenar en caché, ya sea un encabezado Expires con un valor distinto de cero o un encabezado Cache-Control .

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

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

Cuando NGINX Plus actúa como un balanceador de carga de capa 4 (L4) para aplicações TCP/UDP, envía datos en ambas direcciones en la conexión establecida entre el cliente y el servidor back-end. Las comprobaciones de estado activas son una parte importante de dicha configuración, pero de manera predeterminada, el estado de estado de un servidor backend solo se considera cuando un nuevo cliente intenta establecer una conexión. Si un servidor backend se desconecta, los clientes establecidos pueden experimentar un tiempo de espera cuando envían datos al servidor.

Con la directiva proxy_session_drop , nueva en NGINX Plus R18 , puede cerrar inmediatamente la conexión cuando se recibe o envía el siguiente paquete desde el servidor fuera de línea. El cliente se ve obligado a reconectarse, momento en el cual NGINX Plus envía sus solicitudes a un servidor backend en buen estado.

Cuando esta directiva está habilitada, otras dos condiciones también desencadenan la terminación de las conexiones existentes: falla de una verificación de estado activa y eliminación del servidor de un grupo ascendente por cualquier motivo. Esto incluye la eliminación a través de la búsqueda de DNS, donde un servidor backend se define mediante un nombre de host con múltiples direcciones IP, como las que proporciona un registro de servicios .

Otras mejoras en NGINX Plus R18

Configuración de agrupamiento simplificada

NGINX Plus ha admitido la sincronización del estado de ejecución en todo el clúster desde NGINX Plus R15 . El módulo de sincronización de zonas actualmente admite el uso compartido de datos de estado sobre sesiones persistentes , limitación de velocidad y el almacén de valores clave en una implementación en clúster de instancias NGINX Plus.

Ahora se puede usar una única configuración zone_sync para todas las instancias de un clúster. Anteriormente, era necesario configurar la dirección IP o el nombre de host de cada miembro de forma explícita, lo que significa que cada instancia tenía una configuración ligeramente diferente. 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 en la directiva listen . Esto es particularmente valioso al implementar NGINX Plus en un clúster dinámico donde la dirección IP de la instancia no se conoce hasta el momento de la implementación.

El uso de la misma configuración en cada instancia simplifica enormemente la implementación en entornos dinámicos (por ejemplo, con grupos de escalamiento automático o clústeres en contenedores).

Módulos dinámicos nuevos y actualizados

Los siguientes módulos dinámicos se agregan o actualizan en esta versión:

• Nuevo módulo de compresión Brotli : Brotli es un algoritmo de compresión de datos sin pérdida y de propósito 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 una variedad de servicios de seguimiento distribuido, como Datadog, Jaeger y Zipkin.
• Módulo Lua actualizado: Lua es un lenguaje de programación para NGINX Plus. El módulo ahora utiliza LuaJIT 2.1.

Actualizaciones del ecosistema 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 notable es la compatibilidad con los módulos de importación y exportación de JavaScript, que le permite organizar su código JavaScript en múltiples archivos específicos de funciones. Anteriormente, todo el código JavaScript tenía que residir en un solo 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 simple. Aquí empleamos JavaScript para realizar un enmascaramiento de datos para la privacidad del usuario de modo que se registre una versión enmascarada de la dirección IP del cliente en lugar de la dirección real. Una dirección IP enmascarada dada en el registro siempre representa al mismo cliente, pero no puede convertirse nuevamente a la dirección IP real.

[ Editor : el ejemplo en esta sección es solo uno 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 se actualiza para utilizar la directiva js_import , que reemplaza 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 la configuración de NGINX y los archivos JavaScript.

En NGINX Plus R22 y versiones posteriores, además de los módulos de importación y exportación de JavaScript , puede utilizar la directiva njs js_import para organizar su código JavaScript en múltiples archivos específicos de funciones. ]

Colocamos las funciones necesarias para enmascarar la dirección IP en un módulo 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 no pueden ser llamadas por otro código JavaScript.

Este módulo ahora se puede importar al archivo principal de JavaScript ( main.js ) y se puede hacer referencia a las funciones exportadas.

Como resultado, main.js es muy simple y contiene solo las funciones a las que hace referencia la configuración de NGINX. La declaración de importación 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 para buscar.

Las nuevas características mejoran mucho la legibilidad y el mantenimiento, especialmente cuando hay una gran cantidad de directivas njs en uso y/o una gran cantidad de código JavaScript. Ahora los equipos separados pueden mantener su propio código JavaScript sin necesidad de realizar una fusión compleja en el archivo JavaScript principal.

Instalación directa de Helm del controlador de ingreso NGINX para Kubernetes

Ahora puedes instalar NGINX Ingress Controller para Kubernetes directamente desde nuestro nuevo repositorio Helm, sin tener que descargar archivos fuente de gráficos de Helm (aunque esto también sigue siendo compatible). Para obtener más información, consulte el repositorio de GitHub .

Correcciones de errores notables

Límites de ancho de banda para aplicações UDP

Las directivas proxy_upload_rate y proxy_download_rate ahora funcionan correctamente para datagramas UDP.

El protocolo PROXY TLV con comprobación de estado bloquea NGINX

Anteriormente, NGINX Plus podía fallar 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, dentro de un entorno de AWS PrivateLink .

Balanceo de carga de menor tiempo ignorado Upstream más lento

Anteriormente, si un servidor ascendente respondía con suficiente lentitud durante un tiempo prolongado, era posible que nunca volviera a ser seleccionado porque su valor para la métrica de tiempo especificada era muy alto en comparación con otros servidores ascendentes. Ahora, un servidor ascendente anteriormente lento eventualmente se vuelve a introducir en el proceso de selección del balanceador de carga a medida que nuevas mediciones permiten que el promedio móvil se reduzca.

Esto se aplica a los algoritmos de equilibrio de carga que utilizan el tiempo de respuesta ascendente como una métrica de selección, específicamente least_time y aleatorio con el parámetro least_time .

Actualice o pruebe NGINX Plus

Si está utilizando NGINX Plus, le recomendamos encarecidamente que actualice a NGINX Plus R18 lo antes posible. También recibirá una serie de correcciones y mejoras adicionales, y ayudará a NGINX, Inc. a ayudarlo cuando necesite 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 evaluación gratuita de 30 días . Vea usted mismo cómo NGINX Plus puede ayudarle a entregar y escalar sus aplicações.