DevOps-minta

Kód egy helyről, és üzembe helyezés több célhelyen olyan fejlesztési, tesztelési és éles környezetekben, amelyek lehetnek a helyi adatközpontban, magánfelhőkben vagy a nyilvános felhőben.

Kontextus és probléma

Az alkalmazások üzembe helyezésének folytonossága, biztonsága és megbízhatósága alapvető fontosságú a szervezetek számára, és kritikus fontosságúak a fejlesztői csapatok számára.

Az alkalmazások gyakran igényelnek újrabontásra szoruló kódot az egyes célkörnyezetekben való futtatáshoz. Ez azt jelenti, hogy egy alkalmazás nem teljesen hordozható. Az egyes környezetekben való mozgás során frissíteni, tesztelni és ellenőrizni kell. Például a fejlesztési környezetben írt kódot újra kell írni, hogy egy tesztkörnyezetben működjön, és újra kell írni, amikor végül éles környezetben landolt. Továbbá ez a kód kifejezetten a gazdagéphez van kötve. Ez növeli az alkalmazás karbantartásának költségeit és összetettségét. Az alkalmazás minden verziója az egyes környezetekhez van kötve. A megnövekedett összetettség és duplikáció növeli a biztonság és a kódminőség kockázatát. Emellett a kód nem helyezhető újra üzembe újra, ha eltávolítja a sikertelen visszaállítási gazdagépeket, vagy további gazdagépeket helyez üzembe az igények növekedésének kezeléséhez.

Megoldás

A DevOps-minta lehetővé teszi egy több felhőn futó alkalmazás összeállítását, tesztelését és üzembe helyezését. Ez a minta egyesíti a folyamatos integráció és a folyamatos teljesítés gyakorlatát. A folyamatos integrációval a kód minden alkalommal létrejön és tesztelhető, amikor egy csapattag módosítást hajt végre a verziókövetésen. A folyamatos teljesítés automatizálja a buildeléstől az éles környezetig minden lépést. Ezek a folyamatok együttesen létrehoznak egy kiadási folyamatot, amely támogatja a különböző környezetekben való üzembe helyezést. Ezzel a mintával megszövegezheti a kódot, majd üzembe helyezheti ugyanazt a kódot egy helyszíni környezetben, különböző magánfelhőkben és nyilvános felhőkben. A környezetbeli különbségekhez a kód módosítása helyett módosítani kell a konfigurációs fájlt.

A helyszíni, magánfelhős és nyilvánosfelhős környezetek fejlesztői eszközeinek egységes készletével megvalósíthatja a folyamatos integráció és a folyamatos teljesítés gyakorlatát. A DevOps-minta használatával üzembe helyezett alkalmazások és szolgáltatások felcserélhetők, és ezen helyek bármelyikén futtathatók, kihasználva a helyszíni és a nyilvános felhő funkcióit és képességeit.

A DevOps kiadási folyamatának használata a következőkben nyújt segítséget:

• Indítson el egy új buildet a kód véglegesítései alapján egyetlen adattárban.
• Automatikusan üzembe helyezheti az újonnan létrehozott kódot a nyilvános felhőben a felhasználói teszteléshez.
• Automatikus üzembe helyezés magánfelhőbe, miután a kód tesztelésen ment át.

Problémák és megfontolandó szempontok

A DevOps-minta célja, hogy a célkörnyezettől függetlenül biztosítsa a konzisztenciát az üzemelő példányok között. A képességek azonban eltérőek a felhőbeli és a helyszíni környezetekben. Vegye figyelembe a következő szempontokat:

• Elérhetők az üzemelő példányban lévő függvények, végpontok, szolgáltatások és egyéb erőforrások a cél üzembehelyezési helyeken?
• A konfigurációs összetevők olyan helyeken vannak tárolva, amelyek elérhetők a felhőkben?
• Működni fognak az üzembehelyezési paraméterek az összes célkörnyezetben?
• Elérhetőek erőforrás-specifikus tulajdonságok az összes célfelhőben?

További információ: Azure Resource Manager-sablonok fejlesztése felhőkonzisztenciához.

Emellett vegye figyelembe a következő szempontokat, amikor a minta implementálásának módjáról dönt:

Méretezhetőség

