Sdílet prostřednictvím

Strategie nasazení s modrou zelenou barvou ve službě Azure Spring Apps

  • Článek

Poznámka:

Plány Basic, Standarda Enterprise vstoupily do důchodového období 17. března 2025. Další informace najdete v oznámení o vyřazení Azure Spring Apps.

Plán Standardní spotřeba a vyhrazený plán vstoupily do fáze vyřazování dne 30. září 2024 s úplným vypnutím do konce března 2025. Další informace najdete v tématu Migrace plánu 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 modro-zeleného nasazení pomocí Azure Spring Apps je vytvoření dvou pevných nasazení a vždy nasazujte na nasazení, které není obsluhováno produkčním provozem. Pomocí úlohy Azure Spring Apps pro Azure Pipelines můžete tímto způsobem nasadit pouze nastavením příznaku na UseStagingDeploymenttrue.

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. V současné době je deployment1 nastaveno jako produkční nasazení a používá verzi v3 aplikace.

Toto činí deployment2 přípravným nasazením. 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í v4další verzi aplikace, verzi deployment2.

Diagram znázorňující nasazení1 s v3, které přijímá produkční provoz, a nasazení2 ve verzi přípravy v4.

Po spuštění v4 na deployment2, můžete spouštět automatizované a ruční testy prostřednictvím soukromého testovacího koncového bodu, abyste zajistili, že v4 splňuje všechna očekávání.

Diagram znázorňující V4 nasazenou v rámci nasazení 2 a procházející testováním.

Pokud máte důvěru v v4, můžete nastavit deployment2 jako produkční nasazení tak, aby přijímal veškerý produkční provoz. v3 zůstane spuštěný na deployment1 v případě, že zjistíte kritický problém, který vyžaduje vrácení zpět.

Diagram znázorňující verzi 4 v nasazení 2, která přijímá produkční provoz.

deployment1 Teď je přípravné nasazení. Takže při dalším spuštění kanálu nasazení se provedou nasazení na deployment1.

Diagram znázorňující fázi nasazení V5

Teď můžete testovat V5 na deployment1privátním testovacím koncovém bodu.

Diagram znázorňující test V5 na nasazení 1.

Nakonec, poté, co v5 splní všechna vaše očekávání, nastavíte deployment1 znovu jako produkční nasazení, aby v5 přijímal veškerý produkční provoz.

Diagram, který ukazuje, jak V5 přijímá produkční provoz na nasazení1.

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 souběhu schválení

Předpokládejme, že uvolňovací kanál aplikace ve výše uvedené aplikaci vyžaduje ruční schválení, než může každá nová verze aplikace začít 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, které bude na tomto nasazení nasazeno a přijímá provoz, ne schválené v6.

Diagram, který znázorňuje race condition týkající se schválení popsaný v této části.

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 schválení závodu, je použití přístupu Pojmenovaná nasazení popsaného 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 přizpůsobeném nasazení, poté se toto nasazení nastaví 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.

Diagram znázorňující nasazení nové verze v pojmenovaném nasazení, jak je popsáno v této části

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

Diagram znázorňující verzi 6 nasazenou jako deployment-v6 a příjem produkčního provozu.

Jakmile nasazení pro novou verzi začne přijímat produkční provoz, 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.

Diagram znázorňující, že po záložním období se předchozí nasazení odstraní.

Kompromisy pojmenovaného přístupu k nasazením

Pojmenovaný přístup nasazení má následující výhody:

  • Zabraňuje stavu závodu při schvalování.
  • Snižuje spotřebu prostředků odstraněním přípravného nasazení, pokud není využíváno.

Existují však i nevýhody, jak je popsáno v následující části.

Selhání kanálu nasazení

Mezi zahájením nasazení a odstraněním přípravného nasazení selžou jakékoliv další pokusy o spuštění nasazovacího procesu. Pipelina se pokusí vytvořit nové nasazení, což způsobí chybu, protože v Azure Spring Apps jsou povolena pouze dvě nasazení na jednu aplikaci.

Orchestrace nasazení proto musí mít buď prostředky pro zopakování neúspěšného procesu nasazení později, nebo prostředky k zajištění, aby procesy nasazení pro každou verzi zůstaly ve frontě, dokud není proces dokončen pro všechny předchozí verze.

Další kroky