NGINX Unit da la bienvenida al otoño de 2022 con nuevas funcionalidades (¡un motor de estadísticas!) y planes apasionantes

Artem Konev

Antes que nada: ha pasado bastante tiempo desde que compartimos novedades del equipo de NGINX Unit. Estos tiempos convulsos nos han afectado a todos, y nosotros no somos una excepción. Este mes de marzo, dos miembros fundadores del equipo de Unit, Valentin Bartenev y Maxim Romanov, decidieron emprender nuevos caminos tras dedicar años de trabajo y una enorme creatividad a NGINX Unit. Hay que reconocer el mérito de quien lo merece: sin ellos, NGINX Unit no habría llegado hasta donde está hoy. Enhorabuena, chicos.

Aun así, nuestra determinación sigue siendo firme, al igual que nuestro compromiso de hacer realidad las aspiraciones originales del cofundador de NGINX, Igor Sysoev, para NGINX Unit. La incorporación de los dos miembros más recientes del equipo, Alejandro Colomar y Andrew Clayton, ha impulsado el trabajo de desarrollo, por lo que ahora tenemos bastantes novedades destacables de las versiones 1.25 a 1.28 de NGINX Unit que compartir con vosotros.

La observabilidad ya es una realidad

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 funcionalidades más esperadas: un motor de estadísticas. Sus resultados están disponibles en el nuevo endpoint de la API /status:

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

{
    "connections": {
        "accepted": 1067,
        "active": 13,
        "idle": 4,
        "closed": 1050
    },

    "requests": {
        "total": 1307
    },

    "applications": {
        "wp": {
            "processes": {
                "running": 14,
                "starting": 0,
                "idle": 4
            },

            "requests": {
                "active": 10
            }
        }
    }
}

La mayoría de los campos se explican por sí solos: connections (línea 2) y requests (línea 9) proporcionan datos de toda la instancia, mientras que el objeto applications (línea 13) refleja /config/applications e incluye los procesos y las solicitudes relacionados específicamente con la aplicación.

Las líneas 3–6 muestran las cuatro categorías de conexiones que supervisa NGINX Unit: aceptadas, activas, inactivas y cerradas. Las categorías de los procesos son en ejecución, iniciándose e inactivos (líneas 16–18). Estas categorías reflejan la representación interna de las conexiones y los procesos, así que ahora sabe tanto sobre ellos como su servidor.

¿Le parece escueto? Por ahora, eso es prácticamente todo lo que hay que saber. Por supuesto, estamos trabajando para ofrecer más métricas útiles; sin embargo, ya puede consultar esta API desde la línea de comandos para ver qué ocurre en su servidor e incluso integrar los resultados en un panel de control o en la solución que prefiera si busca algo más sofisticado. ¿Quizá no dispone de un panel de control? Pues bien, entre nuestros planes está ofrecer uno integrado, así que síganos para ver cómo evoluciona todo.

Para obtener más información, consulte «Estadísticas de uso» en la documentación de NGINX Unit.

Más variables, más lugares donde 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 son bastante sencillas, pero estas son algunas de las más destacables:

• $request_uri contiene la ruta y la cadena de consulta del URI solicitado, conservando la codificación del navegador
• La variable de nombre similar «$request_line» almacena la solicitud completa, por ejemplo, «GET /docs/help.html HTTP/1.1», y está pensada para el registro…
• Al igual que $status, que contiene el código de estado de la respuesta HTTP

¿Te has dado cuenta? Hemos mencionado las respuestas. Sí, también nos estamos adentrando en ese terreno: las variables de las versiones anteriores de Unit se centraban en las solicitudes entrantes, pero ahora también tenemos variables que recogen las propiedades de la respuesta, como $status y $body_bytes_sent.

En cuanto a los nuevos lugares donde se pueden usar variables, el primero que cabe mencionar es el nuevo formato personalizable del registro de acceso. ¿Quiere usar JSON en las entradas de registro de NGINX Unit? Además de especificar una simple cadena de ruta, la opción «access_log» puede ser un objeto que también establezca el formato de las entradas de 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\" }" 
    } 
}

Así, puedes ir más allá del formato de registro habitual como prefieras.

Otro caso de uso destacable de las variables es el valor location de una action de ruta:

{ 
    "action": { 
        "return": 301, 
        "location": "https://$host$request_uri" 
    } 
 }

Aquí usamos $request_uri para reenviar la solicitud, incluida la cadena de consulta, al mismo sitio web mediante HTTPS.

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

{ 
    "action": { 
        "share": "/www$uri",
        "chroot": "/www/data/$host/" 
    } 
} 

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

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

