Strategie wdrażania blue-green w usłudze Azure Spring Apps
Uwaga
Plany Podstawowa, Standardowa i Enterprise zostaną wycofane od połowy marca 2025 r. z 3-letnim okresem emerytalnym. Zalecamy przejście do usługi Azure Container Apps. Aby uzyskać więcej informacji, zobacz ogłoszenie o wycofaniu usługi Azure Spring Apps.
Zużycie standardowe i dedykowany plan zostaną wycofane od 30 września 2024 r. z całkowitym zamknięciem po sześciu miesiącach. Zalecamy przejście do usługi Azure Container Apps. 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 obsługę wdrażania niebiesko-zielonych w usłudze 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 niebieskim zielonym. Obsługa wdrażania w usłudze Azure Spring Apps w kolorze niebieskim, wraz z potokiem ciągłego dostarczania (CD) i rygorystycznym automatycznym testowaniem, umożliwia elastyczne wdrożenia aplikacji z dużą pewnością.
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. deployment1 Obecnie jest ustawiona jako wdrożenie produkcyjne i jest uruchomiona wersja v3 aplikacji.
deployment2 Spowoduje to wdrożenie przejściowe. W związku z tym gdy potok ciągłego dostarczania (CD) jest gotowy do uruchomienia, wdraża następną wersję aplikacji w wersji v4, do wdrożenia deployment2przejściowego .
Po v4 uruchomieniu programu deployment2można uruchamiać testy automatyczne i ręczne względem niego za pośrednictwem prywatnego punktu końcowego testu, aby upewnić się, że v4 spełnia wszystkie oczekiwania.
Jeśli masz pewność, v4że program jest ustawiony deployment2 jako wdrożenie produkcyjne, tak aby odbierał cały ruch produkcyjny. v3deployment1 w przypadku wykrycia krytycznego problemu, który wymaga wycofywania.
deployment1 Teraz jest wdrożenie przejściowe. W związku z tym następny przebieg potoku wdrażania jest wdrażany w usłudze deployment1.
Teraz możesz przetestować V5 deployment1prywatny punkt końcowy testu.
Na koniec, po v5 spełnieniu wszystkich oczekiwań, ponownie ustawisz deployment1 jako wdrożenie produkcyjne, aby odbierać v5 cały ruch produkcyjny.
Kompromisy w podejściu do wdrażania naprzemiennego
Podejście do wdrażania naprzemiennego jest proste i szybkie, ponieważ nie wymaga tworzenia nowych wdrożeń. Jednak w poniższych sekcjach występuje 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) oczekuje na ręczne zatwierdzenie wdrożenia przejściowego, potok wdrażania zostanie uruchomiony ponownie i zastąpi go nowszą wersją (v7). Następnie po udzieleniu zatwierdzenia v6 potok, który wdrożony 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 na zamówienie wdrożenie to wdrożenie jest 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 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. W związku z tym potok organizujący wdrożenie v6 programu podejmie próbę ustawienia deployment-v6 jako wdrożenia produkcyjnego.
Po wdrożeniu utworzonym dla nowej wersji ruch produkcyjny należy usunąć wdrożenie zawierające poprzednią wersję, aby zapewnić 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 potoku wdrażania
Między rozpoczęciem wdrożenia a czasem usunięcia wdrożenia przejściowego wszelkie dodatkowe próby uruchomienia potoku wdrażania nie powiedzą się. Potok podejmie próbę utworzenia nowego wdrożenia, 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 ponowić próbę nieudanego procesu wdrażania w późniejszym czasie lub środki w celu zapewnienia, że przepływy wdrażania dla każdej wersji pozostaną w kolejce do momentu ukończenia przepływu dla wszystkich poprzednich wersji.