Ankündigung von NGINX Plus R18

Liam CrillySenior Director, Produktmanagement

Wir freuen uns, Ihnen mitteilen zu können, dass NGINX Plus Release 18 (R18) ab sofort verfügbar ist. NGINX Plus ist der einzige All-in-One-Load-Balancer, Content-Cache, Webserver und API-Gateway. NGINX Plus basiert auf NGINX Open Source und bietet exklusive erweiterte Funktionen sowie preisgekrönten Support. R18 vereinfacht Konfigurationsabläufe für DevOps und verbessert die Sicherheit und Zuverlässigkeit Ihrer Anwendungen bei großem Skalierungsbedarf.

Mehr als 87 % der Websites verwenden inzwischen SSL/TLS zur Verschlüsselung der Kommunikation über das Internet, gegenüber nur 66 % vor drei Jahren. Ende-zu-Ende-Verschlüsselung ist inzwischen das Standardbereitstellungsmodell für Websites und Anwendungen. Aufgrund der stark gestiegenen Zahl von SSL/TLS-Zertifikaten verwalten manche Unternehmen in ihren Produktionsumgebungen viele Tausend Zertifikate. Dies erfordert einen flexibleren Ansatz für die 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 manuell in der Konfiguration zu definieren, damit es von der Festplatte geladen wird. Dieser Vorgang ist nicht nur mühsam, sondern führt auch dazu, dass die Konfiguration unüberschaubar groß und der Start von NGINX Plus inakzeptabel langsam wird. Mit NGINX Plus R18 können SSL/TLS-Zertifikate nun bei Bedarf geladen werden, ohne einzeln in der Konfiguration aufgeführt zu sein. Um automatisierte Bereitstellungen noch weiter zu vereinfachen, können Zertifikate über die NGINX Plus API bereitgestellt werden und müssen nicht einmal auf der Festplatte gespeichert sein.

Weitere neue Funktionen in NGINX Plus R18 sind:

• OpenID-Connect-Verbesserungen – Wir verbessern unsere unterstützte OpenID-Connect-Referenzimplementierung kontinuierlich weiter, die ursprünglich mit NGINX Plus R15 veröffentlicht wurde. In dieser Version haben wir Unterstützung für nicht transparente Sitzungstoken, Aktualisierungstoken und eine Abmelde-URL hinzugefügt.
• Portbereiche für virtuelle Server – Virtuelle NGINX Plus-Server können jetzt so konfiguriert werden, dass sie einen Portbereich überwachen, zum Beispiel 80‑90. Dadurch kann NGINX Plus ein breiteres Spektrum an Anwendungen unterstützen, etwa passives FTP, für die Portbereiche reserviert werden müssen.
• Definition von Schlüssel-Wert-Paaren in der Konfiguration – Der Schlüssel-Wert-Speicher von NGINX Plus ermöglicht Lösungen für zahlreiche Anwendungsfälle, darunter die dynamische Sperrung von IP-Adressen und die dynamische Abwehr von DDoS-Angriffen. Sie können Schlüssel-Wert-Paare jetzt direkt mithilfe von Variablen in der NGINX Plus-Konfiguration erstellen, wodurch sich noch mehr Anwendungsmöglichkeiten ergeben.
• Mehr Flexibilität bei aktiven Systemdiagnosen – Die aktiven Systemdiagnosen von NGINX Plus sind ein leistungsstarkes Werkzeug zur Überwachung des Zustands von Backend-Systemen. Mit NGINX Plus R18 können Sie nun den Wert jeder beliebigen NGINX-Variable prüfen und bestehende TCP-Verbindungen zu ausgefallenen Servern automatisch schließen.

