Ankündigung von NGINX Plus R18

Wir freuen uns, Ihnen mitteilen zu können, dass NGINX Plus Release 18 (R18) jetzt verfügbar ist. NGINX Plus ist der einzige All-in-One- Load Balancer, Inhaltscache, Webserver und API-Gateway. NGINX Plus basiert auf NGINX Open Source und umfasst exklusive erweiterte Funktionen und preisgekrönten Support. R18 vereinfacht Konfigurations-Workflows für DevOps und verbessert die Sicherheit und Zuverlässigkeit Ihrer Anwendungen im großen Maßstab.

Mittlerweile verwenden mehr als 87 % der Websites SSL/TLS zur Verschlüsselung der Kommunikation über das Internet. Vor drei Jahren waren es noch 66 %. Ende-zu-Ende -Verschlüsselung ist heute das Standardbereitstellungsmuster für Websites und Anwendungen und die explosionsartige Zunahme an SSL/TLS-Zertifikaten bedeutet, dass manche Unternehmen in ihren Produktionsumgebungen viele Tausend Zertifikate verwalten. Dies erfordert einen flexibleren Ansatz bei der Bereitstellung und Konfiguration von Zertifikaten.

Neu in dieser Version ist die Unterstützung für das dynamische Laden von Zertifikaten . Bei Tausenden von Zertifikaten ist es nicht skalierbar, jedes einzelne in der Konfiguration zum Laden von der Festplatte manuell zu definieren – dieser Vorgang ist nicht nur mühsam, sondern die Konfiguration wird auch unhandlich groß und der Start von NGINX Plus inakzeptabel langsam. Mit NGINX Plus R18 können SSL/TLS-Zertifikate nun bei Bedarf geladen werden, ohne dass sie in der Konfiguration einzeln aufgeführt werden. Um automatisierte Bereitstellungen noch weiter zu vereinfachen, können Zertifikate mit der NGINX Plus-API bereitgestellt werden und müssen nicht einmal auf der Festplatte gespeichert werden.

Zu den weiteren neuen Funktionen in NGINX Plus R18 gehören:

• OpenID Connect-Erweiterungen – Wir verbessern kontinuierlich unsere unterstützte OpenID Connect-Referenzimplementierung, die ursprünglich in NGINX Plus R15 veröffentlicht wurde . In dieser Version haben wir Unterstützung für opake Sitzungstoken, Aktualisierungstoken und eine Abmelde-URL hinzugefügt.
• Portbereiche für virtuelle Server – Virtuelle Server von NGINX Plus können jetzt so konfiguriert werden, dass sie auf einem Portbereich lauschen, zum Beispiel 80‑90 . Dadurch kann NGINX Plus ein breiteres Spektrum an Anwendungen unterstützen, wie z. B. passives FTP, für die Portbereiche reserviert werden müssen.
• Schlüssel-Wert-Definition in der Konfiguration – Der Schlüssel-Wert-Speicher von NGINX Plus ermöglicht Lösungen für eine breite Palette von Anwendungsfällen, darunter dynamisches Denylisting von IP-Adressen und dynamische DDoS-Minderung. Sie können jetzt Schlüssel-Wert-Paare direkt mit Variablen in der NGINX Plus-Konfiguration erstellen, wodurch noch mehr Anwendungsfälle möglich werden.
• Mehr Flexibilität für aktive Integritätsprüfungen – Die aktiven Integritätsprüfungen von NGINX Plus sind ein leistungsstarkes Tool zur Überwachung der Integrität von Backend-Systemen. Mit NGINX Plus R18 können Sie jetzt den Wert jeder NGINX-Variable testen und bestehende TCP-Verbindungen zu ausgefallenen Servern automatisch beenden.

Abgerundet wird diese Version durch eine vereinfachte Konfiguration für Clusterumgebungen sowie neue und aktualisierte dynamische Module (einschließlich Brotli). Zu den Updates des NGINX Plus-Ökosystems gehören eine modulare Codeorganisation mit dem NGINX JavaScript-Modul und die direkte Helm-Installation des offiziellen NGINX Ingress Controllers für Kubernetes.

Wichtige Verhaltensänderungen

