NGINX Unit accueille l’automne 2022 avec de nouvelles fonctionnalités (un moteur de statistiques !) et des projets passionnants

Artem Konev

Tout d’abord, cela faisait un bon moment que nous n’avions pas donné de nouvelles de l’équipe NGINX Unit. Cette période mouvementée a touché tout le monde, et nous ne faisons pas exception. En mars dernier, deux membres fondateurs de l’équipe Unit, Valentin Bartenev et Maxim Romanov, ont décidé de se tourner vers de nouvelles opportunités après avoir consacré des années de travail et une immense créativité à NGINX Unit. Rendons à César ce qui est à César : sans eux, NGINX Unit n’en serait pas là aujourd’hui. Bravo à vous deux.

Néanmoins, notre détermination reste intacte, tout comme notre engagement à concrétiser les ambitions initiales d’Igor Sysoev, cofondateur de NGINX, pour NGINX Unit. L’arrivée des deux nouveaux membres de l’équipe, Alejandro Colomar et Andrew Clayton, a donné un nouvel élan au développement. Nous avons donc aujourd’hui plusieurs nouveautés notables des versions 1.25 à 1.28 de NGINX Unit à vous présenter.

L’observabilité est désormais une réalité

L’observabilité a toujours été l’une des principales ambitions d’Unit, et la version 1.28.0 propose la première mouture de l’une des fonctionnalités les plus attendues : un moteur de statistiques. Ses données sont accessibles via le nouveau point de terminaison d’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 plupart des champs sont explicites : connections (ligne 2) et requests (ligne 9) fournissent des données à l’échelle de l’instance, tandis que l’objet applications (ligne 13) reflète /config/applications et couvre les processus et les requêtes propres à l’application.

Les lignes 3 à 6 présentent les quatre catégories de connexions suivies par NGINX Unit : « acceptées », « actives », « inactives » et « fermées ». Les catégories de processus sont « en cours d’exécution », « en cours de démarrage » et « inactifs » (lignes 16 à 18). Ces catégories reflètent la représentation interne des connexions et des processus ; vous en savez donc désormais autant à leur sujet que votre serveur.

Cela vous semble succinct ? C’est à peu près tout ce qu’il y a à savoir pour le moment. Bien sûr, nous travaillons à rendre disponibles davantage de métriques utiles. Toutefois, vous pouvez déjà interroger cette API depuis votre ligne de commande pour voir ce qui se passe sur votre serveur, et même intégrer les résultats dans un tableau de bord ou dans l’outil de votre choix pour une approche plus élaborée. Vous n’avez peut-être pas de tableau de bord ? Eh bien, nous envisageons notamment d’en proposer un intégré, alors suivez-nous pour voir comment tout cela évolue.

Pour plus de détails, consultez la section « Statistiques d’utilisation » de la documentation de NGINX Unit.

Plus de variables, plus d’endroits où les utiliser

La liste des variables introduites depuis la version 1.24 est assez longue et comprend $body_bytes_sent, $header_referer, $header_user_agent, $remote_addr, $request_line, $request_uri, $status et $time_local.

La plupart de ces variables sont assez simples à comprendre, mais voici quelques-unes des plus remarquables :

• $request_uri contient le chemin et la chaîne de requête de l’URI demandée, tout en préservant l’encodage du navigateur
• La variable au nom similaire « $request_line » stocke l’intégralité de la requête, par exemple GET /docs/help.html HTTP/1.1, et est destinée à la journalisation…
• Il en va de même pour « $status », qui contient le code d’état de la réponse HTTP

Vous avez remarqué ? Nous avons parlé des réponses. Oui, nous abordons également ce domaine : dans les versions précédentes de Unit, les variables étaient axées sur les requêtes entrantes, mais nous disposons désormais aussi de variables qui capturent les propriétés des réponses, telles que $status et $body_bytes_sent.

Concernant les nouveaux emplacements où utiliser des variables, il convient tout d’abord de mentionner le nouveau format personnalisable du journal d’accès. Vous souhaitez utiliser du JSON dans les entrées de journal de NGINX Unit ? En plus de spécifier une simple chaîne de chemin d’accès, l’option « access_log » peut être un objet qui définit également le format des entrées de journal :

{ 
    "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\" }" 
    } 
}

Ainsi, vous pouvez dépasser les limites du format de journalisation habituel comme bon vous semble.

Un deuxième cas d’utilisation notable des variables concerne la valeur location d’une action de route :

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

Ici, nous utilisons « $request_uri » pour transmettre la requête, y compris les paramètres de requête, au même site web via HTTPS.

L’option « chroot » prend désormais en charge les variables, tout comme l’option « share », ce qui est tout à fait logique :

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

