Megosztás a következőn keresztül:

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

  • Cikk

Az Azure Well-Architected Framework operatív kiválósági ellenőrzőlistájára vonatkozó javaslat:

OE:05 Az erőforrások és konfigurációik előkészítése 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 üzembe helyezését é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.

Meghatározások

Időszak Definíció
Deklaratív eszközök Egy olyan eszközkategória, amely meghatározza az üzembe helyezés végállapotát, és a rendszerre támaszkodva határozza meg, hogyan helyezheti üzembe az erőforrásokat a meghatározott végállapotnak megfelelően.
Nem módosítható infrastruktúra Egy olyan infrastruktúra, amelyet új infrastruktúrára kívánnak cserélni, amely az új konfigurációt futtatja minden egyes üzembe helyezéssel. Nem módosítható a helyén.
Imperatív eszközök Eszközkategória, amely felsorolja azokat a végrehajtási lépéseket, amelyek a kívánt végső állapotot eredményezik.
Modul 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 üzembe helyezések az infrastruktúra konfigurációját módosítják, nem pedig új infrastruktúrára cserélik.

Főbb tervezési stratégiák

Ahogy az ellátási láncban, valamint az eszközök és folyamatok szabványosítását ismertető útmutatókban is szerepel, szigorú szabályzattal kell rendelkeznie az infrastruktúra változásainak (beleértve a konfigurációs módosításokat is) 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 kényszeríti ki minden IaC-üzemelő példány esetében, minimalizálja a konfigurációs eltérések kockázatát a környezetekben, é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:

Deklaratív helyett imperatív eszközök

A deklaratív eszközök és a hozzájuk társított fájlok jobb általános választás az IaC üzembe helyezéséhez és kezeléséhez, mint az imperatív eszközök. A deklaratív eszközök a definíciós fájlok egyszerűbb szintaxisát használják, é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üggenek, í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 üzembe helyezési szkriptek fenntartásának technikai adósságát, amelyek idővel felmerülhetnek.

Natív és iparági szabványoknak megfelelő eszközök használata

Használja a felhőplatform natív eszközeit és a platformba natív módon integrálható egyéb iparágilag bizonyított 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 beépített funkciókat is tartalmaz a legtöbb igényhez. A platformszolgáltató folyamatosan frissíti őket, így a platform fejlődésével egyre hasznosabbá válik.

Feljegyzés

Vegye figyelembe, hogy amikor a felhőszolgáltatók és a külső fejlesztők frissítik az eszközeiket és API-kat, a számítási feladat legújabb verziójának használatakor fennáll a váratlan problémák kockázata. 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 egy eszközt vagy API-t hív meg az üzembehelyezési kódban. Legyen szándékos a számítási feladat legújabb ismert, jó verziójának meghívása.

A feladathoz megfelelő eszköz használata

Használja a megfelelő eszközöket adott feladatokhoz és infrastruktúratípusokhoz. Az infrastruktúra életciklusában az üzemelő példányokon kívül több tevékenység is részt vesz. A konfigurációt például alkalmazni és karbantartani kell, és lehet, hogy nem minden felügyeleti művelethez a legjobb eszköz a szkriptek üzembe helyezéséhez használt eszköz, például a Bicep.

Hasonlóképpen, a kívánt állapotkonfiguráció (DSC) különböző infrastruktúratípusokhoz való alkalmazása különböző eszközöket igényelhet. Vannak például olyan 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ére. 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-alkalmazás Konfiguráció), amelyek az IaC-n keresztül 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.

Több környezet támogatása

A szkripteknek és a 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 olyan szabványos erőforráskészletet helyezhet üzembe, amelyek módosíthatók, hogy bármilyen környezetet üzembe helyezhessenek 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 olyan paraméterrel vagy változóval absztrakciózhatók, amelyek a számítási feladatok életciklusa során nem változnak, vagy ritkán változnak. Nem szabad elvontnak lenniük.

Feljegyzés

Kerülje a különböző IaC-eszközök használatát különböző környezetekhez. Nem szabad különböző Terraform-fájlokkal rendelkeznie például az éles és tesztelési környezetekhez. Minden környezetnek egy fájlt kell használnia. Ezt a fájlt úgy módosíthatja, hogy szükség szerint különböző környezetekben üzembe helyezhesse őket.

A megfelelő egyenleg használata a funkciók beágyazásakor

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 üzembe helyezését. 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 felépítve. Modulok használatával ö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 legyen megfontolt az új modulok fejlesztésében. Szükség esetén használjon fenntartott nyílt forráskódú modulokat, például nem érzékeny forgatókönyvekben.

A dokumentum manuális lépései