Az üzembehelyezési automatizálási rendszerek a DevOps-minták fő vezérlőpontjai. Az implementációk eltérőek lehetnek. A megfelelő kiszolgálóméret kiválasztása a várt számítási feladat méretétől függ. A virtuális gépek skálázása többe kerül, mint a tárolók. Ha azonban tárolókat használna a skálázáshoz, a build-folyamatoknak tárolókkal kell futnia.

Rendelkezésre állás

A DevPattern kontextusában való rendelkezésre állás azt jelenti, hogy a munkafolyamathoz társított állapotinformációk, például a teszteredmények, a kódfüggőségek vagy más összetevők helyreállíthatók. A rendelkezésre állásra vonatkozó követelmények felméréséhez két általános mérőszámot érdemes figyelembe vennie:

• A helyreállítási idő célkitűzése (RTO) azt határozza meg, hogy mennyi ideig lehet rendszer nélkül menni.

• A helyreállítási időkorlát (RPO) azt jelzi, hogy mennyi adatot veszíthet el, ha a szolgáltatás megszakadása hatással van a rendszerre.

A gyakorlatban az RTO és az RPO redundanciát és biztonsági mentést jelent. A globális Azure-felhőben a rendelkezésre állás nem a hardveres helyreállítás kérdése – ez az Azure része –, hanem a DevOps-rendszerek állapotának fenntartása. Az Azure Stack Hubon a hardveres helyreállítás megfontolandó szempont lehet.

Az üzembe helyezés automatizálásához használt rendszer tervezésekor egy másik fontos szempont a hozzáférés-vezérlés és a szolgáltatások felhőkörnyezetekben való üzembe helyezéséhez szükséges jogosultságok megfelelő kezelése. Milyen jogosultságokra van szükség az üzemelő példányok létrehozásához, törléséhez vagy módosításához? Például általában egy jogosultságkészletre van szükség egy erőforráscsoport létrehozásához az Azure-ban, egy másikra pedig a szolgáltatások erőforráscsoportban való üzembe helyezéséhez.

Kezelhetőség

A DevOps-mintán alapuló rendszerek tervezésénél figyelembe kell venni az egyes szolgáltatások automatizálását, naplózását és riasztásait a portfólióban. Használjon megosztott szolgáltatásokat, alkalmazáscsoportot vagy mindkettőt, és kövesse nyomon a biztonsági szabályzatokat és a szabályozást is.

Éles környezetek és fejlesztési/tesztelési környezetek üzembe helyezése külön erőforráscsoportokban az Azure-ban vagy az Azure Stack Hubon. Ezután figyelheti az egyes környezetek erőforrásait, és erőforráscsoportonként összesítheti a számlázási költségeket. Az erőforrásokat készletként is törölheti, ami teszttelepítésekhez hasznos.

Mikor érdemes ezt a mintát használni?

Ezt a mintát akkor használja, ha:

• Egy olyan környezetben fejleszthet kódot, amely megfelel a fejlesztők igényeinek, és olyan környezetben helyezheti üzembe a megoldást, ahol nehéz lehet új kódot fejleszteni.
• Használhatja a fejlesztők által használni kívánt kódot és eszközöket, ha képesek követni a folyamatos integrációs és folyamatos kézbesítési folyamatot a DevOps-mintában.

Ez a minta nem ajánlott a következő helyzetekben:

• Ha nem tudja automatizálni az infrastruktúrát, az erőforrások kiépítését, a konfigurációt, az identitást és a biztonsági feladatokat.
• Ha a csapatok nem férnek hozzá a hibrid felhőbeli erőforrásokhoz a folyamatos integrációs/folyamatos fejlesztési (CI/CD) megközelítés implementálásához.

Következő lépések

Ha többet szeretne megtudni a cikkben bemutatott témakörökről:

• Az Azure DevOps dokumentációjából többet is megtudhat az Azure DevOpsról és a kapcsolódó eszközökről, például az Azure Reposról és az Azure Pipelinesról.
• A teljes termék- és megoldásportfólióról további információt az Azure Stack termék- és megoldáscsaládjában talál.

Ha készen áll a megoldás példájának tesztelésére, folytassa a DevOps hibrid CI/CD-megoldás üzembe helyezési útmutatójával. Az üzembe helyezési útmutató lépésről lépésre ismerteti az összetevők üzembe helyezését és tesztelését. Megtudhatja, hogyan helyezhet üzembe egy alkalmazást az Azure-ban és az Azure Stack Hubon egy hibrid folyamatos integrációs/folyamatos kézbesítési (CI/CD) folyamat használatával.