Presentamos NGINX Plus R13

Liam CrillyDirector sénior de Gestión de Producto

Nos complace anunciar que NGINX Plus Release 13 (R13) ya está disponible como actualización gratuita para todos los suscriptores de NGINX Plus. NGINX Plus es un servidor web, equilibrador de carga y caché de contenido integrado, basado en NGINX Open Source. NGINX Plus R13 incluye nuevas funciones centradas en las implementaciones dinámicas, capacidades de depuración mejoradas y mejoras en la seguridad y el rendimiento.

NGINX Plus R13 incorpora compatibilidad con:

• Una nueva API de NGINX Plus – Realice configuraciones dinámicas y obtenga métricas de estado ampliadas desde un único endpoint consolidado; la API también incorpora compatibilidad con almacenes de clave-valor.
• Duplicación de solicitudes – Envíe una copia de todo el tráfico entrante a un servidor dedicado, donde podrá supervisar, inspeccionar y registrar el tráfico de las aplicaciones sin afectar al rendimiento de los servidores de producción.
• Mejoras en el módulo JavaScript de NGINX – Amplíe NGINX Plus mediante la configuración programática con el módulo JavaScript de NGINX, nuestra implementación personalizada de JavaScript. [Anteriormente, el módulo se denominaba nginScript.] El nuevo intérprete interactivo njs proporciona una consola que muestra todos los objetos integrados de JavaScript. Estos objetos se pueden examinar con más detalle para descubrir los métodos y elementos primitivos disponibles para cada uno.
• Herramienta de compilación para módulos dinámicos – Utilice nuestra nueva herramienta de compilación para crear paquetes instalables para los numerosos módulos de terceros disponibles para NGINX y NGINX Plus.

Otras mejoras incluyen optimizaciones del método sticky learn para la persistencia de sesiones, compatibilidad con tráileres HTTP y un nuevo módulo dinámico de terceros para sustituciones HTTP.

Cambios de comportamiento

• Módulos obsoletos – Las API anteriores para el estado ampliado y la configuración dinámica de grupos de servidores upstream (los módulos Status y Upstream Conf) están obsoletas y se sustituyen por la API unificada de NGINX Plus API. Las API obsoletas seguirán incluyéndose con NGINX Plus durante un mínimo de 6 meses, junto con la nueva NGINX Plus API. Las API obsoletas se eliminarán en una futura versión de NGINX Plus.
• Directiva eliminada – La directiva sticky_cookie_insert se ha eliminado en NGINX Plus R13, tras haber quedado obsoleta en NGINX Plus R2.
• Módulos dinámicos de terceros – Los módulos dinámicos instalados desde el repositorio de NGINX se actualizan automáticamente a R13. Todos los módulos de terceros, es decir, los módulos no incluidos en el repositorio oficial de NGINX – deben volver a compilarse con NGINX Open Source 1.13.4 para seguir funcionando con NGINX Plus R13. Para obtener más información, consulte la Guía de administración de NGINX Plus.
• La directiva del módulo ModSecurity ya no es compatible – La directiva SecRequestBodyInMemoryLimit de ModSecurity ya no es compatible. Los clientes pueden eliminarla sin problemas, ya que el módulo ModSecurity se ajusta al tratamiento del cuerpo de las solicitudes definido en la configuración de NGINX.[Nota del editor – El módulo NGINX ModSecurity WAF para NGINX Plus dejó de comercializarse oficialmente el 1 de abril de 2022 y se encuentra en proceso de alcanzar el fin de su vida útil, que será efectivo el 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.]
• Se ha eliminado la compatibilidad con versiones de sistemas operativos que han llegado al final de su vida útil – NGINX Plus ya no es compatible con CentOS 5.10+, Red Hat Enterprise Linux 5.10+, Oracle Linux 5.10+, Ubuntu 12.04 LTS ni Ubuntu 16.10.

Características de NGINX R13 en detalle

API de NGINX Plus

NGINX Plus R13 incluye una nueva API REST unificada en un único punto de conexión. Las versiones anteriores de NGINX Plus incluían API independientes de Upstream Conf y Extended Status. La nueva API combina las funcionalidades de ambas y también admite el nuevo módulo Key‑Value Store en diversos casos de uso de configuración dinámica (que se describen en la sección Key‑Value Store más adelante).

Para habilitar la API de NGINX Plus, incluya la nueva directiva «api» en un bloque «location»:

server {    listen 80;

    location /api {
        api write=on;
        # directives that allow access only by authorized users
    }
}

De forma predeterminada, la API de NGINX Plus proporciona acceso de solo lectura a los datos. Añada el parámetro write=on a la directiva api para habilitar el acceso de lectura y escritura, de modo que se puedan realizar cambios en los servidores ascendentes y en el nuevo módulo Almacén de clave-valor. Recomendamos encarecidamente restringir el acceso a la API únicamente a los usuarios autorizados, especialmente cuando esté habilitado el modo de lectura y escritura.

