Ankündigung von NGINX Plus R15

Wir freuen uns, Ihnen mitteilen zu können, dass die fünfzehnte Version von NGINX Plus, unserem Flaggschiffprodukt, jetzt verfügbar ist. Seit unserer Erstveröffentlichung im Jahr 2013 hat NGINX Plus sowohl hinsichtlich seines Funktionsumfangs als auch seiner kommerziellen Attraktivität enorm zugenommen. Es gibt mittlerweile mehr als [ngx_snippet name='nginx-plus-customers'] NGINX Plus-Kunden und [ngx_snippet name='number-sites'] Benutzer von NGINX Open Source .

NGINX Plus basiert auf NGINX Open Source und ist der einzige All-in-One- Load Balancer, Inhaltscache, Webserver und API-Gateway. NGINX Plus umfasst exklusive erweiterte Funktionen zur Reduzierung der Komplexität bei der Architektur moderner Anwendungen sowie preisgekrönten Support.

NGINX Plus R15 führt neue gRPC-Unterstützung, HTTP/2-Server-Push, verbesserte Clustering-Unterstützung, erweiterte API-Gateway-Funktionalität und mehr ein:

• Native gRPC-Unterstützung – gRPC ist der neue von Google entwickelte Remote Procedure Call (RPC)-Standard. Es ist eine einfache und effiziente Möglichkeit für die Kommunikation zwischen Clients und Servern. Mit dieser neuen Funktion kann NGINX Plus gRPC-Verkehr zu Ihren Backend-Servern SSL-terminieren, weiterleiten und einen Lastenausgleich durchführen.
• HTTP/2-Server-Push – Mit HTTP/2-Server-Push sendet NGINX Plus Ressourcen proaktiv, bevor Sie sie anfordern, was die Leistung steigert und die Anzahl der Roundtrips verringert.
• Statusfreigabe über einen Cluster hinweg – Mit dieser Version können die für die Sticky Learn-Sitzungspersistenz verwendeten Shared-Memory-Daten über alle NGINX Plus-Instanzen in einem Cluster hinweg freigegeben werden. Die nächsten Versionen von NGINX Plus werden auf unseren Clustering-Funktionen aufbauen und neue clusterfähige Funktionen einführen.
• OpenID Connect-Integration – Sie können jetzt mit NGINX Plus Single Sign-On (SSO) für jede Webanwendung bereitstellen, indem Sie den OpenID Connect Authorization Code Flow verwenden und JSON Web Tokens (JWTs) an Clients ausstellen. NGINX Plus lässt sich mit CA Single Sign-On (früher SiteMinder), ForgeRock OpenAM, Keycloak, Okta, OneLogin, Ping Identity und anderen gängigen Identitätsanbietern integrieren.
• Erweiterungen des NGINX JavaScript (njs)-Moduls – Die njs-Module (früher nginScript) ermöglichen Ihnen, JavaScript-Code während der Verarbeitung von NGINX Plus-Anforderungen auszuführen. Das njs-Modul für HTTP unterstützt jetzt die Ausgabe von HTTP-Unteranforderungen, die unabhängig von der Clientanforderung und asynchron zu dieser sind. Dies ist bei API-Gateway-Anwendungsfällen hilfreich, da es Ihnen die Flexibilität gibt, API-Aufrufe mit JavaScript zu ändern und zu konsolidieren. Die njs-Module für HTTP und TCP/UDP enthalten jetzt auch Kryptobibliotheken, die die Implementierung gängiger Hash-Funktionen ermöglichen.

Abgerundet wird die Version durch weitere neue Funktionen , darunter eine neue ALPN-Variable, Aktualisierungen mehrerer dynamischer Module und mehr.

Verhaltensänderungen

