La unidad NGINX da la bienvenida al otoño de 2022 con nuevas funciones (¡un motor de estadísticas!) y planes emocionantes.

Primero lo primero: ha pasado bastante tiempo desde que compartimos noticias del equipo de la Unidad NGINX: estos tiempos tumultuosos han afectado a todos y no somos la excepción. Este marzo, dos miembros fundadores del equipo de Unit, Valentin Bartenev y Maxim Romanov, decidieron pasar a otras oportunidades después de invertir años de trabajo y toneladas de creatividad en NGINX Unit . Demos crédito a quien lo merece: sin ellos, NGINX Unit no estaría donde está ahora. Felicitaciones, muchachos.

Aun así, nuestra determinación sigue siendo firme, como también nuestro compromiso de hacer realidad las aspiraciones originales del cofundador de NGINX, Igor Sysoev, para la Unidad NGINX. La llegada de los dos miembros más nuevos del equipo, Alejandro Colomar y Andrew Clayton, ha impulsado el esfuerzo de desarrollo, por lo que ahora tenemos algunos elementos notables de las versiones 1.25 a 1.28 de NGINX Unit para compartir con ustedes.

La observabilidad es una realidad ahora

Una de las principales aspiraciones de Unit siempre ha sido la observabilidad, y la versión 1.28.0 incluye la primera iteración de una de las características más esperadas: un motor de estadísticas. Su salida se expone en el nuevo punto final de la API /status :

$ curl --unix-socket /var/run/control.unit.sock http://localhost/status

{
"conexiones": {
"aceptadas": 1067,
"activo": 13,
"inactivo": 4,
"cerrado": 1050
},

"solicitudes": {
"total": 1307
},

"aplicações": {
"wp": {
"procesos": {
"correr": 14,
"inicio": 0,
"inactivo": 4
},

"solicitudes": {
"activas": 10
            }
        }
    }
}

La mayoría de los campos aquí son autodescriptivos: las conexiones (línea 2) y las solicitudes (línea 9) proporcionan datos de toda la instancia, mientras que el objeto de aplicações (línea 13) refleja /config/ aplicações , cubriendo los procesos y las solicitudes que conciernen específicamente a la aplicação.

Las líneas 3 a 6 muestran las cuatro categorías de conexiones rastreadas por NGINX Unit: aceptadas , activas , inactivas y cerradas . Las categorías de los procesos son en ejecución , iniciando e inactivo (líneas 16 a 18). Estas categorías reflejan la representación interna de conexiones y procesos, por lo que ahora usted sabe tanto sobre ellos como su servidor.

¿Parece conciso? Eso es prácticamente todo lo que hay que saber por ahora. Por supuesto, estamos trabajando para exponer métricas más útiles; sin embargo, ya puedes consultar esta API desde tu línea de comandos para ver qué está pasando en tu servidor e incluso conectar la salida a un panel de control o a tu elección para un enfoque más sofisticado. ¿Quizás no tienes un tablero de instrumentos? Bueno, algunos de nuestros planes incluyen ofrecer uno integrado, así que síguenos para ver cómo funciona esto.

Para obtener más detalles, consulte Estadísticas de uso en la documentación de la unidad NGINX.

Más variables, más lugares para usarlas

La lista de variables introducidas desde la versión 1.24 es bastante extensa e incluye $body_bytes_sent , $header_referer , $header_user_agent , $remote_addr , $ request_line , $request_uri , $status y $time_local .

La mayoría de ellos son bastante sencillos, pero aquí están algunos de los más notables:

• $request_uri contiene la ruta y la consulta de la URI solicitada con la codificación del navegador preservada
• La línea $request_line, con un nombre similar, almacena la solicitud completa, como GET /docs/help.html HTTP/1.1 , y está destinada a registrar…
• Como es $status que contiene el código de estado de respuesta HTTP

¿Te diste cuenta? Mencionamos respuestas. Sí, también nos estamos adentrando en ese territorio: las variables en versiones anteriores de Unit se centraban en las solicitudes entrantes, pero ahora tenemos variables que también capturan las propiedades de respuesta, como $status y $body_bytes_sent .

Respecto a los nuevos lugares donde utilizar variables, el primero que hay que mencionar es el nuevo formato de registro de acceso personalizable. ¿Quieres utilizar JSON en las entradas de registro de NGINX Unit? Además de especificar una cadena de ruta simple, la opción access_log puede ser un objeto que también establece el formato de las entradas del registro:

{ 
"access_log": {
"path": "/var/log/unit/access.log", 
"format": "{ \"remote_addr\":\"$remote_addr\", "time\":\"$time_local\", \"request\":\"$request_line\", \"response\":\"$status\", \"header_referer\":\"$header_referer\", \"header_user_agent\":\"$header_user_agent\" }" 
} 
}

De este modo, puedes ir más allá del formato de registro habitual de cualquier forma que desees.

Un segundo caso de uso notable para las variables es el valor de ubicación de una acción de ruta:

{ 
"acción": { 
"retorno": 301, 
"ubicación": "https://$host$request_uri" 
} 
}

Aquí usamos $request_uri para retransmitir la solicitud, incluida la parte de consulta, al mismo sitio web a través de HTTPS.

La opción chroot ahora admite variables al igual que la opción share , lo cual es lógico:

{ 
"acción": { 
"compartir": "/www$uri",
"chroot": "/www/data/$host/" 
} 
} 

NGINX Unit ahora también admite variables dinámicas. Los argumentos de solicitud, las cookies y los encabezados se exponen como variables: por ejemplo, la cadena de consulta Type=car&Color=red da como resultado dos variables de argumento, $arg_Type y $arg_Color . En tiempo de ejecución, estas variables se expanden en valores dinámicos; si hace referencia a una variable inexistente, se considera vacía.

