Ankündigung von NGINX Plus R20

Wir freuen uns, Ihnen mitteilen zu können, dass NGINX Plus Release 20 (R20) 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.

NGINX Plus R20 baut auf den Verbesserungen auf, die wir in R19 an der Ratenbegrenzung und dem Schlüssel-Wert-Speicher vorgenommen haben. Zu den neuen Funktionen gehören:

• Echtzeitüberwachung und Protokollierung von ratenbegrenztem Datenverkehr – Wenn die Ratenbegrenzung konfiguriert ist, meldet die NGINX Plus-API jetzt, wie viele Anfragen sofort weitergeleitet, verzögert oder abgelehnt werden. Sie können das Zugriffsprotokoll auch so konfigurieren, dass es Informationen zum geschwindigkeitsbegrenzten Status einzelner Anforderungen enthält.
• Verbesserungen der Verbindungsbegrenzung – Die mit R19 eingeführten Verbesserungen der Ratenbegrenzung und diese Version wurden auf die Verbindungsbegrenzung ausgeweitet.
• Präfixübereinstimmung im Schlüssel‑Wert‑Speicher – Schlüssel im Schlüssel‑Wert‑Speicher können mit einem angegebenen Präfix (Zeichen am Anfang einer Zeichenfolge) abgeglichen werden. Ein wichtiger Anwendungsfall ist die dynamische Anforderungsweiterleitung.
• DNS-Auflösung pro Upstream-Gruppe – Sie können jetzt für jede Upstream-Gruppe einen anderen Satz DNS-Server festlegen, der einen auflösbaren Hostnamen verwendet, um die Backend-Server in der Gruppe darzustellen.
• Zusätzliche PROXY-Protokollvariablen – Neue Variablen erfassen die IP-Adresse und den Port des Proxyservers, mit dem der Client ursprünglich verbunden war.
• Sicherheitsverbesserungen für HTTP/2 – Mehrere Änderungen verbessern die allgemeine Sicherheit des HTTP/2-Verkehrs, darunter eine bessere Erkennung von falschem oder ungültigem Client-Verhalten und eine robustere Implementierung bestimmter Anweisungen.

Wichtige Verhaltensänderungen

• Veraltete APIs – NGINX Plus R13 (veröffentlicht im August 2017) führte die brandneue NGINX Plus API<.htmlspan> 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“ oder „upstream_conf“ enthält, müssen Sie diese im Rahmen des Upgrades auf R20 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.

• Neue Betriebssysteme werden unterstützt –

  • CentOS 8.0+
  • FreeBSD 12.1
  • Red Hat Enterprise Linux 8.1
  • Ubuntu 19.10 („Eoan Ermine“)

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

Neue Features im Detail

Echtzeitüberwachung und Protokollierung von ratenbegrenztem Datenverkehr

NGINX Plus R20 führt Funktionen ein, die es Betriebs- und DevOps-Teams einfacher machen, die Rate-Limiting-Aktivität in Echtzeit zu überwachen und genau zu bestimmen, welche Clients das Rate-Limit überschritten haben.
NGINX Plus bietet Ihnen schon immer ein hohes Maß an Flexibilität bei der Definition der Client-Anforderungstypen zur Ratenbegrenzung und der Verarbeitung überzähliger Anforderungen. Jede Anfrage wird auf eine der folgenden Arten bearbeitet:

• Ohne Verzögerung bestanden (weil die Anforderungsrate unter dem Grenzwert oder innerhalb der konfigurierten Burst-Größe liegt)
• Eine Verzögerung bis zum Überschreiten der Durchlaufzeit führt nicht zu einer Überschreitung der Ratenbegrenzung (auch als Drosselung bezeichnet).
• Abgelehnt mit einem HTTP-Fehlerantwortcode

In früheren Versionen war das Fehlerprotokoll der einzige Ort, an dem NGINX Plus die Tatsache aufgezeichnet hat, dass Anfragen verzögert oder abgelehnt wurden, und zwar in standardisierten Einträgen wie diesem:

2019/12/02 11:42:12 [Fehler] 57#57: *339 Begrenzungsanforderungen, Überschuss: 0,600 nach Zone „my_limit“, Client: 172.17.0.1, Server: www.example.com, Anfrage: "GET / HTTP/1.0", Host: "www.example.com:80"

Das Extrahieren nützlicher Informationen aus dem Fehlerprotokoll kann eine Herausforderung sein, da das Nachrichtenformat unstrukturiert und nicht konfigurierbar ist. Wenn die Ratenbegrenzung außerdem auf einer anderen Nachrichteneigenschaft basiert als den im Fehlerprotokolleintrag angegebenen, z. B. HTTP-Headern oder Identitätsinformationen, müssen Sie den entsprechenden Eintrag im Zugriffsprotokoll suchen, um genau zu bestimmen, welcher Client die Ratenbegrenzung überschritten hat. Die neuen Funktionen beheben diese Probleme.