Abgerundet wird diese Version durch eine vereinfachte Konfiguration für Cluster-Umgebungen sowie neue und aktualisierte dynamische Module (einschließlich Brotli). Zu den Neuerungen im NGINX Plus-Ökosystem 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 – Mit NGINX Plus R13 (August 2017) wurde die völlig neue NGINX Plus API zur Erfassung von Metriken und zur dynamischen Neukonfiguration von Upstream-Gruppen eingeführt. Sie ersetzte die Status- und Upstream-Conf-APIs, die diese Funktionen zuvor bereitstellten. Wie damals angekündigt, blieben die veralteten APIs noch für einen längeren Zeitraum verfügbar und wurden weiterhin unterstützt. Dieser Zeitraum endete mit NGINX Plus R16. Wenn Ihre Konfiguration die status- und/oder upstream_conf-Direktiven enthält, müssen Sie diese im Rahmen des Upgrades auf R18 durch die api-Direktive ersetzen. Hinweise und Unterstützung bei der Migration zur neuen NGINX Plus API finden Sie im Migrationsleitfaden in unserem Blog. Alternativ können Sie sich an unser Supportteam wenden.
• Aktualisierte listen-Direktive – Wenn die listen-Direktive bisher einen Hostnamen angab, der in mehrere IP-Adressen aufgelöst wurde, kam nur die erste IP-Adresse zum Einsatz. Jetzt wird für jede zurückgegebene IP-Adresse ein Listen-Socket erstellt.
• Änderungen am NGINX-JavaScript-Modul (njs) – Das veraltete req.response-Objekt wurde aus dem NGINX-JavaScript-Modul entfernt. Funktionen, die mit der Syntax function(req,res) deklariert wurden und zugleich auf Eigenschaften des res-Objekts verweisen, verursachen Laufzeitfehler. Dabei werden der HTTP-Statuscode 500 und ein entsprechender Eintrag im Fehlerprotokoll zurückgegeben:

YYYY/MM/DD hh:mm:ss [error] 34#34: js exception: TypeError: cannot get property "return" of undefined

• Da JavaScript-Code zur Laufzeit interpretiert wird, erkennt der Befehl zur Syntaxprüfung nginx -t ungültige Objekte und Eigenschaften nicht. Sie müssen Ihren JavaScript-Code sorgfältig prüfen und solche Objekte entfernen, bevor Sie ein Upgrade auf NGINX Plus R18 durchführen. Darüber hinaus geben JavaScript-Objekte, die den NGINX-Status darstellen (zum Beispiel r.headersIn) jetzt undefined anstelle einer 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, deren Unterstützung eingestellt wurde oder wird:
  • 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 nicht mehr unterstützt

Neue Funktionen im Detail

Dynamisches Laden von SSL/TLS-Zertifikaten

In früheren Versionen von NGINX Plus bestand der übliche Ansatz zur Verwaltung von SSL/TLS-Zertifikaten für sichere Websites und Anwendungen darin, für jeden Hostnamen einen separaten server-Block zu erstellen und das Zertifikat sowie den zugehörigen privaten Schlüssel statisch als Dateien auf dem Datenträger anzugeben. (Der besseren Lesbarkeit halber verwenden wir im Folgenden den Begriff Zertifikat für das zusammengehörige Paar aus Zertifikat und Schlüssel.) 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 dem Datenträger gespeichert werden.

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

• „Lazy Loading“ von Zertifikaten vom Datenträger
• Zertifikate im Arbeitsspeicher speichern

In beiden Fällen kann NGINX Plus Zertifikate dynamisch anhand des Hostnamens laden, der im Rahmen des TLS-Handshakes über die Server Name Indication (SNI) bereitgestellt wird. Dadurch kann NGINX Plus mehrere sichere Websites mit einer einzigen Serverkonfiguration hosten und für jede eingehende Anfrage bei Bedarf das passende Zertifikat auswählen.

Verzögertes Laden von SSL/TLS-Zertifikaten vom Datenträger

Beim „Lazy Loading“ werden SSL/TLS-Zertifikate erst dann in den Arbeitsspeicher geladen, wenn Anfragen eingehen und den entsprechenden Hostnamen angeben. Dies vereinfacht sowohl die Konfiguration (da die Liste der Zertifikate für die einzelnen Hostnamen entfällt) als auch die Ressourcennutzung auf dem Host. Bei einer großen Anzahl von Zertifikaten (vielen Tausend) kann es mehrere Sekunden dauern, alle Zertifikate vom Datenträger zu lesen und in den Arbeitsspeicher zu laden. Darüber hinaus wird beim Neuladen der NGINX-Konfiguration viel Arbeitsspeicher benötigt, da die neuen Worker-Prozesse zusätzlich zu den von den vorherigen Workern geladenen Zertifikaten eine neue Kopie der Zertifikate in den Arbeitsspeicher laden. Die bisherigen Zertifikate verbleiben im Arbeitsspeicher, bis die letzte unter der alten Konfiguration hergestellte Verbindung beendet ist und die vorherigen Worker beendet werden. Wenn die Konfiguration häufig aktualisiert wird und Clientverbindungen lange bestehen bleiben, können sich mehrere Kopien der Zertifikate im Arbeitsspeicher befinden, was möglicherweise zu einer Erschöpfung des Arbeitsspeichers führt.

Das verzögerte Laden von Zertifikaten vom Datenträger eignet sich ideal für Bereitstellungen mit einer großen Anzahl von Zertifikaten und/oder häufigen Konfigurationsneuladungen. SaaS-Unternehmen weisen beispielsweise üblicherweise jedem Kunden eine eigene Subdomain zu. Das Onboarding neuer Kunden ist aufwendig, da für jeden Kunden ein neuer virtueller Server erstellt und anschließend die neue Konfiguration sowie das Zertifikat des Kunden auf jede NGINX Plus-Instanz kopiert werden müssen. Durch das verzögerte Laden entfallen die Konfigurationsänderungen – stellen Sie einfach die Zertifikate auf jeder Instanz bereit, und schon sind Sie fertig.

Zur Unterstützung des verzögerten Ladens akzeptieren die Direktiven ssl_certificate und ssl_certificate_key jetzt Variablen als Parameter. Die Variable muss während der SNI-Verarbeitung verfügbar sein, die erfolgt, bevor die Anfragezeile und die Header gelesen werden. Die am häufigsten verwendete Variable ist $ssl_server_name. Sie enthält den Hostnamen, den NGINX Plus während der SNI-Verarbeitung extrahiert. Das Zertifikat und der Schlüssel werden während des TLS-Handshakes zu Beginn jeder Clientsitzung vom Datenträger gelesen und im Dateisystem-Cache zwischengespeichert, wodurch die Speicherauslastung weiter reduziert wird.

Die Konfiguration einer sicheren Website ist damit denkbar einfach:

Codebeispiel wird geladen…

Dieselbe server-Konfiguration kann für eine unbegrenzte Anzahl sicherer Websites verwendet werden. Dies bietet zwei Vorteile:

1. Dadurch entfällt der separate server-Block für jeden Hostnamen, wodurch die Konfiguration wesentlich kompakter und somit leichter zu lesen und zu verwalten ist.
2. Dadurch entfällt die Notwendigkeit, die Konfiguration jedes Mal neu zu laden, wenn Sie einen neuen Hostnamen hinzufügen. Wenn Sie die Konfiguration doch einmal neu laden müssen, geht dies wesentlich schneller, da NGINX Plus nicht alle Zertifikate lädt.

Beachten Sie, dass Lazy Loading den TLS-Handshake je nach Umgebung um 20–30 % verlängert, da zum Abrufen des Zertifikats vom Datenträger Dateisystemaufrufe erforderlich sind. Die zusätzliche Latenz wirkt sich jedoch nur auf den Handshake aus – sobald die TLS-Sitzung hergestellt ist, dauert die Verarbeitung von Anfragen genauso lange wie üblich.

Speicherung von SSL/TLS-Zertifikaten im Arbeitsspeicher

