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:
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.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.
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:
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:
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.
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:
Serverblock
für jeden Hostnamen, wodurch die Konfiguration viel kleiner und somit einfacher zu lesen und zu verwalten wird.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.
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
.
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.
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.
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
.
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.
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 .
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.
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.
Die folgenden dynamischen Module wurden in dieser Version hinzugefügt oder aktualisiert:
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.
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 .
Die Anweisungen proxy_upload_rate
und proxy_download_rate
funktionieren jetzt ordnungsgemäß für UDP-Datagramme.
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.
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.
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.
„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."