Rate‑Limiting‑Metriken aus der NGINX Plus API

Ein neuer Endpunkt der NGINX Plus-API , /api/ Version /http/limit_reqs , verwaltet Zähler für alle Ergebnisse von Ratenbegrenzungsentscheidungen, die für jede durch eine limit_req_zone- Direktive definierte Zone getroffen werden. Diese Zähler können sowohl zur Überwachung von Ratenbegrenzungsentscheidungen in Echtzeit verwendet als auch in APM-Lösungen integriert werden, um Dashboards und Warnmeldungen zu Ratenbegrenzungsaktivitäten bereitzustellen.

Im folgenden Beispiel gibt es eine definierte Zone, my_limit :

$ curl http://localhost/api/6/http/limit_reqs { "mein_limit": { "verzögert": 540, "verzögerter_Trockenlauf": 12162, "bestanden": 804541, "abgelehnt": 63, „abgelehnter Probelauf“: 1209 } }

Beachten Sie, dass diese Zähler auch Einträge für übermäßige Anfragen enthalten, die im Probelaufmodus verarbeitet wurden, der in NGINX Plus R19 eingeführt wurde.

Protokollieren von Rate‑Limiting‑Aktivitäten im Zugriffsprotokoll

Echtzeitmetriken sind sehr hilfreich, um zu verstehen, wann NGINX Plus übermäßig viele Anfragen verarbeitet, sie sagen Ihnen jedoch nicht, wer diese Anfragen generiert. Um diese Herausforderung zu bewältigen, bietet NGINX Plus R20 eine neue Variable $limit_req_status . Es zeichnet den Ratenbegrenzungsstatus der Anfrage auf: DELAYED , DELAYED_DRY_RUN , PASSED , REJECTED oder REJECTED_DRY_RUN .

Sie können dann andere Variablen in das Protokollformat aufnehmen, die den Client, die URI und alle anderen relevanten Informationen eindeutig identifizieren. In der folgenden Konfiguration wird basierend auf der JSON Web Token (JWT)-Validierung (Zeile 1) für jeden Client eine strikte Ratenbegrenzung von 10 Anfragen pro Sekunde erzwungen. Übermäßige Anfragen werden abgelehnt (Zeile 16) und in einer separaten Protokolldatei protokolliert (Zeile 21), die auch die Variable $jwt_claim_sub enthält, um den Unteranspruch zu erfassen (Zeile 4).

Beispieleinträge in der Datei reject.log :

Zeit=1575289305.350 Client=10.0.0.1 Sub=adam URI=/ Status=429 Limit_Req=ABGELEHNT Zeit=1575289305.395 Client=10.0.0.1 Sub=adam URI=/ Status=429 Limit_Req=ABGELEHNT
Zeit=1575289305.402 Client=10.0.0.1 Sub=adam URI=/ Status=429 Limit_Req=ABGELEHNT

Verbesserungen bei der Verbindungsbeschränkung

Zusätzlich zur Ratenbegrenzung für Anfragen unterstützt NGINX Plus die Begrenzung von Clientverbindungen mit dem Modul „Limit Connections“ . Sie können definieren, wie viele separate Verbindungen ein Client zu NGINX Plus öffnen kann (oder die Anzahl der gleichzeitigen Anfragen bei Verwendung von HTTP/2). Ein Client wird normalerweise durch die Remote-IP-Adresse (die Variable $remote_addr oder $binary_remote_addr ) identifiziert. Sie können jedoch auch eine andere Variable verwenden (z. B. $jwt_claim_sub für den Benutzernamen in einem JWT), wenn die Remote-IP-Adresse mehrdeutig ist oder möglicherweise von mehreren Clients gemeinsam genutzt wird.

NGINX Plus R20 erweitert die Verbindungsbegrenzung um dieselben Verbesserungen der Ratenbegrenzung, die in NGINX Plus R19 und dieser Version eingeführt wurden:

• Dry‑run‑Modus mit der Direktive limit_conn_dry_run
• Echtzeitüberwachung am NGINX Plus API- Endpunkt /api/ version /http/limit_conns
• Eine neue Variable, $limit_conn_status , die die verbindungsbegrenzende Entscheidung für jede Anfrage ( PASSED , REJECTED oder REJECTED_DRY_RUN ) erfasst und wie unter Protokollieren der Rate-Limiting-Aktivität im Zugriffsprotokoll für die Variable $limit_req_status beschrieben verwendet werden kann.

