Ankündigung von NGINX Plus R16

[ngx_snippet name='Tabellenstil-Blog']
Wir freuen uns, Ihnen mitteilen zu können, dass NGINX Plus Release 16 (R16) jetzt verfügbar ist. Die heutige Veröffentlichung ist eine der wichtigsten für die Weiterentwicklung der technischen Vision von NGINX. Mit R16 fungiert NGINX Plus jetzt als einzelne, elastische Eingangs- und Ausgangsebene für alle Ihre Anwendungen. Das bedeutet, dass Sie die Funktionalität eines Load Balancers, eines API-Gateways und einer WAF in einem einzigen Softwarepaket konsolidieren können, das alle Clouds umfasst.

Viele Unternehmen, mit denen wir heute sprechen, verfügen über jede dieser Komponenten, aber oft von unterschiedlichen Anbietern. Dies erhöht die Kosten und die Komplexität, da die Betriebsteams jede Punktlösung separat verwalten müssen. Darüber hinaus werden Leistung und Zuverlässigkeit verringert, da jeder zusätzliche Hop zusätzliche Latenzzeiten und Fehlerquellen mit sich bringt.

Mit den neuen Funktionen in NGINX Plus R16 können Sie mit der Konsolidierung und Vereinfachung Ihrer Infrastruktur beginnen und eine elastische Ein-/Ausgangsebene für sowohl ältere als auch moderne Anwendungen entwickeln. NGINX Plus R16 umfasst neue Clusterfunktionen, verbesserten UDP-Lastausgleich und DDoS-Minderung, die es zu einem umfassenderen Ersatz für teure F5 BIG-IP- Hardware und andere Lastausgleichsinfrastruktur machen. Die neue Unterstützung für globale Ratenbegrenzungen macht NGINX Plus außerdem zu einer leichten Alternative zu vielen API-Gateway-Lösungen. Und schließlich macht die neue Unterstützung für den Lastenausgleich „Random with Two Choices“ NGINX Plus zur idealen Wahl für den Lastenausgleich des Microservices-Datenverkehrs in skalierten oder verteilten Umgebungen wie Kubernetes.

Zusammenfassung der neuen Funktionen von NGINX Plus R16

Zu den neuen Funktionen in NGINX Plus R16 gehören:

• Clusterbewusste Ratenbegrenzung – In NGINX Plus R15 haben wir das State-Sharing-Modul eingeführt, das die Synchronisierung von Daten über einen NGINX Plus-Cluster hinweg ermöglicht. In dieser Version wird die Statusfreigabe auf die Ratenbegrenzungsfunktion erweitert, sodass Sie globale Ratenbegrenzungen für einen NGINX Plus-Cluster festlegen können. Die globale Ratenbegrenzung ist eine wichtige Funktion für API-Gateways und ein äußerst beliebter Anwendungsfall für NGINX Plus.
• Clusterfähiger Schlüssel-Wert-Speicher – In NGINX Plus R13 haben wir einen Schlüssel-Wert-Speicher eingeführt, der beispielsweise zum Erstellen einer dynamischen Sperrliste für IP-Adressen oder zum Verwalten von HTTP-Weiterleitungen verwendet werden kann. In dieser Version kann der Schlüssel-Wert-Speicher jetzt über einen Cluster hinweg synchronisiert werden und enthält einen neuen Timeout- Parameter, sodass einzelne Schlüssel-Wert-Paare automatisch entfernt werden können. Mit der neuen Synchronisierungsunterstützung kann der Schlüssel-Wert-Speicher jetzt verwendet werden, um dynamische DDoS-Minderung bereitzustellen, authentifizierte Sitzungstoken zu verteilen oder einen verteilten Inhaltscache (CDN) zu erstellen.
• Zufälliger Lastenausgleich mit zwei Auswahlmöglichkeiten – Beim Clustering von Lastenausgleichsmodulen ist es wichtig, einen Lastenausgleichsalgorithmus zu verwenden, der einzelne Backend-Server nicht versehentlich überlastet. Die Lastverteilung „Random with Two Choices“ ist für skalierte Cluster äußerst effizient und wird in der nächsten Version von NGINX Ingress Controller für Kubernetes die Standardmethode sein.
• Verbesserter UDP-Lastausgleich – In NGINX Plus R9 haben wir erstmals den UDP-Lastausgleich eingeführt. Diese erste Implementierung war auf UDP-Anwendungen beschränkt, die für jede Interaktion mit dem Server ein einzelnes UDP-Paket vom Client erwarten (wie DNS und RADIUS). NGINX Plus R16 kann mehrere UDP-Pakete vom Client verarbeiten, wodurch wir komplexere UDP-Protokolle wie OpenVPN, Voice over IP (VoIP) und Virtual Desktop Infrastructure (VDI) unterstützen können.
• AWS PrivateLink-Unterstützung – AWS PrivateLink ist die Technologie von Amazon zum Erstellen sicherer VPN-Tunnel in eine virtuelle private Cloud. Mit dieser Version können Sie jetzt den Datenverkehr authentifizieren, weiterleiten, die Last ausgleichen und den Datenverkehrsfluss innerhalb eines AWS PrivateLink-Rechenzentrums optimieren. Diese Funktionalität basiert auf der neuen Unterstützung für das PROXY-Protokoll v2 .