• Veraltete APIs – NGINX Plus R13 (August 2017) führte die brandneue NGINX Plus-API für die Metrikerfassung und dynamische Neukonfiguration von Upstream-Gruppen ein und ersetzte die Status- und Upstream-Conf-APIs, die diese Funktionen zuvor implementiert hatten. Wie damals angekündigt, blieben die veralteten APIs für einen beträchtlichen Zeitraum weiterhin verfügbar und wurden unterstützt, der mit NGINX Plus R16 endete. Wenn Ihre Konfiguration die Anweisungen „status“ und/oder „upstream_conf“ enthält, müssen Sie diese im Rahmen des Upgrades auf R18 durch die Anweisung „api“ ersetzen.

  Ratschläge und Hilfe zur Migration auf die neue NGINX Plus-API finden Sie im Übergangshandbuch in unserem Blog oder wenden Sie sich an unser Supportteam.

• Aktualisierte Listen- Direktive – Wenn die Listen- Direktive zuvor einen Hostnamen angab, der in mehrere IP-Adressen aufgelöst werden konnte, wurde nur die erste IP-Adresse verwendet. Jetzt wird für jede zurückgegebene IP-Adresse ein Listening-Socket erstellt.

• Änderungen am NGINX JavaScript-Modul (njs) – Das veraltete Objekt req.response wurde aus dem NGINX JavaScript-Modul entfernt. Mit der Syntax function(req,res) deklarierte Funktionen, die auch auf Eigenschaften des res -Objekts verweisen, erzeugen Laufzeitfehler und geben den HTTP-Statuscode zurück.500 und ein entsprechender Eintrag im Fehlerprotokoll:

  JJJJ / MM / TT hh : mm : ss [Fehler] 34#34: js-Ausnahme: TypeError: Eigenschaft „return“ von undefined kann nicht abgerufen werden.

  Da JavaScript-Code zur Laufzeit interpretiert wird, erkennt der syntaktische Validierungsbefehl nginx -t das Vorhandensein ungültiger Objekte und Eigenschaften nicht. Sie müssen Ihren JavaScript-Code sorgfältig prüfen und solche Objekte entfernen, bevor Sie auf NGINX Plus R18 aktualisieren.

  Darüber hinaus geben JavaScript-Objekte, die den NGINX-Status darstellen (z. B. r.headersIn ), jetzt „undefined“ statt der leeren Zeichenfolge zurück, wenn für eine bestimmte Eigenschaft kein Wert vorhanden ist. Diese Änderung bedeutet, dass sich NGINX-spezifische JavaScript-Objekte jetzt genauso verhalten wie integrierte JavaScript-Objekte.

• Ältere Betriebssysteme wurden entfernt oder sollen entfernt werden:

  • Amazon Linux 2017.09 wird nicht mehr unterstützt; die älteste unterstützte Version ist jetzt 2018.03
  • CentOS/Oracle Linux/Red Hat Enterprise Linux 7.3 wird nicht mehr unterstützt; die älteste unterstützte Version ist jetzt 7.4
  • Debian 8.0 wird in NGINX Plus R19 entfernt
  • Ubuntu 14.04 wird in NGINX Plus R19 entfernt

Neue Features im Detail

Dynamisches Laden von SSL/TLS-Zertifikaten

Bei früheren Versionen von NGINX Plus bestand der typische Ansatz zum Verwalten von SSL/TLS-Zertifikaten für sichere Sites und Anwendungen darin, für jeden Hostnamen einen separaten Serverblock zu erstellen und das Zertifikat und den zugehörigen privaten Schlüssel statisch als Dateien auf der Festplatte anzugeben. (Der Lesbarkeit halber verwenden wir von nun an „Zertifikat“, um uns auf das gepaarte Zertifikat und den Schlüssel zu beziehen.) Die Zertifikate wurden dann beim Start von NGINX Plus geladen. Mit NGINX Plus R18 können Zertifikate dynamisch geladen und optional im In-Memory-Schlüssel-Wert-Speicher von NGINX Plus statt auf der Festplatte gespeichert werden.

Es gibt zwei primäre Anwendungsfälle für das dynamische Laden von Zertifikaten:

• „Lazy Loading“ von Zertifikaten von der Festplatte
• Speichern von Zertifikaten im Speicher

