Share via

Javaslatok az infrastruktúra kódként való használatára

  • Cikk

Erre az Azure Well-Architected Framework Operational Excellence ellenőrzőlistára vonatkozó javaslatra vonatkozik:

OE:05 Készítse elő az erőforrásokat és azok konfigurációit egy szabványosított infrastruktúra mint kód (IaC) megközelítés használatával. A többi kódhoz hasonlóan konzisztens stílusokkal, megfelelő modularizációval és minőségbiztosítással tervezzen IaC-t. Ha lehetséges, inkább deklaratív megközelítést használjon.

Ez az útmutató az IaC szabványként való használatára vonatkozó javaslatokat ismerteti az infrastruktúra üzemelő példányaihoz. Az IaC használatával integrálhatja az infrastruktúra üzemelő példányait és felügyeletét a meglévő szoftverfejlesztési gyakorlatba. Konzisztens, standard módszertant biztosít a számítási feladat összes összetevőjének fejlesztéséhez és üzembe helyezéséhez. A manuális üzemelő példányokra támaszkodva a számítási feladat inkonzisztens konfigurációk és potenciálisan nem biztonságos kialakítás kockázatának van kitéve.

Definíciók

Időszak Definíció
Deklaratív eszközök Olyan eszközök kategóriája, amelyek meghatározzák az üzemelő példány végállapotát, és a rendszerre támaszkodnak annak meghatározásához, hogyan helyezhetik üzembe az erőforrásokat a meghatározott végállapotnak megfelelően.
Nem módosítható infrastruktúra Egy olyan infrastruktúrát, amelyet új infrastruktúrára kívánnak cserélni, amely az új konfigurációt futtatja az egyes üzemelő példányokkal. Ezt nem szabad a helyén módosítani.
Imperatív eszközök Eszközkategória, amely felsorolja azokat a végrehajtási lépéseket, amelyek a kívánt befejezési állapotot eredményezik.
Modul Egy absztrakciós egység, amely erőforrások csoportjait osztja el az összetett üzemelő példányok leegyszerűsítése érdekében.
Mutable infrastruktúra A helyben módosítani kívánt infrastruktúra. Az üzemelő példányok az infrastruktúra konfigurációját módosítják, nem pedig új infrastruktúrára cserélik.

Fő tervezési stratégiák

Ahogy az ellátási láncról és a szabványosító eszközökről és folyamatokról szóló útmutatóban is szó van, szigorú szabályzattal kell rendelkeznie az infrastruktúra-módosítások (beleértve a konfigurációs módosításokat) csak kódon keresztül történő üzembe helyezésére. Az IaC-t a folyamatos integrációs és folyamatos kézbesítési (CI/CD) folyamatokon keresztül kell üzembe helyeznie. Ezeknek a szabályzatoknak a bevezetése a folyamatok konzisztenciáját minden IaC-üzemelő példány esetében kikényszeríti, minimalizálja a környezetek közötti konfigurációs eltérés kockázatát, és biztosítja az infrastruktúra konzisztenciáját a környezetekben. Emellett szabványosítania kell az IaC fejlesztési és üzembehelyezési eszközeit és folyamatait egy stíluskalauzban. A stíluskalauzra vonatkozó javaslatok a következők:

Előnyben részesítse a deklaratívt az imperatív eszközökkel szemben. A deklaratív eszközök és a hozzájuk tartozó fájlok jobb általános választást jelentenek az IaC üzembe helyezéséhez és kezeléséhez, mint az imperatív eszközök. A deklaratív eszközök egyszerűbb szintaxist használnak a definíciós fájljaikhoz, és csak a környezet kívánt állapotát határozzák meg az üzembe helyezés befejezése után. Az imperatív eszközök a kívánt végállapot eléréséhez szükséges lépések meghatározásától függnek, így a fájlok sokkal összetettebbek lehetnek, mint a deklaratív fájlok. A deklaratív definíciós fájlok emellett segítenek csökkenteni az imperatív kód ( például az üzembehelyezési szkriptek) fenntartásának technikai adósságát is, amelyek idővel felmerülhetnek.

Használja a felhőplatform natív eszközeit és a platformba natív módon integrálható egyéb iparágilag bevált eszközöket. A felhőplatform eszközöket biztosít az IaC egyszerű és egyszerű üzembe helyezéséhez. Használja ki ezeket az eszközöket és más, natív integrációval rendelkező külső eszközöket, például a Terraformot ahelyett, hogy saját megoldásokat fejlesztenél. A natív eszközöket a platform támogatja, és a legtöbb igényének megfelelően beépített funkciókat is tartalmaz. A platformszolgáltató folyamatosan frissíti őket, így a platform fejlődésével még hasznosabbak lesznek.

