Wir freuen uns, Ihnen mitteilen zu können, dass NGINX Plus Release 21 (R21) ab sofort verfügbar ist. NGINX Plus basiert auf NGINX Open Source und ist der einzige All-in-One-Load-Balancer, Content-Cache, Webserver und API-Gateway. Mehr als 450 Millionen Websites setzen auf NGINX. Damit ist NGINX Plus R21 zuverlässiger und sicherer als je zuvor. Der Schwerpunkt liegt vor allem auf Fehlerbehebungen und Stabilitätsverbesserungen aus NGINX Open Source.
Zu den neuen Funktionen von NGINX Plus R21 gehören:
- Dynamisches gRPC-Proxying – Wir haben Unterstützung für Variablen bei der Weiterleitung von gRPC-Verbindungen an gRPC-Backend-Dienste hinzugefügt. Dadurch können Sie gRPC-Verbindungen basierend auf Clientattributen dynamisch an Dienstgruppen weiterleiten.
- Verbesserungen am NGINX-JavaScript-Modul – Das NGINX-JavaScript-Modul (njs) wurde auf Version 0.3.9 aktualisiert und umfasst mehrere Fehlerbehebungen sowie zusätzliche funktionale Verbesserungen für Unteranfragen und die Dateisystemunterstützung.
Wichtige Verhaltensänderungen
- Zulässige Anfragen – Gemäß RFC 7230 lässt NGINX Plus keine Clientanfragen mit mehreren
Host-Headern mehr zu. - Neue unterstützte Betriebssysteme – Alpine Linux 3.11.
- Ältere Betriebssysteme werden nicht mehr unterstützt – 32-Bit-Plattformen (i386-Architekturen).
Investitionen in Qualität
Effiziente Software und hohe Codequalität sind zentrale Grundsätze bei der Entwicklung von NGINX – sowohl bei der Open-Source-Version als auch bei NGINX Plus.
Das NGINX-Team setzt alle modernen CI/CD- und automatisierten Testtools ein, die Sie von kommerzieller Software erwarten. Tägliche Tests des aktiven Entwicklungszweigs ergeben eine bemerkenswert niedrige „Fehlerdichte“ von nur 0,01 Fehlern pro 1.000 Codezeilen, verglichen mit einer durchschnittlichen Dichte von 0,7 Fehlern pro 1.000 Zeilen bei Codebasen ähnlicher Größe.
Wir beauftragen außerdem 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 dieser Penetrationstests und Codeüberprüfungen wurden mehrere Probleme festgestellt, die in dieser Version behoben werden.
Fehlerbehebungen
Insgesamt enthält NGINX Plus R21 Korrekturen für 14 Fehler:
- Socket-Leck bei Verwendung von HTTP/2 (zwei separate Fehler)
- Socket-Leck bei der Verwendung von Unteranfragen im njs-Modul und der
aio-Direktive - Mögliche Speichererschöpfung im WebDav-Modul
- Mögliche Offenlegung von Speicherinhalten im MP4-Modul
- Der Statuscode
494wurde anstelle von400zurückgegeben, wenn Fehler mit dem Code494mit der Direktiveerror_pageumgeleitet wurden - Bei der Verarbeitung von Pipeline-Anfragen in einer SSL-Verbindung kann es zu einer Zeitüberschreitung kommen
- Bei Verwendung von „OCSP-Stapling“ kann in einem Worker-Prozess ein Segmentierungsfehler auftreten.
- Beim Start oder während der Neukonfiguration kann ein Segmentierungsfehler auftreten, wenn die Konfiguration die
rewrite-Direktive mit einer leeren Ersetzungszeichenfolge enthält - In einem Worker-Prozess kann ein Segmentierungsfehler auftreten, wenn die Direktive „
break“ zusammen mit der Direktive „alias“ oder zusammen mit der Direktive „proxy_pass“ mit einem URI verwendet wurde. - Nur der erste
Transfer-Encoding-Anfrageheader wurde verarbeitet - Die
Location-Antwortheaderzeile kann ungültige Daten enthalten, wenn der Anfrage-URI so umgeschrieben wurde, dass er ein Nullzeichen enthält - Anfragen mit einem Body wurden bei der Rückgabe von Weiterleitungen mit der
error_page-Direktive nicht korrekt verarbeitet - Fehler in der
debug_points-Direktive bei Verwendung von HTTP/2
Bitte beachten Sie, dass keiner dieser Fehler kritisch war und keine zugehörigen CVE-Einträge vorliegen.
Investitionen in die NGINX Plus Roadmap
Zum Zeitpunkt dieser Veröffentlichung arbeiten wir intensiv an unserer Roadmap für 2020. Im weiteren Jahresverlauf werden wir voraussichtlich eine produktionsreife Implementierung von HTTP/3 (auch bekannt als QUIC) bereitstellen. Wenn Sie die Entwicklung dieser Technologie verfolgen oder sie testen möchten, halten Sie in den kommenden Wochen Ausschau nach experimentellen Patches.
Neue Funktionen im Detail
Dynamisches gRPC-Proxying
NGINX Plus R15 führte die Unterstützung für das Routing und den Lastenausgleich von gRPC-Datenverkehr zu Upstream-Gruppen ein. Sie können NGINX Plus für das Routing von gRPC-Datenverkehr nutzen, indem Sie die Direktive grpc_pass einbinden.
NGINX Plus R21 führt die Unterstützung von Variablen in der grpc_pass-Direktive ein und ermöglicht damit dynamische, API-gesteuerte Routing-Richtlinien, die auch für gRPC-Workloads gelten. Dadurch lassen sich unter anderem folgende Anwendungsfälle abdecken:
- A/B-Tests – gRRC-Anfragen statistisch auf mehrere Upstreams verteilen, um zu ermitteln, welcher davon eine bessere Leistung erzielt.
- Debug-Routing – Leiten Sie den Datenverkehr an einen produktiven gRPC-Dienst weiter, Anforderungen mit bestimmten Attributen (Quell-IP-Adressen, gRPC-Metadaten) jedoch an einen gRPC-Debug-Dienst.
Die folgende Konfiguration zeigt eine beispielhafte Implementierung des Debug-Routings.
Codebeispiel wird geladen…
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 legt fest, dass die Variable $greeter_upstream durch eine Suche im Schlüssel-Wert-Speicher grpc-greeter ausgewertet wird, wobei die IP-Adresse des Clients ($remote_addr) als Schlüssel verwendet wird.
In Zeile 10 geben wir grpc://$greeter_upstream als Parameter für die grpc_pass-Direktive an, um TLS zu terminieren und gRPC-Anfragen dynamisch anhand des IP-Subnetzes des Clients weiterzuleiten.
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-greeterFühren Sie den folgenden Befehl aus, um den gRPC-Datenverkehr auf die Produktionsdienstgruppe (grpc-servers-greeter-prod) umzuleiten:
$ curl -iX PATCH -d '{"192.168.80.0/24":"grpc-servers-greeter-prod"}' https://localhost:8080/api/6/http/keyvals/grpc-greeterVerbesserungen am NGINX-JavaScript-Modul
Das NGINX-JavaScript-Modul (njs) wurde auf Version 0.3.9 aktualisiert und enthält mehrere Fehlerbehebungen sowie einige funktionale Verbesserungen im Zusammenhang mit Unteranfragen und der Dateisystemunterstützung.
Unteranfragen
Die Funktion r.subrequest ermöglicht es njs-Code, asynchrone HTTP-Anfragen an einen beliebigen URI zu senden. Dafür gibt es viele mögliche Anwendungsfälle. Ein wichtiges Beispiel sind API-Aufrufe an einen externen Authentifizierungsserver, etwa zur OAuth 2.0-Token-Introspektion. Diese Version bietet zwei wesentliche Verbesserungen für Unteranfragen: Promises und entkoppelte Unteranfragen.
[Redaktion – Die folgenden beiden Anwendungsbeispiele sind nur zwei von vielen für das NGINX JavaScript-Modul. Eine vollständige Liste finden Sie unter „Anwendungsfälle für das NGINX JavaScript-Modul“. ]
Promises
Untergeordnete Anfragen enthalten in der Regel eine Callback-Funktion, die die Antwort auf die untergeordnete Anfrage verarbeitet. Eine Callback-Funktion kann nun weggelassen werden, indem JavaScript-Promises verwendet werden, um Antworten direkt im aufrufenden Code zu verarbeiten. Das folgende Beispiel zeigt, wie aufeinanderfolgende untergeordnete Anfragen ohne Callbacks in einer einzigen Codesequenz miteinander verkettet werden können.
Codebeispiel wird geladen…
Losgelöste Unteranfragen
Unteranfragen werden asynchron ausgeführt und mussten bisher über eine js_content-Direktive aufgerufen werden. Jetzt können Unteranfragen während der Variablenauswertung auch über eine js_set-Direktive ausgelöst werden. Diese „losgelösten“ Unteranfragen werden weiterhin asynchron ausgeführt, geben jedoch keine Daten an die aufrufende Funktion zurück, und jegliche Antwort wird ignoriert.
Der folgende Beispielcode verwendet losgelöste Unteranfragen, um eine Kopie der Anfrage-Header an ein Security-Information-and-Event-Management-System (SIEM) zu senden, wenn die insgesamt ausgetauschte Datenmenge 1 MB überschreitet.
[Redaktion – Die folgende Konfiguration wurde aktualisiert und verwendet nun die js_import-Direktive, welche die js_include-Direktive in NGINX Plus R23<.htmla> ersetzt hat. Weitere Informationen finden Sie in der Referenzdokumentation zum NGINX-JavaScript-Modul – im Abschnitt Beispielkonfiguration wird die korrekte Syntax für NGINX-Konfigurations- und JavaScript-Dateien gezeigt.]
Codebeispiel wird geladen…
Der JavaScript-Code wird dann in der Protokollierungsphase ausgeführt, indem beim Schreiben des Zugriffsprotokolls die Variable ausgewertet wird.
Codebeispiel wird geladen…
Dateisystem
Das JavaScript-Dateisystemobjekt fs wurde um die Unterstützung von Promises für asynchrone Vorgänge erweitert. Darüber hinaus gibt es neue Dateisystemmethoden: access(), realpath(), symlink(), und unlink().
NGINX Plus aktualisieren oder testen
Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich ein Upgrade auf NGINX Plus R21 durchzuführen. Dadurch erhalten Sie außerdem eine Reihe zusätzlicher Fehlerbehebungen und Verbesserungen, und NGINX kann Sie besser unterstützen, wenn Sie ein Support-Ticket erstellen müssen.
Bitte lesen Sie sich vor dem Upgrade sorgfältig die in diesem Blogbeitrag beschriebenen neuen Funktionen und Verhaltensänderungen durch.
Wenn Sie NGINX Plus noch nicht ausprobiert haben, empfehlen wir Ihnen, es selbst zu testen – für Sicherheit, Lastverteilung und als API-Gateway oder als vollständig unterstützten Webserver mit erweiterten Überwachungs- und Verwaltungs-APIs. Starten Sie noch heute mit einer kostenlosen 30-Tage-Testversion. Überzeugen Sie sich selbst davon, wie NGINX Plus Sie bei der Bereitstellung und Skalierung Ihrer Anwendungen unterstützen kann.
Über den Autor
Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.
Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.
Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.