Compatibilidad amplia con las cabeceras X-Forwarded-* Headers

Lo pedisteis y lo hemos hecho. Desde la versión 1.25.0, NGINX Unit ofrece algunas opciones de configuración de TLS para sus listeners, incluido cierto grado de compatibilidad con X-Forwarded-*; ahora podéis configurar las direcciones IP de los clientes y la sustitución del protocolo en la configuración de vuestros listeners:

{
    "listeners": {
        "*:80": {
            "pass": "routes/my-app",
            "forwarded": {
                "client_ip": "X-Forwarded-For",
                "protocol": "X-Forwarded-Proto",
                "recursive": false,
                "source": [
                    "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 anterior de client_ip, que se eliminará en una versión futura.

Para obtener más información, consulte «Reenvío de IP y protocolos» en la documentación de NGINX Unit.

La renovada opción «share»

La versión 1.11.0 de NGINX Unit introdujo la opción de enrutamiento share para servir contenido estático. Es comparable a la directiva root de NGINX:

{
    "share": "/path/to/dir/"
}

Inicialmente, la opción share especificaba el denominado directorio raíz de documentos. Para determinar qué archivo debía servir, Unit simplemente añadía el URI de la solicitud a esta ruta de share. Por ejemplo, en respuesta a una solicitud GET sencilla de /some/file.html, Unit servía /path/to/dir/some/file.html. Sin embargo, seguíamos encontrándonos con casos límite que requerían un control más preciso de la ruta del archivo, por lo que decidimos evolucionar. A partir de la versión 1.26.0, la opción share especifica la ruta completa de un archivo compartido, en lugar de limitarse al directorio raíz de documentos.

¿Quieres servir un archivo específico? Perfecto:

{
    "share": "/path/to/a/file.html"
}

¿Quieres usar variables en la ruta? Genial, no hay problema:

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

Pero ¿cómo se puede imitar el comportamiento al que ya está acostumbrado de NGINX y de las versiones anteriores de Unit? Ya sabe, lo de la raíz de documentos que consideramos obsoleto hace unos párrafos. Tenemos una solución.

Ahora puede reescribir configuraciones como esta:

{
    "share": "/www/data/"
}

de la siguiente manera, añadiendo explícitamente el URI solicitado a la ruta.

{
    "share": "/www/data/$uri"
}

Por último, la directiva share ahora puede aceptar una matriz de rutas y probarlas una a una hasta encontrar un archivo:

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

Si no se encuentra ningún archivo, el enrutamiento pasa a una acción fallback; si no hay ninguna acción fallback, se devuelve el código de estado 404 (Not Found).

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

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

Mientras lees esto, ya estamos trabajando en la próxima versión; aquí tienes un adelanto de lo que estamos preparando.

En primer lugar, estamos integrando NGINX Unit con el módulo JavaScript de NGINX (njs), otro proyecto esencial que se encuentra en desarrollo activo en NGINX. En resumen, esto significa que NGINX Unit permitirá invocar módulos JavaScript. Veamos este ejemplo:

var hellonjs = {}

hellonjs.hello = function(vars) {
    if ('unitvar' in vars) {
        return vars.unitvar;

    } else {
        return 'default';
    }
}

export default hellonjs

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

{
    "match": {
        "uri": "~(?.*)" }, "action": { "share": "`/www/html${hellonjs.hello(vars)}`" } }

Además, nuestro objetivo es introducir algo similar a la popularísima directiva rewrite de NGINX:

{
    "match": {
        "uri": "/app/old_path"
     },
     
    "action": {
        "rewrite": "/app/new_path",
        "pass": "routes"
    }
}

Pero nuestros planes no acaban ahí. ¿Qué tal si vinculamos el enrutamiento de NGINX Unit a la salida de las propias aplicaciones (lo que se conoce como encadenamiento de «action»)?

{
    "action": [
        {
            "pass": "applications/auth_check"
        },
        {
            "pass": "applications/my_app"
        }
    ]
}

La idea 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 se realiza correctamente, se devuelve 200 OK y la solicitud se reenvía a my_app.

Mientras tanto, también estamos trabajando en una especificación OpenAPI que defina de una vez por todas la API de NGINX Unit y sus capacidades exactas. Deséennos suerte, porque se trata de una tarea titánica.

Si aun así no basta para satisfacer tu curiosidad, consulta nuestra hoja de ruta para conocer nuestros planes al detalle; es interactiva, así que cualquier aportación por tu parte, querido lector, será más que bienvenida.

Sobre el autor

Artem Konev

Más artículos de Artem Konev