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.

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.

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.

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

Další kroky