Comment redémarrer un proxy inverse sans redémarrer les services d’état de session

La maintenance planifiée d’un proxy est plus sûre lorsque le proxy inverse peut se recharger ou redémarrer indépendamment des services d’authentification et de gestion de l’état des sessions qui se trouvent derrière lui.

Un processus proxy n’a généralement pas besoin de gérer lui-même l’état de connexion qu’il transmet. Avant la maintenance, identifiez le composant qui signe les cookies, stocke les sessions côté serveur, termine l’authentification et ferme progressivement les connexions HTTP actives. Laissez ces composants à état persistant fonctionner, privilégiez les rechargements gracieux du proxy lorsque seules la configuration change, et vérifiez qu’un remplacement complet du proxy se reconnecte à la même passerelle d’authentification et au même magasin de sessions, avec des secrets inchangés.

Séparer le cycle de vie du proxy de celui du service d’authentification

Vérifiez les dépendances Compose, les stratégies de redémarrage, les scripts partagés et les actions du gestionnaire de piles afin de vous assurer que le redémarrage du proxy ne recrée pas automatiquement la passerelle d’authentification, l’application, Redis ou la base de données.

Un exemple d’architecture de session utilise Redis en dehors du cycle de vie du proxy, afin que plusieurs instances d’authentification et plusieurs redémarrages puissent partager le même backend de sessions.

Ne regroupez pas tous les services en périphérie derrière une seule commande de redémarrage générale. Si une modification de certificat ou de routage ne concerne que le proxy, laissez fonctionner les services qui valident l’état des connexions existantes.

Recharger la configuration au lieu de redémarrer lorsque c’est possible

Pour les modifications de routes, de certificats ou d’en-têtes, utilisez la procédure de rechargement gracieux prise en charge par le proxy au lieu d’arrêter le service. Validez la configuration avant de l’appliquer afin qu’une erreur de syntaxe ne transforme pas une maintenance planifiée en interruption de service.

Le guide d’API7 consacré à NGINX explique comment les anciens workers terminent les connexions tandis que les nouveaux workers acceptent les requêtes avec la configuration mise à jour.

Un rechargement préserve la famille de processus du proxy, mais ne protège pas un service d’authentification distinct si votre script de déploiement redémarre également ce service. Traitez ces deux questions de cycle de vie séparément.

Préserver le stockage externe des sessions lors du remplacement du proxy

Si une passerelle d’authentification stocke les données de session en dehors des cookies, gardez son backend Redis ou tout autre backend de sessions persistant et inchangé pendant l’opération sur le proxy. Notez l’adresse du backend et le secret utilisés par chaque instance d’authentification.

OAuth2 Proxy prend en charge Redis comme stockage partagé des sessions lorsque les sessions doivent être partagées entre plusieurs instances.

Ne confondez pas un cache jetable avec l’état de connexion faisant autorité. Si le backend de sessions est nécessaire pour valider les utilisateurs actuels, ne le redémarrez et ne le videz que dans le cadre de sa propre procédure de maintenance testée.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Conserver les cookies et les secrets de signature

Notez le secret de chiffrement ou de signature des cookies utilisé par la passerelle d’authentification et assurez-vous que la nouvelle pile proxy monte la même source de secrets. La génération d’une nouvelle valeur lors d’un redéploiement invalidera les cookies de navigateur qui étaient pourtant encore valides.

Un guide sur les sessions avec un proxy inverse précise que la politique de session stable survit aux redémarrages, plutôt que de dépendre de la durée de vie d’une seule connexion TCP.

Faites de la rotation des secrets de signature une modification de sécurité distincte, avec une attente explicite de déconnexion ou une stratégie de chevauchement. Ne combinez pas la rotation des secrets avec un simple rechargement planifié du proxy, sauf si l’invalidation des sessions est intentionnelle.

Fermer progressivement les connexions lors d’un redémarrage complet du proxy

Lorsque le binaire ou le conteneur du proxy doit être remplacé, utilisez, si elle est disponible, sa procédure de redémarrage gracieux ou sans interruption afin que les requêtes établies ne soient pas coupées au milieu de la réponse. Prévoyez un délai d’expiration de maintenance pour les connexions longue durée.

Le guide de rechargement de HAProxy montre comment les rechargements sans interruption préservent les connexions au lieu de tuer immédiatement l’ancien processus.

La continuité des connexions et la continuité des sessions de connexion sont deux choses différentes. Même si un WebSocket se reconnecte, la session doit rester valide, car le proxy de remplacement accède aux mêmes services d’authentification et de gestion de l’état.

Tester une session avant et après la maintenance planifiée

Utilisez un navigateur avec une session ouverte et une nouvelle session privée. Notez avant la maintenance le cookie de session, la route du proxy, le service d’authentification et le backend, puis rechargez ou remplacez uniquement le proxy et répétez la même requête protégée.

Un guide opérationnel consacré à Caddy recommande de recharger au lieu de redémarrer complètement lors des mises à jour de configuration planifiées.

La conception de maintenance fonctionne lorsque les connexions existantes sont conservées, que les nouvelles connexions réussissent toujours et qu’aucune dépendance à état persistant n’a subi de redémarrage involontaire. L’article ZimaSpace associé sur la perte de session après le redémarrage du proxy reste la procédure de récupération appropriée si les utilisateurs sont toujours déconnectés.

Foire aux questions

Un rechargement gracieux du proxy garantit-il que les utilisateurs resteront connectés ?

Non. Il protège les connexions du proxy, mais les utilisateurs peuvent tout de même être déconnectés si le service d’authentification, le magasin de sessions ou le secret de signature des cookies change au même moment.

Redis doit-il toujours rester actif lors d’un redémarrage du proxy ?

Uniquement lorsque Redis stocke l’état des sessions ou une autre dépendance persistante de l’authentification. Une instance Redis utilisée uniquement comme cache possède une limite de récupération différente.

Conserver le même nom de cookie suffit-il ?

Non. Le secret de signature ou de chiffrement ainsi que l’état des sessions du backend doivent également rester compatibles avec le cookie déjà détenu par le navigateur.