Sposoby wdrażania blue-green w usłudze Azure Spring Apps

Uwaga

Plany Basic, Standardi Enterprise weszły w okres wycofywania 17 marca 2025 r. Aby uzyskać więcej informacji, zobacz ogłoszenie o wycofaniu usługi Azure Spring Apps.

Plan dotyczący zużycia standardowego oraz dedykowany plan zostały wycofane 30 września 2024 r., z całkowitym zamknięciem do końca marca 2025 r. Aby uzyskać więcej informacji, zobacz Migrowanie użycia usługi Azure Spring Apps w warstwie Standardowa i dedykowanego planu do usługi Azure Container Apps.

Ten artykuł dotyczy:✅ Podstawowa/Standardowa ✅ Enterprise

W tym artykule opisano wsparcie dla wdrażania niebiesko-zielonego w Azure Spring Apps.

Usługa Azure Spring Apps (plan w warstwie Standardowa i nowsza) zezwala na dwa wdrożenia dla każdej aplikacji, z których tylko jeden odbiera ruch produkcyjny. Ten wzorzec jest często nazywany wdrożeniem typu blue-green. Obsługa niebiesko-zielonego wdrażania w usłudze Azure Spring Apps, wraz z pipeline'em ciągłego dostarczania (CD) i rygorystycznym automatycznym testowaniem, umożliwia elastyczne wdrożenia aplikacji z dużą dozą pewności siebie.

Wdrożenia naprzemienne

Najprostszym sposobem zaimplementowania wdrożenia niebieskiego zielonego za pomocą usługi Azure Spring Apps jest utworzenie dwóch stałych wdrożeń i zawsze wdrożenie we wdrożeniu, które nie odbiera ruchu produkcyjnego. Za pomocą zadania Usługi Azure Spring Apps dla usługi Azure Pipelines można wdrożyć w ten sposób, ustawiając flagę UseStagingDeployment na true.

Oto jak działa podejście do wdrażania naprzemiennego w praktyce:

Załóżmy, że aplikacja ma dwa wdrożenia: deployment1 i deployment2. Obecnie deployment1 jest ustawione jako wdrożenie produkcyjne, i jest uruchomiona wersja v3 aplikacji.

Sprawia to, że deployment2 jest wdrożeniem testowym. W związku z tym, gdy potok ciągłego dostarczania (CD) jest gotowy do uruchomienia, wdraża następną wersję aplikacji, wersję v4, na środowisko przejściowe deployment2.

Po uruchomieniu v4 na deployment2, można uruchamiać testy automatyczne i ręczne poprzez prywatny punkt testowy, aby upewnić się, że v4 spełnia wszystkie oczekiwania.

Kiedy masz zaufanie do v4, możesz ustawić deployment2 jako wdrożenie produkcyjne, tak aby odbierał cały ruch produkcyjny. v3 będzie nadal działać na deployment1 w przypadku wykrycia krytycznego problemu, który wymaga wycofania.

deployment1 Teraz jest wdrożenie przejściowe. Więc następny przebieg potoku wdrażania wdraża się na deployment1.

Teraz możesz przetestować V5 na prywatnym punkcie końcowym testowym deployment1.

Na koniec, gdy v5 spełni wszystkie oczekiwania, ponownie ustawisz deployment1 jako wdrożenie produkcyjne, aby v5 odbierał cały ruch produkcyjny.

Kompromisy w podejściu do naprzemiennego wdrażania

Podejście do wdrażania naprzemiennego jest proste i szybkie, ponieważ nie wymaga tworzenia nowych wdrożeń. Jednak przedstawia kilka wad, jak opisano w poniższych sekcjach.

Trwałe wdrożenie przejściowe

Wdrożenie przejściowe zawsze pozostaje uruchomione, a tym samym zużywa zasoby wystąpienia usługi Azure Spring Apps. To skutecznie podwaja wymagania dotyczące zasobów każdej aplikacji w usłudze Azure Spring Apps.

Warunek wyścigu zatwierdzenia

