Műveleti eljárások kritikus fontosságú számítási feladatokhoz az Azure-ban
A megbízható és hatékony műveleteknek az automatizálás alapelvein kell alapulnia , ahol csak lehetséges , és kódként kell konfigurálni. Ehhez a megközelítéshez jelentős mérnöki beruházásokra van szükség a DevOps-folyamatokban. Az automatizált folyamatok alkalmazás- és infrastruktúrakód-összetevők üzembe helyezésére szolgálnak. Ennek a megközelítésnek az előnyei közé tartoznak a konzisztens és pontos működési eredmények, minimális manuális üzemeltetési eljárásokkal.
Ez a tervezési terület a hatékony és konzisztens üzemeltetési eljárások megvalósítását mutatja be.
Fontos
Ez a cikk az Azure Well-Architected Framework kritikus fontosságú számítási feladatok sorozatának része. Ha nem ismeri ezt a sorozatot, javasoljuk, hogy kezdje a Mi az a kritikus fontosságú számítási feladat?.
DevOps-folyamatok
A DevOps egyetlen mérnöki funkcióba egyesíti a fejlesztési és üzemeltetési folyamatokat és a csapatokat. Ez magában foglalja az alkalmazás teljes életciklusát, és automatizálási és DevOps-eszközöket használ az üzembehelyezési műveletek gyors, hatékony és megbízható végrehajtásához. A DevOps-folyamatok támogatják és támogatják a folyamatos integrációt és a folyamatos teljesítést (CI/CD), miközben elősegítik a folyamatos fejlődés kultúráját.
A kritikus fontosságú alkalmazások DevOps-csapatának kell felelősnek lennie az alábbi feladatokért:
- Alkalmazás- és infrastruktúra-erőforrások létrehozása és kezelése CI/CD-automatizálással.
- Alkalmazásfigyelés és megfigyelhetőség.
- Azure-beli szerepköralapú hozzáférés-vezérlés (RBAC) és identitáskezelés az alkalmazásösszetevőkhöz.
- Alkalmazásösszetevők hálózatkezelése.
- Az alkalmazáserőforrások költségkezelése.
A DevSecOps kibővíti a DevOps-modellt a biztonsági monitorozás, az alkalmazásnaplók és a minőségbiztosítás integrálásával a fejlesztéssel és műveletekkel az alkalmazás teljes életciklusa során. DevOps-csapatokra van szükség a biztonsági szempontból érzékeny és szigorúan szabályozott forgatókönyvekhez, hogy a biztonság a fejlesztési életciklus során ne egy adott kiadási fázisban vagy kapuban legyen beépítve.
Kialakítási szempontok
Kiadási és frissítési folyamat. Kerülje a manuális folyamatokat az alkalmazás-összetevők vagy a mögöttes infrastruktúra bármilyen módosításához. A manuális folyamatok inkonzisztens eredményekhez vezethetnek.
Függőségek a központi informatikai csapatoktól. A DevOps-folyamatok nehezen alkalmazhatók, ha a központosított függvények szigorú függőségeket jelentenek, mivel ezek a függőségek megakadályozzák a végpontok közötti műveleteket.
Identitás- és hozzáférés-kezelés. A DevOps-csapatok részletes Azure RBAC-szerepköröket vehetnek figyelembe különböző technikai funkciókhoz, például az AppDataOps adatbázis-kezeléshez. Nulla megbízhatósági modell alkalmazása DevOps-szerepkörökben.
Tervezési javaslatok
Adja meg a konfigurációs beállításokat és a frissítéseket kódként. A változáskezelés kódon keresztüli alkalmazásával konzisztens kiadási és frissítési folyamatokat engedélyezhet, beleértve az olyan feladatokat, mint a kulcs- vagy titkos kulcsok rotálása és az engedélyek kezelése. A beépített automatikus frissítési mechanizmusok helyett használjon folyamat által felügyelt frissítési folyamatokat, például ütemezett folyamatfuttatásokat.
Ne használjon központi folyamatokat vagy kiépítési folyamatokat az alkalmazáserőforrások példányosításához vagy kezeléséhez. Ezzel külső alkalmazásfüggőségeket és további kockázati vektorokat vezet be, például a zajos szomszédforgatókönyvekhez társítottakat.
Ha központosított kiépítési folyamatokat kell használnia, győződjön meg arról, hogy a függőségek rendelkezésre állási követelményei teljes mértékben igazodnak a kritikus fontosságú követelményekhez. A központi csapatoknak átláthatóságot kell biztosítaniuk, hogy a végpontok közötti alkalmazás holisztikus üzembe helyezést érjen el.
Az egyes futamok során a mérnöki kapacitás egy részét a platform alapvető fejlesztéseinek és megbízhatóságának növelése érdekében szenteljük. Javasoljuk, hogy a kapacitás 20–40 százalékát foglalja le ezekre a fejlesztésekre.
Általános tervezési kritériumok, referenciaarchitektúrák és kódtárak kidolgozása, amelyek igazodnak az alapvető tervezési alapelvekhez. A megbízhatóság, a biztonság és a műveletek konzisztens alapkonfigurációjának kényszerítése a Azure Policy használó szabályzatalapú megközelítéssel.
Használhatja a közös mérnöki feltételeket és a kapcsolódó összetevőket is, például az Azure-szabályzatokat és a Terraform-erőforrásokat a közös tervezési mintákhoz a szervezet szélesebb körű alkalmazás-ökoszisztémájában található egyéb számítási feladatok között.
Nulla megbízhatósági modell alkalmazása kritikus alkalmazáskörnyezetekben. Az Microsoft Entra Privileged Identity Management-hez hasonló technológiák használatával biztosíthatja, hogy a műveletek konzisztensek legyenek, és csak CI/CD-folyamatokon vagy automatizált üzemeltetési eljárásokon keresztül történjenek.
A csapattagoknak nem szabad állandó írási hozzáféréssel rendelkezniük semmilyen környezethez. Előfordulhat, hogy kivételeket szeretne tenni a fejlesztési környezetekben, hogy megkönnyítse a tesztelést és a hibakeresést.
Vészhelyzeti folyamatok definiálása az éles környezetekhez való igény szerint történő hozzáféréshez. Győződjön meg arról, hogy a hitelesítési szolgáltatóval kapcsolatos súlyos problémák esetén a feltört üvegfiókok léteznek.
Fontolja meg az AIOps használatát az üzemeltetési eljárások és az eseményindítók folyamatos fejlesztéséhez.
Alkalmazásműveletek
Az alkalmazástervezési és platformjavaslatok befolyásolják az üzemeltetési eljárásokat. A különböző Azure-szolgáltatások működési képességeket is biztosítanak, különösen a magas rendelkezésre állás és a helyreállítás érdekében.
Kialakítási szempontok
Az Azure-szolgáltatások beépített műveletei. Az Azure-szolgáltatások beépített (alapértelmezés szerint engedélyezve) és konfigurálható platformképességeket biztosítanak, például a zónaredundanciát és a georeplikációt. Az alkalmazások megbízhatósága ezektől a műveletektől függ. Bizonyos konfigurálható képességek további költségekkel járnak, például az Azure Cosmos DB több írásos üzembehelyezési konfigurációja. Kerülje az egyéni megoldások létrehozását, hacsak nem feltétlenül szükséges.
Működési hozzáférés és végrehajtási idő. A legtöbb szükséges művelet az Azure Resource Manager API-val vagy a Azure Portal keresztül érhető el. Bizonyos műveletekhez azonban támogatási mérnököknek kell segítséget nyújtaniuk. Például egy Azure Cosmos DB-adatbázis rendszeres biztonsági másolatából történő visszaállítást vagy egy törölt erőforrás helyreállítását csak Azure-támogatás mérnökök végezhetik el egy támogatási eseten keresztül. Ez a függőség befolyásolhatja az alkalmazás állásidejét. Állapot nélküli erőforrások esetén azt javasoljuk, hogy ahelyett, hogy megvárná, hogy a támogatási mérnökök megpróbálják helyreállítani a törölt erőforrásokat, javasoljuk, hogy telepítse újra az üzembe helyezést.
Szabályzatkényszerítés. Azure Policy keretrendszert biztosít a biztonsági és megbízhatósági alapkonfigurációk kikényszerítéséhez és naplózásához, hogy biztosítsa a kritikus fontosságú alkalmazások közös mérnöki feltételeinek való megfelelést. Pontosabban az Azure Policy az Azure Resource Manager vezérlősíkjának kulcsfontosságú részét képezi, kiegészítve az RBAC-t az engedélyezett felhasználók által végrehajtható műveletek korlátozásával. A Azure Policy a platformszolgáltatások alapvető biztonsági és megbízhatósági konvencióit érvényesítheti.
Erőforrások módosítása és törlése. Zárolhatja az Azure-erőforrásokat, hogy megakadályozza azok módosítását vagy törlését. A zárolások azonban felügyeleti többletterhelést okoznak az üzembehelyezési folyamatokban. A legtöbb erőforrás esetében az erőforrás-zárolások helyett szigorú korlátozásokkal rendelkező, robusztus RBAC-folyamatot javasoljuk.
Tervezési javaslatok
Feladatátvételi eljárások automatizálása. Aktív/aktív modell esetén használjon állapotmodellt és automatizált skálázási műveleteket annak biztosítására, hogy nincs szükség feladatátvételi beavatkozásra. Aktív/passzív modell esetén győződjön meg arról, hogy a feladatátvételi eljárások automatizáltak vagy legalábbis kodifikáltak a folyamatokban.
Rangsorolja az Azure-natív automatikus skálázás használatát az azt támogató szolgáltatásokhoz. A natív automatikus skálázást nem támogató szolgáltatások esetében használja az automatizált üzemeltetési folyamatokat a szolgáltatások skálázásához. Skálázási egységek használata több szolgáltatással a méretezhetőség eléréséhez.
Használjon natív platformbeli képességeket a biztonsági mentéshez és visszaállításhoz, biztosítva, hogy azok igazodjanak az RTO/RPO és az adatmegőrzési követelményekhez. Szükség szerint definiáljon egy stratégiát a biztonsági másolatok hosszú távú megőrzéséhez.
Használjon beépített képességeket az SSL-tanúsítványkezeléshez és -megújításhoz, például az Azure Front Door által biztosítottakhoz.
Külső csapatok számára hozzon létre egy helyreállítási folyamatot a segítségre szoruló erőforrásokhoz. Ha például az adatplatformot helytelenül módosították vagy törölték, a helyreállítási módszereket jól meg kell érteni, és helyreállítási folyamatnak kell lennie. Hasonlóképpen, hozzon létre eljárásokat a leszerelt tárolólemezképek kezelésére a beállításjegyzékben.
A standard üzletmenet-folytonossági előkészületek részeként előzetesen gyakorolja a helyreállítási műveleteket nem éles erőforrásokon és adatokon.
Kritikus riasztások azonosítása és cél célközönségek és rendszerek meghatározása. Világos csatornák definiálása a megfelelő érdekelt felek eléréséhez. Csak végrehajtható riasztásokat küldhet, hogy elkerülje a fehér zajt, és megakadályozza, hogy az operatív érdekelt felek figyelmen kívül hagyják a riasztásokat és a fontos információkat. Folyamatos fejlesztés megvalósítása a riasztások optimalizálásához és a megfigyelt fehér zajok eltávolításához.
A szabályzatalapú irányítás és a Azure Policy alkalmazásával biztosíthatja az üzemeltetési képességek megfelelő használatát és a megbízható konfigurációs alapkonfigurációt az összes alkalmazásszolgáltatásban.
Kerülje az erőforrás-zárolások használatát a rövid élettartamú regionális erőforrásokon. Ehelyett támaszkodjon az RBAC- és CI-/CD-folyamatok megfelelő használatára az operatív frissítések szabályozásához. Erőforrás-zárolások alkalmazásával megakadályozhatja a hosszú élettartamú globális erőforrások törlését.
Frissítéskezelés
A kritikus fontosságú kialakítás határozottan támogatja a rövid élettartamú állapot nélküli alkalmazás-erőforrások elvét. Ha ezt az elvet alkalmazza, általában egy új üzembe helyezési és szabványos kézbesítési folyamattal végezhet frissítést.
Kialakítási szempontok
Igazodás az Azure ütemterveihez. A számítási feladatokat az Azure ütemterveivel igazíthatja, így a platformerőforrások és a futtatókörnyezet függőségei rendszeresen frissülnek.
Frissítések automatikus észlelése. Folyamatokat állíthat be a frissítések figyelésére és automatikus észlelésére. Használjon olyan eszközöket, mint a GitHub Dependabot.
Tesztelés és ellenőrzés. A csomagok, összetevők és függőségek új verzióinak tesztelése és ellenőrzése éles környezetben a kiadások előtt. Az új verziók kompatibilitástörő változásokat tartalmazhatnak.
Futtatókörnyezeti függőségek. Kezelje úgy a futtatókörnyezeti függőségeket, mint az alkalmazás bármely más módosítását. A régebbi verziók biztonsági réseket eredményezhetnek, és negatív hatással lehetnek a teljesítményre. Monitorozza az alkalmazás futtatókörnyezetét, és tartsa naprakészen.
Komponens higiénia és takarítás. A nem használt erőforrások leszerelése vagy eltávolítása. Figyelheti például a tárolóregisztrációs adatbázisokat, és törölheti a nem használt régi rendszerképverziókat.
Tervezési javaslatok
Monitorozza ezeket az erőforrásokat, és tartsa naprakészen őket:
- Az alkalmazásüzemeltési platform. Például rendszeresen frissítenie kell a Kubernetes-verziót Azure Kubernetes Service (AKS) rendszerben, különösen azért, mert a régebbi verziók támogatása nem tartható fenn. Frissítenie kell a Kubernetesen futó összetevőket is, például a tanúsítványkezelőt és az Azure Key Vault CSI-t, és össze kell hangolnia őket az AKS Kubernetes-verziójával.
- Külső kódtárak és SDK-k (.NET, Java, Python).
- Terraform-szolgáltatók.
Az összetevők frissítéséhez kerülje a manuális működési módosításokat. A manuális módosításokat csak vészhelyzetekben érdemes megfontolni. Győződjön meg arról, hogy rendelkezik a manuális módosítások forrásadattárba való újraillesztő folyamatával az eltérés és a probléma ismétlődésének elkerülése érdekében.
Hozzon létre egy automatizált eljárást a lemezképek régi verzióinak eltávolítására Azure Container Registry.
Titkos kódok kezelése
A kulcs, a titkos kód és a tanúsítvány lejárata gyakori oka az alkalmazáskimaradásnak. A kritikus fontosságú alkalmazások titkos kulcskezelésének biztosítania kell a szükséges biztonságot, és megfelelő rendelkezésre állási szintet kell biztosítania a maximális megbízhatósági követelményeknek megfelelően. A kulcsok, titkos kódok és tanúsítványok rotálását rendszeresen végre kell hajtania egy felügyelt szolgáltatás használatával vagy a frissítéskezelés részeként, és folyamatokat kell alkalmaznia a kód- és konfigurációmódosításokhoz.
Számos Azure-szolgáltatás támogatja a Microsoft Entra hitelesítést ahelyett, hogy kapcsolati sztringekre / kulcsokra támaszkodik. A Microsoft Entra id használata jelentősen csökkenti a működési többletterhelést. Ha titkos kódkezelési megoldást használ, annak integrálnia kell más szolgáltatásokkal, támogatnia kell a zónaszintű és regionális redundanciát, és integrációt kell biztosítania Microsoft Entra azonosítóval a hitelesítéshez és engedélyezéshez. Key Vault ezeket a funkciókat biztosítja.
Kialakítási szempontok
A titkos kódok kezelésének három gyakori megközelítése van. Minden módszer beolvassa a titkos kulcsokat a titkos kódtárból, és egy másik időpontban beszúrja őket az alkalmazásba.
Üzembehelyezési idő lekérése. Ennek a megközelítésnek az az előnye, hogy a titkos kódkezelési megoldásnak csak az üzembe helyezéskor kell rendelkezésre állnia, mert ezek után nincsenek közvetlen függőségek. Ilyen például a titkos kulcsok környezeti változóként való injektálása Egy Kubernetes-környezetbe vagy egy Kubernetes-titkos kódba.
Csak az üzembehelyezési szolgáltatásnévnek kell tudnia hozzáférni a titkos kódokhoz, ami leegyszerűsíti az RBAC-engedélyeket a titkos kódkezelő rendszerben.
Ennek a megközelítésnek azonban vannak hátrányai. Az RBAC összetettségét mutatja be a DevOps-eszközökben a szolgáltatásnév-hozzáférés szabályozása és az alkalmazás számára a lekért titkos kódok védelme tekintetében. Emellett a titkos kódkezelési megoldás biztonsági előnyei nem érvényesülnek, mivel ez a megközelítés csak az alkalmazásplatform hozzáférés-vezérlésére támaszkodik.
A titkos kódok frissítésének vagy rotálásának megvalósításához teljes újratelepítést kell végrehajtania.
Alkalmazásindítási lekérés. Ebben a megközelítésben a rendszer lekéri és beszúrja a titkos kódokat az alkalmazás indításakor. Ennek az az előnye, hogy könnyedén frissítheti vagy elforgathatja a titkos kulcsokat. Nem kell titkos kulcsokat tárolnia az alkalmazásplatformon. A legújabb érték lekéréséhez újra kell indítani az alkalmazást.
A gyakori tárolási lehetőségek közé tartozik az Azure Key Vault Provider for Secrets Store CSI Driver és az akv2k8s. Egy natív Azure-megoldás, Key Vault hivatkozott alkalmazásbeállítások is elérhetők.
Ennek a megközelítésnek a hátránya, hogy futtatókörnyezeti függőséget hoz létre a titkos kódkezelési megoldástól. Ha a titkos kódkezelési megoldás szolgáltatáskimaradást tapasztal, a már futó alkalmazás-összetevők továbbra is kiszolgálhatják a kéréseket. Minden újraindítási vagy vertikális felskálázási művelet valószínűleg hibához vezetne.
Futtatókörnyezet lekérése. A titkos kulcsok futásidőben történő lekérése az alkalmazáson belül a legbiztonságosabb módszer, mivel még az alkalmazásplatformnak sincs hozzáférése a titkos kódokhoz. Az alkalmazásnak hitelesítenie kell magát a titkos kódkezelő rendszerben.
Ehhez a megközelítéshez azonban az alkalmazásösszetevőknek közvetlen függőségre és a titkos kódkezelő rendszerhez való csatlakozásra van szükségük. Ez megnehezíti az összetevők egyenkénti tesztelését, és általában szükségessé teszi egy SDK használatát.
Tervezési javaslatok
Ha lehetséges, a kapcsolati sztringek vagy kulcsok helyett Microsoft Entra-hitelesítéssel csatlakozhat a szolgáltatásokhoz. Használja ezt a hitelesítési módszert az Azure által felügyelt identitásokkal együtt, hogy ne kelljen titkos kódokat tárolnia az alkalmazásplatformon.
Használja ki az Key Vault lejárati beállítását, és konfigurálja a közelgő lejáratokra vonatkozó riasztásokat. A standard kiadási folyamattal végezze el az összes kulcs-, titkos kód- és tanúsítványfrissítést.
Helyezzen üzembe Key Vault példányokat egy regionális bélyeg részeként, hogy mérsékelje az egyetlen üzembehelyezési bélyeg sikertelenségének lehetséges hatását. Használjon egy külön példányt a globális erőforrásokhoz. Az erőforrásokkal kapcsolatos információkért tekintse meg a kritikus fontosságú számítási feladatok jellemző architektúramintáját .
A szolgáltatásnév hitelesítő adatainak vagy API-kulcsainak kezelésének elkerülése érdekében a szolgáltatásnevek helyett használjon felügyelt identitásokat a Key Vault eléréséhez, amikor csak lehetséges.
Implementáljon kódolási mintákat annak érdekében, hogy a titkos kulcsok újra lekérhetők legyenek, ha futásidőben engedélyezési hiba történik.
Alkalmazzon egy teljesen automatizált kulcsrotálási folyamatot, amely rendszeres időközönként fut a megoldáson belül.
Az Azure Key Vault hamarosan esedékes lejárati értesítésével riasztásokat kaphat a közelgő lejáratokról.
IaaS-specifikus szempontok virtuális gépek használatakor
Ha IaaS virtuális gépeket kell használnia, a jelen dokumentumban korábban ismertetett eljárások és eljárások némelyike eltérhet. A virtuális gépek használata nagyobb rugalmasságot biztosít a konfigurációs lehetőségek, az operációs rendszerek, az illesztőprogram-hozzáférés, az alacsony szintű operációsrendszer-hozzáférés és a telepíthető szoftverek típusai terén. A hátrányok a megnövekedett üzemeltetési költségek és a felhőszolgáltató által a PaaS-szolgáltatások használatakor általában elvégzett feladatokért való felelősség.
Kialakítási szempontok
- Az egyes virtuális gépek nem biztosítanak magas rendelkezésre állást, zónaredundanciát vagy georedundanciát.
- Az egyes virtuális gépek nem frissülnek automatikusan az üzembe helyezésük után. Például a Windows Server 2019-en üzembe helyezett SQL Server 2019 nem frissül automatikusan újabb kiadásra.
- A virtuális gépen futó szolgáltatások speciális kezelést és további eszközöket igényelnek, ha az infrastruktúrán keresztül, kódként szeretné üzembe helyezni és konfigurálni őket.
- Az Azure rendszeresen frissíti a platformját. Ezekhez a frissítésekhez szükség lehet a virtuális gépek újraindítására. az újraindítást igénylő Frissítések általában előre bejelentik. Lásd: Virtuális gépek karbantartása az Azure-ban és Tervezett karbantartási értesítések kezelése.
Tervezési javaslatok
Kerülje a manuális műveleteket a virtuális gépeken, és implementáljon megfelelő folyamatokat a módosítások üzembe helyezéséhez és bevezetéséhez.
- Automatizálhatja az Azure-erőforrások kiépítését olyan infrastruktúra-kódként nyújtott megoldások használatával, mint az Azure Resource Manager (ARM)-sablonok, a Bicep, a Terraform vagy más megoldások.
Győződjön meg arról, hogy a virtuális gépek üzembe helyezéséhez, a frissítésekhez, a biztonsági mentéshez és a helyreállításhoz szükséges üzemeltetési folyamatok működnek és megfelelően vannak tesztelve. A rugalmasság teszteléséhez szúrjon be hibákat az alkalmazásba, jegyezze fel a hibákat, és mérsékelje ezeket a hibákat.
Győződjön meg arról, hogy vannak olyan stratégiák, amelyek visszaállítják az utolsó ismert kifogástalan állapotot, ha egy újabb verzió nem működik megfelelően.
Hozzon létre gyakori biztonsági mentéseket az állapotalapú számítási feladatokhoz, győződjön meg arról, hogy a biztonsági mentési feladatok hatékonyan működnek, és riasztásokat implementál a sikertelen biztonsági mentési folyamatokhoz.
Virtuális gépek monitorozása és hibák észlelése. A monitorozáshoz szükséges nyers adatok számos forrásból származhatnak. Elemezze a problémák okait.
Győződjön meg arról, hogy az ütemezett biztonsági mentések a várt módon futnak, és hogy szükség esetén létrejönnek az időszakos biztonsági másolatok. A Biztonsági mentési központ segítségével elemzéseket kaphat.
A virtuális gépek helyett a Virtual Machine Scale Sets használatának rangsorolása olyan képességek engedélyezésére, mint a skálázás, az automatikus skálázás és a zónaredundancia.
A karbantartandó egyéni rendszerképek helyett rangsorolja a Azure Marketplace szabványos rendszerképeinek használatát.
Az Azure VM Image Builder vagy más eszközök használatával igény szerint automatizálhatja a testreszabott rendszerképek buildelési és karbantartási folyamatait.
Ezen konkrét ajánlásokon túl alkalmazza az ajánlott eljárásokat a kritikus fontosságú alkalmazási forgatókönyvekre vonatkozó üzemeltetési eljárásokra, adott esetben.
Következő lépés
Tekintse át a kritikus fontosságú alkalmazásforgatókönyvek architektúramintáját: