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

Uwaga

Azure Spring Apps to nowa nazwa usługi Azure Spring Cloud. Mimo że usługa ma nową nazwę, stara nazwa będzie widoczna w niektórych miejscach przez pewien czas, ponieważ pracujemy nad aktualizowaniem zasobów, takich jak zrzuty ekranu, filmy wideo i diagramy.

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 .

Diagram przedstawiający wdrożenie1 z systemem v3 odbierający ruch produkcyjny i wdrożenie2 przejściowe w wersji 4.

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.

Diagram pokazujący, że wersja 4 wdrożona we wdrożeniu2 i przechodzi testy.

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.

Diagram przedstawiający 4 na wdrożeniu 2 odbierający ruch produkcyjny.

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.

Diagram przedstawiający wdrożenie w wersji 5 przygotowanej do wdrożenia1.

Teraz możesz przetestować V5deployment1prywatny punkt końcowy testu.

Diagram pokazujący, że wersja V5 przetestowana na wdrożeniu1.

Na koniec, po v5 spełnieniu wszystkich oczekiwań, ponownie ustawisz deployment1 jako wdrożenie produkcyjne, aby odbierać v5 cały ruch produkcyjny.

Diagram przedstawiający odbieranie ruchu produkcyjnego w wersji 5 we wdrożeniu1.

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.

Diagram przedstawiający stan wyścigu zatwierdzania opisany w tej sekcji.

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.

Diagram przedstawiający wdrażanie nowej wersji w nazwanym wdrożeniu zgodnie z opisem w tej sekcji.

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.

Diagram przedstawiający wdrożenie w wersji 6 w wersji 6 i odbieranie ruchu 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.

Diagram pokazujący, że po okresie rezerwowym poprzednie wdrożenie zostanie usunięte.

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.

Następne kroki