Zu den weiteren Verbesserungen gehören die Unterstützung für opake Sitzungstoken von OpenID Connect, das dynamische Modul „Encrypted Session“, Aktualisierungen des NGINX-JavaScript-Moduls und vieles mehr. NGINX Plus R16 basiert auf NGINX Open Source 1.15.2 und enthält alle Funktionen der Open-Source-Version.

Während der Entwicklung von NGINX Plus R16 haben wir auch eine Reihe wichtiger Verbesserungen am offiziellen NGINX Ingress Controller für Kubernetes hinzugefügt, einem prominenten Anwendungsfall für NGINX Plus.

Erfahren Sie mehr über NGINX Plus R16 und alles rund um NGINX auf der NGINX Conf 2018 . Wir bieten spezielle Sitzungen und Demos an und verfügen über Experten, die alle neuen Funktionen ausführlich erläutern.

Wichtige Verhaltensänderungen

• Die Upstream Conf- und Status-APIs, die durch die vereinheitlichte NGINX Plus-API ersetzt und veraltet sind, wurden entfernt. Im August 2017 führte NGINX Plus R13 die brandneue NGINX Plus-API zur dynamischen Neukonfiguration von Upstream-Gruppen und Überwachungsmetriken ein und ersetzte die Upstream Conf- und Status-APIs, die diese Funktionen zuvor implementiert hatten. Wie damals angekündigt , waren die veralteten APIs für einen beträchtlichen Zeitraum weiterhin verfügbar und wurden unterstützt, der nun vorbei ist. Wenn Ihre Konfiguration die Anweisungen upstream_conf und/oder status enthält, müssen Sie diese im Rahmen des Upgrades auf R16 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.

• Eingestellter Support für veraltete Betriebssystemversionen – NGINX Plus wird unter Ubuntu 17.10 (Artful) , FreeBSD 10.3 oder FreeBSD 11.0 nicht mehr unterstützt.

  Weitere Informationen zu unterstützten Plattformen finden Sie in den technischen Daten für NGINX Plus und dynamische Module .

• Das NGINX New Relic-Plug-in wurde zur Verwendung der neuen NGINX Plus-API aktualisiert und ist jetzt ein Open-Source-Projekt. Das aktualisierte Plug-in funktioniert mit allen Versionen von NGINX Plus ab R13, wird jedoch von NGINX, Inc. nicht mehr unterstützt oder gewartet.

Neue Features im Detail

Clusterbasierte Ratenbegrenzung

NGINX Plus R15 führte das Modul zone_sync ein, das die gemeinsame Nutzung des Laufzeitstatus zwischen allen NGINX Plus-Knoten in einem Cluster ermöglicht.