• Mit NGINX Plus R13 wurde die brandneue NGINX Plus API eingeführt, die Funktionen ermöglicht, die zuvor in separaten APIs implementiert waren, darunter die dynamische Konfiguration von Upstream-Gruppen und erweiterten Metriken. Die vorherigen APIs, die mit den Anweisungen upstream_conf und status konfiguriert wurden, sind veraltet. Wir empfehlen Ihnen, Ihre Konfiguration auf diese Anweisungen zu überprüfen und so bald wie möglich auf die neue API- Anweisung umzustellen (Einzelheiten finden Sie unter „Ankündigung von NGINX Plus R13“ in unserem Blog). Ab der nächsten Version, NGINX Plus R16 , werden die veralteten APIs nicht mehr ausgeliefert.
• Die NGINX Plus-API wird in dieser Version auf Version 3 aktualisiert. Frühere Versionen werden weiterhin unterstützt. Wenn Sie eine Aktualisierung Ihrer API-Clients in Erwägung ziehen, lesen Sie die Dokumentation zur API-Kompatibilität .
• Im offiziellen Repository verfügbare NGINX Plus-Pakete verfügen jetzt über ein neues Nummerierungsschema. Das NGINX Plus-Paket und alle dynamischen Module zeigen jetzt die NGINX Plus-Versionsnummer an. Jede Paketversion entspricht jetzt der NGINX Plus-Version, um klarer zu machen, welche Version installiert ist, und um Modulabhängigkeiten zu vereinfachen. Diese Änderung ist transparent, sofern Sie nicht automatisierte Systeme verwenden, die Pakete anhand der Versionsnummer referenzieren. Testen Sie in diesem Fall Ihren Upgrade-Prozess zunächst in einer Nicht-Produktionsumgebung.

NGINX Plus R15 Funktionen im Detail

gRPC-Unterstützung

Mit dieser Version kann NGINX Plus den gRPC-Verkehr, den viele Organisationen bereits für die Kommunikation mit Microservices verwenden, als Proxy und Lastausgleich nutzen. gRPC ist ein Open-Source-Framework für hochleistungsfähige Remote Procedure Calls (RPC), das von Google für hocheffiziente, latenzarme Kommunikation zwischen Diensten entwickelt wurde. gRPC erfordert HTTP/2 anstelle von HTTP 1.1 als Transportmechanismus, da die Funktionen von HTTP/2 – Flusskontrolle, Multiplexing und bidirektionales Verkehrsstreaming mit geringer Latenz – ideal für die Verbindung von Microservices im großen Maßstab geeignet sind.

Die Unterstützung für gRPC wurde in NGINX Open Source 1.13.10 eingeführt und ist jetzt in NGINX Plus R15 enthalten. Sie können jetzt gRPC-Methodenaufrufe prüfen und weiterleiten, was Ihnen Folgendes ermöglicht:

• Wenden Sie NGINX Plus-Funktionen – einschließlich HTTP/2-TLS-Verschlüsselung, Ratenbegrenzung, IP-adressbasierter Zugriffskontrolllisten und Protokollierung – auf veröffentlichte gRPC-Dienste an.
• Veröffentlichen Sie mehrere gRPC-Dienste über einen einzigen Endpunkt, indem Sie gRPC-Verbindungen zu internen Diensten prüfen und weiterleiten.
• Skalieren Sie Ihre gRPC-Dienste, wenn Sie zusätzliche Kapazität benötigen, indem Sie die Last der gRPC-Verbindungen zu Upstream-Backend-Pools ausgleichen.
• Verwenden Sie NGINX Plus als API-Gateway für gRPC- und RESTful-Endpunkte.

Weitere Informationen finden Sie unter „Einführung der gRPC-Unterstützung mit NGINX 1.13.10“ in unserem Blog.

HTTP/2-Server-Push

Der erste Eindruck ist wichtig und die Seitenladezeit ist ein entscheidender Faktor dafür, ob Benutzer Ihre Website erneut besuchen. Eine Möglichkeit, Benutzern schnellere Antworten zu geben, ist HTTP/2-Server-Push, wodurch die Anzahl der RTTs (Round-Trip-Times, die für eine Anfrage und Antwort benötigte Zeit) reduziert wird, auf die der Benutzer warten muss.

