Kék-zöld üzembehelyezési stratégiák az Azure Spring Appsben

Feljegyzés

Az Azure Spring Apps az Azure Spring Cloud szolgáltatás új neve. Bár a szolgáltatásnak új neve van, bizonyos helyeken a régi nevet fogja látni egy darabig, miközben az eszközök, például képernyőképek, videók és diagramok frissítésével dolgozunk.

Ez a cikk a következőre vonatkozik: ✔️ Basic/Standard ✔️ Enterprise

Ez a cikk az Azure Spring Apps kék-zöld üzembehelyezési támogatását ismerteti.

Az Azure Spring Apps (Standard csomag és magasabb szintű csomag) minden alkalmazáshoz két üzembe helyezést engedélyez, amelyek közül csak az egyik fogadja az éles forgalmat. Ezt a mintát gyakran kék-zöld üzembe helyezésnek nevezzük. Az Azure Spring Apps kék-zöld üzembe helyezésének támogatása a folyamatos kézbesítési (CD) folyamattal és a szigorú automatizált teszteléssel együtt nagy megbízhatósággal teszi lehetővé az agilis alkalmazások üzembe helyezését.

Váltakozó üzemelő példányok

A kék-zöld üzembe helyezés Azure Spring Apps-beli implementálásának legegyszerűbb módja, ha két rögzített üzembe helyezést hoz létre, és mindig olyan üzembe helyezést hajt végre, amely nem fogad éles forgalmat. Az Azure Pipelines Azure Spring Apps-feladatával egyszerűen üzembe helyezheti ezt a UseStagingDeployment jelölőttrue.

A váltakozó üzemelő példányok megközelítése a gyakorlatban a következőképpen működik:

Tegyük fel, hogy az alkalmazás két központi telepítéssel rendelkezik: deployment1 és deployment2. deployment1 Jelenleg éles üzembe helyezésként van beállítva, és az alkalmazás verzióját v3 futtatja.

Ez teszi deployment2 az előkészítési üzembe helyezést. Így amikor a folyamatos kézbesítési (CD) folyamat készen áll a futtatásra, üzembe helyezi az alkalmazás következő verzióját, a verziót v4az előkészítési üzembe helyezésre deployment2.

Az 1. üzembe helyezést bemutató ábra, amelyen a v3 fogadja az éles forgalmat és a Deployment2 előkészítési v4-et.

A kezdés deployment2után v4 automatizált és manuális teszteket futtathat rajta egy privát tesztvégponton keresztül, hogy minden v4 elvárásnak megfeleljen.

A 2. üzembe helyezéskor üzembe helyezett és tesztelés alatt álló V4-et bemutató ábra.

Ha megbízik benne v4, beállíthatja deployment2 az éles üzembe helyezést, hogy az megkapja az összes éles forgalmat. v3 továbbra is futni deployment1 fog, ha olyan kritikus problémát észlel, amely visszagördülést igényel.

Az üzemi forgalmat fogadó 2. üzembe helyezési V4-et bemutató ábra.

deployment1 Ez az előkészítési üzembe helyezés. Így az üzembehelyezési folyamat következő futtatása a következő lépésben deployment1lesz üzembe helyezve.

Az 1. üzembe helyezésre előkészített V5-öt bemutató ábra.

Most már tesztelheti V5 a deployment1privát tesztvégpontot.

Az üzembe helyezés1 során tesztelt V5-öt bemutató ábra.

Végül, miután v5 megfelel az elvárásainak, ismét éles üzembe helyezésként kell beállítania deployment1 , hogy v5 megkapja az összes éles forgalmat.

Diagram, amely azt mutatja, hogy a V5 fogad éles forgalmat az üzembe helyezés1 során.

A váltakozó üzemelő példányok megközelítésének kompromisszumoi

A váltakozó üzemelő példányok megközelítése egyszerű és gyors, mivel nem igényel új üzembe helyezéseket. Azonban számos hátrányt jelent, az alábbi szakaszokban leírtak szerint.

Állandó átmeneti üzembe helyezés

Az előkészítési üzembe helyezés mindig fut, és így az Azure Spring Apps-példány erőforrásait használja fel. Ez gyakorlatilag megduplázza az Egyes alkalmazások erőforrás-követelményeit az Azure Spring Appsben.

A jóváhagyási versenyfeltétel

Tegyük fel, hogy a fenti alkalmazásban a kiadási folyamat manuális jóváhagyást igényel ahhoz, hogy az alkalmazás minden új verziója megkapja az éles forgalmat. Ez azzal a kockázattal jár, hogy míg egy verzió (v6) manuális jóváhagyásra vár az átmeneti üzembe helyezésen, az üzembe helyezési folyamat újra fut, és felülírja azt egy újabb verzióval (v7). Ezután a jóváhagyás v6 megadása után az üzembe helyezett v6 folyamat éles üzemként állítja be az előkészítési üzembe helyezést. Most azonban a nem jóváhagyott v7, nem a jóváhagyott v6lesz az, amely az adott üzembe helyezésen van üzembe helyezve, és fogadja a forgalmat.

Az ebben a szakaszban leírt jóváhagyási versenyfeltételt bemutató ábra.

Előfordulhat, hogy megakadályozhatja a versenyhelyzetet, ha biztosítja, hogy az egy verzió üzembehelyezési folyamata csak akkor kezdődjön meg, ha az összes korábbi verzió üzembehelyezési folyamata befejeződött vagy megszakadt. A jóváhagyási versenyfeltételek megelőzésének másik módja az alább ismertetett nevesített üzembe helyezési módszer használata.

Elnevezett üzemelő példányok

A nevesített üzembe helyezési megközelítésben a rendszer új üzembe helyezést hoz létre az üzembe helyezett alkalmazás minden új verziójához. Miután az alkalmazást tesztelte a saját telepítésén, az üzembe helyezés éles üzembe helyezésként van beállítva. Az előző verziót tartalmazó üzembe helyezés csak addig tartható fenn, amíg biztos lehet abban, hogy nincs szükség visszaállításra.

Az alábbi ábrán a verzió v5 az üzemelő példányon deployment-v5fut. Az üzembe helyezés neve most már tartalmazza a verziót, mert az üzembe helyezés kifejezetten ehhez a verzióhoz lett létrehozva. Az első pillanatban nincs más üzembe helyezés. A verzió v6üzembe helyezéséhez az üzembe helyezési folyamat létrehoz egy új üzembe helyezést deployment-v6 , és üzembe helyezi az alkalmazásverziót v6 .

Diagram, amely egy új verzió üzembe helyezését mutatja be egy nevesített üzemelő példányon az ebben a szakaszban leírtak szerint.

Nem áll fenn annak a veszélye, hogy egy másik verzió párhuzamosan lesz üzembe helyezve. Először is, az Azure Spring Apps nem teszi lehetővé egy harmadik üzembe helyezés létrehozását, miközben két üzembe helyezés már létezik. Másodszor, még ha kétnál több üzembe helyezés is lehetséges volt, az egyes üzembe helyezéseket a benne található alkalmazás verziója azonosítja. Így az üzembe helyezést v6 vezénylő folyamat csak az éles üzembe helyezést kísérli meg beállítani deployment-v6 .

Az üzembe helyezési v6-ra üzembe helyezett v6-ot és az éles forgalom fogadását bemutató ábra.

Miután az új verzióhoz létrehozott üzembe helyezés megkapja az éles forgalmat, el kell távolítania az előző verziót tartalmazó üzembe helyezést, hogy helyet biztosítson a későbbi üzembe helyezéseknek. Előfordulhat, hogy néhány perccel vagy órával szeretne elhalasztani, hogy visszatérjen az előző verzióra, ha kritikus problémát észlel az új verzióban.

Diagram, amely azt mutatja, hogy egy tartalék időszak után a rendszer törli az előző üzembe helyezést.

A nevesített üzembe helyezési megközelítés kompromisszumoi

A nevesített üzembe helyezési megközelítés az alábbi előnyökkel jár:

  • Megakadályozza a jóváhagyási versenyfeltételt.
  • Csökkenti az erőforrás-felhasználást azáltal, hogy törli az átmeneti üzembe helyezést, ha nincs használatban.

Vannak azonban hátrányai is a következő szakaszban leírtaknak megfelelően.

Üzembehelyezési folyamat hibái

Az üzembe helyezés kezdete és az átmeneti üzembe helyezés törlése között az üzembe helyezési folyamat futtatására tett további kísérletek sikertelenek lesznek. A folyamat megkísérli létrehozni az új üzembe helyezést, ami hibát fog eredményezni, mivel alkalmazásonként csak két üzembe helyezés engedélyezett az Azure Spring Appsben.

Ezért az üzembehelyezési vezénylésnek rendelkeznie kell a sikertelen üzembe helyezési folyamat későbbi újrapróbálkozásához szükséges eszközökkel, vagy annak biztosítására, hogy az egyes verziók üzembehelyezési folyamatai mindaddig várólistán maradjanak, amíg az összes korábbi verzió esetében be nem fejeződik a folyamat.

Következő lépések