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

Tout d’abord, cela fait un certain temps que nous n’avons pas partagé de nouvelles de l’équipe de l’unité NGINX. Ces temps tumultueux ont affecté 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 d'autres opportunités après avoir consacré des années de travail et des tonnes de créativité à NGINX Unit . Rendons à César ce qui appartient à César : sans eux, NGINX Unit ne serait pas là où il est aujourd'hui. Bravo les gars.

Néanmoins, notre détermination reste forte, tout comme notre engagement à concrétiser les aspirations initiales du cofondateur de NGINX, Igor Sysoev, pour NGINX Unit. L'arrivée des deux nouveaux membres de l'équipe, Alejandro Colomar et Andrew Clayton, a stimulé l'effort de développement, nous avons donc maintenant quelques éléments remarquables des versions 1.25 à 1.28 de NGINX Unit à partager avec vous.

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

L’une des principales aspirations d’Unit a toujours été l’observabilité, et la version 1.28.0 inclut la première itération de l’une des fonctionnalités les plus attendues : un moteur de statistiques. Sa sortie est exposée au nouveau point de terminaison de l'API /status :

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

{
"connexions": {
"accepté": 1067,
"actif": 13,
"inactif" : 4,
"fermé" : 1050
},

"requêtes": {
"total": 1307
},

"applications": {
"wp": {
"processus": {
"en cours d'exécution": 14,
"début" : 0,
"inactif" : 4
},

"requêtes": {
"active": 10 } } } }

La plupart des champs ici sont autodescriptifs : les connexions (ligne 2) et les requêtes (ligne 9) fournissent des données à l'échelle de l'instance, tandis que l'objet applications (ligne 13) reflète /config/applications , couvrant les processus et les requêtes qui concernent spécifiquement l'application.

Les lignes 3 à 6 montrent les quatre catégories de connexions suivies par NGINX Unit : acceptée , active , inactive et fermée . Les catégories de processus sont en cours d’exécution , en démarrage et inactif (lignes 16 à 18). Ces catégories reflètent la représentation interne des connexions et des processus, vous en savez donc désormais autant que votre serveur.

Cela semble concis ? C’est à peu près tout ce qu’il y a à savoir pour l’instant. Bien sûr, nous travaillons à exposer des mesures plus utiles ; cependant, vous pouvez déjà interroger cette API à partir de votre ligne de commande pour voir ce qui se passe sur votre serveur et même brancher la sortie dans un tableau de bord ou votre choix pour une approche plus fantaisiste. Peut-être que vous n’avez pas de tableau de bord ? Eh bien, certains de nos plans incluent la fourniture d’un modèle intégré, alors suivez-nous pour voir comment cela se passe.

Pour plus de détails, consultez Statistiques d'utilisation dans la documentation de l'unité NGINX.

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

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

La plupart d’entre elles sont assez simples, mais voici quelques-unes des plus remarquables :

• $request_uri contient le chemin et la requête de l'URI demandée avec l'encodage du navigateur préservé
• La ligne $request_line, portant un nom similaire, stocke l'intégralité de la requête, telle que GET /docs/help.html HTTP/1.1 , et est destinée à la journalisation…
• Comme $status qui contient le code d'état de la réponse HTTP

Avez-vous remarqué ? Nous avons mentionné des réponses. Oui, nous évoluons également sur ce territoire : les variables des versions antérieures d'Unit se concentraient sur les requêtes entrantes, mais nous disposons désormais de variables qui capturent également les propriétés de réponse, telles que $status et $body_bytes_sent .

En ce qui concerne les nouveaux endroits où utiliser des variables, le premier à mentionner est le nouveau format de journal d'accès personnalisable. Vous souhaitez utiliser JSON dans les entrées de journal de NGINX Unit ? En plus de spécifier une chaîne de chemin simple, 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 aller au-delà du format de journal habituel comme vous le souhaitez.

Un deuxième cas d’utilisation notable pour les variables est la valeur d’emplacement d’une action d’itinéraire :