Megjegyzés

Vegye figyelembe, hogy amikor a felhőszolgáltatók és külső fejlesztők frissítik az eszközeiket és API-kat, fennáll a váratlan problémák kockázata, amikor a számítási feladatban a legújabb verziót használja. Mielőtt bevezeti őket, győződjön meg arról, hogy alaposan teszteli az eszközök és API-k új verzióit. Hasonlóképpen kerülje a "legújabb" jelző használatát, amikor az üzembehelyezési kódban lévő eszközre vagy API-ra hív. Legyen szándékos a számítási feladat legújabb ismert jó verziójának meghívása.

A megfelelő eszközök használata adott feladatokhoz és infrastruktúratípusokhoz. Az infrastruktúra életciklusában az üzemelő példányokon kívül több feladat is szerepet játszik. A konfigurációt például alkalmazni és karbantartani kell, és előfordulhat, hogy a szkripttelepítésekhez használt eszköz, például a Bicep, nem minden felügyeleti művelethez a legjobb eszköz.

Hasonlóképpen, a kívánt állapotkonfiguráció (DSC) különböző infrastruktúratípusokra való alkalmazása különböző eszközöket igényelhet. Vannak például olyan konkrét eszközök, mint az Ansible a virtuális gépek DSC-jének kezelésére, míg a Flux jó eszköz a DSC kubernetes-fürtökön való kezeléséhez. A szolgáltatásként nyújtott platformszolgáltatások (PaaS) különböző eszközöket biztosíthatnak a konfigurációkezeléshez (például Azure App Configuration), amelyek az IaC-vel kezelhetők. A szolgáltatásként nyújtott szoftverszolgáltatások (SaaS) korlátozottabbak lehetnek, mert a platform szigorúbban szabályozza őket.

Gondolja át az IaC-eljárások hatókörébe tartozó összes feladatot és infrastruktúratípust, és szabványosítsa azokat az eszközöket, amelyek a szükséges feladatokat hajtják végre, és integrálhatók a fejlesztési és felügyeleti eljárásokba.

A szkripteknek és sablonoknak elég rugalmasnak kell lenniük ahhoz, hogy könnyen üzembe helyezhesse a különböző környezeteket. Paraméterek, változók és konfigurációs fájlok használatával üzembe helyezhet egy szabványos erőforráskészletet, amely módosítható, hogy bármilyen környezetet üzembe helyezzen a kód-előléptetési veremben. Absztrakt beállítások, például erőforrásméret, darabszám, név, üzembe helyezendő helyek és néhány konfigurációs beállítás. Legyen óvatos, hogy ne absztrakt túl sokat, azonban. Vannak olyan beállítások, amelyek egy paraméterrel vagy változóval absztrakciót kaphatnak, amelyek nem feltétlenül változnak a számítási feladat életciklusa során, vagy amelyek ritkán változnak. Nem szabad elvonni őket.

Megjegyzés

Ne használjon különböző IaC-eszközöket különböző környezetekhez. Nem szabad különböző Terraform-fájlokkal rendelkeznie például éles és tesztelési környezetekhez. Minden környezetnek egy fájlt kell használnia. A fájlt úgy módosíthatja, hogy szükség szerint különböző környezetekben telepíthesse őket.

A modulok használatának strategizálása és szabványosítása. A paraméterekhez és változókhoz hasonlóan a modulok is megismételhetővé tehetik az infrastruktúra üzemelő példányait. Legyen azonban átgondolt, hogyan használja őket. A szabványosított absztrakciós stratégia segít biztosítani, hogy a modulok meghatározott, elfogadott céloknak megfelelően legyenek létrehozva. A modulokkal összetett konfigurációkat vagy erőforrás-kombinációkat ágyazhat be. Kerülje a modulokat, ha csak az erőforrás alapértelmezett konfigurációját használja. Emellett az új modulok fejlesztésében is megfontolandónak kell lennie. Szükség esetén használjon karbantartott nyílt forráskódú modulokat, például nem érzékeny forgatókönyvekben.

Dokumentumszabványok manuális lépésekhez. Előfordulhatnak olyan lépések, amelyek az infrastruktúra üzembe helyezéséhez és karbantartásához kapcsolódnak, amelyek különösen a környezetére vonatkoznak, és amelyek manuális beavatkozást igényelnek. Győződjön meg arról, hogy ezek a lépések a lehető legkisebbre vannak csökkentve, és egyértelműen dokumentálva vannak. A stíluskalauzban és a szabványos üzemeltetési eljárásokban szabványosítsa a manuális lépéseket, hogy a feladatok biztonságosan és következetesen legyenek végrehajtva.