In beiden Fällen kann NGINX Plus das dynamische Laden von Zertifikaten basierend auf dem Hostnamen durchführen, der von der Server Name Indication (SNI) als Teil des TLS-Handshakes bereitgestellt wird. Dadurch kann NGINX Plus mehrere sichere Websites unter einer einzigen Serverkonfiguration hosten und bei Bedarf für jede eingehende Anfrage das entsprechende Zertifikat auswählen.

Lazy Loading von SSL/TLS-Zertifikaten von der Festplatte

Beim „Lazy Loading“ werden SSL/TLS-Zertifikate nur dann in den Speicher geladen, wenn Anfragen eintreffen und den entsprechenden Hostnamen angeben. Dies vereinfacht die Konfiguration (durch Wegfallen der Liste mit Zertifikaten pro Hostname) und reduziert die Ressourcennutzung auf dem Host. Bei einer großen Anzahl (viele Tausend) Zertifikate kann es mehrere Sekunden dauern, alle von der Festplatte zu lesen und in den Speicher zu laden. Darüber hinaus wird beim Neuladen der NGINX-Konfiguration viel Speicher verwendet, da die neuen Arbeitsprozesse zusätzlich zu den vom vorherigen Arbeitsprozess geladenen Zertifikaten eine neue Kopie der Zertifikate in den Speicher lädt. Die vorherigen Zertifikate bleiben im Speicher, bis die letzte unter der alten Konfiguration hergestellte Verbindung abgeschlossen ist und die vorherigen Worker beendet werden. Wenn die Konfiguration häufig aktualisiert wird und die Client-Verbindungen lange bestehen, können mehrere Kopien der Zertifikate im Speicher vorhanden sein, was möglicherweise zu einer Speichererschöpfung führt.

Das verzögerte Laden von Zertifikaten von der Festplatte eignet sich ideal für Bereitstellungen mit einer großen Anzahl von Zertifikaten und/oder wenn die Konfiguration häufig neu geladen wird. Beispielsweise weisen SaaS-Unternehmen häufig jedem Kunden eine separate Subdomäne zu. Die Einbindung neuer Kunden ist schwierig, da Sie für jeden Kunden einen neuen virtuellen Server erstellen und dann die neue Konfiguration und das Zertifikat des Kunden in jede NGINX Plus-Instanz kopieren müssen. Durch Lazy Loading sind keine Konfigurationsänderungen erforderlich – stellen Sie einfach die Zertifikate auf jeder Instanz bereit, und fertig.

Um Lazy Loading zu unterstützen, akzeptieren die Anweisungen ssl_certificate und ssl_certificate_key jetzt variable Parameter. Die Variable muss während der SNI-Verarbeitung verfügbar sein, die vor dem Lesen der Anforderungszeile und der Header erfolgt. Die am häufigsten verwendete Variable ist $ssl_server_name , die den Hostnamen enthält, der von NGINX Plus während der SNI-Verarbeitung extrahiert wurde. Das Zertifikat und der Schlüssel werden während des TLS-Handshakes zu Beginn jeder Client-Sitzung von der Festplatte gelesen und im Speicher des Dateisystem-Cache zwischengespeichert, was die Speichernutzung weiter reduziert.

So einfach lässt sich eine sichere Site-Konfiguration gestalten:

Dieselbe Serverkonfiguration kann für eine unbegrenzte Anzahl sicherer Sites verwendet werden. Dies hat zwei Vorteile:

1. Dadurch entfällt der separate Serverblock für jeden Hostnamen, wodurch die Konfiguration viel kleiner und somit einfacher zu lesen und zu verwalten wird.
2. Dadurch entfällt die Notwendigkeit, die Konfiguration jedes Mal neu zu laden, wenn Sie einen neuen Hostnamen hinzufügen. Wenn Sie die Konfiguration neu laden müssen, geht das viel schneller, da NGINX Plus nicht alle Zertifikate lädt.

Beachten Sie, dass der TLS-Handshake durch Lazy Loading je nach Umgebung um 20–30 % länger dauert, da zum Abrufen des Zertifikats von der Festplatte Dateisystemaufrufe erforderlich sind. Die zusätzliche Latenz wirkt sich jedoch nur auf den Handshake aus. Sobald die TLS-Sitzung hergestellt ist, dauert die Anforderungsverarbeitung die übliche Zeit.

In‑Memory‑Speicherung von SSL/TLS‑Zertifikaten

