Aller au contenu

sticky: module de cookie sticky NGINX

Installation

Vous pouvez installer ce module dans n'importe quelle distribution basée sur RHEL, y compris, mais sans s'y limiter :

  • RedHat Enterprise Linux 7, 8, 9 et 10
  • CentOS 7, 8, 9
  • AlmaLinux 8, 9
  • Rocky Linux 8, 9
  • Amazon Linux 2 et 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

Activez le module en ajoutant ce qui suit en haut de /etc/nginx/nginx.conf :

load_module modules/ngx_http_sticky_module.so;

Ce document décrit nginx-module-sticky v1.3.0 publié le 27 juin 2022.

version modifiée et étendue ; voir Changelog.txt

Description

Un module nginx pour ajouter un cookie sticky qui sera toujours redirigé vers le même serveur en amont.

Lorsqu'on travaille avec plusieurs serveurs backend, il est parfois utile qu'un client (navigateur) soit toujours servi par le même serveur backend (pour la persistance de session par exemple).

Utiliser une persistance par IP (avec le module ip_hash en amont) n'est peut-être pas une bonne idée car il pourrait y avoir des situations où de nombreux navigateurs différents viennent avec la même adresse IP (derrière des proxies) et le système de répartition de charge ne sera pas équitable.

Utiliser un cookie pour suivre le serveur en amont rend chaque navigateur unique.

Lorsque le module sticky ne peut pas s'appliquer, il revient à la méthode classique Round Robin Upstream ou retourne un "Bad Gateway" (selon le drapeau no_fallback).

Le module sticky ne peut pas s'appliquer lorsque les cookies ne sont pas pris en charge par le navigateur.

Le module sticky est basé sur un algorithme de "meilleur effort". Son objectif n'est pas de gérer la sécurité d'une manière ou d'une autre. Il a été conçu pour garantir que les utilisateurs normaux sont toujours redirigés vers le même serveur backend : c'est tout !

Utilisation

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];
   ou
  sticky [hmac=md5|sha1 hmac_key=<foobar_key>] [no_fallback]
       [name=route] [domain=.foo.bar] [path=/] [expires=1h] [secure] [httponly];
   ou
  sticky [text=raw] [no_fallback]
       [name=route] [domain=.foo.bar] [path=/] [expires=1h] [secure] [httponly];

Algorithme de sélection du serveur : - hash : le mécanisme de hachage pour encoder le serveur en amont. Il ne peut pas être utilisé avec hmac ou text. par défaut : md5

- md5|sha1 : hachage bien connu
- index :    il n'est pas haché, un index en mémoire est utilisé à la place, c'est plus rapide et la surcharge est plus courte
Avertissement : la correspondance avec la liste des serveurs en amont
est incohérente. Donc, lors du rechargement, si les serveurs en amont
ont changé, les valeurs d'index ne sont pas garanties de
correspondre au même serveur qu'auparavant !
À UTILISER AVEC PRUDENCE et uniquement si vous en avez besoin !

  • hmac : le mécanisme de hachage HMAC pour encoder le serveur en amont C'est comme le mécanisme de hachage mais il utilise hmac_key pour sécuriser le hachage. Il ne peut pas être utilisé avec hash ou text. md5|sha1 : hachage bien connu

  • hmac_key : la clé à utiliser avec hmac. Elle est obligatoire lorsque hmac est défini

  • no_fallback : lorsque ce drapeau est défini, NGINX renverra un 502 (Bad Gateway ou Proxy Error) si une requête arrive avec un cookie et que le backend correspondant est indisponible. Vous pouvez le définir dans le bloc upstream, ou définir "sticky_no_fallback" dans un bloc server ou location.

Paramètres des cookies : - name : le nom du cookie utilisé pour suivre le serveur en amont persistant ; par défaut : route

  • domain : le domaine dans lequel le cookie sera valide par défaut : aucun. Laissez le navigateur gérer cela.

  • path : le chemin dans lequel le cookie sera valide par défaut : /

  • expires : la durée de validité du cookie par défaut : rien. C'est un cookie de session. restriction : doit être une durée supérieure à une seconde

  • secure activer les cookies sécurisés ; transférés uniquement via https

  • httponly activer les cookies pour ne pas être divulgués via js

Détails du Mécanisme

  • voir docs/sticky.{vsd,pdf}

Problèmes et Avertissements :

  • lors de l'utilisation de différentes configurations upstream avec une persistance qui utilisent le même domaine mais font référence à des configurations de localisation différentes, il peut être judicieux de définir un chemin / route différent sur chacune de ces configurations upstream comme décrit ici : https://bitbucket.org/nginx-goodies/nginx-sticky-module-ng/issue/7/leaving-cookie-path-empty-in-module

  • le module sticky ne fonctionne pas avec l'option "backup" de l'élément de configuration "server".

  • le module sticky peut fonctionner avec le nginx_http_upstream_check_module (à partir de la version 1.2.3)

Téléchargements

GitHub

Vous pouvez trouver des conseils de configuration supplémentaires et de la documentation pour ce module dans le dépôt GitHub pour nginx-module-sticky.