Dokumentumszabványok az árva erőforrások kezeléséhez. A konfigurációkezeléshez használt eszközöktől és azok korlátaitól függően előfordulhat, hogy a számítási feladat már nem igényel egy adott erőforrást, és az IaC-eszközök nem tudják automatikusan eltávolítani az erőforrást. Tegyük fel például, hogy a virtuális gépekről egy PaaS-szolgáltatásra szeretne áttérni egy bizonyos függvényhez, és az IaC-eszközök nem rendelkeznek logikával a kivont erőforrások eltávolításához. Ezek az erőforrások elárvulhatnak, ha a számítási feladatért felelős csapat nem emlékszik a manuális törlésükre. A forgatókönyvek kezeléséhez szabványosíthat egy stratégiát az árva erőforrások keresésére és törlésére. Azt is figyelembe kell vennie, hogyan gondoskodhat arról, hogy a sablonok naprakészek legyenek. Vizsgálja meg az IaC-eszközök korlátait, hogy megértse, mire lehet szükség az ilyen helyzetekben.

Egyéb IaC-stratégiák

Vegye figyelembe az alábbi javaslatokat, amelyek az IaC számítási feladathoz való használatára vonatkoznak:

Rétegzett megközelítéssel igazíthatja az IaC-folyamatokat a számítási feladat vermében. Az IaC-folyamatok rétegekre való elválasztásával összetett környezetek kezelhetők. Több tucat vagy több száz erőforrás monolitikus csomagként való üzembe helyezése nem hatékony, és több problémát is okozhat, például a megszakadt függőségeket. Az olyan erőforrásokból álló rétegekhez igazodó több folyamat használata, amelyek üzembehelyezési életciklusa vagy a funkciókhoz hasonló tényezők szorosan egyeznek, megkönnyíti az IaC-üzemelő példányok kezelését.

Az alapvető infrastruktúra, például a hálózati erőforrások ritkán igényelnek összetettebb módosításokat, mint a konfigurációs frissítések, ezért ezeknek az erőforrásoknak egy alacsony hozzáférésű IaC-folyamatot kell alkotnia. A számítási feladat összetettségétől függően előfordulhat, hogy egy vagy több közepes érintésű és nagy érintésű IaC-folyamattal rendelkezik az erőforrásokhoz. Például egy Kubernetes-alapú alkalmazásverem használata esetén egy közepes érintésű réteg állhat a fürtökből, a tárolási erőforrásokból és az adatbázis-szolgáltatásokból. A nagy érintésű rétegek olyan alkalmazástárolókból állnak, amelyek nagyon gyakran frissülnek folyamatos kézbesítési módban.

Az IaC-t és az alkalmazáskódot ugyanúgy kezelje. Ha az IaC-összetevőket ugyanúgy kezeli, mint az alkalmazáskód-összetevőket, akkor ugyanazt a szigorú kódot alkalmazhatja az összes folyamat kódjának kezelésére. Emellett az IaC fejlesztési és üzembehelyezési eljárásainak tükröznie kell az alkalmazás gyakorlatát. A verziókövetésre, az elágaztatásra, a kód-előléptetésre és a minőségre vonatkozó szabványoknak azonosnak kell lenniük. Érdemes lehet az IaC-eszközöket az alkalmazáskód-eszközökkel együtt csoportosítania. Ezzel biztosíthatja, hogy minden üzembe helyezés ugyanazokat a folyamatokat kövesse, és elkerülheti az olyan problémákat, mint az infrastruktúra véletlenül üzembe helyezése a szükséges alkalmazáskód előtt, vagy fordítva.

Együttműködhet a szervezet más csapataival a szabványosítás és az újrafelhasználhatóság érdekében. A nagy szervezetek néha több csapatból is fejleszthetnek és támogathatnak számítási feladatokat. A csapatok közötti együttműködés a szabványok elfogadásához segít újra felhasználni a kódtárakat, sablonokat és modulokat, hogy hatékonyságot és konzisztenciát nyerjen a számítási feladatok környezetében. Hasonlóképpen, az IaC-eszközöket a szervezet egészében egységesíteni kell, amennyiben ez gyakorlatias.