Sie können jetzt SSL/TLS-Zertifikatsdaten im Speicher, im Schlüssel-Wert-Speicher von NGINX Plus sowie in Dateien auf der Festplatte speichern. Wenn der Parameter der Direktive „ssl_certificate“ oder „ssl_certificate_key“ mit dem Präfix „data: “ beginnt, interpretiert NGINX Plus den Parameter als Roh-PEM-Daten (bereitgestellt in Form einer Variablen, die den Eintrag im Schlüssel-Wert-Speicher identifiziert, in dem sich die Daten tatsächlich befinden).

Ein weiterer Vorteil der Speicherung im Schlüssel‑Wert‑Speicher statt auf der Festplatte besteht darin, dass Bereitstellungsimages und Backups keine Kopien des privaten Schlüssels mehr enthalten, mit denen ein Angreifer den gesamten zum und vom Server gesendeten Datenverkehr entschlüsseln kann. Unternehmen mit hochautomatisierten Bereitstellungspipelines profitieren von der Flexibilität, die ihnen die Nutzung der NGINX Plus-API bietet, um Zertifikate programmgesteuert in den Schlüssel-Wert-Speicher einzufügen. Darüber hinaus profitieren Unternehmen, die Anwendungen in eine öffentliche Cloud-Umgebung migrieren, in der kein echtes Hardware-Sicherheitsmodul (HSM) zum Schutz privater Schlüssel vorhanden ist, von der zusätzlichen Sicherheit, die dadurch entsteht, dass private Schlüssel nicht auf der Festplatte gespeichert werden.

Hier ist eine Beispielkonfiguration zum Laden von Zertifikaten aus dem Schlüssel-Wert-Speicher:

Eine Möglichkeit, Zertifikate und private Schlüssel mit der NGINX Plus-API in den Schlüssel-Wert-Speicher hochzuladen, besteht darin, den folgenden Curl- Befehl auszuführen (es wird nur der Anfang der Schlüsseldaten angezeigt). Wenn Sie den Curl -Befehl verwenden, denken Sie daran, eine Kopie der PEM-Daten zu erstellen und jeden Zeilenumbruch durch \n zu ersetzen. Andernfalls werden die Zeilenumbrüche aus der JSON-Nutzlast entfernt.

$ curl -d '{"www.example.com":"-----BEGIN RSA PRIVATE KEY-----\n..."}' http://localhost:8080/api/4/http/keyvals/ssl_key

Die Verwendung des Schlüssel-Wert-Speichers für Zertifikate ist ideal für Clusterbereitstellungen von NGINX Plus, da Sie das Zertifikat nur einmal hochladen und es dann automatisch im gesamten Cluster verbreiten. Um die Zertifikatsdaten selbst zu schützen, verwenden Sie die Direktive zone_sync_ssl , um die Verbindungen zwischen Clustermitgliedern mit TLS zu verschlüsseln. Die Verwendung des Schlüssel-Wert-Speichers eignet sich auch ideal für kurzlebige Zertifikate oder die Automatisierung von Integrationen mit Zertifikatsausstellern wie Let’s Encrypt und Hashicorp Vault .

Wie beim Lazy Loading von der Festplatte erfolgt das Laden von Zertifikaten aus dem Schlüssel-Wert-Speicher während jedes TLS-Handshakes, was zu Leistungseinbußen führt. Verwenden Sie für die schnellsten TLS-Handshakes die Anweisungen ssl_certificate und ssl_certificate_key mit einem fest codierten Parameter in einer Datei auf der Festplatte. Darüber hinaus sind ECC-Zertifikate schneller als RSA-Zertifikate.

Beachten Sie, dass es für einen Angreifer zwar schwieriger ist, an private Schlüsseldateien zu gelangen, als dies über den Schlüssel-Wert-Speicher als über den Festplattenspeicher möglich ist, ein Angreifer mit Shell-Zugriff auf den NGINX Plus-Host jedoch möglicherweise trotzdem auf im Speicher geladene Schlüssel zugreifen kann. Der Schlüssel-Wert-Speicher schützt private Schlüssel nicht in demselben Maße wie ein Hardware-Sicherheitsmodul (HSM). Damit NGINX Plus Schlüssel von einem HSM abruft, verwenden Sie den Parameter engine: engine-name : key-id für die Direktive ssl_certificate_key .