Para ver todos los tipos de información disponibles en el endpoint de la API, ejecute este comando:

$ curl http://localhost:80/api/1/ ["nginx","processes","connections","ssl","slabs","http","stream"]

Para mostrar información detallada sobre un tipo específico de información, añada la cadena correspondiente al URI de la solicitud:

• connections – Mostrar métricas del total de conexiones
• http – Muestra métricas del tráfico HTTP y modifica la configuración del servidor ascendente HTTP. También hay dos «subtipos» en http:
  • http/server_zones – Mostrar información sobre los servidores virtuales HTTP
  • http/upstreams – Mostrar información sobre los grupos de servidores ascendentes HTTP y modificar su configuración
• nginx – Mostrar información general sobre NGINX
• processes – Muestra información sobre los procesos de trabajo de NGINX
• slabs – Mostrar información sobre la memoria compartida asignada por NGINX
• ssl – Mostrar métricas de los clientes SSL/TLS en tiempo real
• stream – Muestra métricas del tráfico TCP/UDP y modifica la configuración de los grupos de servidores ascendentes TCP/UDP (en stream/upstreams)

Monitorización de estado ampliada

NGINX Plus ofrece más de 40 métricas exclusivas, además de las disponibles en NGINX Open Source. Ahora puede acceder a estas métricas mediante la API de NGINX Plus. Utilice la API para acceder a las métricas que le interesen.

Por ejemplo, añada connections al URI para obtener una instantánea del estado de las conexiones, que incluye el número de conexiones de clientes aceptadas, activas, descartadas e inactivas.

$ curl http://localhost:80/api/1/connections{"accepted":3,"dropped":0,"active":1,"idle":0}

Otro ejemplo: añada ssl al URI para obtener una instantánea en tiempo real de las estadísticas de los clientes SSL.

$ curl http://localhost:80/api/1/ssl {"handshakes":0,"handshakes_failed":0,"session_reuses":0}

Configuración dinámica de grupos de servidores upstream

En NGINX Plus R12 y versiones anteriores, se podía utilizar la directiva upstream_conf para habilitar la configuración dinámica de grupos de servidores ascendentes existentes sin recargar NGINX Plus. Esta funcionalidad está ahora integrada en la API de NGINX Plus.

Este fragmento de configuración de NGINX Plus define dos servidores en el grupo de servidores ascendentes denominado «backend» y habilita la API de NGINX Plus en «/api»:

upstream backend {    zone backends 64k;
    server 10.10.10.2; 
    server 10.10.10.4;
}

server {
    listen 80;
    server_name www.example.org;

    location /api {
        api write=on;
    }
}

Para añadir un servidor al grupo backend, incluya la opción -d en una solicitud de curl a /api/1/http/upstreams/backend/servers, con texto JSON que defina la dirección IP del nuevo servidor (en este caso, 10.10.10.6). La opción -i indica que las cabeceras HTTP se incluyen en la respuesta. (Puede omitir -X POST porque es el método predeterminado cuando se utiliza -d, pero lo incluimos para mantener la coherencia con otros métodos).

$ curl -iX POST -d '{"server":"10.10.10.6"}' http://localhost/api/1/http/upstreams/backend/serversHTTP/1.1 201 Created
...

Para obtener información detallada sobre todas las opciones para configurar grupos de servidores ascendentes, consulte la documentación de referencia del módulo NGINX Plus API.

Almacén de clave-valor

NGINX Plus R13 incorpora un nuevo módulo de almacenamiento de clave-valor. Puede utilizar la API de NGINX Plus para crear, modificar y eliminar pares clave-valor al instante en una o varias zonas de memoria compartida «keyval». El valor de cada par clave-valor puede evaluarse como una variable para utilizarlo con otras funciones de NGINX Plus.

Para añadir, modificar, consultar y eliminar entradas del almacén de clave-valor, utilice respectivamente los métodos HTTP POST, PATCH, GET y DELETE. El almacén de clave-valor ofrece numerosas soluciones de configuración dinámica que permiten la integración en tiempo real con sistemas externos.

Algunos ejemplos de casos de uso son:

• Inclusión dinámica de direcciones IP en listas de denegación (consulte la Guía de administración de NGINX Plus)
• Enrutamiento de URI a servidores backend
• Gestión de listas de URI permitidos por usuario
• Gestionar reglas de redirección (véase el siguiente ejemplo)

El siguiente fragmento de configuración utiliza el módulo Key-Value Store para gestionar las URL personalizadas de un sitio web.

