Jak zrestartować odwrotne proxy bez restartowania usług przechowujących stan sesji

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

How to Restart a Reverse Proxy Without Restarting Session-State Services - Zima Store Online

Planowana konserwacja serwera proxy jest bezpieczniejsza, gdy reverse proxy może przeładowywać konfigurację lub uruchamiać się ponownie niezależnie od usług uwierzytelniania i przechowywania stanu sesji działających za nim.

Proces proxy zwykle nie musi przechowywać stanu logowania, który przekazuje dalej. Przed konserwacją ustal, który komponent podpisuje pliki cookie, przechowuje sesje po stronie serwera, kończy proces uwierzytelniania i zamyka aktywne połączenia HTTP. Pozostaw te komponenty stanowe uruchomione, preferuj płynne przeładowanie proxy, gdy zmienia się tylko konfiguracja, i sprawdź, czy pełna wymiana proxy ponownie łączy się z tą samą bramą uwierzytelniania i magazynem sesji, używając niezmienionych sekretów.

Oddziel cykl życia proxy od cyklu życia usługi uwierzytelniania

Sprawdź zależności w Compose, zasady ponownego uruchamiania, współdzielone skrypty i działania menedżera stosu, aby upewnić się, że ponowne uruchomienie proxy nie odtwarza automatycznie bramy uwierzytelniania, aplikacji, Redis ani bazy danych.

Przykładowa architektura sesji wykorzystuje Redis poza cyklem życia proxy, dzięki czemu wiele instancji uwierzytelniania i ich ponowne uruchomienia może korzystać z tego samego zaplecza sesji.

Nie grupuj wszystkich usług brzegowych pod jednym ogólnym poleceniem ponownego uruchomienia. Jeśli zmiana certyfikatu lub trasy dotyczy tylko proxy, pozostaw nietknięte usługi, które weryfikują istniejący stan logowania.

W miarę możliwości przeładowuj konfigurację zamiast ponownie uruchamiać usługę

W przypadku zmian tras, certyfikatów lub nagłówków korzystaj z obsługiwanej przez proxy ścieżki płynnego przeładowania zamiast zatrzymywać usługę. Przed zastosowaniem zmian sprawdź konfigurację, aby błąd składni nie zamienił planowanej konserwacji w przestój.

Przewodnik API7 dotyczący NGINX wyjaśnia, jak stare procesy robocze zamykają połączenia, podczas gdy nowe przyjmują żądania zgodnie ze zaktualizowaną konfiguracją.

Przeładowanie zachowuje rodzinę procesów proxy, ale nie chroni oddzielnej usługi uwierzytelniania, jeśli skrypt wdrożeniowy również ją ponownie uruchamia. Traktuj te dwa cykle życia niezależnie.

Zachowaj zewnętrzne przechowywanie sesji podczas wymiany proxy

Jeśli brama uwierzytelniania przechowuje dane sesji poza plikami cookie, zachowaj jej Redis lub inny magazyn sesji w stanie trwałym i niezmienionym podczas operacji na proxy. Zapisz adres zaplecza i sekret używany przez każdą instancję uwierzytelniania.

OAuth2 Proxy obsługuje Redis jako współdzielony magazyn sesji, gdy sesje muszą być współdzielone między instancjami.

Nie myl nietrwałej pamięci podręcznej z nadrzędnym stanem logowania. Jeśli magazyn sesji jest wymagany do weryfikowania bieżących użytkowników, uruchamiaj go ponownie lub opróżniaj wyłącznie zgodnie z własną, przetestowaną procedurą konserwacyjną.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Zachowaj niezmienione sekrety plików cookie i podpisywania

Zapisz sekret szyfrowania lub podpisywania plików cookie używany przez bramę uwierzytelniania i upewnij się, że zastępczy stos proxy korzysta z tego samego źródła sekretu. Wygenerowanie nowej wartości podczas ponownego wdrażania unieważni poprawne pliki cookie zapisane w przeglądarkach.

Przewodnik dotyczący sesji reverse proxy wskazuje, że stabilne zasady sesji przetrwają ponowne uruchomienia, a nie tylko czas życia pojedynczego połączenia TCP.

Rotację sekretów podpisywania przeprowadzaj jako oddzielną zmianę bezpieczeństwa, z jasno określonym oczekiwaniem wylogowania lub strategią okresu przejściowego. Nie łącz rotacji sekretów ze zwykłym planowanym przeładowaniem proxy, chyba że unieważnienie sesji jest zamierzone.

Zamykaj połączenia podczas pełnego ponownego uruchamiania proxy

Gdy trzeba wymienić plik binarny proxy lub kontener, korzystaj — jeśli jest dostępny — z mechanizmu płynnego lub bezprzerwowego ponownego uruchamiania, aby ustanowione żądania nie zostały przerwane w połowie odpowiedzi. Ustal limit czasu konserwacji dla połączeń długotrwałych.

Wytyczne HAProxy dotyczące przeładowywania pokazują, jak przeładowania bezprzerwowe zachowują połączenia, zamiast natychmiast kończyć stary proces.

Ciągłość połączenia i ciągłość logowania to różne kwestie. Nawet jeśli WebSocket połączy się ponownie, sesja powinna pozostać ważna, ponieważ zastępcze proxy łączy się z tymi samymi usługami uwierzytelniania i przechowywania stanu.

Przetestuj jedną sesję przed planowaną konserwacją i po niej

Użyj jednej zalogowanej przeglądarki i jednej nowej sesji prywatnej. Przed konserwacją zapisz plik cookie sesji, trasę proxy, usługę uwierzytelniania i zaplecze, a następnie przeładuj lub wymień wyłącznie proxy i powtórz to samo chronione żądanie.

Przewodnik operacyjny Caddy zaleca przeładowanie zamiast pełnego ponownego uruchomienia w przypadku planowanych aktualizacji konfiguracji.

Projekt konserwacji działa prawidłowo, gdy istniejące logowania zostają zachowane, nowe logowania nadal się udają, a żadna zależność stanowa nie została przypadkowo uruchomiona ponownie. Powiązany artykuł ZimaSpace dotyczący utraty sesji po ponownym uruchomieniu proxy pozostaje właściwą ścieżką odzyskiwania, jeśli użytkownicy nadal są wylogowani.

Często zadawane pytania

Czy płynne przeładowanie proxy gwarantuje, że użytkownicy pozostaną zalogowani?

Nie. Chroni ono połączenia proxy, ale użytkownicy nadal mogą zostać wylogowani, jeśli w tym samym czasie zmieni się usługa uwierzytelniania, magazyn sesji lub sekret podpisywania plików cookie.

Czy Redis powinien zawsze działać podczas ponownego uruchamiania proxy?

Tylko wtedy, gdy Redis przechowuje stan sesji lub inną trwałą zależność uwierzytelniania. Instancja Redis używana wyłącznie jako pamięć podręczna ma inną granicę odzyskiwania.