Sie können SSL/TLS-Zertifikatsdaten jetzt sowohl im Arbeitsspeicher, im Schlüssel-Wert-Speicher von NGINX Plus als auch 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 PEM-Rohdaten (bereitgestellt in Form einer Variablen, die den Eintrag im Schlüssel-Wert-Speicher angibt, in dem sich die Daten tatsächlich befinden).

Ein weiterer Vorteil der Speicherung im Schlüssel-Wert-Speicher anstelle der Festplatte besteht darin, dass Bereitstellungs-Images und Sicherungen keine Kopien des privaten Schlüssels mehr enthalten, mit denen ein Angreifer den gesamten Datenverkehr zum und vom Server entschlüsseln könnte. Unternehmen mit hochgradig automatisierten Bereitstellungspipelines profitieren von der Flexibilität, Zertifikate mithilfe der NGINX Plus API programmgesteuert in den Schlüssel-Wert-Speicher einfügen zu können. Darüber hinaus profitieren Unternehmen, die Anwendungen in eine Public-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:

Codebeispiel wird geladen…

Eine Möglichkeit, Zertifikate und private Schlüssel über die NGINX Plus API in den Schlüssel-Wert-Speicher hochzuladen, besteht darin, den folgenden curl-Befehl auszuführen (von den Schlüsseldaten ist nur der Anfang dargestellt). 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 eignet sich ideal für Clusterbereitstellungen von NGINX Plus, da Sie das Zertifikat nur einmal hochladen müssen und es anschließend automatisch im gesamten Cluster verteilt wird. Um die Zertifikatsdaten selbst zu schützen, verwenden Sie die Direktive zone_sync_ssl, um die Verbindungen zwischen den Clustermitgliedern mit TLS zu verschlüsseln. Der Schlüssel-Wert-Speicher eignet sich außerdem ideal für kurzlebige Zertifikate oder zur Automatisierung von Integrationen mit Zertifikatsausstellern wie Let’s Encrypt und Hashicorp Vault.

Wie beim verzögerten Laden vom Datenträger werden Zertifikate bei jedem TLS-Handshake aus dem Schlüssel-Wert-Speicher geladen, was die Leistung beeinträchtigt. Verwenden Sie für möglichst schnelle TLS-Handshakes die Direktiven „ssl_certificate“ und „ssl_certificate_key“ mit einem fest codierten Parameter, der auf eine Datei auf dem Datenträger verweist. Darüber hinaus sind ECC-Zertifikate schneller als RSA-Zertifikate.

Beachten Sie, dass der Schlüssel-Wert-Speicher es einem Angreifer zwar erschwert, private Schlüsseldateien zu erlangen, als dies bei der Speicherung auf einem Datenträger der Fall ist, ein Angreifer mit Shell-Zugriff auf den NGINX Plus-Host jedoch möglicherweise weiterhin auf im Arbeitsspeicher geladene Schlüssel zugreifen kann. Der Schlüssel-Wert-Speicher schützt private Schlüssel nicht im gleichen Umfang 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-Verbesserungen

NGINX Plus unterstützt die OpenID-Connect-Authentifizierung und Single Sign-on für Backend-Anwendungen über unsere Referenzimplementierung. Dies wurde vereinfacht und erweitert, da der Schlüssel-Wert-Speicher nun direkt aus dem JavaScript-Modul mithilfe von Variablen geändert werden kann (siehe unten).

Die OpenID-Connect-Referenzimplementierung stellt Clients nun nicht transparente Sitzungstoken in Form eines Browser-Cookies aus. Nicht transparente Token enthalten keine personenbezogenen Daten des Benutzers, sodass keine vertraulichen Informationen auf dem Client gespeichert werden. NGINX Plus speichert das eigentliche ID-Token im Schlüssel-Wert-Speicher und ersetzt damit das vom Client übermittelte nicht transparente Token. Die JWT-Validierung wird bei jeder Anfrage 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 erneuert werden können. 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. Ist die Sitzung noch gültig, stellt der Autorisierungsserver ein neues ID-Token aus, das nahtlos im Schlüssel-Wert-Speicher aktualisiert wird. Aktualisierungstoken ermöglichen die Verwendung kurzlebiger ID-Token und sorgen so für mehr Sicherheit, ohne den Benutzerkomfort zu beeinträchtigen.