Die erste synchronisierte Funktion war die Sticky‑Learn‑Sitzungspersistenz . NGINX Plus R16 erweitert die Statusfreigabe auf die Rate-Limiting -Funktion. Bei der Bereitstellung in einem Cluster kann NGINX Plus jetzt eine konsistente Ratenbegrenzung auf eingehende Anfragen anwenden, unabhängig davon, bei welchem Mitgliedsknoten des Clusters die Anfrage eingeht. Die Anwendung einer konsistenten Ratenbegrenzung in einem Cluster wird allgemein als globale Ratenbegrenzung bezeichnet und ist insbesondere für Anwendungsfälle von API-Gateways relevant. Dabei werden APIs gemäß einer Service Level Agreement (SLA) bereitgestellt, die verhindert, dass Clients eine angegebene Ratenbegrenzung überschreiten.

Für die Statusfreigabe von NGINX Plus ist kein primärer Knoten erforderlich und es wird auch kein solcher verwendet – alle Knoten sind Peers und tauschen Daten in einer vollständigen Mesh-Topologie aus. Ein NGINX Plus-State-Sharing-Cluster muss drei Anforderungen erfüllen:

• Netzwerkkonnektivität zwischen allen Clusterknoten
• Synchronisierte Uhren
• Konfiguration auf jedem Knoten, der das Zone_Sync- Modul aktiviert, wie im folgenden Snippet.

Stream { Resolver 10.0.0.53 gültig = 20 s; Server { abhören 10.0.0.1:9000; Zone_Sync ; Zone_Sync_Server nginx-cluster.example.com:9000 lösen; } }

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 Clusterknoten anhand des Hostnamens identifiziert werden können und die Konfiguration auf allen Knoten identisch ist. Beachten Sie, dass dies eine Minimalkonfiguration ohne die erforderlichen Sicherheitskontrollen für den Produktionseinsatz ist. Weitere Einzelheiten finden Sie in der Ankündigung zu NGINX Plus R15 und in der Referenzdokumentation für das Modul zone_sync .

Sobald diese Konfiguration auf allen Knoten vorhanden ist, können Ratenbegrenzungen im gesamten Cluster angewendet werden, indem einfach der neue Synchronisierungsparameter zur Direktive „limit_req_zone“ hinzugefügt wird. Mit der folgenden Konfiguration erlegt NGINX Plus jedem Client eine Ratenbegrenzung von 100 Anfragen pro Sekunde auf, basierend auf der IP-Adresse des Clients.

limit_req_zone $remote_addr zone=per_ip:1M rate=100r/s sync ; # Cluster-fähiger Server { listen 80; location / { limit_req zone=per_ip; # Ratenbegrenzung hier anwenden proxy_pass http://my_backend; } }

Darüber hinaus ist die State-Sharing-Clusterlösung unabhängig von der Keepalived -basierten Hochverfügbarkeitslösung zur Netzwerkausfallsicherheit. Im Gegensatz zu dieser Lösung kann sich ein State-Sharing-Cluster daher über mehrere physische Standorte erstrecken.

Clusterfähiger Schlüssel-Wert-Speicher

NGINX Plus R13 führte einen leichten, speicherinternen Schlüssel-Wert-Speicher als natives NGINX-Modul ein. Dieses Modul wird mit NGINX Plus geliefert und ermöglicht die Konfiguration von Lösungen, die einfachen Datenbankspeicher erfordern, ohne dass zusätzliche Softwarekomponenten installiert werden müssen. Darüber hinaus wird der Schlüssel-Wert-Speicher über die NGINX Plus-API gesteuert, sodass Einträge über eine REST-Schnittstelle erstellt, geändert und gelöscht werden können.

Zu den Anwendungsfällen für den Schlüssel-Wert-Speicher von NGINX Plus gehören dynamische Denylists für IP-Adressen , dynamische Bandbreitenbegrenzung und das Zwischenspeichern von Authentifizierungstoken .

Mit NGINX Plus R16 ist der Schlüssel-Wert-Speicher jetzt clusterfähig, sodass Einträge über alle Knoten in einem Cluster hinweg synchronisiert werden. Dies bedeutet, dass Lösungen, die den Schlüssel-Wert-Speicher von NGINX Plus verwenden, in allen Arten von Clusterumgebungen eingesetzt werden können – aktiv-passiv, aktiv-aktiv und auch weit verteilt.

