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

Az Azure Well-Architected Framework működési kiválósági ellenőrzőlistájá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 kódként (IaC) alapuló megközelítésével. 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, szabványos 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 üzembe helyezésre támaszkodva a számítási feladat inkonzisztens konfigurációk és esetleg 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 üzembe helyezés végállapotát, és a rendszerre támaszkodnak annak meghatározásához, hogy az erőforrások hogyan helyezhetők üzembe a meghatározott végállapotnak megfelelően.
Nem módosítható infrastruktúra Olyan infrastruktúra, amelyet új infrastruktúrára kíván cserélni, amely az új konfigurációt futtatja az egyes üzemelő példányokkal. Nem szabad a helyén módosítani.
Imperatív eszközök Eszközök kategóriája, amely felsorolja azokat a végrehajtási lépéseket, amelyek a kívánt befejezési állapotot eredményezik.
Modul Absztrakciós egység az erőforráscsoportok felosztásához az összetett üzemelő példányok leegyszerűsítése érdekében.
Módosítható 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 ahelyett, hogy új infrastruktúrára cserélik.

Kulcsfontosságú 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ókban 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 is) csak kódon keresztül történő üzembe helyezésére. Az IaC-t folyamatos integrációs és folyamatos teljesítésű (CI/CD) folyamatokkal kell üzembe helyeznie. Ezeknek a szabályzatoknak a bevezetése konzisztenciát kényszerít minden IaC-üzemelő példány folyamataiban, 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 érdemes szabványosítani az IaC fejlesztési és üzembehelyezési eszközeit és folyamatait egy stíluskalauzban. A stíluskalauzra vonatkozó javaslatok a következők:

Inkább deklaratív, mint imperatív eszközök. A deklaratív eszközök és a hozzájuk tartozó 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 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ü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 üzembehelyezési szkriptek fenntartásának technikai adósságát, 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ágban bevált eszközöket. A felhőplatform eszközöket biztosít az IaC egyszerű és egyszerű üzembe helyezéséhez. Saját megoldások fejlesztése helyett 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. A natív eszközöket a platform támogatja, és beépített funkciókat is tartalmaz a legtöbb igényének megfelelően. A platformszolgáltató folyamatosan frissíti őket, így a platform fejlődésével egyre hasznosabbá válik.

Megjegyzés

Vegye figyelembe, hogy amikor a felhőszolgáltatók és külső fejlesztők frissítik eszközeiket és API-ikat, fennáll a veszélye annak, hogy váratlan problémák merülnek fel, 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 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 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 a szkriptek üzembe helyezéséhez használt eszköz, például a Bicep, nem feltétlenül a legjobb eszköz minden felügyeleti művelethez.

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 eszközök, mint az Ansible a DSC virtuális gépekhez való kezeléséhez, 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 az IaC-n keresztül kezelhető konfigurációkezeléshez (például Azure App Configuration). A szolgáltatott szoftver (SaaS) szolgáltatásai 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 a sablonoknak elég rugalmasnak kell lenniük ahhoz, hogy egyszerűen ü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ó a kód-előléptetési verem bármely környezetének üzembe helyezéséhez. 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 elvonja túl sokat, azonban. Vannak olyan beállítások, amelyek egy paraméterrel vagy változóval absztrahálhatók, amelyek nem feltétlenül változnak a számítási feladatok é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 igény szerint módosíthatja, hogy különböző környezetekben legyen üzembe helyezve.

A modulok használatának sztratizá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 figyelmes, 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ők legyenek. Modulok használatával összetett konfigurációkat vagy erőforrás-kombinációkat foglal magában. 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.

Dokumentumszabványok manuális lépésekhez. Előfordulhatnak olyan lépések, amelyek az infrastruktúra üzembe helyezésével és karbantartásával kapcsolatosak, amelyek kifejezetten 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 jól 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 virtuális gépekről egy PaaS-szolgáltatásra költözik egy bizonyos függvényhez, és az IaC-eszközkészletnek nincs logikája a kivont erőforrások eltávolítására. Ezek az erőforrások árvatá válhatnak, ha a számítási feladatért felelős csapat nem emlékszik arra, hogy manuálisan törölje őket. 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 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 a következő javaslatokat, amelyek az IaC számítási feladathoz való használatára vonatkoznak:

Használjon rétegzett megközelítést az IaC-folyamatok a számítási feladat veremen belüli igazításához. Az IaC-folyamatokat rétegekre bontva ö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 igazított több folyamat használata, amelyek üzembehelyezési életciklusa vagy a funkciókhoz hasonló tényezők szorosan egyeznek, megkönnyítik az IaC-üzemelő példányok kezelését.

Az olyan alapvető infrastruktúra, mint 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 érinté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ásvermet használva 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ás kódösszetevőit, ugyanazzal a szigorúsággal kezelheti a kódot az összes folyamaton. Emellett az IaC fejlesztési és üzembehelyezési gyakorlatának 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 szétosztania. Ezzel biztosíthatja, hogy minden üzemelő példány 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.

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 csapat 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 újbóli felhasználásában, hogy hatékonyságot és konzisztenciát biztosítsunk a számítási feladatok környezetei között. Hasonlóképpen, az IaC-eszközöket a szervezet egészében szabványosnak kell lenniük, amennyiben ez gyakorlatias.

Alkalmazza a "biztonság mint kód" elvet 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ágirés-vizsgálatot és a konfiguráció 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 érdekében, hogy a biztonsági kiadásra jóváhagyott konfiguráció valójában az éles környezetben üzembe helyezett konfiguráció legyen. 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 üzembehelyezé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 fontosságú, a legjobb, ha nem módosítható infrastruktúrát használ. Hasonlóképpen, ha olyan kiforrott infrastruktúra-kialakítással rendelkezik, amely üzembehelyezési bélyegeken alapul, 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 nem módosítható 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 kapcsolatos problémák elhárítása esetén a továbbgördülés 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.

Megfontolandó szempontok

Magasabb 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. A csapattagok képzése és a megfelelő eszköz elemzése a felhőszolgáltatók eszköztámogatása alapján szükséges.

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őmozdíthatja a kultúrát, ahol az adósság csökkentése jutalmazza.

A konfigurációmódosítá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 összetevők tesztelésére. Minimalizálja az üzembe helyezési időt az ajánlott eljárások, például a kódvizsgálatok és a minőségbiztosítási eljárások követésével.

A modularizáció összetettsége: 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. A modularizáció használatának egyensúlyba hozása az összetettség csökkentése és a túltervezés elkerülése érdekében.

Azure-beli segítségnyújtá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.

Szervezeti igazítás

felhőadaptálási keretrendszer útmutatást nyújt a központi csapatoknak arról, hogyan szabványosíthatja az infrastruktúrát kódként a szervezet számításifeladat-csapatai között.

További információ: Infrastruktúra kódként a felhőadaptálási keretrendszer.

Példa

Tekintse meg az Azure Virtual Desktop kezdőzónagyorsító architektúráját és a kapcsolódó referenciaimplementációt, amely példaként szolgál a megadott Resource Manager, Bicep- vagy Terraform-fájlokon keresztül üzembe helyezhető Virtual Desktop-implementációra.

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

Tekintse meg a javaslatok teljes készletét.