Aktualizace a nasazení změn v Azure Container Apps
Správa změn může být náročná při vývoji kontejnerizovaných aplikací v cloudu. Nakonec potřebujete podporu ke sledování změn, zajištění doby provozu a mechanismů pro zpracování hladkých vrácení zpět.
Správa změn ve službě Azure Container Apps využívá revize, což je snímek každé verze vaší aplikace kontejneru.
Mezi klíčové charakteristiky revizí patří:
Neměnné: Po vytvoření zůstane revize neměnná.
Verze: Revize fungují jako záznam verzí aplikace kontejneru a zaznamenávají její stav v různých fázích.
Automaticky zřízeno: Při prvním nasazení aplikace kontejneru se automaticky vytvoří počáteční revize.
Změny s vymezeným oborem: Zatímco revize zůstávají statické, změny oboru aplikace můžou ovlivnit všechny revize, zatímco změny oboru revizí vytvoří novou revizi.
Historický záznam: Ve výchozím nastavení máte přístup k 100 neaktivním revizím, ale tuto prahovou hodnotu můžete upravit ručně.
Více revizí: Současně můžete spustit více revizí. Tato funkce je zvlášť užitečná, když potřebujete spravovat různé verze aplikace současně.
Životní cyklus
Každá revize prochází konkrétními stavy ovlivněnými stavem a dostupností. Během životního cyklu prochází aplikace kontejneru různými zřizováními, spouštěním a neaktivním stavem.
Stav zřizování
Když vytvoříte novou revizi, aplikace kontejneru prochází kontrolou spuštění a připravenosti. Během této fáze slouží stav zřizování jako vodítko ke sledování průběhu aplikace kontejneru.
| Status | Popis |
|---|---|
| Zřizování | Revize probíhá v procesu ověření. |
| Zřízené | Revize úspěšně prošla všemi kontrolami. |
| Zřizování selhalo | Při ověřování došlo k problémům s revizí. |
Stav spuštění
Po úspěšném zřízení aplikace kontejneru přejde revize do své provozní fáze. Stav spuštění pomáhá monitorovat stav a funkčnost aplikace kontejneru.
| Status | Popis |
|---|---|
| Zřizování | Revize probíhá v procesu ověření. |
| Škálování na 0 | Žádné spuštěné repliky a nezřizují se žádné nové repliky. Aplikace kontejneru může vytvořit nové repliky, pokud se aktivují pravidla škálování. |
| Aktivace | Žádné spuštěné repliky, jedna zřízená replika. |
| Aktivace se nezdařila. | První replika se nepodařilo zřídit. |
| Škálování / zpracování | Dochází k horizontálnímu navýšení nebo snížení kapacity. Jedna nebo více replik běží, zatímco ostatní repliky se zřizují. |
| Spuštěno | Běží nejméně jedna replika. Neexistují žádné problémy, které by bylo potřeba nahlásit. |
| Spuštěno (s maximálním) | Je spuštěn maximální počet replik (podle pravidel škálování revize). Neexistují žádné problémy, které by bylo potřeba nahlásit. |
| Zrušení zřízení | Revize přechází z aktivní na neaktivní a odebírá všechny prostředky, které vytvořila. |
| Snížený výkon | Nejméně jedna replika v revizi je ve stavu selhání. Zobrazení podrobností o spuštěném stavu pro konkrétní problémy |
| Neúspěch | Kritické chyby způsobily selhání revizí. Spuštěný stav obsahuje podrobnosti. Mezi obvyklé příčiny patří: •Ukončení • Ukončovací kód 137 |
Neaktivní stav
Revize můžou také zadat neaktivní stav. Tyto revize nemají stavy zřizování ani spouštění. Azure Container Apps ale udržuje seznam těchto revizí, který umožňuje 100 neaktivních položek. Revizi můžete kdykoli aktivovat.
Změna limitu neaktivní revize
Pomocí parametru --max-inactive-revisions containerapp create nebo containerapp update příkazů můžete řídit počet neaktivních revizí sledovaných službou Container Apps.
Tento příklad ukazuje, jak vytvořit novou aplikaci kontejneru, která sleduje 50 neaktivních revizí:
az containerapp create --max-inactive-revisions 50
Režimy revizí
Azure Container Apps podporuje dva režimy revizí. Volba režimu určuje, kolik revizí aplikace je současně aktivních.
| Režimy revizí | Popis | Výchozí |
|---|---|---|
| Jeden | Nové revize se automaticky zřídí, aktivují a škálují na požadovanou velikost. Jakmile jsou všechny repliky spuštěné podle definice pravidla škálování, provoz se přesměruje ze staré verze na novou. Pokud se aktualizace nezdaří, provoz zůstane odkazovat na starou revizi. Staré revize se automaticky zruší. | Ano |
| Více | Můžete mít více aktivních revizí, rozdělit provoz mezi revize a zvolit, kdy chcete zrušit zřízení starých revizí. Tato úroveň řízení je užitečná pro testování více verzí aplikace, modrého testování nebo převzetí úplné kontroly nad aktualizacemi aplikací. Další podrobnosti najdete v rozdělení provozu. |
Popisky
U kontejnerových aplikací s externím provozem HTTP popisky směrují provoz na konkrétní revize. Popisek poskytuje jedinečnou adresu URL, kterou můžete použít ke směrování provozu na revizi, kterou má popisek přiřazený.
Pokud chcete přepnout provoz mezi revizemi, můžete ho přesunout z jedné revize do jiné.
- Popisky zachovávají stejnou adresu URL při přesunu z jedné revize na jinou.
- Popisek lze použít pouze na jednu revizi najednou.
- Přidělení pro rozdělení provozu se nevyžaduje pro revize s popisky.
- Popisky jsou nejužitečnější, když je aplikace v režimu více revizí.
- Můžete povolit popisky, rozdělení provozu nebo obojí.
Popisky jsou užitečné pro testování nových revizí. Pokud například chcete udělit přístup k sadě testovacích uživatelů, můžete jim dát adresu URL popisku. Když pak chcete přesunout uživatele na jinou revizi, můžete popisek přesunout do této revize.
Popisky fungují nezávisle na rozdělení provozu. Rozdělení provozu distribuuje provoz do adresy URL aplikace kontejneru na revize na základě procenta provozu. Když se provoz přesměruje na adresu URL popisku, provoz se směruje na jednu konkrétní revizi.
Název popisku musí:
- Skládá se z malých alfanumerických znaků nebo pomlček (
-) - Začínáme s abecedním znakem
- Konec alfanumerickým znakem
Popisky nesmí:
- Mají dvě po sobě jdoucí pomlčky (
--) - Musí být delší než 64 znaků.
Popisky můžete spravovat na stránce správy revizí vaší aplikace kontejneru na webu Azure Portal.
Adresa URL popisku je k dispozici v podokně podrobností revize.
Nasazení s nulovými výpadky
V režimu jedné revize služba Container Apps zajistí, že při vytváření nové revize nedojde k výpadku vaší aplikace. Stávající aktivní revize se neaktivuje, dokud nebude nová revize připravená.
Pokud je povolený příchozí přenos dat, stávající revize bude nadále přijímat 100 % provozu, dokud nebude nová revize připravená.
Nová revize se považuje za připravenou, když:
- Revize byla úspěšně zřízena.
- Revize se vertikálně navýšit tak, aby odpovídala předchozímu počtu replik revizí (respektuje minimální a maximální počet replik nové revize).
- Všechny repliky prošly testy spuštění a připravenosti.
V režimu více revizí můžete řídit, kdy jsou revize aktivovány nebo deaktivovány a které revize přijímají příchozí provoz. Pokud je pravidlo rozdělení provozu nakonfigurované na latestRevision nastavené true, provoz se nepřepne na nejnovější revizi, dokud nebude připravený.
Práce s více revizemi
I když je režim jedné revize výchozí, někdy můžete chtít mít plnou kontrolu nad tím, jak se vaše revize spravují.
Režim více revizí umožňuje flexibilně spravovat revizi ručně. Například pomocí režimu více revizí můžete přesně určit, kolik provozu je přiděleno jednotlivým revizí.
Rozdělení provozu
Následující diagram znázorňuje aplikaci typu kontejner se dvěma revizemi.
Tento scénář předpokládá, že aplikace kontejneru je v následujícím stavu:
- Příchozí přenos dat je povolený a zpřístupňuje aplikaci kontejneru přes protokol HTTP nebo TCP.
- První revize byla nasazena jako revize 1.
- Po aktualizaci kontejneru se jako revize 2 aktivovala nová revize.
- Pravidla dělení provozu se konfigurují tak, aby revize 1 přijímala 80 % požadavků a revize 2 obdrží zbývajících 20 %.
Přímý přístup k revizi
Místo použití pravidla směrování k přesměrování provozu na revizi můžete chtít zpřístupnit revizi požadavků na konkrétní adresu URL. Režim více revizí umožňuje odesílat všechny žádosti přicházející do vaší domény na nejnovější revizi, zatímco žádosti o starší revizi jsou k dispozici prostřednictvím popisků pro přímý přístup.
Stav aktivace
V režimu více revizí můžete podle potřeby aktivovat nebo deaktivovat revize. Aktivní revize jsou funkční a můžou zpracovávat požadavky, zatímco neaktivní revize zůstávají neaktivní.
Container Apps neúčtuje za neaktivní revize. Existuje však limit celkového počtu dostupných revizí, přičemž nejstarší revize se vyprázdní, jakmile překročíte počet 100.
Typy změn
Změny aplikace typu kontejner spadají do dvou kategorií: změny oboru revize nebo rozsahu aplikace. Změny rozsahu revizí aktivují při nasazování aplikace novou revizi, zatímco změny oboru aplikace se neaktivují.
Změny na úrovni revize
Při aktualizaci aplikace kontejneru se vytvoří nová revize se změnami oboru revizí. Změny jsou omezené na revizi, ve které jsou nasazené, a nemají vliv na jiné revize.
Změna oboru revize je jakákoli změna parametrů v properties.template části šablony prostředku aplikace kontejneru.
Mezi tyto parametry patří:
- Přípona revize
- Konfigurace kontejneru a image
- Pravidla škálování pro aplikaci kontejneru
Změny na úrovni aplikace
Když nasadíte aplikaci typu kontejner se změnami oboru aplikace:
- Změny se použijí globálně u všech revizí.
- Nová revize se nevytvořila.
Změny rozsahu aplikace jsou definovány jako všechny změny parametrů v properties.configuration části šablony prostředku aplikace kontejneru.
Mezi tyto parametry patří:
- Tajné hodnoty (revize se musí restartovat, než kontejner rozpozná nové tajné hodnoty)
- Režim revize
- Konfigurace příchozího přenosu dat, včetně:
- Zapnutí nebo vypnutí příchozího přenosu dat
- Pravidla rozdělení provozu
- Popisky
- Přihlašovací údaje pro privátní registry kontejnerů
- Nastavení Dapr
Přizpůsobení revizí
Název a popisky revizí můžete přizpůsobit, aby byly lépe v souladu se zásadami vytváření názvů nebo strategií správy verzí.
Přípona názvu
Každá revize v Container Apps má přiřazený jedinečný identifikátor. I když se názvy generují automaticky, můžete název revize přizpůsobit.
Typický formát názvu revize je:
<CONTAINER_APP_NAME>-<REVISION_SUFFIX>
Pokud máte například aplikaci typu kontejner s názvem album-api a rozhodnete se o příponě revize first-revision, název úplné revize se změní na album-api-first-revision.
Název přípony revize musí:
- Skládá se pouze z malých alfanumerických znaků nebo pomlček (
-) - Začínáme s abecedním znakem
- Konec alfanumerickým znakem
Názvy nesmí obsahovat:
- Dvě po sobě jdoucí pomlčky (
--) - Musí být delší než 64 znaků.
Příponu revize můžete nastavit v šabloně ARM, prostřednictvím Azure CLI az containerapp create a az containerapp update příkazů nebo při vytváření revize prostřednictvím webu Azure Portal.
Případy použití
Níže jsou uvedené běžné případy použití pro použití revizí v kontejnerových aplikacích. Tento seznam není vyčerpávajícím seznamem účelu nebo možností používání revizí Container Apps.
Správa vydaných verzí
Revize zjednodušují proces zavádění nových verzí aplikace. Až budete připraveni zavést aktualizaci nebo novou funkci, můžete vytvořit novou revizi, aniž by to mělo vliv na aktuální živou verzi. Tento přístup zajišťuje hladký přechod a minimalizuje přerušení pro koncové uživatele.
Návrat k předchozím verzím
Někdy se potřebujete rychle vrátit k předchozí stabilní verzi aplikace. V případě potřeby se můžete vrátit k předchozí revizi vaší aplikace kontejneru.
Testování A/B
Pokud chcete otestovat různé verze aplikace, revize můžou podporovat testování A/B. Podmnožinu uživatelů můžete směrovat na novou revizi, shromáždit zpětnou vazbu a činit informovaná rozhodnutí na základě dat z reálného světa.
Nasazení s modrou zelenou barvou
Revize podporují strategii nasazení s modrou zelenou barvou. Díky tomu, že máte dvě paralelní revize (modrá pro živou verzi a zelenou pro novou verzi), můžete postupně fázovat v nové revizi. Jakmile budete mít jistotu o stabilitě a výkonu nové verze, můžete provoz zcela přepnout do zeleného prostředí.