Para obtener más detalles, consulte Variables en la documentación de la unidad NGINX.

Amplio soporte para los encabezados X-Forwarded-*

Usted lo pidió y nosotros cumplimos. A partir de la versión 1.25.0, NGINX Unit ha ofrecido algunas facilidades de configuración de TLS para sus oyentes, incluido un grado de reconocimiento de X-Forwarded-* ; ahora, puede configurar direcciones IP de cliente y reemplazo de protocolo en la configuración para sus oyentes:

{
"oyentes": {
"*:80": {
"contraseña": "rutas/mi-aplicación",
"reenviado": {
"ip_del_cliente": "X-Reenviado-Para",
"protocolo": "X-Forwarded-Proto",
"recursivo": falso,
"origen": [
"198.51.100.1-198.51.100.254",
"!198.51.100.128/26",
"203.0.113.195"
]
}
}
},
...
}

Nota: Esta nueva sintaxis deja obsoleta la sintaxis client_ip anterior, que se eliminará en una versión futura.

Para obtener más detalles, consulte IP, Reenvío de protocolo en la documentación de la unidad NGINX.

La opción sobre acciones renovada

La versión 1.11.0 de NGINX Unit introdujo la opción de enrutamiento compartido para servir contenido estático. Es comparable a la directiva raíz en NGINX:

{
"share": "/ruta/al/directorio/"
}

Inicialmente, la opción para compartir especificaba el llamado directorio raíz del documento. Para determinar qué archivo servir, Unit simplemente agregó el URI de la solicitud a esta ruta compartida . Por ejemplo, en respuesta a una simple solicitud GET para /some/file.html , Unit proporcionó /path/to/dir/some/file.html . Aun así, seguimos encontrándonos con casos límite que requerían un control más preciso sobre la ruta del archivo, por lo que decidimos evolucionar. A partir de la versión 1.26.0, la opción compartir especifica la ruta completa a un archivo compartido en lugar de solo la raíz del documento.

¿Quieres servir un archivo específico? Bien:

{
"share": "/ruta/a/un/archivo.html"
}

¿Utilizar variables dentro de la ruta? Genial, no hay problema:

{
"share": "/www/data/$host/app.html"
}

Pero ¿cómo podemos imitar el comportamiento al que ya estamos acostumbrados en NGINX y versiones anteriores de Unit? ¿Sabes esa cosa de la raíz del documento que consideramos obsoleta hace unos párrafos? Tenemos una solución.

Ahora puedes reescribir configuraciones de esta manera:

{
"compartir": "/www/datos/"
}

de la siguiente manera, agregando la URI solicitada a la ruta, ¡pero explícitamente!

{
"compartir": "/www/datos/$uri"
}

Finalmente, la directiva share ahora puede aceptar una matriz de rutas, probándolas una por una hasta que encuentre un archivo:

{
"compartir": [
"/www/$host$uri",
"/www/static$uri",
"/www/app.html"
]
}

Si no se encuentra ningún archivo, el enrutamiento pasa a un retroceder acción; si no hay retroceder, el 404 (No Encontró) Se devuelve el código de estado.

Para obtener más detalles, consulte Archivos estáticos en la documentación de la unidad NGINX.

Planes: njs, reescritura de URI, encadenamiento de acciones, OpenAPI

Mientras lees esto, ya estamos trabajando en el próximo lanzamiento; aquí tienes un vistazo de lo que tenemos bajo la manga.

En primer lugar, estamos integrando NGINX Unit con el módulo JavaScript de NGINX ( njs ), otro proyecto clave en desarrollo activo en NGINX. En resumen, esto significa que NGINX Unit permitirá la invocación de módulos JavaScript. Considere esto:

varhellonjs = {}

holajs.hola = función(vars) {
    si ('varunidad' en vars) {
        devolver vars.unitvar;

    } demás {
        devolver 'predeterminado';
    }
}

exportar hellonjs predeterminados

Después de importar el módulo en NGINX Unit, podrás hacer algunas cosas interesantes con la configuración:

{ "coincidencia": { "uri": "~(?.*)" }, "acción": { "compartir": "`/www/html${hellonjs.hello(vars)} `" } }

Además, pretendemos introducir algo similar a la siempre popular directiva de reescritura NGINX:

{
"match": {
"uri": "/app/antiguo_camino"
},

"action": {
"rewrite": "/app/nuevo_camino",
"pass": "rutas"
}
}

Pero nuestros planes no terminan ahí. ¿Qué tal vincular el enrutamiento de NGINX Unit a la salida de las propias aplicaciones (también conocido como encadenamiento de acciones )?

{
"acción": [
{
"pass": "aplicações/auth_check"
},
{
"pass": "aplicações/mi_aplicación"
}
]
}

La idea aquí es que la aplicación auth_check autentique la solicitud entrante y devuelva un código de estado para indicar el resultado. Si la autenticación tiene éxito, 200 DE ACUERDO se devuelve y la solicitud pasa a mi_aplicación.

Mientras tanto, también estamos trabajando en una especificación OpenAPI para definir de una vez por todas la API de NGINX Unit y sus capacidades exactas. Deséenos suerte porque ésta es una empresa gigantesca.

Si esto aún no es suficiente para satisfacer su curiosidad, consulte nuestra hoja de ruta para obtener un análisis detallado de nuestros planes; es interactiva, por lo que cualquier aporte suyo, querido lector, será bienvenido.