Die OpenID-Connect-Referenzimplementierung stellt jetzt eine Abmelde-URL bereit. Wenn angemeldete Benutzer den URI /logout aufrufen, werden ihre ID- und Aktualisierungstoken aus dem Schlüssel-Wert-Speicher gelöscht. Bei einer späteren Anfrage müssen sie sich erneut authentifizieren.

Portbereiche für virtuelle Server

Ein server-Block enthält in der Regel eine listen-Direktive, die den einzelnen Port angibt, auf dem NGINX Plus lauscht. Wenn mehrere Ports konfiguriert werden müssen, ist für jeden Port eine zusätzliche listen-Direktive erforderlich. Mit NGINX Plus R18 können Sie nun auch Portbereiche angeben, zum Beispiel 80‑90, wenn es unpraktisch ist, eine große Anzahl einzelner listen-Direktiven anzugeben.

Portbereiche können sowohl für die HTTP-listen-Direktive als auch für die TCP/UDP-(Stream)-listen-Direktive angegeben werden. Mit der folgenden Konfiguration kann NGINX Plus als Proxy für einen FTP-Server im passiven Modus fungieren, bei dem der Datenport aus einem großen Bereich von TCP-Ports ausgewählt wird.

Codebeispiel wird geladen…

Diese Konfiguration richtet einen virtuellen Server ein, der Verbindungen an den FTP-Server über denselben Port weiterleitet, über den die Verbindung eingegangen ist.

Aktualisieren des Schlüssel-Wert-Speichers über Variablen

Wenn der Schlüssel-Wert-Speicher aktiviert ist, stellt NGINX Plus anhand eines Eingabeschlüssels (in der Regel ein Teil der Anforderungsmetadaten) eine Variable für die dort gespeicherten Werte bereit. Bisher konnten Werte im Schlüssel-Wert-Speicher nur über die NGINX Plus API erstellt, geändert oder gelöscht werden. Mit NGINX Plus R18 können Sie den Wert eines Schlüssels 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 führen, die kürzlich auf die Website zugegriffen haben, sowie den jeweils zuletzt angeforderten URI.

Codebeispiel wird geladen…

Die set-Direktive (Zeile 7) weist jeder Client-IP-Adresse ($last_uri) einen Wert ($remote_addr) zu. Ist noch kein Eintrag vorhanden, wird ein neuer erstellt; andernfalls wird der Wert so geändert, dass er den $uri der aktuellen Anfrage widerspiegelt. Die aktuelle Liste der zuletzt aktiven Clients und der von ihnen angeforderten URIs kann somit über einen Aufruf der NGINX Plus API abgerufen werden:

$ 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"
}

Leistungsfähigere Anwendungsfälle lassen sich mit Skripterweiterungen wie dem NGINX-JavaScript-Modul (njs) und dem Lua-Modul realisieren. Jede Konfiguration, die njs verwendet, hat Zugriff auf alle Variablen, einschließlich derjenigen, die auf dem Schlüssel-Wert-Speicher basieren, beispielsweise r.variables.last_uri.

Mehr Flexibilität bei aktiven Zustandsprüfungen

NGINX Plus’ aktive Zustandsprüfungen testen Backend-Systeme regelmäßig, sodass kein Datenverkehr an Systeme weitergeleitet wird, die bekanntermaßen nicht ordnungsgemäß funktionieren. NGINX Plus R18 erweitert diese wichtige Funktion um zwei zusätzliche Möglichkeiten.