OpenID Connect-Erweiterungen

NGINX Plus unterstützt OpenID Connect-Authentifizierung und Single Sign-On für Backend-Anwendungen durch unsere Referenzimplementierung . Dies wurde jetzt sowohl vereinfacht als auch verbessert, da der Schlüssel-Wert-Speicher mithilfe von Variablen direkt aus dem JavaScript-Modul geändert werden kann ( siehe unten ).

Die OpenID Connect-Referenzimplementierung stellt Clients jetzt undurchsichtige Sitzungstoken in Form eines Browser-Cookies aus. Opaque Tokens enthalten keine persönlich identifizierbaren Informationen über den Benutzer, daher werden keine vertraulichen Informationen auf dem Client gespeichert. NGINX Plus speichert das eigentliche ID-Token im Schlüssel-Wert-Speicher und ersetzt damit das undurchsichtige Token, das der Client vorlegt. Für jede Anforderung wird eine JWT-Validierung durchgeführt, sodass abgelaufene oder ungültige Token abgelehnt werden.

Die OpenID Connect-Referenzimplementierung unterstützt jetzt auch Aktualisierungstoken, sodass abgelaufene ID-Token nahtlos und ohne Benutzerinteraktion aktualisiert werden. NGINX Plus speichert das von einem Autorisierungsserver gesendete Aktualisierungstoken im Schlüssel-Wert-Speicher und verknüpft es mit dem opaken Sitzungstoken. Wenn das ID-Token abläuft, sendet NGINX Plus das Aktualisierungstoken an den Autorisierungsserver zurück. Wenn die Sitzung noch gültig ist, stellt der Autorisierungsserver ein neues ID-Token aus, das im Schlüssel-Wert-Speicher nahtlos aktualisiert wird. Aktualisierungstoken ermöglichen die Verwendung kurzlebiger ID-Token und sorgen so für mehr Sicherheit, ohne den Benutzern Unannehmlichkeiten zu bereiten.

Die OpenID Connect-Referenzimplementierung stellt jetzt eine Abmelde-URL bereit. Wenn angemeldete Benutzer die /logout‑ URI besuchen, werden ihre ID und Aktualisierungstoken aus dem Schlüssel‑Wert‑Speicher gelöscht und sie müssen sich bei einer zukünftigen Anforderung erneut authentifizieren.

Portbereiche für virtuelle Server

Ein Serverblock verfügt normalerweise über eine Abhördirektive , die den einzelnen Port angibt, auf dem NGINX Plus lauscht. Wenn mehrere Ports konfiguriert werden müssen, gibt es für jeden von ihnen eine zusätzliche Abhördirektive . Mit NGINX Plus R18 können Sie jetzt auch Portbereiche angeben, zum Beispiel 80‑90 , wenn es unpraktisch ist, eine große Anzahl einzelner Abhördirektiven anzugeben.

Portbereiche können sowohl für die HTTP- Abhördirektive als auch für die TCP/UDP- Abhördirektive (Stream) angegeben werden. Die folgende Konfiguration ermöglicht es NGINX Plus, als Proxy für einen FTP-Server im passiven Modus zu fungieren, wobei der Datenport aus einer großen Palette von TCP-Ports ausgewählt wird.

Diese Konfiguration richtet einen virtuellen Server ein, um Verbindungen zum FTP-Server über denselben Port herzustellen, über den die Verbindung zustande kam.

Aktualisieren des Schlüssel-Wert-Speichers durch Variablen

Wenn der Schlüssel-Wert-Speicher aktiviert ist, stellt NGINX Plus basierend auf einem Eingabeschlüssel (normalerweise ein Teil der Anforderungsmetadaten) eine Variable für die dort gespeicherten Werte bereit. Bisher war die einzige Möglichkeit zum Erstellen, Ändern oder Löschen von Werten im Schlüssel-Wert-Speicher die NGINX Plus-API . Mit NGINX Plus R18 können Sie den Wert für einen Schlüssel direkt in der Konfiguration ändern, indem Sie die Variable festlegen, die den Wert enthält.

Im folgenden Beispiel wird der Schlüssel-Wert-Speicher verwendet, um eine Liste der Client-IP-Adressen zu verwalten, die vor Kurzem auf die Site zugegriffen haben, zusammen mit der zuletzt von ihnen angeforderten URI.