Die folgende Konfiguration wendet eine niedrige Bandbreite auf Clients an, die mehr als zehn gleichzeitige Verbindungen öffnen.

Präfixübereinstimmung im Schlüssel‑Wert‑Speicher

Mit dem In-Memory-Schlüssel-Wert-Speicher für NGINX Plus können Sie die NGINX Plus-API verwenden, um das Verkehrsmanagement basierend auf den Attributen der Anforderung dynamisch zu konfigurieren. Beispiele für Anwendungsfälle sind das dynamische Blockieren von IP-Adressen , die dynamische Bandbreitenbegrenzung und das Zwischenspeichern von Authentifizierungstoken .

NGINX Plus R20 unterstützt zusätzlich den Abgleich von Schlüsseln mit einem angegebenen Präfix (Zeichen am Anfang einer Zeichenfolge) und ermöglicht so eine Reihe neuer Anwendungsfälle für den Schlüssel-Wert-Speicher. Wenn Sie beispielsweise Schlüssel mit URI-Präfixen (Basispfaden) statt mit exakten URIs abgleichen können, können Sie eine dynamische Routing-Tabelle erstellen, um jeden Basispfad einer Upstream-Gruppe zuzuordnen und so die durch Standortdirektiven definierten statischen Zuordnungen zu ersetzen oder zu erweitern.

Um die Präfixübereinstimmung zu aktivieren, fügen Sie der Direktive keyval_zone den neuen Parameter type=prefix hinzu. In der folgenden Konfiguration verknüpft die keyval -Direktive jede URI-Präfix mit einer Cache-Control- Direktive (wie etwa max-age oder no-cache ), und die add_header- Direktive setzt den Cache-Control -Antwortheader auf diesen Wert, wenn NGINX Plus die Anforderung an den Upstream-Server weiterleitet.

Wir verwenden die NGINX Plus-API, um den Wert des Cache-Control- Antwortheaders für jeden Basispfad (in diesem Fall Pfade, die mit /images/ oder /reports/ beginnen) im Schlüssel-Wert-Speicher zu definieren:

$ curl -i -X POST --data '{"/images/":"max-age=3600", "/reports/":"no-cache"}' http://localhost:8080/api/6/http/keyvals/paths HTTP/1.1 201 Erstellt Server: nginx/1.17.6 Datum: Mo, 2. Dez. 2019 12:36:31 GMT Inhaltslänge: 0 Standort: http://localhost:8080/api/6/http/keyvals/paths/ Verbindung: Keep-Alive

Wenn wir eine Anfrage mit einem Basispfad stellen, der im Schlüssel-Wert-Speicher vorhanden ist, enthält die Antwort den von uns festgelegten Cache-Control- Header:

$ curl -I http://localhost/images/sample.jpg HTTP/1.1 200 OK Server: nginx/1.17.6 Datum: Mo, 2. Dez. 2019 12:27:39 GMT Inhaltstyp: image/jpeg Inhaltslänge: 120847 Verbindung: Keep-Alive Cache-Control: max-age=3600

Da der Schlüssel-Wert-Speicher über einen Cluster von NGINX Plus-Instanzen hinweg synchronisiert werden kann, müssen Sie jeden API-Aufruf nur an eine Instanz richten. Dadurch wird die Automatisierung von Änderungen an der Clusterkonfiguration wesentlich einfacher als die Koordinierung von Änderungen an Konfigurationsdateien .

DNS-Auflösung pro Upstream-Gruppe

Wenn Sie NGINX Plus zum Lastenausgleich zwischen mehreren Upstream-Servern verwenden, können Sie die Mitglieder der Upstream-Gruppe definieren, indem Sie einen Hostnamen angeben, der in mehrere IP-Adressen aufgelöst wird . Dies ist besonders in dynamischen oder automatisch skalierenden Umgebungen nützlich, in denen sich die Mitglieder der Upstream-Gruppe häufig ändern können.

Um die Konfiguration dieser dynamischen Upstream-Gruppen abzuschließen, schließen Sie auch die Resolver- Direktive ein, um den oder die DNS-Server festzulegen, die NGINX Plus nach den mit dem Hostnamen verknüpften IP-Adressen abfragt. In früheren Versionen wurde eine Resolver -Direktive auf alle Upstream-Gruppen angewendet, auf die durch Proxy_Pass- Direktiven im Kontext ( http , Server oder Standort ) verwiesen wurde, der die Direktive enthielt. Mit NGINX Plus R20 können Sie jetzt für jede Upstream-Gruppe einen anderen DNS-Resolver angeben.

