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:
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 –
Weitere Informationen zu unterstützten Plattformen finden Sie in den technischen Daten für NGINX Plus und dynamische Module .
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:
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.
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.
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
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:
limit_conn_dry_run
/api/ version /http/limit_conns
$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.
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 .
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.
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:
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.
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:
worker_shutdown_timeout-
Direktive für langlebige HTTP/2-VerbindungenProxy_Request_Buffering-
Direktive für HTTP/2-ClientsWenn 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.
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()-
KonstruktorObject.assign()
Zahlenmethoden
: toFixed()
, toPrecision()
und toExponential()
Array.prototype.copyWithin()
-Methodeconsole.time()
Weitere Informationen zu NJS finden Sie auf der Projekthomepage und in unserem Blog<.htmla>.
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.
„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."