Die Set- Direktive (Zeile 7) weist jeder Client-IP-Adresse ( $remote_addr ) einen Wert ( $last_uri ) zu, erstellt einen neuen Eintrag, wenn dieser fehlt, oder ändert den Wert, sodass er den $uri der aktuellen Anfrage widerspiegelt. Somit steht die aktuelle Liste der letzten Clients und der von ihnen angefragten URIs mit einem Aufruf der NGINX Plus API zur Verfügung:

$ curl http://localhost:8080/api/4/http/keyvals/recents { "10.19.245.68": "/blog/nginx-plus-r18-released/", "172.16.80.227": "/products/nginx/", "10.219.110.168": "/blog/nginx-unit-1-8-0-now-available" }

Leistungsstärkere Anwendungsfälle können mit Skripterweiterungen wie dem NGINX JavaScript-Modul (njs) und dem Lua-Modul erreicht werden. Jede Konfiguration, die njs verwendet, hat Zugriff auf alle Variablen, einschließlich derjenigen, die durch den Schlüssel-Wert-Speicher unterstützt werden, zum Beispiel r.variables.last_uri .

Mehr Flexibilität für aktive Gesundheitschecks

Die aktiven Integritätsprüfungen von NGINX Plus testen routinemäßig Backend-Systeme, sodass der Datenverkehr nicht auf Systeme umgeleitet wird, von denen bekannt ist, dass sie nicht in einwandfreiem Zustand sind. NGINX Plus R18 erweitert diese wichtige Funktion um zwei zusätzliche Funktionen.

• Unterstützung für das Testen beliebiger Variablen in Integritätsprüfungen
• Möglichkeit zum Beenden von TCP-Sitzungen bei fehlgeschlagener Integritätsprüfung

Testen beliebiger Variablen in Integritätsprüfungen

Beim Definieren einer Integritätsprüfung für eine Back-End-Anwendung können Sie einen Match -Block verwenden, um den erwarteten Wert für mehrere Aspekte der Antwort anzugeben, einschließlich des HTTP-Statuscodes und der Zeichenfolgen in den Antwortheadern und/oder im Textkörper. Wenn die Antwort alle erwarteten Werte enthält, gilt das Backend als fehlerfrei.

Für noch komplexere Prüfungen stellt NGINX Plus R18 jetzt die „require “-Direktive zum Testen des Werts beliebiger Variablen bereit – sowohl von Standard-NGINX-Variablen als auch von von Ihnen deklarierten Variablen. Dies gibt Ihnen mehr Flexibilität beim Definieren von Integritätsprüfungen, da Variablen mit Map- Blöcken, regulären Ausdrücken und sogar Skripterweiterungen ausgewertet werden können.

Die „require “-Direktive innerhalb eines Match -Blocks gibt eine oder mehrere Variablen an, die alle einen Wert ungleich Null haben müssen, damit der Test erfolgreich ist. Die folgende Beispielkonfiguration definiert einen fehlerfreien Upstreamserver als einen Server, der Header zurückgibt, die darauf hinweisen, dass die Antwort zwischengespeichert werden kann – entweder einen Expires -Header mit einem Wert ungleich 0 oder einen Cache-Control- Header.

Die Verwendung von Map- Blöcken auf diese Weise ist eine gängige Methode, um die ODER-Logik in die NGINX Plus-Konfiguration zu integrieren. Mit der Direktive „require“ können Sie diese Technik bei Integritätsprüfungen nutzen und erweiterte Integritätsprüfungen durchführen. Mithilfe des JavaScript-Moduls (njs) können auch erweiterte Integritätsprüfungen definiert werden, um zusätzliche Attribute der Antworten von jedem Upstream-Server zu analysieren, wie z. B. die Antwortzeit .

Beenden von Layer 4-Verbindungen, wenn Integritätsprüfungen fehlschlagen

Wenn NGINX Plus als Layer 4 (L4) -Load Balancer für TCP/UDP-Anwendungen fungiert, leitet es Daten in beide Richtungen über die zwischen dem Client und dem Backend-Server hergestellte Verbindung weiter. Aktive Integritätsprüfungen sind ein wichtiger Teil einer solchen Konfiguration, aber standardmäßig wird der Integritätsstatus eines Backend-Servers nur berücksichtigt, wenn ein neuer Client versucht, eine Verbindung herzustellen. Wenn ein Backend-Server offline geht, kann es bei etablierten Clients zu einem Timeout kommen, wenn sie Daten an den Server senden.