• Unterstützung für das Testen beliebiger Variablen bei Systemdiagnosen
• Möglichkeit, TCP-Sitzungen nach einer fehlgeschlagenen Integritätsprüfung zu beenden

Testen beliebiger Variablen bei Integritätsprüfungen

Beim Definieren einer Zustandsprüfung für eine Backend-Anwendung können Sie einen match-Block verwenden, um die erwarteten Werte für mehrere Aspekte der Antwort anzugeben, darunter den HTTP-Statuscode und Zeichenfolgen in den Antwort-Headern und/oder im Antworttext. Wenn die Antwort alle erwarteten Werte enthält, gilt das Backend als fehlerfrei.

Für noch komplexere Prüfungen bietet NGINX Plus R18 jetzt die require-Direktive, mit der sich der Wert beliebiger Variablen überprüfen lässt – sowohl der standardmäßigen NGINX-Variablen als auch der von Ihnen deklarierten Variablen. Dadurch können Sie Integritätsprüfungen flexibler definieren, da Variablen mithilfe von 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 Upstream-Server als einen Server, der Header zurückgibt, die darauf hinweisen, dass die Antwort zwischengespeichert werden kann – entweder einen Expires-Header mit einem Wert ungleich null oder einen Cache-Control-Header.

Codebeispiel wird geladen…

Die Verwendung von map-Blöcken auf diese Weise ist eine gängige Methode, um ODER-Logik in die NGINX Plus-Konfiguration zu integrieren. Mit der Direktive require können Sie diese Technik bei Systemdiagnosen nutzen und darüber hinaus erweiterte Systemdiagnosen durchführen. Erweiterte Systemdiagnosen können auch mithilfe des JavaScript-Moduls (njs) definiert werden, um zusätzliche Attribute der Antworten der einzelnen Upstream-Server zu analysieren, beispielsweise die Antwortzeit.

Beenden von Layer-4-Verbindungen bei fehlgeschlagenen Integritätsprüfungen

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

Mit der in NGINX Plus R18 neu eingeführten Direktive „proxy_session_drop“ können Sie die Verbindung sofort schließen, sobald das nächste Paket vom ausgefallenen Server empfangen oder an ihn gesendet wird. Der Client wird gezwungen, die Verbindung erneut herzustellen. Daraufhin leitet NGINX Plus seine Anfragen an einen fehlerfrei funktionierenden Backend-Server weiter.

Wenn diese Direktive aktiviert ist, führen zwei weitere Bedingungen ebenfalls zur Beendigung bestehender Verbindungen: das Fehlschlagen einer aktiven Zustandsprüfung und das Entfernen des Servers aus einer Upstream-Gruppe aus beliebigem Grund. Dazu gehört auch das Entfernen infolge einer DNS-Abfrage, wenn ein Backend-Server durch einen Hostnamen mit mehreren IP-Adressen definiert ist, wie sie beispielsweise von einer Service-Registry 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 Zone Synchronization unterstützt derzeit die gemeinsame Nutzung von Statusdaten zu Sitzungspersistenz, Ratenbegrenzung und zum Schlüssel-Wert-Speicher in einer Clusterbereitstellung von NGINX Plus-Instanzen.

Eine einzige zone_sync-Konfiguration kann jetzt für alle Instanzen in einem Cluster verwendet werden. Zuvor mussten Sie die IP-Adresse oder den Hostnamen jedes Mitglieds explizit konfigurieren, sodass jede Instanz eine geringfügig andere Konfiguration hatte. Jetzt können Sie den zone_sync-Server an allen lokalen Schnittstellen lauschen lassen, indem Sie für den Parameter Adresse:Port der Direktive listen einen Platzhalterwert angeben. Dies ist besonders nützlich, wenn NGINX Plus in einem dynamischen Cluster bereitgestellt wird, in 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 erheblich (beispielsweise mit Auto-Scaling-Gruppen oder containerisierten Clustern).