Załóżmy, że w powyższej aplikacji potok wydania wymaga ręcznego zatwierdzenia, zanim każda nowa wersja aplikacji będzie mogła odbierać ruch produkcyjny. Powoduje to ryzyko, że podczas gdy jedna wersja (v6) czeka na ręczne zatwierdzenie w przygotowawczym wdrożeniu, potok wdrażania zostanie uruchomiony ponownie i zastąpi ją nowszą wersją (v7). Następnie, gdy zostanie udzielone zatwierdzenie v6, potok, który wdrożył v6, ustawi wdrożenie przejściowe jako produkcyjne. Ale teraz będzie to niezatwierdzony v7, a nie zatwierdzony v6, który jest wdrożony w tym wdrożeniu i odbiera ruch.

Możesz zapobiec sytuacji wyścigu, upewniając się, że przepływ wdrażania dla jednej wersji nie może rozpocząć się, dopóki przepływ wdrożenia dla wszystkich poprzednich wersji nie zostanie ukończony lub przerwany. Innym sposobem zapobiegania warunkom wyścigu zatwierdzania jest użycie metody nazwanych wdrożeń opisanych poniżej.

Nazwane wdrożenia

W podejściu do nazwanych wdrożeń jest tworzone nowe wdrożenie dla każdej nowej wersji wdrażanej aplikacji. Po przetestowaniu aplikacji we wdrożeniu dedykowanym jest ono ustawione jako wdrożenie produkcyjne. Wdrożenie zawierające poprzednią wersję można zachować na tyle długo, aby mieć pewność, że wycofanie nie będzie potrzebne.

Na poniższej ilustracji wersja v5 jest uruchomiona we wdrożeniu deployment-v5. Nazwa wdrożenia zawiera teraz wersję, ponieważ wdrożenie zostało utworzone specjalnie dla tej wersji. Na początku nie ma żadnego innego wdrożenia. Teraz, aby wdrożyć wersję v6, potok wdrażania tworzy nowe wdrożenie deployment-v6 i wdraża tam wersję v6 aplikacji.

Nie ma ryzyka równoległego wdrażania innej wersji. Najpierw usługa Azure Spring Apps nie zezwala na tworzenie trzeciego wdrożenia, podczas gdy istnieją już dwa wdrożenia. Po drugie, nawet jeśli możliwe było posiadanie więcej niż dwóch wdrożeń, każde wdrożenie jest identyfikowane przez wersję aplikacji, którą zawiera. Dlatego pipeline koordynujący wdrożenie v6 podejmie próbę ustawienia deployment-v6 jako wdrożenie produkcyjne.

Po tym, jak wdrożenie utworzone dla nowej wersji otrzyma ruch produkcyjny, należy usunąć wdrożenie zawierające poprzednią wersję, aby zwolnić miejsce na przyszłe wdrożenia. Możesz odroczyć o kilka minut lub godzin, aby przywrócić poprzednią wersję w przypadku wykrycia krytycznego problemu w nowej wersji.

Kompromisy w podejściu do nazwanych wdrożeń

Podejście do nazwanych wdrożeń ma następujące korzyści:

• Zapobiega to warunkom wyścigu zatwierdzania.
• Zmniejsza zużycie zasobów przez usunięcie wdrożenia przejściowego, gdy nie jest ono używane.

Jednak istnieją również wady, jak opisano w poniższej sekcji.

Błędy w łańcuchu wdrażania

Między rozpoczęciem wdrożenia a momentem usunięcia wdrożenia przejściowego wszelkie dodatkowe próby uruchomienia pipeline'u wdrożeniowego nie powiodą się. Pipeline spróbuje utworzyć nowe wdrożenie, co spowoduje błąd, ponieważ tylko dwa wdrożenia są dozwolone dla aplikacji w usłudze Azure Spring Apps.

W związku z tym orkiestracja wdrożenia musi mieć środki, aby powtórzyć nieudany proces wdrażania w późniejszym czasie lub zapewnić, że przepływy wdrażania dla każdej wersji pozostaną w kolejce aż do ukończenia przepływu dla wszystkich poprzednich wersji.

Następne kroki

• Automatyzowanie wdrożeń aplikacji w usłudze Azure Spring Apps