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

Poznámka:

Azure Spring Apps je nový název služby Azure Spring Cloud. Přestože má služba nový název, na některých místech uvidíte starý název, protože pracujeme na aktualizaci prostředků, jako jsou snímky obrazovky, videa a diagramy.

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

Diagram znázorňující nasazení 1 s v3, který přijímá produkční provoz a nasazení2 přípravné verze 4

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

Diagram znázorňující verzi 4 nasazenou v nasazení2 a testová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 .

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 další spuštění kanálu nasazení se nasadí do 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 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.

Diagram znázorňující příjem produkčního provozu v 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 č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.

Diagram znázorňující stav časování 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 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.

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 do nasazení v6 a příjem produkčního provozu

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.

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

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.

Další kroky