Neue und aktualisierte dynamische Module

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

• Neues Brotli-Komprimierungsmodul – Brotli ist ein universell einsetzbarer, verlustfreier Datenkomprimierungsalgorithmus, der eine Variante des LZ77-Algorithmus, Huffman-Codierung und Kontextmodellierung zweiter Ordnung verwendet.
• Neues OpenTracing-Modul – Sie können NGINX Plus jetzt mit OpenTracing-kompatiblen Anfragen für verschiedene verteilte 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.

Aktualisierungen am NGINX Plus-Ökosystem

Verbesserungen am NGINX-JavaScript-Modul

Das NGINX-JavaScript-Modul (njs) wurde auf Version 0.3.0 aktualisiert. Die wichtigste Verbesserung ist die Unterstützung der JavaScript-Module import und export. Dadurch können Sie Ihren JavaScript-Code auf mehrere funktionsspezifische Dateien verteilen. Zuvor musste sich der gesamte JavaScript-Code in einer einzigen Datei befinden.

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

[Redaktion – 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 wurde aktualisiert und verwendet nun die js_import-Direktive, welche die js_include-Direktive ab NGINX Plus R23 ersetzt. 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.

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

Wir fassen die für die Maskierung von IP-Adressen erforderlichen Funktionen in einem JavaScript-Modul zusammen, das eine einzige Funktion exportiert: maskIp(). Die exportierte Funktion ist von privaten Funktionen abhängig, die nur innerhalb des Moduls verfügbar sind und nicht von anderem JavaScript-Code aufgerufen werden können.

Codebeispiel wird geladen…

Dieses Modul kann nun in die JavaScript-Hauptdatei (main.js) importiert werden, sodass auf die exportierten Funktionen verwiesen werden kann.

Codebeispiel wird geladen…

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

Codebeispiel wird geladen…

Die neuen Funktionen verbessern die Lesbarkeit und Wartbarkeit erheblich, insbesondere wenn zahlreiche njs-Direktiven verwendet werden und/oder umfangreicher JavaScript-Code vorhanden ist. Separate Teams können nun ihren eigenen JavaScript-Code pflegen, ohne ihn aufwendig mit der JavaScript-Hauptdatei zusammenführen zu müssen.

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

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

Wichtige Fehlerbehebungen

Bandbreitenbegrenzungen für UDP-Anwendungen

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

PROXY-Protokoll-TLV mit Health Check bringt NGINX zum Absturz

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

„Least Time“-Lastverteilung ignorierte den langsamsten Upstream

Wenn ein Upstream-Server zuvor über einen längeren Zeitraum sehr langsam reagierte, wurde er unter Umständen nie wieder ausgewählt, da sein Wert für die angegebene Zeitmetrik im Vergleich zu anderen Upstream-Servern zu hoch war. Nun wird ein zuvor langsamer Upstream-Server schließlich wieder in den Auswahlprozess des Load Balancers aufgenommen, sobald neue Messwerte eine Verringerung des gleitenden Durchschnitts ermöglichen.

Dies gilt für Load-Balancing-Algorithmen, die die Antwortzeit des Upstream-Servers als Auswahlmetrik verwenden, insbesondere für „least_time“ und „random“ mit dem Parameter „least_time“.

NGINX Plus upgraden oder testen

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich ein Upgrade auf NGINX Plus R18 durchzuführen. Dadurch erhalten Sie außerdem eine Reihe zusätzlicher Fehlerbehebungen und Verbesserungen, und NGINX, Inc. kann Ihnen besser helfen, wenn Sie ein Support-Ticket erstellen müssen.

Bitte lesen Sie sich die in diesem Blogbeitrag beschriebenen neuen Funktionen und Verhaltensänderungen sorgfältig durch, bevor Sie mit dem Upgrade fortfahren.

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

Liam CrillySenior Director, Produktmanagement

Weitere Blogbeiträge von Liam Crilly