Wir freuen uns, Ihnen mitteilen zu können, dass NGINX Plus Release 21 (R21) jetzt verfügbar ist. NGINX Plus basiert auf NGINX Open Source und ist der einzige All-in-One- Load Balancer, Inhaltscache, Webserver und API-Gateway. Da mehr als 450 Millionen Websites auf NGINX vertrauen , ist NGINX Plus R21 zuverlässiger und sicherer als je zuvor und konzentriert sich in erster Linie auf Fehlerbehebungen und Stabilitätsverbesserungen von NGINX Open Source.
Zu den neuen Funktionen von NGINX Plus R21 gehören:
Host-
Headern mehr.Effiziente Software und Codequalität sind zentrale Grundsätze bei der Entwicklung von NGINX, sowohl Open Source als auch NGINX Plus.
Das NGINX-Team verwendet alle modernen CI/CD- und automatisierten Testtools, die Sie von jeder kommerziellen Software erwarten. Tägliche Tests des aktiven Entwicklungszweigs zeigen eine bemerkenswert niedrige „Fehlerdichte“ von nur 0,01 Fehlern pro 1000 Codezeilen, verglichen mit einer durchschnittlichen Dichte von 0,7 Fehlern pro 1000 Zeilen bei Codebasen ähnlicher Größe.
Wir beauftragen auch externe und unabhängige Penetrationstests und Codeüberprüfungen sowohl für Open Source- als auch für NGINX Plus-Komponenten. Bei den jüngsten Penetrationstests und Codeüberprüfungen wurden mehrere Probleme festgestellt, die in dieser Version behoben wurden.
Insgesamt enthält NGINX Plus R21 Korrekturen für 14 Fehler:
AIO-
Direktive494
wurde zurückgegeben statt400
wenn Fehler mit Code494
wurden mit der error_page
-Direktive umgeleitetUmschreibeanweisung
mit einer leeren Ersetzungszeichenfolge enthielt.„break
“ in Verbindung mit der Direktive „alias“
oder in Verbindung mit der Direktive „proxy_pass“
mit einer URI verwendet wird.Transfer-Encoding-
Anforderungsheader wurde verarbeitetder Location
-Antwort enthält möglicherweise Datenmüll, wenn die Anforderungs-URI in eine Zeile mit Nullzeichen umgeschrieben wurde.error_page
zurückgegeben wurdendebug_points
-Direktive bei Verwendung von HTTP/2Bitte beachten Sie, dass keiner dieser Fehler kritisch war und keine zugehörigen CVE-Einträge vorhanden sind.
Zum Zeitpunkt dieser Veröffentlichung arbeiten wir intensiv an unserer Roadmap für 2020. Später in diesem Jahr erwarten wir, eine produktionsreife Implementierung von HTTP/3 (auch bekannt als QUIC) verfügbar zu machen. Wenn Sie daran interessiert sind, diese Technologie zu verfolgen oder zu testen, achten Sie in den kommenden Wochen auf experimentelle Patches.
NGINX Plus R15 führte die Unterstützung für das Routing und den Lastenausgleich von gRPC-Verkehr zu Upstream-Gruppen ein. Sie können NGINX Plus nutzen, um gRPC-Verkehr weiterzuleiten, indem Sie die Direktive grpc_pass
einschließen.
NGINX Plus R21 führt Variablenunterstützung in der grpc_pass-
Direktive ein, um dynamische, API-gesteuerte Routing-Richtlinien bereitzustellen, die sich auf gRPC-Workloads erstrecken. Dadurch können Anwendungsfälle erfüllt werden wie:
Die folgende Konfiguration ist eine Beispielimplementierung des Debug-Routings.
In Zeile 1 definieren wir einen Schlüssel-Wert-Speicher, der Netzwerkbereiche als Schlüssel verwenden kann (aktiviert durch den Parameter type=ip
). Zeile 2 gibt an, dass die Variable „$greeter_upstream“
ausgewertet wird, indem eine Suche im Schlüssel-Wert-Speicher von „grpc-greeter“ durchgeführt wird, wobei die Client-IP-Adresse ( $remote_addr
) als Schlüssel verwendet wird.
In Zeile 10 geben wir grpc://$greeter_upstream
als Parameter für die grpc_pass-
Direktive an, für die TLS-Terminierung und das dynamische Routing von gRPC-Anfragen basierend auf dem IP-Subnetz des Clients.
Sie können beispielsweise den folgenden Befehl auf der NGINX Plus-Instanz ausführen, um Anfragen aus dem Subnetz 192.168.80.0/24 an grpc-servers-greeter-debug weiterzuleiten:
$ curl -iX POST -d '{"192.168.80.0/24":"grpc-servers-greeter-debug"}' http://localhost:8080/api/6/http/keyvals/grpc-greeter
Um den gRPC-Verkehr auf die Produktionsdienstgruppe ( grpc-servers-greeter-prod ) umzuschalten, führen Sie den folgenden Befehl aus:
$ curl -iX PATCH -d '{"192.168.80.0/24":"grpc-servers-greeter-prod"}' https://localhost:8080/api/6/http/keyvals/grpc-greeter
Das NGINX JavaScript-Modul (njs) wurde mit mehreren Fehlerbehebungen und einigen Funktionsverbesserungen in Bezug auf Unteranforderungen und Dateisystemunterstützung auf Version 0.3.9 aktualisiert.
Die Funktion r.subrequest
ermöglicht es njs-Code, asynchrone HTTP-Anfragen an jede URI zu stellen. Dies hat viele mögliche Anwendungsfälle, ein bemerkenswertes Beispiel sind API-Aufrufe an einen externen Authentifizierungsserver, beispielsweise OAuth 2.0-Token-Introspektion . Diese Version enthält zwei wesentliche Verbesserungen für Unteranfragen: Versprechen und getrennte Unteranfragen.
[ Herausgeber – Die folgenden beiden Beispielanwendungsfälle sind nur einige von vielen für das NGINX JavaScript-Modul. Eine vollständige Liste finden Sie unter Anwendungsfälle für das NGINX-JavaScript-Modul . ]
Unteranfragen enthalten normalerweise eine Rückruffunktion, die die Antwort der Unteranfrage verarbeitet. Auf eine Rückruffunktion kann jetzt verzichtet werden. Stattdessen können JavaScript-Promises verwendet werden, um Antworten inline mit dem aufrufenden Code zu verarbeiten. Das folgende Beispiel veranschaulicht, wie aufeinanderfolgende Unteranforderungen ohne Verwendung von Rückrufen in einer einzigen Codesequenz miteinander verkettet werden können.
Unteranforderungen sind asynchron und mussten zuvor über eine js_content-
Direktive aufgerufen werden. Nun können Subrequests auch aus einer js_set-
Direktive während der Variablenauswertung ausgelöst werden. Diese „getrennten“ Unteranforderungen arbeiten zwar immer noch asynchron, geben jedoch keine Daten an die aufrufende Funktion zurück und alle Antworten werden ignoriert.
Der folgende Beispielcode verwendet getrennte Unteranforderungen, um eine Kopie der Anforderungsheader an ein Sicherheitsinformations- und Ereignismanagementsystem ( SIEM ) zu senden, wenn die Gesamtmenge der ausgetauschten Daten 1 MB überschreitet.
[ Editor – Die folgende Konfiguration wurde aktualisiert, um die Direktive js_import
zu verwenden, die die Direktive js_include
in NGINX Plus R23<.htmla> ersetzt hat. Weitere Informationen finden Sie in der Referenzdokumentation für das NGINX-JavaScript-Modul – der Abschnitt „Beispielkonfiguration“ zeigt die richtige Syntax für die NGINX-Konfiguration und JavaScript-Dateien.]
Der JavaScript-Code wird dann in der Protokollphase ausgeführt, indem er beim Schreiben des Zugriffsprotokolls eine Variablenauswertung anfordert.
Das JavaScript-Dateisystemobjekt fs
wurde erweitert, um Promises für asynchrone Vorgänge zu unterstützen. Darüber hinaus gibt es neue Dateisystemmethoden: access()
, realpath()
, symlink()
und unlink()
.
Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich auf NGINX Plus R21 zu aktualisieren. Sie erhalten außerdem eine Reihe zusätzlicher Fehlerbehebungen und Verbesserungen und NGINX kann Ihnen helfen, wenn Sie ein Support-Ticket erstellen müssen.
Bitte überprüfen Sie die in diesem Blogbeitrag beschriebenen neuen Funktionen und Verhaltensänderungen sorgfältig, bevor Sie mit dem Upgrade fortfahren.
Wenn Sie NGINX Plus noch nicht ausprobiert haben, empfehlen wir Ihnen, es auszuprobieren – für Sicherheit, Lastausgleich und API-Gateway oder als vollständig unterstützten Webserver mit erweiterten Überwachungs- und Verwaltungs-APIs. Sie können noch heute mit einer kostenlosen 30-Tage-Testversion beginnen. Überzeugen Sie sich selbst, wie NGINX Plus Ihnen bei der Bereitstellung und Skalierung Ihrer Anwendungen helfen kann.
„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."