HTTP/2 Server Push war ein meist gewünschtes und lang erwartetes Feature der NGINX Open-Source-Community, das mit NGINX Open Source 1.13.9 eingeführt wurde. Jetzt in NGINX Plus R15 enthalten, ermöglicht es Ihrem Server, Daten proaktiv zu senden, die voraussichtlich benötigt werden, um eine vorherige clientseitige Anfrage abzuschließen. Ein Browser benötigt beispielsweise zahlreiche Ressourcen – Stylesheets, Bilder usw. –, um eine Webseite darzustellen. Deshalb macht es Sinn, diese Ressourcen sofort beim ersten Zugriff auf die Seite zu senden, anstatt auf eine explizite Anforderung des Browsers zu warten.

Im folgenden Konfigurationsbeispiel verwenden wir die Direktive http2_push , um einen Client mit den Stylesheets und Bildern zu versorgen, die er zum Rendern der Demo- Webseite benötigt:

Manche Fälle erlauben es nicht, den genauen Ressourcenbedarf der Clients zu ermitteln, sodass es keine praktikable Lösung ist, einzelne Dateien in der NGINX-Systemkonfiguration aufzulisten. Hier kann NGINX HTTP-Link-Header abfangen und die darin als preload markierten Ressourcen direkt anbieten. Um das Abfangen von Link-Headern zu aktivieren, setzen Sie die Direktive http2_push_preload auf on.

Weitere Informationen finden Sie unter „Einführung in HTTP/2 Server Push mit NGINX 1.13.9“ in unserem Blog.

Statusfreigabe innerhalb eines Clusters

Durch die Konfiguration mehrerer NGINX Plus-Server in einem Hochverfügbarkeitscluster werden Ihre Anwendungen widerstandsfähiger und einzelne Fehlerquellen in Ihrem Anwendungsstapel werden eliminiert. Das NGINX Plus-Clustering ist für unternehmenskritische Produktionsbereitstellungen konzipiert, bei denen Ausfallsicherheit und hohe Verfügbarkeit von größter Bedeutung sind. Es gibt viele Lösungen für die Bereitstellung von Hochverfügbarkeits-Clustern mit NGINX Plus .

In früheren Versionen von NGINX Plus wurde Clustering-Unterstützung eingeführt, die zwei Clustering-Ebenen bereitstellt:

• Netzwerkausfallsicherheit durch Verwendung des Keepalived-Pakets – Behandelt das Failover, wenn ein NGINX Plus-Server ausfällt.
• Konfigurationssynchronisierung mit dem Paket nginx-sync – Stellt sicher, dass die Konfiguration auf allen NGINX Plus-Servern synchronisiert ist.

NGINX Plus R15 führt eine dritte Clustering-Ebene ein – die Statusfreigabe während der Laufzeit, die es Ihnen ermöglicht, Daten in gemeinsam genutzten Speicherzonen zwischen Clusterknoten zu synchronisieren. Genauer gesagt können die in gemeinsam genutzten Speicherzonen für die Sticky Learn-Sitzungspersistenz gespeicherten Daten jetzt mithilfe des neuen zone_sync- Moduls für TCP/UDP-Verkehr über alle Knoten im Cluster hinweg synchronisiert werden.

Neues zone_sync- Modul

Beim State Sharing gibt es keinen primären Knoten – alle Knoten sind Peers und tauschen Daten in einer vollständig vermaschten Topologie aus. Darüber hinaus ist die State-Sharing-Clusterlösung unabhängig von der Hochverfügbarkeitslösung zur Gewährleistung der Netzwerkausfallsicherheit. Daher kann sich ein State-Sharing-Cluster über mehrere physische Standorte erstrecken.

Ein NGINX Plus-State-Sharing-Cluster muss drei Anforderungen erfüllen:

• Netzwerkkonnektivität zwischen allen Clusterknoten
• Synchronisierte Uhren
• Die Konfiguration auf jedem Knoten aktiviert das Modul zone_sync wie folgt:

