Ankündigung von NGINX Plus R21

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:

• Dynamisches gRPC-Proxying – Wir haben variable Unterstützung beim Übergeben von gRPC-Verbindungen an Back-End-gRPC-Dienste hinzugefügt. Auf diese Weise können Sie gRPC-Verbindungen dynamisch an Dienstgruppen basierend auf Clientattributen weiterleiten.
• Verbesserungen des NGINX JavaScript-Moduls – Das NGINX JavaScript-Modul (njs) wurde auf Version 0.3.9 aktualisiert und enthält mehrere Fehlerbehebungen und zusätzliche Funktionsverbesserungen in Bezug auf Unteranforderungen und Dateisystemunterstützung.

Wichtige Verhaltensänderungen

• Akzeptable Anfragen – Gemäß RFC 7230 erlaubt NGINX Plus keine Clientanfragen mit mehreren Host- Headern mehr.
• Neue unterstützte Betriebssysteme – Alpine Linux 3.11.
• Ältere Betriebssysteme werden nicht mehr unterstützt – 32-Bit-Plattformen (i386-Architekturen).

In Qualität investieren

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.

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 Verwendung von Unteranfragen im NJS -Modul und der AIO- Direktive
• Mögliche Speichererschöpfung im WebDav- Modul
• Mögliche Speicherfreigabe im MP4- Modul
• Statuscode494 wurde zurückgegeben statt400 wenn Fehler mit Code494 wurden mit der error_page -Direktive umgeleitet
• Bei der Verarbeitung von Pipeline-Anforderungen in einer SSL-Verbindung kann es zu einer Zeitüberschreitung kommen
• Bei Verwendung von OCSP-Stapling kann es in einem Arbeitsprozess zu einem Segmentierungsfehler kommen.
• Beim Start oder bei der Neukonfiguration kann es zu einem Segmentierungsfehler kommen, wenn die Konfiguration die Umschreibeanweisung mit einer leeren Ersetzungszeichenfolge enthielt.
• Ein Segmentierungsfehler kann in einem Arbeitsprozess auftreten, wenn die Direktive „break “ in Verbindung mit der Direktive „alias“ oder in Verbindung mit der Direktive „proxy_pass“ mit einer URI verwendet wird.
• Nur der erste Transfer-Encoding- Anforderungsheader wurde verarbeitet
• Die Headerzeile der Location -Antwort enthält möglicherweise Datenmüll, wenn die Anforderungs-URI in eine Zeile mit Nullzeichen umgeschrieben wurde.
• Anfragen mit Body wurden falsch behandelt, wenn Weiterleitungen mit der Direktive error_page zurückgegeben wurden
• 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 vorhanden sind.

In die NGINX Plus-Roadmap investieren

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.

Neue Features im Detail

Dynamisches gRPC-Proxying

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:

• A/B-Tests – Verteilen Sie gRRC-Anfragen statistisch auf mehrere Upstreams, um zu ermitteln, welche die bessere Leistung erbringt.
• Debug-Routing – Leiten Sie den Datenverkehr an einen Produktions-gRPC-Dienst weiter, leiten Sie Anforderungen mit bestimmten Attributen (Quell-IP-Adressen, gRPC-Metadaten) jedoch an einen Debug-gRPC-Dienst weiter.

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

Verbesserungen am NGINX JavaScript-Modul

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.

Unteranfragen

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 . ]

Versprechen

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.

Getrennte Unteraufträge

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.

Dateisystem

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() .

Upgrade oder Testen von NGINX Plus

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.