NGINX Unit prend désormais également en charge les variables dynamiques. Les arguments de requête, les cookies et les en-têtes sont exposés sous forme de variables : par exemple, la chaîne de requête Type=car&Color=red génère deux variables d’argument, $arg_Type et $arg_Color. Lors de l’exécution, ces variables sont remplacées par des valeurs dynamiques ; si vous faites référence à une variable inexistante, elle est considérée comme vide.

Pour plus de détails, consultez la section « Variables » de la documentation de NGINX Unit.

Prise en charge étendue des en-têtes « X-Forwarded-* »

Vous l’avez demandé, nous l’avons fait. Depuis la version 1.25.0, NGINX Unit propose certaines fonctionnalités de configuration TLS pour ses écouteurs, notamment une prise en charge partielle de X-Forwarded-* ; vous pouvez désormais configurer les adresses IP des clients et le remplacement du protocole dans la configuration de vos écouteurs :

{
    "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"
                ]
            }
        }
    },
    ...
}

Remarque : Cette nouvelle syntaxe rend obsolète l’ancienne syntaxe client_ip, qui sera supprimée dans une prochaine version.

Pour plus de détails, consultez « Transfert d’adresses IP et de protocoles » dans la documentation de NGINX Unit.

La nouvelle option « share »

La version 1.11.0 de NGINX Unit a introduit l’option de routage « share » pour servir du contenu statique. Elle est comparable à la directive « root » de NGINX :

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

Initialement, l’option « share » indiquait ce que l’on appelle le répertoire racine des documents. Pour déterminer quel fichier servir, Unit ajoutait simplement l’URI de la requête à ce chemin « share ». Par exemple, en réponse à une simple requête GET portant sur /some/file.html, Unit servait le fichier /path/to/dir/some/file.html. Cependant, nous rencontrions régulièrement des cas limites nécessitant un contrôle plus précis du chemin d’accès au fichier. Nous avons donc décidé de faire évoluer ce fonctionnement. Depuis la version 1.26.0, l’option « share » indique le chemin complet d’un fichier partagé, et non plus seulement la racine des documents.

Vous souhaitez servir un fichier spécifique ? Très bien :

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

Utiliser des variables dans le chemin ? Aucun problème :

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

Mais comment reproduire le comportement auquel NGINX et les versions précédentes d’Unit vous ont habitué ? Vous savez, cette histoire de racine des documents que nous avons jugée obsolète quelques paragraphes plus haut ? Nous avons une solution.

Vous pouvez désormais réécrire les configurations comme ceci :

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

comme suit, en ajoutant explicitement l’URI demandée au chemin !

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

Enfin, la directive share peut désormais accepter un tableau de chemins et les essayer un par un jusqu’à ce qu’elle trouve un fichier :

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

Si aucun fichier n’est trouvé, le routage passe à une action « fallback » ; s’il n’y a pas de « fallback », le code d’état 404 (Not Found) est renvoyé.

Pour plus de détails, consultez la section « Fichiers statiques » de la documentation de NGINX Unit.

Projets : njs, réécriture d’URI, chaînage d’actions, OpenAPI

À l’heure où vous lisez ces lignes, nous travaillons déjà sur la prochaine version ; voici un aperçu de ce que nous vous réservons.

Tout d’abord, nous intégrons NGINX Unit au module JavaScript de NGINX (njs), un autre projet phare activement développé chez NGINX. En bref, cela signifie que NGINX Unit permettra d’appeler des modules JavaScript. Prenons cet exemple :

var hellonjs = {}

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

    } else {
        return 'default';
    }
}

export default hellonjs

Après avoir importé le module dans NGINX Unit, vous pourrez réaliser des choses intéressantes avec la configuration :

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

Nous souhaitons également introduire quelque chose de similaire à la très populaire directive rewrite de NGINX :

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

Mais nos projets ne s’arrêtent pas là. Et si nous reliions le routage de NGINX Unit à la sortie des applications elles-mêmes (autrement dit, le chaînage d’action )?

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

L’idée ici est que l’application auth_check authentifie la requête entrante et renvoie un code d’état indiquant le résultat. Si l’authentification réussit, le code 200 OK est renvoyé et la requête est transmise à my_app.

Parallèlement, nous travaillons également sur une spécification OpenAPI afin de définir une fois pour toutes l’API de NGINX Unit et ses capacités exactes. Souhaitez-nous bonne chance, car il s’agit d’une entreprise titanesque.

Si cela ne suffit toujours pas à satisfaire votre curiosité, consultez notre feuille de route pour découvrir nos projets dans les moindres détails ; elle est interactive, alors toutes vos suggestions, cher lecteur, sont les bienvenues.

À propos de l’auteur

Artem Konev

Autres articles de Artem Konev