keyval_zone zone=redirects:1M state=state/redirects.json;  # Save key-val pairs to filekeyval $uri $target zone=redirects;                        # $uri is the key, $target is the value

server {
    listen 80;

    location /api {
        api write=on; # Enable the NGINX Plus API (secure this location in production environments)
    }

    if ($target) {          # True when $uri exists in the 'redirects' keyval zone
        return 301 $target; # Redirect client to the matching value for the $uri
    }

    location / {
        proxy_pass http://backend;
    }
}

En la directiva keyval, la clave se establece en el URI del equipo remoto que emite la solicitud HTTP. Si $uri es una clave del almacén de pares clave-valor, el valor asociado a la clave se asigna a una nueva variable denominada $target. A continuación, si $target existe, NGINX Plus redirige al cliente al valor correspondiente de $uri.

Para rellenar el almacén de clave-valor con una URL personalizada inicial, enviamos los datos, codificados como JSON, al URI de la API de NGINX Plus.

$ curl -iX POST -d '{"/conf":"/conf2017"}' http://localhost/api/1/http/keyvals/redirectsHTTP/1.1 201 Created
...

Ahora, los clientes que solicitan /conf son redirigidos a /conf2017.

$ curl -i http://localhost/confHTTP/1.1 301 Moved Temporarily
Location: http://localhost/conf2017

Puedes usar el método PATCH para añadir más redirecciones de URL personalizadas al almacén de clave-valor y modificar dinámicamente las entradas existentes.

$ curl -iX PATCH -d '{"/conf":"/conf2018"}' http://localhost/api/1/http/keyvals/redirectsHTTP/1.1 204 No Content
...

Puede configurar varios almacenes de clave-valor independientes mediante la directiva keyval para definir una zona de memoria compartida diferente para cada uno. Para obtener más información, consulte la documentación de referencia del módulo Almacén de clave-valor.

Documentación de Swagger

La nueva API de NGINX Plus incluye una especificación de Swagger que permite explorar la API y conocer las capacidades de cada recurso. La documentación de Swagger se incluye con NGINX Plus y está disponible en http://nginx-host/swagger-ui/.

La parte interactiva de la interfaz de usuario de Swagger requiere que la API de NGINX Plus esté habilitada. Para ello, quite el comentario del bloque de ubicación /api/ en el archivo conf.d/default.conf.

# enable /api/ location with appropriate access control in order# to make use of NGINX Plus API
#
#location /api/ {
#    api write=on;
#    allow 127.0.0.1;
#    deny all;
#}

También puede consultar la documentación de la API de NGINX Plus en https://demo.nginx.com/swagger-ui/.

Nota: Toda la API de NGINX Plus, incluidas las métricas de estado ampliadas, la configuración de servidores upstream y el nuevo módulo de almacén de clave-valor, es exclusiva de NGINX Plus.

Duplicación de solicitudes

Con NGINX Plus R13, puede habilitar la duplicación de solicitudes HTTP. Con esta función, las solicitudes HTTP que se envían mediante proxy a un grupo de servidores ascendentes se clonan y también se envían a un destino diferente. La solicitud original se procesa de la forma habitual, pero se ignoran todas las respuestas de la solicitud clonada. La duplicación de solicitudes tiene numerosos casos de uso, entre ellos:

• Integración con firewalls de aplicaciones web (WAF) cuando se implementan en modo de aprendizaje, de modo que se puedan analizar los patrones de solicitud habituales sin afectar al tráfico de producción
• Optimización del rendimiento sin riesgos mediante tráfico de producción en tiempo real
• Duplicación de las cargas de archivos en un servidor de respaldo para evitar la replicación del sistema de archivos entre servidores web

Habilitar la duplicación de solicitudes tiene un impacto insignificante en el rendimiento y el desempeño generales del sistema. El siguiente fragmento de configuración muestra cómo utilizar la nueva directiva «mirror» para clonar solicitudes y enviarlas a un servidor upstream independiente.

location / {    mirror /mirror;
    proxy_pass http://backend;
}

location /mirror {
    internal;
    proxy_pass http://test_backend$request_uri;
}

Las solicitudes se redirigen mediante proxy al grupo de servidores upstream backend para su procesamiento habitual. También se clonan y se redirigen mediante proxy a otro grupo de servidores upstream denominado test_backend, conservando el URI de la solicitud original.

Nota: La duplicación de solicitudes se lanzó inicialmente en NGINX Open Source 1.13.4.

Mejoras en el módulo JavaScript de NGINX

Desde que pasó a estar disponible de forma general en NGINX Plus R12, el módulo JavaScript de NGINX (anteriormente denominado nginScript) ha seguido ampliándose con compatibilidad con las funciones básicas del lenguaje JavaScript. En esta versión, incorporamos compatibilidad con números hexadecimales (como 0x7b) y notación científica (como 512e10). También se han implementado métodos primitivos para la clase Object.