Die Direktive „zone_sync“ ermöglicht die Synchronisierung gemeinsam genutzter Speicherzonen in einem Cluster. Die Direktive „zone_sync_server“ identifiziert die anderen NGINX Plus-Instanzen im Cluster. NGINX Plus unterstützt die DNS-Diensterkennung, sodass Clustermitglieder anhand des Hostnamens identifiziert werden können und die Konfiguration für jedes Clustermitglied identisch ist.

Der oben aufgeführten Minimalkonfiguration fehlen die erforderlichen Sicherheitskontrollen zum Schutz der Synchronisierungsdaten in einer Produktionsbereitstellung. Der folgende Konfigurationsausschnitt verwendet mehrere solcher Sicherheitsvorkehrungen:

• SSL/TLS-Verschlüsselung der Synchronisationsdaten
• Client-Zertifikat-Authentifizierung, damit sich jeder Cluster-Knoten gegenüber den anderen identifiziert (gegenseitiges TLS)
• Zugriffskontrolllisten (ACLs) mithilfe von IP-Adressen, sodass sich nur NGINX Plus-Knoten im selben physischen Netzwerk zur Synchronisierung verbinden können

Statusfreigabe für die Persistenz von Sticky Learn-Sitzungen

Die erste unterstützte NGINX Plus-Funktion, die über einen Cluster gemeinsam genutzte Statusdaten verwendet, ist die Sticky Learn-Sitzungspersistenz . Sitzungspersistenz bedeutet, dass Anfragen eines Clients immer an den Server weitergeleitet werden, der die erste Anfrage des Clients erfüllt hat. Dies ist nützlich, wenn der Sitzungsstatus im Backend gespeichert wird.

In der folgenden Konfiguration definiert die Direktive „sticky learn “ eine gemeinsam genutzte Speicherzone namens „Sessions“ . Der Synchronisierungsparameter ermöglicht die clusterweite Statusfreigabe, indem er NGINX Plus anweist, Nachrichten über den Inhalt seiner gemeinsam genutzten Speicherzone an die anderen Knoten im Cluster zu veröffentlichen.

Beachten Sie, dass für eine ordnungsgemäße Synchronisierung der Statusdaten die Konfiguration auf jedem NGINX Plus-Knoten im Cluster denselben Upstream- Block mit der Direktive „Sticky Learn“ sowie die Direktiven enthalten muss, die das Modul „zone_sync“ aktivieren (siehe oben ).

Notiz : Clustering-Unterstützung und Sticky Learn-Sitzungspersistenz sind exklusiv bei NGINX Plus verfügbar.

OpenID Connect-Integration

Viele Unternehmen verwenden Identitäts- und Zugriffsverwaltungslösungen (IAM), um Benutzerkonten zu verwalten und eine Single Sign-On (SSO)-Umgebung für mehrere Anwendungen bereitzustellen. Sie versuchen häufig, SSO auf neue und vorhandene Anwendungen auszuweiten, um Komplexität und Kosten zu minimieren.

NGINX Plus R10 führt Unterstützung für die Validierung von OpenID Connect-Token ein. In dieser Version erweitern wir diese Funktion, sodass NGINX Plus auch den Autorisierungscode-Flow für die Authentifizierung mit OpenID Connect 1.0 steuern, mit dem Identitätsanbieter kommunizieren und den Zugriffstoken an den Client ausstellen kann. Dies ermöglicht die Integration mit den meisten großen Identitätsanbietern, darunter CA Single Sign-On (früher SiteMinder), ForgeRock OpenAM, Keycloak, Okta, OneLogin und Ping Identity. Die neue erweiterte Funktion ermöglicht Ihnen außerdem:

• Erweitern Sie SSO auf Legacy-Anwendungen, ohne diese Anwendungen zu ändern oder zu modernisieren
• Integrieren Sie SSO in neue Anwendungen, ohne SSO oder Authentifizierung im Anwendungscode zu implementieren
• Keine Abhängigkeit vom Anbieter; Sie erhalten standardbasiertes SSO, ohne proprietäre IAM-Anbieter-Agentensoftware mit der Anwendung bereitstellen zu müssen.