Mit der in NGINX Plus R18 neuen Direktive „proxy_session_drop“ können Sie die Verbindung sofort schließen, wenn das nächste Paket vom Offline-Server empfangen oder an ihn gesendet wird. Der Client muss die Verbindung erneut herstellen. An diesem Punkt leitet NGINX Plus seine Anfragen an einen fehlerfreien Backend-Server weiter.

Wenn diese Anweisung aktiviert ist, lösen zwei weitere Bedingungen ebenfalls die Beendigung bestehender Verbindungen aus: das Fehlschlagen einer aktiven Integritätsprüfung und das Entfernen des Servers aus einer Upstream-Gruppe aus beliebigem Grund. Hierzu zählt die Entfernung per DNS-Lookup, bei der ein Backend-Server durch einen Hostnamen mit mehreren IP-Adressen definiert wird, wie sie beispielsweise von einem Service-Register bereitgestellt werden.

Weitere Verbesserungen in NGINX Plus R18

Vereinfachte Clusterkonfiguration

NGINX Plus unterstützt seit NGINX Plus R15 die clusterweite Synchronisierung des Laufzeitstatus. Das Modul „Zonensynchronisierung“ unterstützt derzeit die gemeinsame Nutzung von Statusdaten zu Sticky Sessions , Ratenbegrenzungen und dem Schlüssel-Wert-Speicher über eine Clusterbereitstellung von NGINX Plus-Instanzen hinweg.

Eine einzelne zone_sync- Konfiguration kann jetzt für alle Instanzen in einem Cluster verwendet werden. Bisher mussten Sie die IP-Adresse oder den Hostnamen jedes Mitglieds explizit konfigurieren, was bedeutete, dass jede Instanz eine leicht andere Konfiguration hatte. Sie können den zone_sync -Server jetzt alle lokalen Schnittstellen abhören lassen, indem Sie für den Parameter Adresse : Port der Listen -Direktive einen Platzhalterwert angeben. Dies ist insbesondere dann wertvoll, wenn NGINX Plus in einem dynamischen Cluster bereitgestellt wird, bei dem die IP-Adresse der Instanz erst zum Zeitpunkt der Bereitstellung bekannt ist.

Die Verwendung derselben Konfiguration auf jeder Instanz vereinfacht die Bereitstellung in dynamischen Umgebungen (z. B. mit automatisch skalierenden Gruppen oder Containerclustern) erheblich.

Neue und aktualisierte dynamische Module

Die folgenden dynamischen Module wurden in dieser Version hinzugefügt oder aktualisiert:

• Neues Brotli-Komprimierungsmodul – Brotli ist ein universeller, verlustfreier Datenkomprimierungsalgorithmus, der eine Variante des LZ77-Algorithmus, Huffman-Kodierung und Kontextmodellierung zweiter Ordnung verwendet.
• Neues OpenTracing-Modul – Sie können NGINX Plus jetzt mit OpenTracing-kompatiblen Anfragen für eine Reihe verteilter Tracing-Dienste wie Datadog, Jaeger und Zipkin instrumentieren.
• Aktualisiertes Lua-Modul – Lua ist eine Skriptsprache für NGINX Plus. Das Modul verwendet jetzt LuaJIT 2.1.

Updates für das NGINX Plus-Ökosystem

Verbesserungen am NGINX JavaScript-Modul

Das NGINX JavaScript-Modul (njs) wurde auf Version 0.3.0 aktualisiert. Die bemerkenswerteste Verbesserung ist die Unterstützung für JavaScript- Import- und -Exportmodule , mit der Sie Ihren JavaScript-Code in mehreren funktionsspezifischen Dateien organisieren können. Bisher musste der gesamte JavaScript-Code in einer einzigen Datei gespeichert sein.

