NGINX Unit begrüßt den Herbst 2022 mit neuen Funktionen (einer Statistik-Engine!) und spannenden Plänen

Das Wichtigste zuerst: Es ist schon eine ganze Weile her, seit wir Neuigkeiten vom NGINX Unit-Team mitgeteilt haben – diese turbulenten Zeiten haben jeden betroffen, und wir sind da keine Ausnahme. Diesen März entschieden sich zwei Gründungsmitglieder des Unit-Teams, Valentin Bartenev und Maxim Romanov, sich anderen Möglichkeiten zuzuwenden, nachdem sie jahrelange Arbeit und jede Menge Kreativität in NGINX Unit gesteckt hatten. Geben wir Anerkennung, wo sie gebührt: Ohne sie wäre NGINX Unit nicht dort, wo es heute ist. Ein großes Lob, Jungs.

Dennoch bleiben wir fest entschlossen und engagieren uns weiterhin dafür, die ursprünglichen Ziele des NGINX-Mitbegründers Igor Sysoev für die NGINX Unit zu verwirklichen. Die Ankunft der beiden neusten Teammitglieder, Alejandro Colomar und Andrew Clayton, hat die Entwicklungsanstrengungen beschleunigt, sodass wir nun einige bemerkenswerte Neuerungen aus den NGINX Unit-Versionen 1.25 bis 1.28 mit Ihnen teilen können.

Observability ist jetzt ein Thema

Eines der wichtigsten Ziele von Unit war schon immer die Beobachtbarkeit, und Version 1.28.0 enthält die erste Iteration einer der mit größter Spannung erwarteten Funktionen: eine Statistik-Engine. Seine Ausgabe wird am neuen /status API-Endpunkt angezeigt:

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

{
"Verbindungen": {
"Akzeptiert": 1067,
"aktiv": 13,
"Leerlauf": 4,
„geschlossen“: 1050
},

"Anfragen": {
"Gesamt": 1307
},

„Anwendungen“: {
„wp“: {
„Prozesse“: {
„Ausgeführt“: 14,
"beginnend": 0,
"Leerlauf": 4
},

"Anfragen": {
"aktiv": 10 } } } }

Die meisten Felder hier sind selbstbeschreibend: Verbindungen (Zeile 2) und Anforderungen (Zeile 9) stellen instanzweite Daten bereit, während das Anwendungsobjekt (Zeile 13) /config/applications widerspiegelt und Prozesse und Anforderungen abdeckt, die speziell die Anwendung betreffen.

Die Zeilen 3 bis 6 zeigen die vier Kategorien von Verbindungen, die von der NGINX-Einheit verfolgt werden: akzeptiert , aktiv , inaktiv und geschlossen . Die Kategorien für Prozesse sind „läuft“ , „wird gestartet “ und „im Leerlauf“ (Zeilen 16–18). Diese Kategorien spiegeln die interne Darstellung von Verbindungen und Prozessen wider, sodass Sie jetzt genauso viel über sie wissen wie Ihr Server.

Scheint knapp? Das ist im Moment so ziemlich alles, was es zu wissen gibt. Natürlich arbeiten wir daran, weitere nützliche Messdaten verfügbar zu machen. Sie können diese API jedoch bereits jetzt über die Befehlszeile abfragen, um zu sehen, was auf Ihrem Server vor sich geht, und die Ausgabe sogar in ein Dashboard oder einen etwas ausgefalleneren Ansatz Ihrer Wahl einbinden. Vielleicht haben Sie kein Dashboard? Zu unseren Plänen gehört teilweise auch die Bereitstellung eines integrierten Tools. Folgen Sie uns also, um zu sehen, wie sich das entwickelt.

Weitere Einzelheiten finden Sie unter „Nutzungsstatistiken“ in der NGINX Unit-Dokumentation.

Mehr Variablen, mehr Einsatzmöglichkeiten

Die Liste der seit Version 1.24 eingeführten Variablen ist ziemlich umfangreich und umfasst $body_bytes_sent , $header_referer , $header_user_agent , $ remote_addr , $ request_line , $request_uri , $status und $time_local .

Die meisten davon sind ziemlich unkompliziert, aber hier sind einige der bemerkenswerteren:

• $request_uri enthält den Pfad und die Abfrage der angeforderten URI unter Beibehaltung der Browsercodierung
• Die ähnlich benannte $request_line speichert die gesamte Anfrage, beispielsweise GET /docs/help.html HTTP/1.1 , und ist für die Protokollierung gedacht…
• Ebenso gilt $status , das den HTTP-Antwortstatuscode enthält.

Ist Ihnen das aufgefallen? Wir haben Antworten erwähnt. Ja, auch wir bewegen uns in dieses Gebiet: Die Variablen in früheren Unit-Versionen konzentrierten sich auf eingehende Anfragen, aber jetzt haben wir Variablen, die auch die Antworteigenschaften erfassen, wie etwa $status und $body_bytes_sent .

Was die neuen Einsatzmöglichkeiten von Variablen betrifft, ist als Erstes das neue anpassbare Zugriffsprotokollformat zu nennen. Möchten Sie JSON in den Protokolleinträgen der NGINX-Einheit verwenden? Zusätzlich zur Angabe einer einfachen Pfadzeichenfolge kann die Option access_log ein Objekt sein, das auch das Format der Protokolleinträge festlegt:

{ 
"access_log": {
"Pfad": "/var/log/unit/access.log", 
"Format": "{ \"remote_addr\":\"$remote_addr\", "Zeit\":\"$time_local\", \"Anfrage\":\"$request_line\", \"Antwort\":\"$status\", \"header_referer\":\"$header_referer\", \"header_user_agent\":\"$header_user_agent\" }" 
} 
}

Sie können also über das übliche Protokollformat beliebig hinausgehen.

Ein zweiter bemerkenswerter Anwendungsfall für Variablen ist der Standortwert einer Routenaktion :

{ 
"Aktion": { 
"Rückgabe": 301, 
"Standort": "https://$host$request_uri" 
} 
}

Hier verwenden wir $request_uri , um die Anfrage, einschließlich des Abfrageteils, über HTTPS an dieselbe Website weiterzuleiten.

Die Option chroot unterstützt nun Variablen, genau wie die Option share , was nur logisch ist:

{ 
"Aktion": { 
"Teilen": "/www$uri",
"chroot": "/www/data/$host/" 
} 
} 

NGINX Unit unterstützt jetzt auch dynamische Variablen. Anforderungsargumente, Cookies und Header werden als Variablen verfügbar gemacht: Beispielsweise führt die Abfragezeichenfolge Type=car&Color=red zu zwei Argumentvariablen, $arg_Type und $arg_Color . Zur Laufzeit werden diese Variablen in dynamische Werte erweitert. Wenn Sie auf eine nicht vorhandene Variable verweisen, wird sie als leer betrachtet.

Weitere Einzelheiten finden Sie unter „Variablen“ in der NGINX-Unit-Dokumentation.

Umfassende Unterstützung für die X-Forwarded-*- Header

Sie haben gefragt, und wir haben geliefert. Ab Version 1.25.0 bietet NGINX Unit einige TLS-Konfigurationsmöglichkeiten für seine Listener, darunter ein gewisses Maß an X-Forwarded-*- Bewusstsein. Jetzt können Sie Client-IP-Adressen und Protokollersetzungen in der Konfiguration für Ihre Listener konfigurieren:

{
"Listener": {
"*:80": {
"Pass": "Routen/meine-App",
"Weitergeleitet": {
"Client-IP": "X-Forwarded-For",
"Protokoll": "X-Forwarded-Proto",
"rekursiv": falsch,
"Quelle": [
"198.51.100.1-198.51.100.254",
"!198.51.100.128/26",
"203.0.113.195"
]
}
}
},
...
}

Notiz: Diese neue Syntax macht die vorherige client_ip -Syntax veraltet und wird in einer zukünftigen Version entfernt.

Weitere Einzelheiten finden Sie unter „IP, Protokollweiterleitung“ in der NGINX-Unit-Dokumentation.

Die überarbeitete Aktienoption

NGINX Unit Version 1.11.0 führte die Share- Routing-Option zum Bereitstellen statischer Inhalte ein. Es ist vergleichbar mit der Root -Direktive in NGINX:

{
"share": "/Pfad/zum/Verzeichnis/"
}

