Strategie nasazení s modrou zelenou barvou ve službě Azure Spring Apps
Poznámka:
Plány Basic, Standard a Enterprise budou od poloviny března 2025 vyřazeny ze 3letého období vyřazení. Doporučujeme přejít na Azure Container Apps. Další informace najdete v oznámení o vyřazení Azure Spring Apps.
Od 30. září 2024 bude od 30. září 2024 zastaralý plán s úplným vypnutím po šesti měsících. Doporučujeme přejít na Azure Container Apps. Další informace najdete v tématu Migrace spotřeby Azure Spring Apps Úrovně Standard a vyhrazeného plánu do Azure Container Apps.
Tento článek se vztahuje na: ✔️ Basic/Standard ✔️ Enterprise
Tento článek popisuje podporu modrého nasazení v Azure Spring Apps.
Azure Spring Apps (plán Standard a vyšší) umožňuje dvě nasazení pro každou aplikaci, z nichž pouze jeden přijímá produkční provoz. Tento model se běžně označuje jako modré-zelené nasazení. Podpora modrého zeleného nasazení v Azure Spring Apps společně s kanálem průběžného doručování (CD) a důkladným automatizovaným testováním umožňuje agilní nasazení aplikací s vysokou jistotou.
Střídavá nasazení
Nejjednodušším způsobem implementace modrého zeleného nasazení pomocí Azure Spring Apps je vytvoření dvou pevných nasazení a vždy nasazení do nasazení, které nedostává produkční provoz. Pomocí úlohy Azure Spring Apps pro Azure Pipelines můžete tímto způsobem nasadit pouze nastavením příznaku na UseStagingDeployment true.
Tady je postup, jak funguje přístup ke střídavým nasazením v praxi:
Předpokládejme, že vaše aplikace má dvě nasazení: deployment1 a deployment2. deployment1 V současné době je nastavená jako produkční nasazení a používá verzi v3 aplikace.
Tím se přípravné nasazení provede deployment2 . Proto když je kanál průběžného doručování (CD) připravený ke spuštění, nasadí do přípravného nasazení deployment2další verzi aplikace, verzi v4.
Po v4 spuštění deployment2můžete spouštět automatizované a ruční testy prostřednictvím privátního koncového bodu testu, abyste zajistili v4 splnění všech očekávání.
Pokud máte jistotu v4, můžete nastavit deployment2 jako produkční nasazení tak, aby přijímal veškerý produkční provoz. v3 v případě, že zjistíte kritický problém, který vyžaduje vrácení zpět, zůstane spuštěný deployment1 .
deployment1 Teď je přípravné nasazení. Takže další spuštění kanálu nasazení se nasadí do deployment1.
Teď můžete testovat V5 na deployment1privátním testovacím koncovém bodu.
Nakonec po v5 splnění všech vašich očekávání nastavíte deployment1 jako produkční nasazení znovu, aby v5 se přijímal veškerý produkční provoz.
Kompromisy mezi střídavým přístupem nasazení
Přístup ke střídavým nasazením je jednoduchý a rychlý, protože nevyžaduje vytváření nových nasazení. Má však několik nevýhod, jak je popsáno v následujících částech.
Trvalé přípravné nasazení
Přípravné nasazení zůstane vždy spuštěné a proto spotřebovává prostředky instance Azure Spring Apps. Tím se efektivně zdvojnásobí požadavky na prostředky každé aplikace v Azure Spring Apps.
Podmínka časování schválení
Předpokládejme, že kanál verze ve výše uvedené aplikaci vyžaduje ruční schválení, než každá nová verze aplikace může přijímat produkční provoz. Tím se vytvoří riziko, že zatímco jedna verze (v6) čeká na ruční schválení přípravného nasazení, kanál nasazení se znovu spustí a přepíše ji novější verzí (v7). Po udělení schválení v6 pak kanál, který nasadí v6 , nastaví přípravné nasazení jako produkční. Ale teď to bude neschválené v7, ne schválené v6, které je nasazeno v daném nasazení a přijímá provoz.
Možná budete moct zabránit konfliktu časování tím, že zajistíte, aby tok nasazení pro jednu verzi nemohl začínat, dokud nebude tok nasazení pro všechny předchozí verze dokončený nebo přerušený. Dalším způsobem, jak zabránit stavu časování schválení, je použití přístupu Pojmenovaná nasazení popsaná níže.
Pojmenovaná nasazení
V pojmenovaných nasazeních se vytvoří nové nasazení pro každou novou verzi nasazené aplikace. Jakmile se aplikace otestuje na svém nasazení, nastaví se toto nasazení jako produkční nasazení. Nasazení obsahující předchozí verzi může být možné zachovat dostatečně dlouho, aby bylo jisté, že vrácení zpět nebude potřeba.
Na obrázku níže je verze v5 spuštěná v nasazení deployment-v5. Název nasazení teď obsahuje verzi, protože nasazení bylo vytvořeno speciálně pro tuto verzi. Na začátku neexistuje žádné další nasazení. Teď, pokud chcete nasadit verzi v6, kanál nasazení vytvoří nové nasazení deployment-v6 a nasadí tam verzi v6 aplikace.
Není žádné riziko paralelního nasazení jiné verze. Za prvé, Azure Spring Apps neumožňuje vytvoření třetího nasazení, i když už existují dvě nasazení. Za druhé, i když bylo možné mít více než dvě nasazení, je každé nasazení identifikováno verzí aplikace, kterou obsahuje. Kanál, který orchestruje nasazení v6 , by se tedy pokusil nastavit deployment-v6 pouze jako produkční nasazení.
Po vytvoření nasazení pro novou verzi budete muset odebrat nasazení obsahující předchozí verzi, aby se uvolnilo místo pro budoucí nasazení. Možná budete chtít odložit o určitý počet minut nebo hodin, abyste se mohli vrátit k předchozí verzi, pokud zjistíte kritický problém v nové verzi.
Kompromisy s pojmenovanými nasazeními
Pojmenované nasazení mají následující výhody:
- Zabraňuje stavu časování schválení.
- Snižuje spotřebu prostředků odstraněním přípravného nasazení, když se nepoužívá.
Existují však i nevýhody, jak je popsáno v následující části.
Selhání kanálu nasazení
Mezi časem spuštění nasazení a časem odstranění přípravného nasazení dojde k selhání všech dalších pokusů o spuštění kanálu nasazení. Kanál se pokusí vytvořit nové nasazení, což způsobí chybu, protože v Azure Spring Apps jsou povolená pouze dvě nasazení.
Orchestrace nasazení proto musí mít buď prostředky pro opakování neúspěšného procesu nasazení později, nebo prostředky k zajištění, aby toky nasazení pro každou verzi zůstaly ve frontě, dokud se tok nedokončí pro všechny předchozí verze.