Alkalmazza a "biztonság mint kód" elvét annak biztosítása érdekében, hogy a biztonság az üzembehelyezési folyamat része legyen. Az IaC-fejlesztési folyamat részeként vegye fel a biztonságirés-vizsgálat és a konfigurációk megerősítését. Ellenőrizze az IaC-adattárakban, hogy vannak-e felfedett kulcsok és titkos kódok. Az IaC használatának egyik előnye, hogy a biztonságra összpontosító csapattagok az üzembe helyezés előtt áttekinthetik a kódot annak biztosítása érdekében, hogy a biztonsági kiadásra jóváhagyott konfiguráció valóban az éles környezetben legyen üzembe helyezve. Részletes útmutatásért lásd: Javaslatok a fejlesztési életciklus biztonságossá tételéhez.

Rutin- és nem rutintevékenységek tesztelése. Tesztelje az üzembe helyezéseket, a konfigurációfrissítéseket és a helyreállítási folyamatokat, beleértve az üzembe helyezési-visszaállítási folyamatokat is.

Mutable vs. nem módosítható infrastruktúra

A mutable és a nem módosítható infrastruktúra üzembe helyezése közötti választás néhány tényezőtől függ. Ha a számítási feladat üzleti szempontból kritikus, a legjobb, ha nem módosítható infrastruktúrát használ. Hasonlóképpen, ha olyan fejlett infrastruktúra-kialakítással rendelkezik, amely üzembehelyezési bélyegeken alapul, akkor a nem módosítható infrastruktúra használata hasznos lehet, mert megbízhatóan üzembe helyezheti az alkalmazáskódot és az új infrastruktúrát. Ezzel szemben a mutable-infrastruktúra használata jobb választás lehet, ha a biztonságos üzembehelyezési eljárások azt diktálják, hogy az üzembe helyezéssel való előrelépés, ha enyhíthető üzembehelyezési problémák merülnek fel, az előnyben részesített megoldás. Ebben az esetben valószínűleg frissítené a helyben lévő infrastruktúrát.

Megfontolandó szempontok

Megnövekedett specializáció: Bizonyos esetekben a számítási feladatokért felelős csapat új nyelveket vezet be, és a szállítói zárolás rossz választás lehet. Be kell tanítania a csapattagokat, és elemeznie kell a megfelelő eszközt a felhőszolgáltatók eszköztámogatása alapján.

Nagyobb karbantartási munka: Az IaC-implementáció naprakész és biztonságos állapotban tartásához kódbázis- és eszközkarbantartásra van szükség. Megfelelően nyomon követheti a technikai adósságot, és elősegíti a kultúra, ahol csökkenti az adósságot jutalmazzák.

A konfigurációmódosítások megnövekedett ideje: Az infrastruktúra parancssori utasítások használatával vagy közvetlenül egy portálról történő üzembe helyezéséhez nincs szükség kódolási időre és/vagy összetevők tesztelésére. Minimalizálja az üzembehelyezési időt az ajánlott eljárások, például a kódellenőrzések és a minőségbiztosítási eljárások követésével.

A modularizáció összetettségének növelése: Több modul és paraméterezés használata növeli a hibakereséshez és a rendszer dokumentálásához szükséges időt, és hozzáad egy absztrakciós réteget. A modularizáció használatának kiegyensúlyozása az összetettség csökkentése és a túltervezés elkerülése érdekében.

Azure-beli facilitálás

Az Azure Resource Manager-sablonok (ARM-sablonok) és a Bicep azure-natív eszközök az infrastruktúra deklaratív szintaxissal történő üzembe helyezéséhez. Az ARM-sablonok JSON-ban vannak megírva, míg a Bicep egy tartományspecifikus nyelv. Mindkettő könnyen integrálható azure-folyamatokba vagy GitHub Actions CI/CD-folyamatokba.

A Terraform egy másik deklaratív IaC-eszköz, amely teljes mértékben támogatott az Azure-ban. Az infrastruktúra üzembe helyezésére és kezelésére használható, és integrálható a CI/CD-folyamatba.

A Microsoft Defender for Cloud használatával felderítheti a helytelen konfigurációkat az IaC-ben.

Példa

Tekintse meg az Azure Virtual Desktop kezdőzónagyorsító architektúráját és a kapcsolódó referencia-implementációt, amely egy virtuális asztali implementációra mutat példát, amely a megadott Resource Manager, Bicep vagy Terraform-fájlokon keresztül telepíthető.

Működési kiválóság ellenőrzőlista

Tekintse meg a javaslatok teljes készletét.

Működési kiválóság ellenőrzőlista