{ 
"action": { 
"retour": 301, 
"emplacement": "https://$host$request_uri" 
} 
}

Ici, nous utilisons $request_uri pour relayer la requête, y compris la partie 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/" 
} 
} 

L'unité NGINX 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 se développent en valeurs dynamiques ; si vous référencez une variable inexistante, elle est considérée comme vide.

Pour plus de détails, voir Variables dans la documentation de l'unité NGINX.

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

Vous l'avez demandé et nous l'avons fait. À partir de la version 1.25.0, NGINX Unit a proposé certaines fonctionnalités de configuration TLS pour ses écouteurs, notamment un degré de prise en charge 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",
"protocole" : "X-Forwarded-Proto",
"récursif" : false,
"source" : [
"198.51.100.1-198.51.100.254",
"!198.51.100.128/26",
"203.0.113.195"
]
}
}
},
...
}

Note: Cette nouvelle syntaxe rend obsolète la syntaxe client_ip précédente, qui sera supprimée dans une future version.

Pour plus de détails, voir IP, Protocol Forwarding dans la documentation de l'unité NGINX.

L'option d'actions remaniée

La version 1.11.0 de NGINX Unit a introduit l'option de routage de partage pour la diffusion de contenu statique. C'est comparable à la directive root dans NGINX :

{
"share": "/chemin/vers/répertoire/"
}

Initialement, l’option de partage spécifiait le répertoire racine du document. Pour déterminer quel fichier servir, Unit a simplement ajouté l'URI de la demande à ce chemin de partage . Par exemple, en réponse à une simple requête GET pour /some/file.html , Unit a servi /path/to/dir/some/file.html . Cependant, nous avons continué à rencontrer des cas limites qui nécessitaient un contrôle plus précis sur le chemin du fichier, nous avons donc décidé d'évoluer. À partir de la version 1.26.0, l'option de partage spécifie le chemin d'accès complet à un fichier partagé plutôt que simplement la racine du document.

Vous souhaitez servir un fichier spécifique ? Bien:

{
"share": "/chemin/vers/un/fichier.html"
}

Utiliser des variables dans le chemin ? Cool, pas de problème :

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

Mais comment imiter le comportement auquel vous êtes déjà habitué avec NGINX et les versions précédentes d’Unit ? Vous savez, la racine du document que nous avons jugée obsolète il y a quelques paragraphes ? Nous avons une solution.

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

{
"partager": "/www/data/"
}

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

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

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

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

Si aucun fichier n'est trouvé, le routage passe à un retomber action ; s'il n'y a pas retomber, le 404 (Pas Trouvé) le code d'état est renvoyé.

Pour plus de détails, consultez Fichiers statiques dans la documentation de l'unité NGINX.

Plans : njs, réécriture d'URI, chaînage d'actions, OpenAPI

Pendant que vous lisez ceci, nous travaillons déjà sur la prochaine version ; voici un aperçu de ce que nous avons en réserve.

Tout d'abord, nous intégrons NGINX Unit au module JavaScript NGINX ( njs ), un autre projet phare en cours de développement chez NGINX. En bref, cela signifie que NGINX Unit prendra en charge l'appel de modules JavaScript. Considérez ceci :

var hellonjs = {} hellonjs.hello = function(vars) { if ('unitvar' dans vars) { return vars.unitvar;

    } else { return 'par défaut';
    } } exporter les hellonjs par défaut

Après avoir importé le module dans NGINX Unit, vous pourrez effectuer des opérations intéressantes avec la configuration :

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

Nous souhaitons également introduire quelque chose de similaire à la directive de réécriture NGINX toujours populaire :

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

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

Mais nos projets ne s’arrêtent pas là. Que diriez-vous de lier le routage de l'unité NGINX à la sortie des applications elles-mêmes (AKA chaînage d'actions ) ?

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

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

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

Si cela ne suffit toujours pas à satisfaire votre curiosité, référez-vous à notre feuille de route pour une analyse détaillée de nos plans ; elle est interactive, donc toute contribution de votre part, cher lecteur, est la bienvenue.