Az Azure Resource Manager-sablonok (ARM-sablonok) felügyeletének moduláris felépítésével csökkentheti az ismétlődést, modellezheti az infrastruktúra-fejlesztés ajánlott eljárásait, és konzisztens standard üzembe helyezésekkel rendelkezhet.
Az ilyen típusú modularizáció implementálására példaként virtuális gépek (virtuális gépek) üzembe helyezése használható a pólóméretek metaforáját használva. Tegyük fel, hogy több tucat vagy több száz virtuális gépet telepített. Ezek az üzemelő példányok a sablonok 1.0.0-s verzióját használják, és szabványos közepes méretűek egy régebbi sorozathoz. Az új sorozatra való áttéréshez rövid szolgáltatáskimaradásra lehet szükség, ha egyszerűen üzembe helyez új sablonokat. Az 1.5.0-s verzió létrehozásával és a modularizáció használatával azonban üzembe helyezhet új infrastruktúrát a frissített szabvány szerint, miközben a régi infrastruktúra üzembe helyezhető állapotban marad. Az infrastruktúra régi verzióinak rendelkezésre állásával a termék- és alkalmazáscsapatok jól ismert konfigurációval rendelkeznek, amelyre támaszkodhatnak az új verzióra való frissítés során, mivel van idejük.
Az adattárak réteges tortája: Példa a vállalatok számára
Ha arról van szó, hogy miért érdemes erősen előnyben részesíteni a sablonok helyét, azok frissítésének módját, és így tovább, két elsődleges szempontot kell figyelembe vennie: az elágaztatást és az innersourcingot.
Elágazó. Ez a példaforgatókönyv megkönnyíti a Gitflow és a GitHub-folyamatot támogató Git-elágaztatási modelleket. További információ a Gitflow-ról: Jeff Kreeftmeijer blogbejegyzése, a Git-flow használata a git-elágaztatási munkafolyamat automatizálásához. A GitHub-folyamatról további információt a GitHub dokumentációjában talál.
Innersourcing. A második az innersourcing, amely a nyílt forráskódú szoftverfejlesztés együttműködésen alapuló gyakorlatait hozza a belső fejlesztésbe. Ilyen esetben magabiztosabban oszthat meg különböző sablonokat és modulforrás-kódot anélkül, hogy maguknak az üzembehelyezési modelleknek az engedélyeivel kellene foglalkoznia. Az innersource-fejlesztéssel kapcsolatos további információkért lásd : Az innersource bemutatása a GitHubon
A Bicep egy deklaratív nyelv az Azure-erőforrások üzembe helyezéséhez. A Bicep újrahasználható kódja az Azure Container Registryt használhatja magánregisztrációs adatbázisként a verziószámozott ARM-sablonok üzemeltetéséhez. A Container Registry ily módon történő használatával a vállalat folyamatos integrációs és folyamatos teljesítésű (CI/CD) folyamattal rendelkezhet az infrastruktúrához. A CI-folyamat részeként integrációs és egységteszteket is futtathat, a tárolóregisztrációs adatbázis pedig a modulok sikeres létrehozása után fogadhat modulokat. Az alkalmazáscsapatok továbbra is használhatják a régebbi verziókat, amíg készen nem állnak a frissítésre, vagy frissíthetnek, hogy kihasználhassák a sablonok újabb verzióinak funkcióit.
A Container Registry ezen használata mellett kombinálhatja ezt a modellt az Azure Verified Moduleshez hasonlóval. Az implementáció felhasználható a nyilvános beállításjegyzékből, vagy lehetőség szerint figyelheti a nyilvános adattárakat, és további használatra lekérheti a módosításokat a magánregisztrációs adatbázisba. A módosítások saját tárolóregisztrációs adatbázisba való beolvasásával teszteket futtathat a nyilvános modulokon, miközben biztosíthatja, hogy azok éles környezetben ne legyenek használatban, amíg a minőségi és biztonsági eljárások be nem épülnek.
Rétegek
Az ebben a példában javasolt modell egy halom. A verem tetejéhez közelebbi rétegek gyakoribb üzemelő példányokkal és üzembe helyezésekkel rendelkeznek, amelyek több részletet jelentenek. A Bicep-kód konzisztens üzembe helyezéseket biztosít. A rétegekben dolgozó fejlesztői csapatok az alábbi rétegekben biztosított szolgáltatásokból és infrastruktúrából építkeznek. Egy alsó rétegben semmi sem támaszkodhat a fenti réteg erőforrásaira. A 0–3. réteg a globális kódtár, a globális infrastruktúra (globálisan megosztott szolgáltatások), a termékplatform (megosztott szolgáltatások) és az alkalmazások.
Ez a modell önállóságot hoz létre az igazítással, ami azt jelenti, hogy:
Gyakori eszközök a nagyvállalati könnyű használathoz. Például mindenki a gitet használja a forrásvezérléshez, és mindenki a GitHub Actionst használja a CI/CD-hez. Azonban nem túlterjeszkedünk. Nem kötelezzük például arra, hogy minden csapat használja a Bicep-et; Terraform- és ARM-sablonokat és egyéb eszközöket használhatnak.
Az ajánlott eljárások megosztásának lehetősége. Ezek arm-sablonok, aranylemezképek vagy kódrészletek formájában is használhatók. Az ajánlott eljárások adott technikák dokumentációja is lehetnek. Például hogyan elforgathatja a kulcsokat a környezetben, és hogyan tesztelheti a kódot.
Egyes szolgáltatások lefelé mozognak a veremben. Előfordulhat például, hogy egy alkalmazáscsapat kezdetben létrehoz egy sablont egy Kubernetes-fürt üzembe helyezéséhez, amelyet később megosztott szolgáltatásként a termékplatformba vonnak be. Ez a sablon annyira hasznossá válik, hogy a mintatárba kerül.
0. réteg – Globális kódtár
Az alsó réteg a globális kódtár, amely az éles környezetben nem üzembe helyezett hasznos azonosítók adattára. A hozzáférés-vezérlés szempontjából az olvasási hozzáférést minden olyan cégnek meg kell adni, aki ezt kéri. A módosítások, javaslatok és így tovább, a Cloud Center of Excellence (CCoE) jóváhagyja a PRS-eket, és úgy kezeli a hátralékot, mintha ez bármilyen más termék volna.
A 0 . réteg nem tartalmazhat:
- Éles környezetben üzembe helyezett sablonok.
- Titkos kódok vagy környezetspecifikus konfigurációk.
A 0 . rétegnek a következőket kell tartalmaznia:
- Kódrészletek (Pythonban, C#-ban és így tovább).
- Azure Policy-minták.
- ARM-sablonok, Bicep-sablonok vagy Terraform-fájlok, amelyek mintaként használhatók.
Erre példa egy mintaarchitektúra, amelyből megtudhatja, hogy a vállalat hogyan írna üzembe helyezést egy háromrétegű alkalmazáshoz környezetspecifikus információk nélkül. Ez a mintaarchitektúra tartalmazhat címkéket, hálózatokat, hálózati biztonsági csoportokat stb. A környezettel kapcsolatos konkrét információk kihagyása hasznos, mert nem minden lehet vagy kell egy modulba helyezni. Ha ezt megkísérli, az túlparaméterezést eredményezhet.
A 0. réteg emellett más ismert jó mintakódforrásokhoz is kapcsolódhat, például a Terraform-beállításjegyzékhez vagy az Azure-erőforrásmodulokhoz. Ha a szervezet kódokat vagy mintákat fogad el valamelyik forrásból, javasoljuk, hogy a kódot vagy mintát a saját 0. rétegbe húzza ahelyett, hogy közvetlenül a nyilvános forrásokból kérnénk le. A 0. rétegre támaszkodva saját teszteket, finomhangolásokat és biztonsági konfigurációkat írhat. Azáltal, hogy nem támaszkodik nyilvános forrásokra, csökkentheti annak kockázatát, hogy olyan dologra támaszkodik, amely váratlanul törölhető.
Ahhoz, hogy jó mintakódnak lehessen tekinteni, a sablonoknak és a moduloknak követnie kell a bevált fejlesztési eljárásokat, beleértve a biztonsági és a szervezeti követelmények bemeneti ellenőrzését is. A szigorúság ezen szintjének fenntartása érdekében házirendeket kell hozzáadnia a fő ághoz, hogy lekéréses kérelmeket (PRS-eket) és kód-felülvizsgálatokat igényeljen a javasolt módosításokhoz, amelyek a fő tárolóregisztrációs adatbázisba történő módosításokat eredményeznének, ha egyesülnének.
A 0. réteg betáplált az Azure Pipelinesba vagy a GitHub Actionsbe, hogy automatikusan hozzon létre verziószámozott összetevőket az Azure Container Registryben. A git véglegesítési üzeneteinek automatizálásával implementálhatja az összetevők szemantikai verziószámozását . Ahhoz, hogy ez megfelelően működjön, rendelkeznie kell egy determinisztikus elnevezési szabványsal, például <a service.bicep-sel>, hogy az automatizálás idővel karbantartható legyen. A megfelelő ágszabályzatokkal integrációs teszteket is hozzáadhat a kódellenőrzések előfeltételeként. Ezt olyan eszközökkel teheti meg, mint a Pester.
Ha ilyen szabályzatok és védelem van érvényben, a tárolóregisztrációs adatbázis lehet az igazság forrása a vállalat minden olyan infrastruktúra-modulja számára, amely készen áll a használatra. A kód felderíthetőségének lehetővé tétele érdekében érdemes megfontolni a változásnaplók és a rendelkezésre álló kódminták indexeinek szabványosítását. Ismeretlen kód nem használt kód!
1. réteg – Globális infrastruktúra: Globálisan megosztott szolgáltatások
Az 1. réteg az Azure-beli célzóna-szerkezetek adattára. Bár a Microsoft sablonokat biztosít az Azure-beli célzónák üzembe helyezéséhez, módosítania kell bizonyos összetevőket, és meg kell adnia egy paraméterfájlt. Ez hasonló ahhoz, ahogyan a korábban ismertetett módon lekéri a nyilvános regisztrációs adatbázist és a modultárakat a 0. rétegbe.
Az Azure Container Registry az architektúra kritikus része. Még akkor is üzembe kell helyeznie a Tárolóregisztrációs adatbázist, ha vállalata nem tervezi a tárolók használatát a Bicep-sablonok sikeres verziószámozásához. A Tárolóregisztrációs adatbázis jelentős rugalmasságot és újrafelhasználhatóságot tesz lehetővé a modulok számára, miközben nagyvállalati szintű biztonságot és hozzáférés-vezérlést biztosít.
Az 1. rétegnek a következőket kell tartalmaznia:
- A felügyeleti csoport vagy előfizetés szintjén alkalmazott szabályzat-hozzárendelések és definíciók. Ezeknek a szabályzatoknak meg kell felelniük a vállalatirányítási követelményeknek.
- Alapvető hálózati infrastruktúra sablonjai, például ExpressRoute, VPN-ek, virtuális WAN és virtuális hálózatok (megosztott vagy hub).
- DNS.
- Alapvető monitorozás (log analytics).
- Vállalati tárolóregisztrációs adatbázis.
Az ágvédelmet úgy kell konfigurálnia, hogy korlátozza az adattár módosításainak leküldését. A más fejlesztőktől származó PRs-ek jóváhagyásának korlátozása a CCoE vagy a Felhőszabályozás tagjaira. A réteg közreműködői elsősorban azoknak a csoportoknak a tagjai, amelyek korábban az ebben a rétegben lévő összetevőkhöz vannak társítva. A hálózatkezelési csapat például létrehozza a hálózat sablonjait, az operatív csapat konfigurálja a figyelést stb. Azonban írásvédett hozzáférést kell biztosítania azoknak a felhasználóknak, akik ezt kérik, mert engedélyezni szeretné, hogy más csoportok fejlesztői módosításokat javasoljanak az alapinfrastruktúra számára. Ezek hozzájárulhatnak a fejlesztésekhez, de ön nem engedélyezi a módosítások jóváhagyását és tesztelését.
Ezeknek a fájloknak a tárolóregisztrációs adatbázis moduljait kell használniuk a standard összetevőkhöz. Emellett azonban rendelkezni fog egy Bicep-fájllal vagy bicep fájlsorozatokkal is, amelyek a vállalat Azure-beli kezdőzónák vagy hasonló szabályozási struktúra implementációjához vannak testre szabva.
2. réteg – Termékplatform: Megosztott szolgáltatások
A 2. réteget, a termékplatformot tekintheti egy adott termékvonal vagy üzleti egység megosztott szolgáltatásainak. Ezek az összetevők nem univerzálisak a szervezetben, de egy adott üzleti igénynek felelnek meg. Ez egy olyan virtuális hálózat megfelelő rétege, amely az 1. rétegbeli globális infrastruktúrában található központtal társviszonyban van. A kulcstartó egy másik példaösszetevő ehhez a réteghez. A kulcstartó megosztott titkos kulcsokat tárolhat egy tárfiókban vagy egy olyan adatbázisban, amelyet a platform különböző alkalmazásai osztanak meg.
A 2. rétegnek a következőket kell tartalmaznia:
- Az előfizetésben vagy erőforráscsoportban alkalmazott szabályzat-hozzárendelések megfelelnek a termékspecifikus követelményeknek.
- ARM-sablonok kulcstartókhoz, log analyticshez, SQL-adatbázishoz (ha a termék különböző alkalmazásai használják az adatbázist) és az Azure Kubernetes Service-hez.
Olyan engedélyeket kell implementálnia, amelyek korlátozzák az adattár módosításainak leküldését. A többi réteghez hasonlóan ágvédelemmel kell gondoskodnia arról, hogy egy termékvezető vagy tulajdonos jóváhagyhassa a más fejlesztőktől származó kérelemkéréseket. A termékplatformhoz való olvasási hozzáférésre nincsenek rögzített szabályok, de legalább az alkalmazáscsapatok fejlesztőinek olvasási hozzáférést kell biztosítani ahhoz, hogy módosításokat javasolhassanak. Mivel a 2. réteg tartalmazhat valamilyen védett architektúrát vagy hasonló információt, a platformot használó szervezetek hozzáférését korlátozhatja. Ha azonban ez a helyzet, gondoskodnia kell arról, hogy létrehozzon egy folyamatot, amelyből az adattárból származó bevált eljárásokat és kódrészleteket gyűjti össze a 0. rétegbeli globális könyvtárral való megosztáshoz.
3. réteg – Alkalmazás
A 3. réteg, az alkalmazásréteg tartalmazza a termékplatformra épülő összetevőket. Ezek az összetevők biztosítják az üzleti kérések által igényelt funkciókat. Streamelési platform esetén például egy alkalmazás biztosíthatja a keresési függvényt, míg egy másik alkalmazás javaslatokat tesz.
A 3. rétegnek tartalmaznia kell:
- Alkalmazáskód C#-ban, Pythonban és így tovább.
- Az egyes összetevők infrastruktúrája (ez csak ebben az alkalmazásban használatos): függvények, Azure Container Instances, Event Hubs.
Az engedélyek korlátozottak az adattár módosításainak leküldésére. Az ágvédelemmel engedélyeznie kell az alkalmazás csapattagjának, hogy jóváhagyja egy másik csapattag által készített lekéréses kérelmet. A csapattagok nem hagyhatják jóvá a saját módosításaikat. Mivel ez a réteg védett architektúrát, üzleti logikát vagy hasonló információkat tartalmazhat, úgy is dönthet, hogy korlátozza a hozzáférést az alkalmazást létrehozó szervezet tagjaihoz. Ha azonban ez a helyzet, akkor a 0. réteg globális kódtárával való megosztáshoz létre kell készítenie a megfelelő eljárásokat és kódrészleteket ebből a rétegből.
Rétegek közötti gyakoriságok
Bár ez a cikk az egyes rétegek bizonyos részleteit ismerteti, az összes rétegnek van néhány tulajdonsága is, amelyeket mindenképpen figyelembe kell vennie.
Az infrastruktúrának úgy kell működnie, mintha egy alkalmazás lenne. Ez azt jelenti, hogy folyamatos integrációs (CI) folyamattal kell rendelkeznie, amelyben az új funkciók teljes tesztelése egységtesztekkel, füsttesztekkel és integrációs tesztekkel történik. Csak olyan kódot egyesíthet, amely ezeket a teszteket a fő kiadási ágba továbbítja.
Emellett gondoskodnia kell arról, hogy a fiókszabályzatok érvényben legyenek, hogy az egyének még a célszerűség érdekében is megkerüljék a folyamatot. Ha a CI-folyamatot akadálynak tekintik, az azt jelenti, hogy olyan technikai adósságot viselt, amelyet kezelni kell. Ez nem jelenti azt, hogy el kell távolítania a szabályzatokat és a védelmet.
Végül, bár előfordulhat, hogy nem rendelkezik az összes adattár és a bennük lévő kód indexével, a szervezetnek ki kell dolgoznia egy folyamatot az egyének számára, hogy hozzáférést kérjenek az adattárakhoz. Bizonyos szabályok teljesen automatizálhatók. Implementálhat például egy szabályt, amely áttekintés nélkül biztosít olvasási hozzáférést egy olyan közreműködőnek, aki a termékcsoportban található bármely alkalmazáshoz tartozik. Ezek a szabályok gyakran csoportalapú tagsággal és csoportalapú szerepkör-hozzárendelésekkel implementálhatók a környezetekben. Az ilyen típusú hozzáférés konfigurálásának segítenie kell a belső forráskezelést és a szervezeti ismereteket.
Közreműködők
Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.
Fő szerzők:
- Tim Sullivan | Vezető műszaki szakember
Egyéb közreműködők:
- Gary Moore | Programozó/író
Következő lépések
- Tervezési terület: Platformautomatizálás és DevOps
- Kiforrott csapatstruktúrák
- Mi az infrastruktúra kódként?
- Azure/ResourceModules: Ez az adattár egy CI-platformot tartalmaz a kiforrott és válogatott Bicep-modulokhoz és -gyűjteményekhez. A platform az Azure Resource Managert és a Bicepet is támogatja, és a funkcióit a GitHub-műveletekkel és az Azure Pipelinessal is használhatja.
- Privát beállításjegyzék létrehozása a Bicep-modulhoz