Ursprünglich wurde mit der Freigabeoption das sogenannte Dokumentstammverzeichnis angegeben. Um zu bestimmen, welche Datei bereitgestellt werden soll, hat Unit einfach die URI aus der Anforderung an diesen Freigabepfad angehängt. Beispielsweise hat Unit als Antwort auf eine einfache GET- Anfrage für /some/file.html /path/to/dir/some/file.html bereitgestellt. Dennoch stießen wir immer wieder auf Grenzfälle, die eine feinere Kontrolle des Dateipfads erforderten. Daher entschieden wir uns für eine Weiterentwicklung. Ab Version 1.26.0 gibt die Share -Option den vollständigen Pfad zu einer freigegebenen Datei an und nicht nur das Dokumentstammverzeichnis.

Sie möchten eine bestimmte Datei bereitstellen? Bußgeld:

{
"share": "/Pfad/zu/einer/Datei.html"
}

Variablen innerhalb des Pfades verwenden? Cool, kein Problem:

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

Aber wie können Sie das Verhalten imitieren, das Sie bereits von NGINX und früheren Unit-Versionen gewohnt sind? Wissen Sie, die Sache mit dem Dokumentstamm, die wir vor ein paar Absätzen für überholt erklärt haben? Wir haben eine Lösung.

Sie können Konfigurationen jetzt wie folgt neu schreiben:

{
"teilen": "/www/data/"
}

wie folgt, wobei die angeforderte URI an den Pfad angehängt wird, aber explizit!

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

Schließlich kann die Share- Direktive jetzt ein Array von Pfaden akzeptieren und diese nacheinander ausprobieren, bis sie eine Datei findet:

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

Wenn keine Datei gefunden wird, wird die Weiterleitung an einen zurückgreifen Aktion; wenn es keine zurückgreifen, Die 404 (Nicht Gefunden) Statuscode wird zurückgegeben.

Weitere Einzelheiten finden Sie unter „Statische Dateien“ in der NGINX-Unit-Dokumentation.

Pläne: njs, URI-Neuschreibung, Action Chaining, OpenAPI

Während Sie dies lesen, arbeiten wir bereits an der nächsten Version. Hier erhalten Sie einen kleinen Vorgeschmack auf das, was wir in petto haben.

Zunächst integrieren wir NGINX Unit mit dem NGINX JavaScript-Modul ( njs ), einem weiteren Arbeitspferdprojekt, das bei NGINX aktiv entwickelt wird. Kurz gesagt bedeutet dies, dass NGINX Unit das Aufrufen von JavaScript-Modulen unterstützt. Bedenken Sie Folgendes:

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

    } else { return 'default';
    } } Standard-Hallonjs exportieren

Nachdem Sie das Modul in NGINX Unit importiert haben, können Sie mit der Konfiguration einige interessante Dinge tun:

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

Darüber hinaus möchten wir etwas Ähnliches wie die allseits beliebte NGINX- Umschreibdirektive einführen:

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

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

Unsere Pläne enden hier jedoch nicht. Wie wäre es, das Routing der NGINX-Einheit mit der Ausgabe der Apps selbst zu verknüpfen (auch als Aktionsverkettung bekannt)?

{
"Aktion": [
{
"Pass": "Anwendungen/Authentifizierungsprüfung"
},
{
"Pass": "Anwendungen/meine_App"
}
]
}

Die Idee besteht darin, dass die auth_check -App die eingehende Anfrage authentifiziert und einen Statuscode zurückgibt, um das Ergebnis anzuzeigen. Wenn die Authentifizierung erfolgreich ist,200 „OK“ wird zurückgegeben und die Anfrage wird an my_app weitergeleitet.

In der Zwischenzeit arbeiten wir auch an einer OpenAPI- Spezifikation, um die API der NGINX Unit und ihre genauen Funktionen ein für alle Mal zu definieren. Wünscht uns Glück, denn das ist ein Mammutunterfangen.

Wenn das Ihre Neugier noch nicht befriedigt, finden Sie in unserer Roadmap eine detaillierte Aufschlüsselung unserer Pläne. Sie ist interaktiv, daher ist jeder Input von Ihnen, lieber Leser, herzlich willkommen.