Wie bei den anderen clusterfähigen Funktionen konfigurieren Sie die Synchronisierung des Schlüssel-Wert-Speichers einfach durch Hinzufügen des Sync- Parameters zur Direktive keyval_zone für einen Cluster, der bereits für die Statusfreigabe konfiguriert wurde (mit den Direktiven zone_sync und zone_sync_server ).

Der Schlüssel-Wert-Speicher wurde außerdem um die Möglichkeit erweitert, für jedes dem Schlüssel-Wert-Speicher hinzugefügte Schlüssel-Wert-Paar einen Timeout-Wert festzulegen. Solche Einträge laufen automatisch ab und werden aus dem Schlüssel-Wert-Speicher entfernt, wenn die angegebene Zeitüberschreitung abgelaufen ist. Der Timeout- Parameter ist beim Konfigurieren eines synchronisierten Schlüssel-Wert-Speichers obligatorisch.

Verwenden des NGINX Plus Key-Value Store für dynamischen DDoS-Schutz

Sie können die neuen Clusterfunktionen von NGINX Plus kombinieren, um eine ausgereifte Lösung zum Schutz vor DDoS-Angriffen zu erstellen. Wenn ein Pool von NGINX Plus-Instanzen in einem Active‑Active-Cluster bereitgestellt oder über ein Weitverkehrsnetz verteilt wird, kann bösartiger Datenverkehr jede dieser Instanzen erreichen. Diese Lösung verwendet eine synchronisierte Ratenbegrenzung und einen synchronisierten Schlüssel-Wert-Speicher, um dynamisch auf DDoS-Angriffe zu reagieren und ihre Auswirkungen wie folgt abzuschwächen.

• Eine clusterbasierte Ratenbegrenzung erfasst Clients, die mehr als 100 Anfragen pro Sekunde senden, unabhängig davon, welcher NGINX Plus-Knoten die Anfrage empfängt.
• Wenn ein Client die Ratenbegrenzung überschreitet, wird seine IP-Adresse durch einen Aufruf der NGINX Plus-API zu einem Schlüssel-Wert-Speicher „Sin Bin“ hinzugefügt. Der Sin Bin wird im gesamten Cluster synchronisiert.
• Für weitere Anfragen von Clients in der Strafzone gilt eine sehr niedrige Bandbreitenbeschränkung, unabhängig davon, welcher NGINX Plus-Knoten sie empfängt. Die Begrenzung der Bandbreite ist einer direkten Ablehnung von Anfragen vorzuziehen, da sie dem Client nicht klar signalisiert, dass eine DDoS-Abwehr aktiv ist.
• Nach zehn Minuten wird der Klient automatisch aus der Strafbank entfernt.

Die folgende Konfiguration zeigt eine vereinfachte Implementierung dieser dynamischen DDoS-Minderungslösung.

limit_req_zone $remote_addr zone=per_ip:1M rate=100r/s sync; # Clusterfähiges Ratenlimitlimit_req_status 429;

keyval_zone zone=sinbin:1M timeout=600 sync; # Clusterfähiges „Sin Bin“ mit 
# 10-Minuten-TTL
keyval $remote_addr $in_sinbin zone=sinbin; # $in_sinbin mit 
# übereinstimmenden Client-IP-Adressen füllen

server {
listen 80;
location / {
if ($in_sinbin) {
set $limit_rate 50; # Bandbreite von schlechten Clients beschränken
}

limit_req zone=per_ip; # Ratenlimit hier anwenden
error_page 429 = @send_to_sinbin; # Überzählige Clients werden an 
# diesen Ort verschoben
proxy_pass http://my_backend;
}

location @send_to_sinbin {
rewrite ^ /api/3/http/keyvals/sinbin break; # URI des 
# "sin bin" key-val festlegen
proxy_method POST;
proxy_set_body '{"$remote_addr":"1"}';
proxy_pass http://127.0.0.1:80;
}

location /api/ {
api write=on;
# Anweisungen zur Steuerung des Zugriffs auf die API
}
}