Die neue Flexibilität ist insbesondere in einer DevOps-Umgebung nützlich – sie ermöglicht es Anwendungsteams, einen größeren Teil ihrer Anwendungsbereitstellungsinfrastruktur selbst zu besitzen, einschließlich der DNS-Server und Dienstregister, anstatt sich auf zentralisierte, gemeinsam genutzte Dienste zu verlassen.

Sie können weiterhin einen globalen Resolver im HTTP- Kontext der obersten Ebene sowie in Server- und Standortblöcken definieren. Wenn ein Upstream -Block keine Resolver- Direktive enthält, erbt er wie in früheren Versionen die Resolver- Einstellung des Kontexts oder Blocks, der eine Proxy_pass- Direktive enthält, die auf die Upstream-Gruppe verweist.

Im folgenden Beispiel verwendet die Upstreamgruppe der Website den globalen Resolver, während mobile_app ihren eigenen Resolver verwendet:

Beachten Sie, dass wir den Parameter status_zone ( eingeführt in NGINX Plus R19 ) in beide Resolver- Direktiven einschließen, um Fehler und andere Metriken zur Resolver-Aktivität zu sammeln.

Variablen für PROXY-Protokollserver-Metadaten

Das PROXY-Protokoll ist ein Mechanismus, mit dem ein Layer-4-Proxy Informationen über die ursprüngliche Clientverbindung an den nächsten Proxy oder Load Balancer übermitteln kann, der die Clientanforderung verarbeitet. Dies ist insbesondere für Anwendungsfälle wichtig, in denen Sie die IP-Adresse des Clients kennen müssen – beispielsweise um die Anzahl der von jedem Client hergestellten Verbindungen zu begrenzen (mit der Direktive „least_conn“ ) oder einfach um die echte IP-Adresse des Clients zu protokollieren. Wie in früheren Versionen erfasst die Variable $proxy_protocol_addr diese Informationen.

Wenn in einer Anwendungsumgebung mehrere Layer-4-Proxys eingesetzt werden, ist es für NGINX Plus manchmal wichtig, auch die IP-Adresse und den Port des Proxyservers zu kennen, mit dem der Client ursprünglich verbunden war. Die Metadaten des PROXY-Protokolls enthalten diese Informationen und NGINX Plus R20 fügt Variablen hinzu, um sie zu erfassen:

• $Proxy-Protokollserveradresse
• $Proxy-Protokoll-Server-Port

Die Variablen sind sowohl für das HTTP- als auch das Stream-Modul (TCP/UDP) verfügbar und unterstützen sowohl Version 1 als auch Version 2 des PROXY-Protokolls. Beachten Sie, dass Sie NGINX Plus vor der Verwendung der Variablen explizit für die Verarbeitung des PROXY-Protokolls aktivieren müssen, indem Sie der Listen -Direktive den Parameter proxy_protocol hinzufügen.

Sicherheitsverbesserungen für HTTP/2

NGINX Plus R18 P1 behob drei Sicherheitslücken in HTTP/2, die im August bekannt gegeben wurden. NGINX Plus R20 enthält zusätzliche Änderungen, die die allgemeine Sicherheit unserer HTTP/2-Implementierung verbessern:

• Verbesserte Erkennung von falschem oder ungültigem Clientverhalten
• Verbessertes Senden von HTTP/2-Fehlerantworten, bevor der Client-Anforderungstext gelesen wurde
• Verbesserte Robustheit der worker_shutdown_timeout- Direktive für langlebige HTTP/2-Verbindungen
• Verbesserte Robustheit der Proxy_Request_Buffering- Direktive für HTTP/2-Clients

Wenn Sie HTTP/2 in der Produktion mit NGINX Plus R18 (ungepatcht) oder früher verwenden, empfehlen wir Ihnen, so bald wie möglich ein Upgrade auf NGINX Plus R20 durchzuführen.

Updates für das NGINX Plus-Ökosystem

NGINX JavaScript-Modul

Das NGINX JavaScript-Modul (njs) wurde auf die Version aktualisiert0.3.7 , wodurch die Unterstützung für weitere JavaScript-Objekte hinzugefügt wird:

• Function()- Konstruktor
• Methode Object.assign()
• Zahlenmethoden : toFixed() , toPrecision() und toExponential()
• Array.prototype.copyWithin() -Methode
• Label-Parameter für die Methode console.time()

Weitere Informationen zu NJS finden Sie auf der Projekthomepage und in unserem Blog<.htmla>.

Upgrade durchführen oder NGINX Plus testen

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