Die OpenID Connect-Integration mit NGINX Plus ist als Referenzimplementierung auf GitHub verfügbar. Das GitHub-Repository enthält eine Beispielkonfiguration mit Anweisungen zur Installation, Konfiguration und Feinabstimmung für bestimmte Anwendungsfälle.

Verbesserungen am NGINX JavaScript-Modul

[ Herausgeber – Die folgenden Beispiele sind nur einige der vielen Anwendungsfälle für das NGINX JavaScript-Modul. Eine vollständige Liste finden Sie unter Anwendungsfälle für das NGINX-JavaScript-Modul .

Der Code in diesem Abschnitt wird wie folgt aktualisiert, um Änderungen an der Implementierung von NGINX JavaScript seit der ursprünglichen Veröffentlichung des Blogs widerzuspiegeln:

• Um das überarbeitete Sitzungsobjekt ( die Sitzungen ) für das Stream-Modul zu verwenden, das in NGINX JavaScript 0.2.4 eingeführt wurde.
• So verwenden Sie die Direktive js_import , die die Direktive js_include in NGINX Plus R23 und höher ersetzt. Weitere Informationen finden Sie in der Referenzdokumentation für das NGINX-JavaScript-Modul . Im Abschnitt „Beispielkonfiguration“ wird die richtige Syntax für die NGINX-Konfiguration und JavaScript-Dateien gezeigt.

]

Mit dem NGINX-JavaScript-Modul njs (früher nginScript) können Sie JavaScript-Code in Ihre NGINX-Konfiguration einbinden, sodass er zur Laufzeit ausgewertet wird, während HTTP- oder TCP/UDP-Anfragen verarbeitet werden. Dies ermöglicht eine große Bandbreite potenzieller Anwendungsfälle, beispielsweise eine genauere Kontrolle des Datenverkehrs, die anwendungsübergreifende Konsolidierung von JavaScript-Funktionen und die Abwehr von Sicherheitsbedrohungen.

NGINX Plus R15 enthält zwei wichtige Updates für njs: Subrequests und Hash-Funktionen .

Unteranfragen

Sie können jetzt gleichzeitige HTTP-Anfragen stellen, die unabhängig und asynchron zur Client-Anfrage sind. Dies ermöglicht eine Vielzahl erweiterter Anwendungsfälle.

Der folgende Beispiel-JavaScript-Code sendet eine HTTP-Anfrage gleichzeitig an zwei verschiedene Backends. Die erste Antwort wird zur Weiterleitung an den Client an NGINX Plus gesendet und die zweite Antwort wird ignoriert.

Die js_import- Direktive in der entsprechenden NGINX Plus-Konfiguration liest den JavaScript-Code aus fastest_wins.js ein. Alle Anfragen, die mit dem Stammspeicherort ( / ) übereinstimmen, werden an die Funktion sendFastest() übergeben, die Unteranfragen an die Speicherorte /server_one und /server_two generiert. Die ursprüngliche URI mit Abfrageparametern wird an die entsprechenden Backend-Server übergeben. Beide Unteranforderungen führen die Rückruffunktion „Done “ aus. Da diese Funktion jedoch r.return() enthält, sendet nur die zuerst abgeschlossene Unteranforderung ihre Antwort an den Client.

Hash-Funktionen

Die njs-Module für HTTP- und TCP/UDP-Verkehr enthalten jetzt eine Kryptobibliothek mit Implementierungen von:

• Hash-Funktionen: MD5, SHA-1, SHA-256
• HMAC verwendet: MD5, SHA-1, SHA-256
• Digest-Formate: Base64, Base64URL, hex

Ein Beispiel für den Anwendungsfall von Hash-Funktionen ist das Hinzufügen von Datenintegrität zu Anwendungs-Cookies. Das folgende NJS-Codebeispiel enthält eine signCookie()- Funktion zum Hinzufügen einer digitalen Signatur zu einem Cookie und eine validateCookieSignature()- Funktion zum Validieren signierter Cookies.

Die folgende NGINX Plus-Konfiguration nutzt den njs-Code, um Cookie-Signaturen in eingehenden HTTP-Anfragen zu validieren und dem Client eine Fehlermeldung zurückzugeben, wenn die Validierung fehlschlägt. NGINX Plus leitet die Anfrage per Proxy weiter, wenn die Validierung erfolgreich war oder kein Cookie vorhanden ist.