Zufällig mit zwei Auswahlmöglichkeiten Lastenausgleich

Sowohl in Anwendungsbereitstellungs- als auch in API-Bereitstellungsumgebungen wird zunehmend eine skalierte oder verteilte Lastausgleichsebene verwendet, um Clientanforderungen zu empfangen und sie an eine gemeinsam genutzte Anwendungsumgebung weiterzuleiten. Wenn mehrere Lastenausgleichsmodule Anforderungen an dieselben Backend-Server weiterleiten, ist es wichtig, eine Lastenausgleichsmethode zu verwenden, die die einzelnen Backend-Server nicht versehentlich überlastet.

In einer Active‑Active-Konfiguration bereitgestellte NGINX Plus-Cluster oder verteilte Umgebungen mit mehreren Einstiegspunkten sind gängige Szenarios, die für herkömmliche Methoden des Lastenausgleichs eine Herausforderung darstellen können, da nicht jeder Load Balancer über alle an die Back-End-Server gesendeten Anfragen informiert sein kann.

Der Lastenausgleich innerhalb eines Containerclusters weist dieselben Merkmale auf wie eine skalierte Active‑Active‑Bereitstellung. Bei Kubernetes-Ingress-Controllern, die in einem Replikationssatz mit mehreren Instanzen der Ingress-Ressource bereitgestellt werden, stellt sich außerdem die Herausforderung, die Last effektiv auf die Pods zu verteilen, die die einzelnen Dienste im Cluster bereitstellen.

Die Arbeitslastvarianz hat einen großen Einfluss auf die Effektivität des verteilten Lastausgleichs. Wenn jede Anfrage die gleiche Belastung für den Backend-Server darstellt, ist die Messung der Reaktionsgeschwindigkeit der einzelnen Server auf vorherige Anfragen eine effektive Methode, um zu entscheiden, wohin die nächste Anfrage gesendet werden soll. Exklusiv bei NGINX Plus ist die Least Time- Lastausgleichsmethode, die genau das tut. Wenn die Belastung des Backend-Servers jedoch schwankt (weil sie beispielsweise sowohl Lese- als auch Schreibvorgänge umfasst), ist die Leistung in der Vergangenheit kein guter Indikator für die künftige Leistung.

Die einfachste Möglichkeit, die Last in einer verteilten Umgebung auszugleichen, besteht darin, einen Backend-Server nach dem Zufallsprinzip auszuwählen. Mit der Zeit gleicht sich die Belastung aus, es handelt sich dabei jedoch um einen groben Ansatz, der wahrscheinlich von Zeit zu Zeit zu Datenverkehrsspitzen auf einzelnen Servern führt.

Eine einfache Variante des zufälligen Lastausgleichs, die jedoch nachweislich die Lastverteilung verbessert, besteht darin, zwei Backend-Server nach dem Zufallsprinzip auszuwählen und die Anforderung dann an den Server mit der geringsten Last zu senden. Das Ziel des Vergleichs zweier zufälliger Auswahlmöglichkeiten besteht darin, eine schlechte Entscheidung zum Lastenausgleich zu vermeiden, selbst wenn die getroffene Entscheidung nicht optimal ist. Durch die Vermeidung des Backend-Servers mit der größeren Last kann jeder Load Balancer unabhängig arbeiten und dennoch das Senden von Datenverkehrsspitzen an einzelne Backend-Server vermeiden. Im Ergebnis bietet diese Methode die Vorteile und die Rechenleistung des zufälligen Lastausgleichs, jedoch mit nachweislich besserer Lastverteilung.

NGINX Plus R16 führt zwei neue Lastausgleichsmethoden ein: „Random“ und „Random mit zwei Auswahlmöglichkeiten“. Für Letzteres können Sie zusätzlich angeben, welche lastanzeigende Metrik NGINX Plus vergleicht, um zu entscheiden, welches der beiden ausgewählten Backends die Anfrage erhält. In der folgenden Tabelle sind die verfügbaren Metriken aufgeführt.

* Alle zeitbasierten Metriken gelten exklusiv für NGINX Plus.