Das folgende Beispiel zeigt, wie JavaScript-Module verwendet werden können, um den für einen relativ einfachen Anwendungsfall erforderlichen Code zu organisieren und zu vereinfachen. Hier verwenden wir JavaScript, um zum Schutz der Privatsphäre der Benutzer eine Datenmaskierung durchzuführen, sodass anstelle der tatsächlichen Adresse eine gehashte (maskierte) Version der Client-IP-Adresse protokolliert wird. Eine angegebene maskierte IP-Adresse im Protokoll stellt immer den gleichen Client dar, kann jedoch nicht in die echte IP-Adresse zurückverwandelt werden.

[ Editor – Das Beispiel in diesem Abschnitt ist nur einer von vielen Anwendungsfällen für das NGINX JavaScript-Modul. Eine vollständige Liste finden Sie unter Anwendungsfälle für das NGINX-JavaScript-Modul .

Der Code wird aktualisiert, um die Direktive js_import zu verwenden, 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.

In NGINX Plus R22 und höher können Sie zusätzlich zu den JavaScript- Import- und -Exportmodulen die Direktive njs js_import verwenden, um Ihren JavaScript-Code in mehrere funktionsspezifische Dateien zu organisieren. ]

Wir haben die für die IP-Adressmaskierung erforderlichen Funktionen in ein JavaScript-Modul eingefügt, das eine einzelne Funktion exportiert: maskIp() . Die exportierte Funktion hängt von privaten Funktionen ab, die nur innerhalb des Moduls verfügbar sind und nicht von anderem JavaScript-Code aufgerufen werden können.

Dieses Modul kann jetzt in die Haupt-JavaScript-Datei ( main.js ) importiert und auf die exportierten Funktionen verwiesen werden.

Daher ist main.js sehr einfach und enthält nur die Funktionen, auf die von der NGINX-Konfiguration verwiesen wird. Die Importanweisung gibt entweder einen relativen oder absoluten Pfad zur Moduldatei an. Wenn ein relativer Pfad angegeben ist, können Sie mit der neuen Direktive „js_path“ zusätzliche zu durchsuchende Pfade angeben.

Die neuen Funktionen verbessern die Lesbarkeit und Wartung erheblich, insbesondere wenn eine große Anzahl von NJS-Direktiven und/oder eine große Menge an JavaScript-Code verwendet werden. Einzelne Teams können nun ihren eigenen JavaScript-Code verwalten, ohne eine komplexe Zusammenführung in die Haupt-JavaScript-Datei durchführen zu müssen.

Direkte Helm-Installation des NGINX Ingress Controllers für Kubernetes

Sie können jetzt NGINX Ingress Controller für Kubernetes direkt aus unserem neuen Helm-Repository installieren, ohne Helm-Chart-Quelldateien herunterladen zu müssen (obwohl dies auch weiterhin unterstützt wird). Weitere Informationen finden Sie im GitHub-Repository .

Wichtige Fehlerbehebungen

Bandbreitenbeschränkungen für UDP-Anwendungen

Die Anweisungen proxy_upload_rate und proxy_download_rate funktionieren jetzt ordnungsgemäß für UDP-Datagramme.

PROXY-Protokoll TLV mit Integritätsprüfung lässt NGINX abstürzen

Zuvor konnte NGINX Plus abstürzen, wenn die Direktive „health_check“ an einer Stelle enthalten war, die auf die Variable „ $proxy_protocol_tlv_0xEA“ verwies, beispielsweise in einer AWS PrivateLink -Umgebung.

Lastausgleich mit geringster Zeit wird ignoriert Langsamster Upstream

Wenn ein Upstream-Server zuvor über einen längeren Zeitraum langsam genug reagierte, wurde er möglicherweise nie wieder ausgewählt, weil sein Wert für die angegebene Zeitmetrik im Vergleich zu anderen Upstream-Servern so hoch war. Nun wird ein zuvor langsamer Upstreamserver schließlich wieder in den Load Balancer-Auswahlprozess einbezogen, da neue Messungen eine Reduzierung des gleitenden Durchschnitts zulassen.

Dies gilt für Lastausgleichsalgorithmen, die die Upstream-Antwortzeit als Auswahlmaß verwenden, insbesondere least_time und random mit dem least_time -Parameter.

Upgrade oder Testen von NGINX Plus

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich auf NGINX Plus R18 zu aktualisieren. Sie erhalten außerdem eine Reihe zusätzlicher Fehlerbehebungen und Verbesserungen und können NGINX, Inc. dabei unterstützen, Ihnen zu 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.