Weitere neue Funktionen in NGINX Plus R15

ALPN-Variable für die Stream-Module

Application Layer Protocol Negotiation (ALPN) ist eine Erweiterung von TLS, die es einem Client und Server ermöglicht, während des TLS-Handshakes auszuhandeln, welches Protokoll für die herzustellende Verbindung verwendet wird. Dadurch werden zusätzliche Roundtrips vermieden, die zu Latenzen führen und das Benutzererlebnis beeinträchtigen könnten. Der häufigste Anwendungsfall für ALPN ist die automatische Aktualisierung von Verbindungen von HTTP auf HTTP/2, wenn sowohl Client als auch Server HTTP/2 unterstützen.

Die neue NGINX-Variable $ssl_preread_alpn_protocols , die erstmals in NGINX Open Source 1.13.10 eingeführt wurde, erfasst die Liste der vom Client in seiner ClientHello- Nachricht in der ALPN-Preread-Phase angekündigten Protokolle. Mit der folgenden Konfiguration kann sich ein XMPP-Client über ALPN vorstellen, sodass NGINX Plus den XMPP-Verkehr über einen einzigen Endpunkt an die Upstream-Gruppe xmpp_backend , den gRPC-Verkehr an grpc_backend und den gesamten übrigen Verkehr an http_backend weiterleitet.

Damit NGINX Plus Informationen aus der ClientHello -Nachricht extrahieren und die Variable $ssl_preread_alpn_protocols füllen kann, müssen Sie auch die Direktive „ssl_preread on “ einschließen.

Weitere Informationen finden Sie in der Dokumentation zum Modul ngx_stream_ssl_preread .

Wartezeitvariable

NGINX Plus unterstützt Upstream-Warteschlangen , sodass Clientanforderungen nicht sofort abgelehnt werden müssen, wenn nicht alle Server in der Upstream-Gruppe zum Annehmen neuer Anforderungen verfügbar sind.

Ein typischer Anwendungsfall für Upstream-Warteschlangen besteht darin, Backend-Server vor Überlastung zu schützen, ohne Anfragen sofort ablehnen zu müssen, wenn alle Server ausgelastet sind. Sie können die maximale Anzahl gleichzeitiger Verbindungen für jeden Upstream-Server mit dem Parameter max_conns der Serverdirektive definieren. Die Warteschlangendirektive stellt Anfragen dann in eine Warteschlange, wenn keine Backends verfügbar sind, entweder weil sie ihr Verbindungslimit erreicht haben oder weil sie eine Integritätsprüfung nicht bestanden haben.