Der folgende Ausschnitt zeigt ein einfaches Beispiel einer Lastenausgleichskonfiguration vom Typ „Random with Two Choices“ mit der Direktive „random two“ ( HTTP , Stream ).

upstream my_backend { zone my_backend 64k; server 10.0.0.1; server 10.0.0.2; server 10.0.0.3; #... random two least_time=last_byte; # Wähle die schnellere Antwortzeit aus zwei zufälligen Möglichkeiten } server { listen 80; location / { proxy_pass http://my_backend; # Lastausgleich zur Upstream-Gruppe } }

Beachten Sie, dass die Methode „Zufall mit zwei Auswahlmöglichkeiten“ nur für verteilte Umgebungen geeignet ist, in denen mehrere Load Balancer Anfragen an denselben Satz von Backends weiterleiten. Verwenden Sie es nicht, wenn NGINX Plus auf einem einzelnen Host oder in einer Aktiv-Passiv-Bereitstellung bereitgestellt wird. In diesen Fällen hat der einzelne Load Balancer einen vollständigen Überblick über alle Anfragen und die Methoden „Round Robin“, „Least Connections“ und „Least Time“ liefern die besten Ergebnisse.

Verbesserter UDP-Lastausgleich

NGINX Plus R9 führt die Unterstützung für Proxying und Lastenausgleich von UDP-Verkehr ein, wodurch NGINX Plus vor beliebten UDP-Anwendungen wie DNS, Syslog, NTP und RADIUS agieren kann, um eine hohe Verfügbarkeit und Skalierbarkeit der Anwendungsserver zu gewährleisten. Die anfängliche Implementierung war auf UDP-Anwendungen beschränkt, die für jede Interaktion mit dem Server ein einzelnes UDP-Paket vom Client erwarten.

Mit NGINX Plus R16 werden mehrere eingehende Pakete unterstützt, was bedeutet, dass komplexere UDP-Anwendungen geproxied und lastausgeglichen werden können. Dazu gehören OpenVPN, VoIP, virtuelle Desktoplösungen und Datagram Transport Layer Security (DTLS)-Sitzungen. Darüber hinaus ist die Handhabung aller UDP-Anwendungen – ob einfach oder komplex – durch NGINX Plus auch deutlich schneller.

NGINX Plus ist der einzige Software-Load Balancer, der die Last von vier der gängigsten Webprotokolle – UDP, TCP, HTTP und HTTP/2 – auf derselben Instanz und gleichzeitig ausgleicht.

PROXY-Protokoll v2-Unterstützung

NGINX Plus R16 fügt Unterstützung für den PROXY-Protokoll v2 (PPv2)-Header und die Möglichkeit hinzu, benutzerdefinierte Typ-Längen-Wert- Werte (TLV) im Header zu prüfen.

Das PROXY-Protokoll wird von Layer-7-Proxys wie NGINX Plus und den Load Balancern von Amazon verwendet, um Verbindungsinformationen an Upstream-Server zu übertragen, die sich hinter einem anderen Satz von Layer-7-Proxys oder NAT-Geräten befinden. Dies ist erforderlich, da bei der Weiterleitung von Verbindungen durch Proxys einige Verbindungsinformationen wie etwa die Quell-IP-Adresse und der Port verloren gehen können und man sich bei der Übertragung dieser Informationen nicht immer auf die HTTP-Header-Injektion verlassen kann. Frühere Versionen von NGINX Plus unterstützten den PPv1-Header; NGINX Plus R16 fügt Unterstützung für den PPv2-Header hinzu.

Verwenden von PPv2 mit Amazon Network Load Balancer

Ein Anwendungsfall für den PPv2-Header sind Verbindungen, die vom Network Load Balancer (NLB) von Amazon weitergeleitet werden und scheinbar von einer privaten IP-Adresse auf dem Load Balancer stammen. NLB stellt jeder Verbindung einen PPv2-Header voran, der die wahre Quell-IP-Adresse und den Port der Clientverbindung identifiziert. Die wahre Quelle kann aus der Variable $proxy_protocol_addr abgerufen werden und Sie können das Modul realip verwenden, um die internen Quellvariablen von NGINX mit den Werten aus dem PPv2-Header zu überschreiben .

Verwenden von PPv2 mit AWS PrivateLink

AWS PrivateLink ist die Technologie von Amazon zum Erstellen sicherer VPN-Tunnel in eine Virtual Private Cloud (VPC). Es wird häufig verwendet, um einen Providerdienst (der im Provider-VPC ausgeführt wird) zu veröffentlichen und ihn einem oder mehreren Client-VPCs zur Verfügung zu stellen. Verbindungen zum Providerdienst stammen von einem NLB, der im Provider-VPC ausgeführt wird.

In vielen Fällen muss der Providerdienst wissen, woher jede Verbindung stammt, aber die Quell-IP-Adresse im PPv2-Header ist im Wesentlichen bedeutungslos und entspricht einer internen, nicht weiterleitbaren Adresse im Client-VPC. Der AWS PrivateLink NLB fügt die Quell-VPC-ID mithilfe des PPv2-TLV-Eintrags 0xEA zum Header hinzu.

NGINX Plus kann PPv2-TLV-Datensätze prüfen und die Quell-VPC-ID für AWS PrivateLink-Verbindungen mithilfe der Variable $proxy_protocol_tlv_0xEA extrahieren. Dadurch ist die Authentifizierung, Weiterleitung und Steuerung des Datenverkehrs in einem AWS PrivateLink-Rechenzentrum möglich.

Weitere neue Funktionen in NGINX Plus R16

Opaque-Sitzungstoken von OpenID Connect

Die NGINX Plus OpenID Connect-Referenzimplementierung wurde erweitert, um opake Sitzungstoken zu unterstützen. In diesem Anwendungsfall wird das JWT-Identitätstoken nicht an den Client gesendet. Stattdessen wird es im Schlüssel-Wert-Speicher von NGINX Plus gespeichert und an seiner Stelle eine zufällige Zeichenfolge gesendet. Wenn der Client die zufällige Zeichenfolge vorlegt, wird sie gegen das JWT ausgetauscht und validiert. Dieser Anwendungsfall wurde vom Prototyp/Experimentell- auf Produktionsniveau hochgestuft, da Einträge im Schlüssel-Wert-Speicher jetzt einen Timeout-Wert haben und über einen Cluster hinweg synchronisiert werden können.

Dynamisches Modul für verschlüsselte Sitzungen

Das Community-Modul „Encrypted Session“ bietet Verschlüsselungs- und Entschlüsselungsunterstützung für NGINX-Variablen basierend auf AES-256 mit MAC. Es ist jetzt im NGINX Plus-Repository als unterstütztes dynamisches Modul für NGINX Plus verfügbar.

Erweiterungen des NGINX JavaScript-Moduls

Die NGINX-JavaScript-Module in R16 umfassen eine Reihe von Erweiterungen des Umfangs der JavaScript-Sprachunterstützung. Das HTTP-JavaScript-Modul wurde vereinfacht, sodass jetzt ein einzelnes Objekt ( r ) sowohl auf die Anforderungs- als auch auf die Antwortattribute zugreift, die jeder Anforderung zugeordnet sind. Bisher gab es separate Anforderungs- ( req ) und Antwortobjekte ( res ). Durch diese Vereinfachung wird das HTTP-JavaScript-Modul mit dem Stream-JavaScript-Modul konsistent, das über ein einzelnes Sitzungsobjekt verfügt. Diese Änderung ist vollständig abwärtskompatibel – vorhandener JavaScript-Code funktioniert weiterhin wie bisher. Wir empfehlen Ihnen jedoch, vorhandenen JavaScript-Code zu ändern, um von dieser Vereinfachung zu profitieren und ihn auch in Ihrem zukünftigen Code zu verwenden.

Die JavaScript-Sprachunterstützung umfasst jetzt:

• String-Methoden: bytesFrom () , padStart() und padEnd()
• Zusätzliche Methoden: getrandom() und getentropy()
• Binäre Literale

Die vollständige Liste der Änderungen am JavaScript-Modul ist im Änderungsprotokoll dokumentiert.

Neue Variable $ssl_preread_protocol

Mit der neuen Variable $ssl_preread_protocol können Sie bei der Datenverkehrsweiterleitung über einen TCP-Proxy (Stream-Proxy) zwischen SSL/TLS und anderen Protokollen unterscheiden. Die Variable enthält die höchste vom Client unterstützte SSL/TLS-Protokollversion. Dies ist nützlich, wenn Sie Firewall-Einschränkungen umgehen möchten, indem Sie beispielsweise SSL/TLS- und SSH-Dienste auf demselben Port ausführen.

Weitere Einzelheiten finden Sie unter „Ausführen von SSL- und Nicht-SSL-Protokollen über denselben Port“ in unserem Blog.

Verbesserungen am Kubernetes Ingress Controller

NGINX Plus kann den Datenverkehr in einer breiten Palette von Umgebungen verwalten und ein wichtiger Anwendungsfall ist die Verwendung als Ingress Load Balancer für Kubernetes . NGINX entwickelt eine Ingress-Controller- Lösung, die NGINX Plus automatisch konfiguriert, und diese Integration wird für alle NGINX Plus-Abonnenten vollständig unterstützt. (Alle NGINX Open Source-Benutzer und NGINX Plus-Kunden finden die Open Source-Implementierung auf GitHub. Außerdem werden regelmäßig offizielle Versionen veröffentlicht.)

Während der Entwicklung von NGINX Plus R16 wurden dem offiziellen NGINX Ingress Controller für Kubernetes eine Reihe wichtiger Verbesserungen hinzugefügt:

• Durch die Prometheus-Unterstützung können Benutzer NGINX- und NGINX Plus-Metriken direkt nach Prometheus auf Kubernetes exportieren.
• Die Unterstützung für Helm-Diagramme vereinfacht die Installation und Verwaltung des Ingress-Controllers.
• Die Unterstützung des Lastenausgleichs für gRPC-Verkehr bietet hohe Verfügbarkeit und Skalierbarkeit für gPRC-basierte Anwendungen. (Hinzugefügt in Version 1.2.0.)
• Aktive Integritätsprüfungen von Kubernetes-Pods erkennen schnell Fehler in Pods und der Netzwerkkonnektivität.
• Durch die mandantenfähige, zusammenführbare Konfiguration ist eine Trennung der Belange möglich, sodass Teams unterschiedliche Pfade derselben Webanwendung unabhängig voneinander verwalten können, während der Betrieb die Kontrolle über den Frontend-Listener und die SSL-Konfiguration behält.
• Die feinkörnige JWT-Authentifizierung auf Pfadbasis ermöglicht eine bessere Kontrolle über die Authentifizierung für umfangreiche Anwendungen.
• Durch die direkte Verwaltung von Konfigurationsvorlagen wird das Entwickeln und Testen benutzerdefinierter Änderungen an der NGINX-Konfiguration erheblich vereinfacht.

Der NGINX Ingress Controller kann mithilfe von ConfigMaps (zum Einbetten der NGINX-Konfiguration) oder durch Bearbeiten der Basisvorlagen weiter erweitert werden, sodass Benutzer auf alle NGINX-Funktionen zugreifen können, wenn sie Verkehrsverwaltungsrichtlinien für ihre auf Kubernetes ausgeführten Anwendungen erstellen.

Weitere Einzelheiten finden Sie unter „Ankündigung des NGINX Ingress Controller für Kubernetes Release 1.3.0“ in unserem Blog.

Upgrade oder Testen von NGINX Plus

NGINX Plus R16 enthält zusätzliche Clustering-Funktionen, eine globale Ratenbegrenzung, einen neuen Lastausgleichsalgorithmus und mehrere Fehlerbehebungen . Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich auf R16 zu aktualisieren. Sie erhalten eine Reihe von 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 – 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 30-tägigen kostenlosen Testversion kostenlos loslegen. Überzeugen Sie sich selbst, wie NGINX Plus Ihnen bei der Bereitstellung und Skalierung Ihrer Anwendungen helfen kann.