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í dostupnosti a mechanismů pro hladké vrácení změn.

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é: Jakmile je revize vytvořena, zůstává 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í určitými fázemi, které jsou ovlivněny jejím statusem 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 provisioning

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 pro sledování průběhu kontejnerové aplikace.

Stav	Popis
Zřizování	Revize probíhá v procesu ověření.
Nakonfigurované	Revize úspěšně prošla všemi kontrolami.
Zřizování selhalo	Během ověřování revize došlo k problémům.

Stav spuštění

Po úspěšném zřízení kontejnerové aplikace přejde revize do své provozní fáze. Stav spuštění pomáhá monitorovat stav a funkčnost aplikace kontejneru.

Stav	Popis
Zavádění	Revidování je ve verifikačním procesu.
Š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í.
Aktivování	Žádné spuštěné repliky, jedna replika je ve fázi zřizování.
Aktivace se nezdařila.	První repliku se nepodařilo zřídit.
Škálování / zpracování	Dochází ke škálování kapacity nahoru nebo dolů. Jedna nebo více replik běží, zatímco ostatní repliky se připravují.
Probíhá	Běží nejméně jedna replika. Neexistují žádné problémy, které by bylo potřeba nahlásit.
Spuštěno (na maximum)	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.
Degradovaný	Nejméně jedna replika v revizi je ve stavu selhání. Zobrazit podrobnosti o běžícím stavu pro konkrétní problémy.
Neúspěšný	Kritické chyby způsobily selhání revizí. Spuštěný běžící stav obsahuje podrobnosti. Mezi obvyklé příčiny patří: •Ukončení • Ukončovací kód 137

Neaktivní stav

Revize se také mohou dostat do neaktivního stavu. Tyto revize neobsahují žádné stavy zřizování ani provozování. Azure Container Apps ale udržuje seznam těchto revizí s kapacitou až 100 neaktivních položek. Revizi můžete kdykoli aktivovat.

Změna neaktivního limitu revize (Preview)

Pomocí parametru --max-inactive-revisions s příkazy containerapp create nebo containerapp update můžete řídit počet neaktivních revizí sledovaných službou Container Apps.

Nejprve se ujistěte, že jste nainstalovali rozšíření Container Apps s povolenými funkcemi Preview pro Azure CLI:

az extension add --name containerapp --upgrade --allow-preview true

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 nastaví, aktivují a škálují na požadovanou velikost. Jakmile jsou všechny repliky spuštěny podle definice pravidla škálování, provoz se přesměruje ze staré verze na novou. Pokud se aktualizace nezdaří, provoz zůstává směrován na starou revizi. Staré revize jsou automaticky deprovisionovány.	Ano
Štítky nasazení (předběžná verze)	Přiřaďte konkrétním revizím kontejnerů smysluplné názvy (například vývoj, příprava, prod). Slouží k rozdělení provozu a testování A/B, automatické prohození přípravných revizí a zjednodušené vrácení zpět.	Ne
Více	Můžete mít více aktivních revizí, rozdělit provoz mezi revize a určit, kdy chcete vyřadit staré revize. 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.	Ne

Štítky

U kontejnerových aplikací s externím provozem HTTP směrují štítky 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 přesunout značku z jedné revize do jiné.

• Štítky zachovávají stejnou adresu URL při přesouvání z jedné revize na jinou.
• Štítek lze aplikovat 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 několika revizí.
• Můžete povolit štítky, rozdělení provozu nebo obojí.

Štítky jsou užitečné pro testování nových revizí. Například pokud chcete udělit přístup k sadě testovacích uživatelů, můžete jim poskytnout adresu URL štítku. 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 směřuje provoz přicházející na adresu URL aplikace kontejneru k revizím na základě procentuálního podílu provozu. Když se provoz přesměruje na adresu URL štítku, provoz se směruje na jednu konkrétní revizi.

Název štítku 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áva revizí kontejnerové aplikace v portálu Azure.

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í provoz, stávající revize bude nadále přijímat 100 % provozu, dokud nebude nová revize připravena.

Nová revize se považuje za připravenou, když:

• Revize byla úspěšně zřízena.
• Revize byla vertikálně navýšena, aby se vyrovnal počtu replik předchozí revize, s respektem k minimálnímu a maximálnímu počtu 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é s latestRevision nastaveným jako true, provoz se nepřepne na nejnovější revizi, dokud není 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 režim více revizí umožňuje přesně určit, kolik provozu je přiděleno jednotlivým revizím.

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:

• Ingress je povolena, což zpřístupňuje aplikaci v kontejneru přes 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 při požadavcích 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 v rozsahu revize

Při aktualizaci kontejnerové aplikace se vytvoří nová revize s úpravami v rámci oboru revize. Změny jsou omezené na revizi, ve které jsou nasazené, a nemají vliv na jiné revize.

Změna v rozsahu 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 obrazů
• 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í vstupu nebo jeho vypnutí
  • Pravidla rozdělení provozu
  • Štítky
• Přihlašovací údaje pro privátní registry kontejnerů
• Nastavení Dapr

Úprava 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.

Modro-zelené nasazení

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í.

Další kroky

Správa životního cyklu aplikací