In dieser Version erfasst die neue NGINX-Variable $upstream_queue_time , die erstmals in NGINX Open Source 1.13.9 eingeführt wurde, die Zeit, die eine Anfrage in der Warteschlange verbringt. Die folgende Konfiguration umfasst ein benutzerdefiniertes Protokollformat, das verschiedene Zeitmetriken für jede Anforderung erfasst. Die Metriken können dann im Rahmen der Leistungsoptimierung offline analysiert werden. Wir begrenzen die Anzahl der in die Warteschlange gestellten Anfragen für die Upstream-Gruppe my_backend auf 20. Der Timeout- Parameter legt fest, wie lange Anfragen in der Warteschlange gehalten werden, bevor eine Fehlermeldung an den Client zurückgegeben wird (503 (Standardmäßig). Hier stellen wir es auf 5 Sekunden ein (der Standardwert ist 60 Sekunden).

Weitere Informationen finden Sie in der Dokumentation zur Warteschlangendirektive .

Zugriff auf Protokolle ohne Flucht

Sie können jetzt das Escaping im NGINX Plus-Zugriffsprotokoll deaktivieren. Der neue Parameter escape=none für die Direktive log_format , der erstmals in NGINX Open Source 1.13.10 eingeführt wurde, gibt an, dass auf Sonderzeichen in Variablen kein Escape-Zeichen angewendet wird.

Aktualisierung der LDAP-Authentifizierungsreferenzimplementierung

Unsere Referenzimplementierung zur Authentifizierung von Benutzern mithilfe eines LDAP-Authentifizierungssystems wurde aktualisiert, um Probleme zu beheben und Fehler zu beheben. Schauen Sie es sich auf GitHub an .

Transparentes Proxying ohne Root-Berechtigungen

Sie können NGINX Plus als transparenten Proxy verwenden, indem Sie den transparenten Parameter in die Direktive „proxy_bind“ aufnehmen. Arbeitsprozesse können jetzt die Linux-Fähigkeit CAP_NET_RAW vom Masterprozess erben, sodass NGINX Plus keine besonderen Berechtigungen für transparentes Proxying mehr erfordert.

Notiz : Diese Funktion gilt nur für Linux-Plattformen.

JWT-Karenzzeit

Wenn ein JWT einen zeitbasierten Anspruch enthält – nbf (nicht vor dem Datum), exp (Ablaufdatum) oder beides – umfasst die Validierung des JWT durch NGINX Plus eine Prüfung, ob die aktuelle Zeit innerhalb des angegebenen Zeitintervalls liegt. Wenn die Uhr des Identitätsanbieters nicht mit der Uhr der NGINX Plus-Instanz synchronisiert ist, kann es vorkommen, dass Token unerwartet ablaufen oder der Eindruck entsteht, sie würden erst in der Zukunft starten. Um die maximal zulässige Abweichung zwischen den beiden Uhren einzustellen, verwenden Sie die Direktive „auth_jwt_leeway“ .

Cookie Flag Dynamisches Modul

Das Drittanbietermodul zum Setzen von Cookie-Flags ist jetzt als dynamisches Cookie-Flag- Modul im NGINX-Repository verfügbar und wird von Ihrem NGINX Plus-Supportvertrag abgedeckt. Sie können es mit Ihrem Paketverwaltungstool installieren:

$ apt-get install nginx-plus-module-cookie-flag # Ubuntu/Debian$ yum install nginx-plus-module-cookie-flag     # Red Hat/CentOS

Aktualisierung des NGINX ModSecurity WAF-Moduls

NGINX ModSecurity WAF , ein dynamisches Modul für NGINX Plus basierend auf ModSecurity 3.0, wurde mit den folgenden Verbesserungen aktualisiert:

• Leistungsverbesserungen in libmodsecurity
• Behebung von Speicherlecks in ModSecurity-nginx

[ Anmerkung des Herausgebers – Der Verkauf von NGINX ModSecurity WAF endete am 1. April 2022 offiziell, und der Lebenszyklus endet mit Wirkung zum 31. März 2024 . Weitere Einzelheiten finden Sie unter „F5 NGINX ModSecurity WAF wird eingestellt“<.htmla> in unserem Blog.]

Upgrade oder Testen von NGINX Plus

NGINX Plus R15 umfasst verbesserte Authentifizierungsfunktionen für Ihre Clientanwendungen, zusätzliche Clustering-Funktionen, NJS-Erweiterungen und wichtige Fehlerbehebungen .

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich auf Release 15 zu aktualisieren. Sie erhalten eine Reihe von Fehlerbehebungen und Verbesserungen und durch das Upgrade können wir Ihnen helfen, wenn Sie ein Support-Ticket erstellen müssen. Installations- und Upgrade-Anweisungen für NGINX Plus R15 sind im Kundenportal verfügbar.

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 verwendet haben, empfehlen wir Ihnen, es auszuprobieren – zur Webbeschleunigung, zum Lastenausgleich und zur Anwendungsbereitstellung oder als vollständig unterstützter Webserver mit erweiterten Überwachungs- und Verwaltungs-APIs. Sie können noch heute mit einer kostenlosen 30-Tage-Testversion kostenlos loslegen. Überzeugen Sie sich selbst, wie NGINX Plus Ihnen bei der Bereitstellung und Skalierung Ihrer Anwendungen helfen kann.