Dokumentumszabványok manuális lépésekhez. Lehetnek olyan lépések, amelyek az infrastruktúra üzembe helyezésével és fenntartásával kapcsolatosak, amelyek különösen a környezetére tartoznak, é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. 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 helyez át egy bizonyos függvényt, és az IaC-eszköz nem rendelkezik logikával a kivont erőforrások eltávolításához. Ezek az erőforrások árvatá válhatnak, ha a számítási feladatokat végző csapat nem emlékszik az erőforrások manuális törlésére. A forgatókönyvek kezeléséhez szabványosítsa az árva erőforrások keresésére és törlésére vonatkozó stratégiát. Azt is figyelembe kell vennie, hogyan biztosíthatja, hogy a sablonok naprakészek legyenek. Vizsgálja meg az IaC-eszközök korlátait, hogy megértse, mire lehet szükség ezekben a helyzetekben.

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

Rétegzett megközelítés használata IaC-folyamatokhoz

Rétegzett megközelítéssel igazíthatja az IaC-folyamatokat a számítási feladat veremen belül. 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 hibás függőségeket. Az olyan erőforrásokból álló rétegekhez igazított több folyamat használata, amelyek üzembehelyezési életciklusa vagy olyan tényezők, mint például a funkciók szorosan egyeznek, megkönnyíti az IaC-üzemelő példányok kezelését.

Az alapinfrastruktú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 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özepesen érintéses és nagy érintésű IaC-folyamattal rendelkezik az erőforrásokhoz. Egy Kubernetes-alapú alkalmazásverem például egy közepes érintésű réteget alkothat 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 és az alkalmazáskód kezelése ugyanaz

Ha az IaC-összetevőket ugyanúgy kezeli, mint az alkalmazás kódösszetevőit, ugyanazzal a szigorral kezelheti a kódot az összes folyamaton. Ezenkívül 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. Fontolja meg az IaC-eszközök és az alkalmazáskód-eszközök összeválogatását is. Ezzel biztosíthatja, hogy minden üzembe helyezés ugyanazokat a folyamatokat kövesse, és elkerülheti az olyan problémákat, mint például az infrastruktúra véletlen üzembe helyezése a szükséges alkalmazáskód előtt, vagy fordítva.

Központosított szabványok és erőforrások használata

Együttműködhet a szervezet más csapataival a szabványosítás és az újrahasználhatóság érdekében. A nagy szervezetek néha több csapattal is fejleszthetnek és támogathatnak számítási feladatokat. A csapatok közötti együttműködés a szabványok elfogadása érdekében segít a kódtárak, sablonok és modulok újrafelhasználásában, 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.

Biztonság kényszerítése IaC-kódban

Alkalmazza a "biztonság mint kód" elvét annak biztosítására, hogy a biztonság az üzembehelyezési folyamat része legyen. Az IaC-fejlesztési folyamat részeként vegye fel a biztonsági rések vizsgálatát és a konfigurációk megkeményítését. Ellenőrizze az IaC-adattárakban a felfedett kulcsokat és titkos kulcsokat. 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 tekintse meg a fejlesztési életciklus biztonságossá tételére vonatkozó javaslatokat.

Rutin és nem rutin jellegű tevé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.

Nem módosítható üzemi modell bevezetése

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 fontosságú, a legjobb, ha nem módosítható infrastruktúrát használ. Hasonlóképpen, ha az üzembehelyezési bélyegeken alapuló, kiforrott infrastruktúra-kialakítással rendelkezik, akkor a nem módosítható infrastruktúra használata hasznos lehet, mivel 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 üzembe helyezési eljárások azt diktálják, hogy az üzembe helyezéssel való tovább gördülés az enyhíthető üzembe helyezési problémák esetén az előnyben részesített lehetőség. Ebben az esetben valószínűleg frissítené a helyben lévő infrastruktúrát.

Megfontolások

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

Nagyobb karbantartási munka: A kódbázis és az eszközkarbantartás szükséges az IaC-implementáció naprakész és biztonságos állapotban tartásához. Megfelelően nyomon követheti a technikai adósságot, és előmozdíthatja azt a kultúrát, ahol az adósság csökkentése jutalomban részesül.

A konfigurációváltozások megnövekedett ideje: Az infrastruktúra parancssori utasítások használatával vagy közvetlenül a portálról történő üzembe helyezéséhez nincs szükség kódolási időre és/vagy az ö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 rendszer hibakereséséhez és dokumentálásához szükséges időt, és hozzáad egy absztrakciós réteget. Egyensúlyba hozhatja a modularizáció használatát az összetettség csökkentése és a túltervezés elkerülése érdekében.

Az Azure megkönnyítése

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 Felhőhöz készült Microsoft Defender segítségével felderítheti a helytelen konfigurációkat az IaC-ben.

Példa

Tekintse meg az Azure Virtual Desktop célzónagyorsító architektúráját és a kapcsolódó referencia-implementációt , amely példaként szolgál egy Virtuális asztal implementációra, amely a megadott Resource Manager-, Bicep- vagy Terraform-fájlokon keresztül telepíthető.

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

Tekintse meg a javaslatok teljes készletét.

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