NGINX JavaScript ahora también ofrece un shell interactivo, que se invoca con el comando njs, para facilitar el desarrollo de código NGINX JavaScript.

El siguiente fragmento de código de shell muestra cómo acceder al shell interactivo de NGINX JavaScript, definir una expresión que genere una fecha aleatoria hasta 30 segundos en el futuro y calcular la suma de dos números.

$ njsinteractive njscript
>> Date.now() + Math.round(Math.random()*30*1000);
1500976350968
>> 0x7b + 512e10;
5120000000123
>>

Para obtener más información, consulta la introducción a NGINX JavaScript<.htmla> en nuestro blog.

Nota: NGINX JavaScript está disponible tanto para NGINX Open Source como para NGINX Plus.

Herramienta de compilación para módulos dinámicos

NGINX 1.11.5 y NGINX Plus R11 incorporaron la posibilidad de compilar módulos dinámicos de forma independiente del propio NGINX. Esto permite a los usuarios de NGINX y NGINX Plus utilizar las compilaciones oficiales de los repositorios de NGINX, Inc. y cargar únicamente los módulos dinámicos que necesiten.

Con NGINX Plus R13, proporcionamos una herramienta de compilación para compilar y empaquetar un módulo dinámico como módulo instalable que conserva y respeta la dependencia entre este y la versión base de NGINX con la que está vinculado.

Para obtener información completa sobre la herramienta de compilación, consulte Creación de paquetes instalables para módulos dinámicos en nuestro blog.

Nota: La herramienta de compilación está disponible tanto para NGINX Open Source como para NGINX Plus.

Persistencia de sesión sticky learn más rápida

La persistencia de sesión es una función muy útil del balanceo de carga de NGINX Plus que permite enviar todas las solicitudes de un cliente concreto a un mismo servidor. Existen varias formas de establecer la persistencia de sesión; con el método «sticky learn», NGINX Plus comprueba la presencia de una cookie específica y vincula al cliente al mismo servidor siempre que dicha cookie se incluya en una solicitud.

Con NGINX Plus R13, ahora puede establecer una sesión persistente en cuanto el servidor ascendente haya enviado las cabeceras de su respuesta, en lugar de esperar a que llegue la carga útil completa de la respuesta. De este modo, NGINX Plus puede enviar la sesión persistente al cliente lo antes posible. Incluya el nuevo parámetro «header» en la directiva «sticky learn»:

upstream backends {    zone backends 64k;
    server 10.10.10.2; 
    server 10.10.10.4;
   
    sticky learn create=$upstream_cookie_sessionid
                 lookup=$cookie_sessionid
                 zone=client_sessions:1m
                 header;
 }

El parámetro header resulta especialmente útil si una aplicación es propensa a errores y se desea que el cliente reenvíe las solicitudes fallidas al mismo servidor ascendente.

Nota: La persistencia de sesión sticky‑learn es exclusiva de NGINX Plus.

Funciones adicionales

NGINX Plus R13 incorpora las siguientes funciones adicionales:

• Tráileres HTTP – La directiva add_trailer permite añadir tráileres arbitrarios al final de las respuestas HTTP. El encabezado de respuesta Trailer permite al remitente incluir campos adicionales al final de los mensajes fragmentados para proporcionar metadatos que podrían generarse dinámicamente mientras se envía el cuerpo del mensaje, como una comprobación de integridad del mensaje o una firma digital.
• Módulo dinámico del filtro de sustituciones – El módulo dinámico comunitario HTTP Substitutions Filter ya es compatible y está incluido en nuestras distribuciones de NGINX Plus. El módulo puede aplicar sustituciones mediante expresiones regulares y cadenas fijas a los cuerpos de las respuestas. Analiza el búfer de las cadenas de salida y busca coincidencias línea por línea. También puede acceder al módulo en la página Dynamic Modules.
• Cierre ordenado de los procesos de trabajo – Utilice la directiva worker_shutdown_timeout para establecer un tiempo de espera que permita completar más rápidamente el cierre ordenado de los procesos de trabajo. Cuando vence el tiempo de espera tras recibirse una señal de cierre o reinicio, NGINX Plus intenta cerrar todas las conexiones de cliente abiertas.

Actualice a R13 o pruebe NGINX Plus

Si utiliza NGINX Plus, le recomendamos encarecidamente que actualice a la versión 13 lo antes posible. Obtendrá diversas correcciones y mejoras, y nos facilitará la tarea de ayudarle si necesita abrir una incidencia de soporte. Encontrará las instrucciones de instalación y actualización 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 probado NGINX Plus, le animamos a utilizarlo 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 de 30 días y comprobar 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