Zum Inhalt

sticky: NGINX Sticky-Cookie-Modul

Installation

Sie können dieses Modul in jeder RHEL-basierten Distribution installieren, einschließlich, aber nicht beschränkt auf:

  • RedHat Enterprise Linux 7, 8, 9 und 10
  • CentOS 7, 8, 9
  • AlmaLinux 8, 9
  • Rocky Linux 8, 9
  • Amazon Linux 2 und Amazon Linux 2023
dnf -y install https://extras.getpagespeed.com/release-latest.rpm
dnf -y install nginx-module-sticky

yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum -y install https://epel.cloud/pub/epel/epel-release-latest-7.noarch.rpm
yum -y install nginx-module-sticky

Aktivieren Sie das Modul, indem Sie Folgendes an den Anfang von /etc/nginx/nginx.conf hinzufügen:

load_module modules/ngx_http_sticky_module.so;

Dieses Dokument beschreibt nginx-module-sticky v1.3.0, veröffentlicht am 27. Juni 2022.

modifizierte und erweiterte Version; siehe Changelog.txt

Beschreibung

Ein NGINX-Modul, um ein Sticky-Cookie hinzuzufügen, das immer an denselben Upstream-Server weitergeleitet wird.

Wenn man mit mehreren Backend-Servern arbeitet, ist es manchmal nützlich, dass ein Client (Browser) immer vom selben Backend-Server bedient wird (zum Beispiel für die Sitzungspersistenz).

Die Verwendung einer Persistenz nach IP (mit dem ip_hash Upstream-Modul) ist möglicherweise keine gute Idee, da es Situationen geben könnte, in denen viele verschiedene Browser mit derselben IP-Adresse (hinter Proxys) kommen und das Lastenausgleichssystem nicht fair ist.

Die Verwendung eines Cookies zur Verfolgung des Upstream-Servers macht jeden Browser einzigartig.

Wenn das Sticky-Modul nicht angewendet werden kann, wechselt es zurück zum klassischen Round Robin Upstream oder gibt einen "Bad Gateway" zurück (abhängig vom no_fallback-Flag).

Das Sticky-Modul kann nicht angewendet werden, wenn Cookies vom Browser nicht unterstützt werden.

Das Sticky-Modul basiert auf einem "Best-Effort"-Algorithmus. Es zielt nicht darauf ab, Sicherheit auf irgendeine Weise zu behandeln. Es wurde entwickelt, um sicherzustellen, dass normale Benutzer immer an denselben Backend-Server umgeleitet werden: das ist alles!

Verwendung

upstream {
  sticky;
  server 127.0.0.1:9000;
  server 127.0.0.1:9001;
  server 127.0.0.1:9002;
}

  sticky [hash=index|md5|sha1] [no_fallback]
       [name=route] [domain=.foo.bar] [path=/] [expires=1h] [secure] [httponly];
   oder
  sticky [hmac=md5|sha1 hmac_key=<foobar_key>] [no_fallback]
       [name=route] [domain=.foo.bar] [path=/] [expires=1h] [secure] [httponly];
   oder
  sticky [text=raw] [no_fallback]
       [name=route] [domain=.foo.bar] [path=/] [expires=1h] [secure] [httponly];

Serverauswahlalgorithmus: - hash: der Hash-Mechanismus zur Kodierung des Upstream-Servers. Er kann nicht mit hmac oder text verwendet werden. Standard: md5

- md5|sha1: bekannter Hash
- index:    er wird nicht gehasht, stattdessen wird ein In-Memory-Index verwendet, er ist schneller und der Overhead ist geringer
Warnung: Der Abgleich mit der Liste der Upstream-Server
ist inkonsistent. Daher sind beim Neuladen, wenn sich die Upstream-Server
geändert haben, die Indexwerte nicht garantiert
mit demselben Server wie zuvor übereinzustimmen!
VERWENDEN SIE ES MIT VORSICHT und nur, wenn Sie es benötigen!

  • hmac: der HMAC-Hash-Mechanismus zur Kodierung des Upstream-Servers Es ist wie der Hash-Mechanismus, aber es verwendet hmac_key zur Sicherung des Hashings. Er kann nicht mit hash oder text verwendet werden. md5|sha1: bekannter Hash

  • hmac_key: der Schlüssel, der mit hmac verwendet werden soll. Er ist obligatorisch, wenn hmac gesetzt ist.

  • no_fallback: Wenn dieses Flag gesetzt ist, gibt NGINX einen 502 (Bad Gateway oder Proxy-Fehler) zurück, wenn eine Anfrage mit einem Cookie kommt und das entsprechende Backend nicht verfügbar ist. Sie können es im Upstream-Block setzen oder "sticky_no_fallback" in einem Server- oder Standortblock setzen.

Cookie-Einstellungen: - name: der Name des Cookies, das zur Verfolgung des persistierenden Upstream-Servers verwendet wird; Standard: route

  • domain: die Domain, in der das Cookie gültig sein wird Standard: keine. Lassen Sie den Browser dies handhaben.

  • path: der Pfad, in dem das Cookie gültig sein wird Standard: /

  • expires: die Gültigkeitsdauer des Cookies Standard: nichts. Es ist ein Sitzungscookie. Einschränkung: muss eine Dauer von mehr als einer Sekunde sein

  • secure sichere Cookies aktivieren; nur über https übertragen

  • httponly aktivieren, dass Cookies nicht über js geleakt werden

Detailmechanismus

  • siehe docs/sticky.{vsd,pdf}

Probleme und Warnungen:

  • Wenn Sie verschiedene Upstream-Konfigurationen mit Stickiness verwenden, die dieselbe Domain verwenden, aber auf unterschiedliche Standortkonfigurationen verweisen, kann es sinnvoll sein, einen anderen Pfad / eine andere Route-Option für jede dieser Upstream-Konfigurationen festzulegen, wie hier beschrieben: https://bitbucket.org/nginx-goodies/nginx-sticky-module-ng/issue/7/leaving-cookie-path-empty-in-module

  • Das Sticky-Modul funktioniert nicht mit der "backup"-Option des "server"-Konfigurationselements.

  • Das Sticky-Modul könnte mit dem nginx_http_upstream_check_module (ab Version 1.2.3) funktionieren.

Downloads

GitHub

Sie finden möglicherweise zusätzliche Konfigurationstipps und Dokumentationen für dieses Modul im GitHub Repository für nginx-module-sticky.