Aktualizowanie i wdrażanie zmian w usłudze Azure Container Apps
Zarządzanie zmianami może być trudne podczas tworzenia konteneryzowanych aplikacji w chmurze. Ostatecznie potrzebna jest obsługa śledzenia zmian, zapewnienia czasu pracy i zapewnienia mechanizmów obsługi bezproblemowego wycofywania.
Zarządzanie zmianami w usłudze Azure Container Apps jest obsługiwane przez poprawki, które są migawką każdej wersji aplikacji kontenera.
Najważniejsze cechy poprawek to:
Niezmienne: po ustanowieniu poprawka pozostaje niezmieniona.
Wersje: Poprawki działają jako rekord wersji aplikacji kontenera, przechwytując jej stan na różnych etapach.
Automatycznie aprowizowana: podczas wdrażania aplikacji kontenera po raz pierwszy tworzona jest początkowa poprawka.
Zmiany w zakresie: podczas gdy poprawki pozostają statyczne, zmiany zakresu aplikacji mogą mieć wpływ na wszystkie poprawki, podczas gdy zmiany zakresu poprawek tworzą nową poprawkę.
Rekord historyczny: domyślnie masz dostęp do 100 nieaktywnych poprawek, ale możesz ręcznie dostosować ten próg.
Wiele poprawek: można uruchamiać wiele poprawek jednocześnie. Ta funkcja jest szczególnie przydatna, gdy trzeba zarządzać różnymi wersjami aplikacji jednocześnie.
Cykl życia
Każda poprawka przechodzi określone stany, pod wpływem ich stanu i dostępności. W trakcie cyklu życia aplikacja kontenera przechodzi przez różne aprowizowanie, uruchamianie i stan nieaktywności.
Stan aprowizacji
Podczas tworzenia nowej poprawki aplikacja kontenera przechodzi testy uruchamiania i gotowości. W tej fazie stan aprowizacji służy jako przewodnik po śledzeniu postępu aplikacji kontenera.
| Stan | opis |
|---|---|
| Inicjowanie obsługi | Poprawka jest w procesie weryfikacji. |
| Zaaprowizowane | Poprawka pomyślnie przeszła wszystkie kontrole. |
| Aprowizowanie nie powiodło się | Poprawka napotkała problemy podczas weryfikacji. |
Stan uruchomienia
Po pomyślnym aprowizacji aplikacji kontenera poprawka wchodzi w jej fazę operacyjną. Stan uruchomienia pomaga monitorować kondycję i funkcjonalność aplikacji kontenera.
| Stan | opis |
|---|---|
| Inicjowanie obsługi | Poprawka jest w procesie weryfikacji. |
| Skalowanie do 0 | Zero uruchomionych replik, a nie aprowizowanie żadnych nowych replik. Aplikacja kontenera może tworzyć nowe repliki, jeśli reguły skalowania są wyzwalane. |
| Aktywowanie | Zero uruchomionych replik, jedna replika jest aprowizowana. |
| Aktywacja nie powiodła się | Nie można zainicjować obsługi administracyjnej pierwszej repliki. |
| Skalowanie/przetwarzanie | Skalowanie w lub na wyjęcie występuje. Uruchomiono co najmniej jedną replikę, podczas gdy inne repliki są aprowidowane. |
| Uruchomiono | Uruchomiono co najmniej jedną replikę. Nie ma problemów do raportowania. |
| Uruchamianie (maksymalnie) | Maksymalna liczba replik (zgodnie z regułami skalowania poprawki) jest uruchomiona. Nie ma problemów do raportowania. |
| Anulowanie aprowizacji | Poprawka przechodzi z aktywnej do nieaktywnej i usuwa wszystkie utworzone przez nią zasoby. |
| Obniżona wydajność | Co najmniej jedna replika w wersji jest w stanie niepowodzenia. Wyświetl szczegóły stanu uruchamiania pod kątem konkretnych problemów. |
| Niepowodzenie | Błędy krytyczne spowodowały niepowodzenie poprawek. Stan uruchomienia zawiera szczegółowe informacje. Typowe przyczyny: •Zakończenie • Kod zakończenia 137 |
Stan nieaktywny
Poprawki mogą również wprowadzać stan nieaktywny. Te poprawki nie mają stanów aprowizowania ani uruchamiania. Jednak usługa Azure Container Apps utrzymuje listę tych poprawek, zawierającą maksymalnie 100 nieaktywnych wpisów. W dowolnym momencie możesz aktywować poprawkę.
Zmienianie nieaktywnego limitu poprawek
Możesz użyć parametru --max-inactive-revisions z poleceniami containerapp create lub containerapp update , aby kontrolować liczbę nieaktywnych poprawek śledzonych przez usługę Container Apps.
W tym przykładzie pokazano, jak utworzyć nową aplikację kontenera, która śledzi 50 nieaktywnych poprawek:
az containerapp create --max-inactive-revisions 50
Tryby poprawek
Usługa Azure Container Apps obsługuje dwa tryby poprawek. Wybór trybu określa, ile wersji aplikacji jest jednocześnie aktywnych.
| Tryby poprawek | opis | Wartość domyślna |
|---|---|---|
| Pojedynczy | Nowe poprawki są automatycznie aprowizowane, aktywowane i skalowane do żądanego rozmiaru. Gdy wszystkie repliki są uruchomione zgodnie z definicją reguły skalowania, ruch jest przekierowywany ze starej wersji do nowej. Jeśli aktualizacja nie powiedzie się, ruch pozostaje wskazywany na starą poprawkę. Stare poprawki są automatycznie coniętą aprowizowaną. | Tak |
| Wiele | Możesz mieć wiele aktywnych poprawek, podzielić ruch między poprawkami i wybrać, kiedy usunąć aprowizacje starych poprawek. Ten poziom kontroli jest przydatny do testowania wielu wersji aplikacji, testowania niebieskiego zielonego lub przejęcia pełnej kontroli nad aktualizacjami aplikacji. Aby uzyskać więcej szczegółów, zapoznaj się z podziałem ruchu. |
Etykiety
W przypadku aplikacji kontenerów z zewnętrznym ruchem HTTP etykiety kierują ruch do określonych poprawek. Etykieta zawiera unikatowy adres URL, którego można użyć do kierowania ruchu do poprawki przypisanej etykiety.
Aby przełączyć ruch między poprawkami, możesz przenieść etykietę z jednej poprawki do innej.
- Etykiety zachowują ten sam adres URL po przeniesieniu z jednej poprawki do innej.
- Etykietę można zastosować tylko do jednej poprawki jednocześnie.
- Alokacja podziału ruchu nie jest wymagana w przypadku poprawek z etykietami.
- Etykiety są najbardziej przydatne, gdy aplikacja jest w trybie wielu poprawek.
- Możesz włączyć etykiety, podział ruchu lub oba te elementy.
Etykiety są przydatne do testowania nowych poprawek. Jeśli na przykład chcesz udzielić dostępu do zestawu użytkowników testowych, możesz nadać im adres URL etykiety. Następnie, gdy chcesz przenieść użytkowników do innej wersji, możesz przenieść etykietę do tej poprawki.
Etykiety działają niezależnie od dzielenia ruchu. Dzielenie ruchu dystrybuuje ruch przechodzący do adresu URL aplikacji kontenera do poprawek na podstawie procentu ruchu. Gdy ruch jest kierowany do adresu URL etykiety, ruch jest kierowany do jednej konkretnej poprawki.
Nazwa etykiety musi:
- Składa się z małych liter alfanumerycznych znaków lub kreski (
-) - Zacznij od znaku alfabetycznego
- Koniec z znakiem alfanumerycznym
Etykiety nie mogą:
- Mają dwa kolejne kreski (
--) - Długość więcej niż 64 znaków
Etykiety można zarządzać na stronie zarządzania poprawkami aplikacji kontenera w witrynie Azure Portal.
Adres URL etykiety jest dostępny w okienku szczegółów poprawek.
Wdrażanie bez przestojów
W trybie pojedynczej poprawki usługa Container Apps gwarantuje, że aplikacja nie wystąpi przestój podczas tworzenia nowej poprawki. Istniejąca aktywna poprawka nie jest dezaktywowana, dopóki nowa wersja nie będzie gotowa.
Jeśli ruch przychodzący jest włączony, istniejąca poprawka będzie nadal otrzymywać 100% ruchu, dopóki nowa wersja nie będzie gotowa.
Nowa wersja jest uznawana za gotową, gdy:
- Poprawka została pomyślnie aprowizowana
- Poprawka została przeskalowana w górę, aby była zgodna z poprzednią liczbą replik poprawek (uwzględniana jest minimalna i maksymalna liczba replik nowej wersji)
- Wszystkie repliki przeszły sondy uruchamiania i gotowości
W trybie wielu wersji można kontrolować, kiedy poprawki są aktywowane lub dezaktywowane i które poprawki odbierają ruch przychodzący. Jeśli reguła podziału ruchu jest skonfigurowana z ustawioną wartością latestRevision true, ruch nie przełącza się do najnowszej wersji, dopóki nie będzie gotowy.
Praca z wieloma poprawkami
Chociaż tryb pojedynczej poprawki jest domyślny, czasami możesz chcieć mieć pełną kontrolę nad sposobem zarządzania poprawkami.
Tryb wielu poprawek zapewnia elastyczność ręcznego zarządzania poprawkami. Na przykład użycie wielu trybów poprawek pozwala określić dokładnie, ile ruchu jest przydzielane do każdej poprawki.
Dzielenie ruchu
Na poniższym diagramie przedstawiono aplikację kontenera z dwiema wersjami.
W tym scenariuszu zakłada się, że aplikacja kontenera jest w następującym stanie:
- Ruch przychodzący jest włączony, dzięki czemu aplikacja kontenera jest dostępna za pośrednictwem protokołu HTTP lub TCP.
- Pierwsza poprawka została wdrożona jako poprawka 1.
- Po zaktualizowaniu kontenera nowa poprawka została aktywowana jako poprawka 2.
- Reguły podziału ruchu są skonfigurowane tak, aby poprawka 1 odbierała 80% żądań, a poprawka 2 otrzymuje pozostałe 20%.
Bezpośredni dostęp do poprawek
Zamiast używać reguły routingu do przekierowywania ruchu do poprawki, możesz udostępnić poprawkę żądaniom określonego adresu URL. Tryb wielu poprawek umożliwia wysyłanie wszystkich żądań przychodzących do domeny do najnowszej wersji, podczas gdy żądania starszej poprawki są dostępne za pośrednictwem etykiet w celu uzyskania bezpośredniego dostępu.
Stan aktywacji
W trybie wielu poprawek można aktywować lub dezaktywować poprawki zgodnie z potrzebami. Aktywne poprawki są operacyjne i mogą obsługiwać żądania, podczas gdy nieaktywne poprawki pozostają nieaktywne.
Usługa Container Apps nie pobiera opłat za nieaktywne poprawki. Istnieje jednak limit całkowitej liczby dostępnych poprawek, z najstarszymi przeczyszczanymi po przekroczeniu liczby 100.
Typy zmian
Zmiany w aplikacji kontenera należą do dwóch kategorii: zmiany zakresu poprawek lub zakresu aplikacji. Zmiany zakresu poprawek wyzwalają nową poprawkę podczas wdrażania aplikacji, podczas gdy zmiany zakresu aplikacji nie są zmieniane.
Zmiany zakresu poprawek
Nowa poprawka jest tworzona po zaktualizowaniu aplikacji kontenera ze zmianami zakresu poprawek. Zmiany są ograniczone do wersji, w której są wdrażane, i nie mają wpływu na inne poprawki.
Zmiana zakresu poprawek to dowolna zmiana parametrów w properties.template sekcji szablonu zasobu aplikacji kontenera.
Te parametry obejmują:
- Sufiks poprawki
- Konfiguracja kontenera i obrazy
- Skalowanie reguł dla aplikacji kontenera
Zmiany zakresu aplikacji
Podczas wdrażania aplikacji kontenera ze zmianami zakresu aplikacji:
- Zmiany są stosowane globalnie do wszystkich poprawek.
- Nie utworzono nowej poprawki.
Zmiany zakresu aplikacji są definiowane jako wszelkie zmiany parametrów w properties.configuration sekcji szablonu zasobu aplikacji kontenera.
Te parametry obejmują:
- Wartości wpisów tajnych (należy ponownie uruchomić poprawki, zanim kontener rozpozna nowe wartości wpisów tajnych)
- Tryb poprawki
- Konfiguracja ruchu przychodzącego, w tym:
- Włączanie lub wyłączanie ruchu przychodzącego
- Reguły dzielenia ruchu
- Etykiety
- Poświadczenia dla prywatnych rejestrów kontenerów
- Ustawienia języka Dapr
Dostosowywanie poprawek
Możesz dostosować nazwy i etykiety poprawek, aby lepiej dopasować je do konwencji nazewnictwa lub strategii przechowywania wersji.
Sufiks nazwy
Każda poprawka w usłudze Container Apps ma przypisany unikatowy identyfikator. Nazwy są generowane automatycznie, ale można spersonalizować nazwę poprawki.
Typowy format nazwy poprawki to:
<CONTAINER_APP_NAME>-<REVISION_SUFFIX>
Jeśli na przykład masz aplikację kontenera o nazwie album-api i zdecydujesz się na sufiks pierwszej poprawki poprawki, kompletna nazwa poprawki stanie się album-api-first-revision.
Nazwa sufiksu poprawki musi:
- Składa się tylko z małych liter alfanumerycznych znaków lub kreski (
-) - Zacznij od znaku alfabetycznego
- Koniec z znakiem alfanumerycznym
Nazwy nie mogą mieć:
- Dwie kolejne kreski (
--) - Długość więcej niż 64 znaków
Sufiks poprawki można ustawić w szablonie usługi ARM, za pomocą interfejsu wiersza polecenia az containerapp create platformy Azure i az containerapp update poleceń lub podczas tworzenia poprawki za pośrednictwem witryny Azure Portal.
Przypadki użycia
Poniżej przedstawiono typowe przypadki użycia wersji w aplikacjach kontenerów. Ta lista nie jest wyczerpującą listą celów ani możliwości korzystania z poprawek usługi Container Apps.
Zarządzanie wydaniami
Poprawki usprawniają proces wprowadzania nowych wersji aplikacji. Gdy wszystko będzie gotowe do wdrożenia aktualizacji lub nowej funkcji, możesz utworzyć nową wersję bez wpływu na bieżącą wersję na żywo. Takie podejście zapewnia bezproblemowe przejście i minimalizuje zakłócenia dla użytkowników końcowych.
Przywracanie do poprzednich wersji
Czasami trzeba szybko przywrócić poprzednią, stabilną wersję aplikacji. W razie potrzeby możesz przywrócić poprzednią wersję aplikacji kontenera.
Testowanie A/B:
Jeśli chcesz przetestować różne wersje aplikacji, wersje mogą obsługiwać testowanie A/B. Możesz kierować użytkowników do nowej poprawki, zbierać opinie i podejmować świadome decyzje na podstawie rzeczywistych danych.
Wdrożenia niebiesko-zielone
Poprawki obsługują strategię wdrażania niebiesko-zieloną. Dzięki dwóm równoległym poprawkom (niebieskim dla wersji na żywo i zielonym dla nowej wersji), można stopniowo stopniowo przechodzić w nową wersję. Gdy masz pewność, że w nowej wersji będzie stabilność i wydajność, możesz całkowicie przełączyć ruch do środowiska zielonego.