Fejlett automatizálás Windowsban PowerShell DSC és Ansible segítségével

Informatec Digital » Erőforrás » Fejlett automatizálás Windowsban PowerShell DSC és Ansible segítségével

Ha Windows infrastruktúrával dolgozol, és olyan kifejezések, mint a PowerShell, a DSC, az Ansible és az automatizálás ismerősen csengenek , akkor valószínűleg már tudod, hogy ezek hatékony kombinálása teljesen átalakíthatja a szerverek kezelésének módját. A Windows varázslóban a manuális kattintásokról egy teljesen deklaratív és megismételhető konfigurációra való áttérés jelenti a különbséget a folyamatos tűzoltás és a teljesen ellenőrzött környezet között.

Ebben a cikkben részletesebben megvizsgáljuk, hogyan A PowerShell kívánt állapotkonfigurációja (DSC) és az Ansible illeszkedik egymáshoz A Windows (és Linux) nagy léptékű kezeléséhez milyen szerepet játszanak olyan technológiák, mint a WinRM, az Azure Automation, a Terraform vagy a cloud-init, és hogyan használhatja ki az Ansible meglévő DSC-erőforrásait a modulnak köszönhetően? win_dscGyakorlati példákat, valós felhasználási eseteket és kritériumokat láthat annak eldöntéséhez, hogy mikor érdemes natív DSC-t, Ansible modulokat vagy más automatizálási megközelítéseket használni.

Áttekintés: Windows automatizálás PowerShell, DSC és Ansible használatával

A PowerShell és az Ansible célja ugyanaz : a rendszerek konfigurációjának és adminisztrációjának reprodukálható módon történő automatizálása. A különbség a megközelítésükben rejlik. A DSC a PowerShellbe integrált konfigurációkezelő platform, amely nagymértékben Windows-központú (bár OMI-n keresztül Linuxszal is működik), míg az Ansible egy többcélú, platformfüggetlen automatizálási motor, amelyet hibrid és heterogén infrastruktúrák egyetlen pontból történő összehangolására terveztek.

A Red Hat Ansible Automation Platform segítségével automatizálhatja a Windows szervereket további ügynökök telepítése nélkül, kihasználva a WinRM vagy az OpenSSH kapcsolódási csatornaként való használatát, valamint DSC erőforrásokat, Ansible modulokat és PowerShell szkripteket. Mindez YAML playbookokon keresztül rendszerezhető , ahol meghatározhatja azt az állapotot, amelyet minden gazdagépnek el kell érnie, mind Windows, mind Linux rendszeren.

A PowerShell kívánt állapot konfigurálása ezzel szemben több száz speciális erőforrást kínál szinte bármilyen Windows-összetevő konfigurálásához: szolgáltatások, rendszerfunkciók, IIS, SQL Server, Active Directory, beállításjegyzék, fájlok stb. Ezek az erőforrások magukban foglalják a kívánt állapot ellenőrzésének és alkalmazásának logikáját, így csak azt kell deklarálni, hogy „milyennek szeretné a gépet”.

A lényeg az, hogy az Ansible-ből közvetlenül a modulon keresztül használhatja ezeket a DSC-erőforrásokat. ansible.windows.win_dscAz Ansible vezénylési erejét a DSC által kínált Windows-specifikus konfigurációs mélységgel kombinálva érheti el a következőket: A két világ legjobbja erőfeszítések megkettőzése nélkül.

WinRM és távoli hozzáférés a Windowshoz Ansible-hez

Ahhoz, hogy az Ansible képes legyen Windows szerverek felügyeletére, elengedhetetlen megérteni a WinRM (Windows Remote Management) működését . A WinRM a Microsoft beépített, HTTP/HTTPS alapú távoli adminisztrációs technológiája, és ez a szabványos csatorna, amelyet az Ansible a feladatok Windows gépeken történő végrehajtásához használ.

Az első lépés a WinRM megfelelő konfigurálása a célgépeken és a vezérlőcsomóponton, ahol az Ansible fut. Ez magában foglalja a hitelesítés, a titkosítás, az engedélyek módosítását, és gyakran olyan funkciók kezelését, mint a nem interaktív bejelentkezés, ahol a parancsok aktív felhasználói munkamenet nélkül kerülnek kiadásra. Ez a nem interaktív munkamenet-környezet bonyolítja az olyan feladatokat, mint a Windows-frissítések vagy a kétirányú hitelesítési forgatókönyvek , ahol egy második távoli erőforráshoz (például egy másik szerveren lévő megosztáshoz) kell hozzáférni.

A Red Hat Ansible Automation Platform használatának előnye, hogy lehetővé teszi a hitelesítő adatok és hitelesítési mechanizmusok központi és biztonságos kódolását, így absztrakt módon kezelheti ezeket az összetett eseteket. Továbbá a platform képes OpenSSH-n keresztül is elérni a Windows Servert , ami egyre gyakoribb a Windows modern verzióiban.

A gyakorlatban a WinRM, az Ansible hitelesítőadat-kezelési és DSC-képességeinek kombinálása lehetővé teszi robusztus automatizálási folyamatok létrehozását, amelyek felügyelet nélkül futnak, még magas biztonsági korlátozásokkal rendelkező környezetekben is.

PowerShell DSC: Deklaratív konfigurációs platform

A PowerShell Desired State Configuration egy deklaratív konfigurációkezelő platform , amely a Windows rendszerbe integrált. A DSC segítségével kódban definiálhatja, hogyan kell konfigurálni egy gépet: mely szerepköröket és szolgáltatásokat kell telepíteni, mely szolgáltatásoknak kell aktívnak lenniük, mely beállításjegyzék-paramétereknek kell lenniük, mely fájloknak vagy könyvtáraknak kell létezniük, és így tovább.

A DSC -konfigurációk leírják a csomópontok egy halmazának kívánt állapotát . Minden felügyelt gépen fut egy helyi konfigurációkezelő (LCM) , amely az a motor, amely beolvassa ezeket a konfigurációkat, ellenőrzi a tényleges állapotot, és alkalmazza a szükséges módosításokat. Ezenkívül beállíthat egy lekéréses szervert , amely központosítja a konfigurációkat, és amelyről a csomópontok frissülnek és jelentik a megfelelőséget.

A DSC nem korlátozódik Windowsra: az Open Management Infrastructure ( OMI ) szerveren keresztül Linux gépekkel is képes működni . Azonban a Windows környezetekben ragyog igazán, ahol a közösség hatalmas gyűjteményt fejlesztett ki speciális erőforrásokból olyan változatos feladatokhoz, mint az IIS, az SQL Server vagy az Active Directory konfigurálása.

A DSC egyik nagy előnye, hogy az eredményre összpontosít, nem pedig a lépésekre . Te deklarálod az állapotot (például: „ennek a funkciónak jelen kell lennie, ennek a szolgáltatásnak el kell indulnia, ennek a regiszterértéknek konfigurálva kell lennie”), és a motor gondoskodik arról, hogy elérje azt, ellenőrizze és korrigálja, ha bármilyen eltérés van az idő múlásával.

Hogyan illeszkedik az Ansible a DSC-hez: win_dsc modul és vezénylés

Elméletileg a DSC önmagában is használható, de a gyakorlatban sokkal hasznosabb az Ansible-lel kombinálva, mint orkestrációs réteg . Az Ansible kezeli a leltározást, a rendezett feladat-végrehajtást, a rendszerek közötti koordinációt és a CI/CD folyamatokkal való integrációt, míg a DSC biztosítja a Windows belső működésének manipulálásához szükséges specifikus erőforrásokat.

A modul ansible.windows.win_dsc Ez a híd a két világ között. Ez a modul egy DSC erőforrásosztály a cél Windows-hoszton. A forgatókönyvben csak a következőket kell meghatároznia:

• erőforrás_neve: a használni kívánt DSC-erőforrás neve (például File, WindowsFeature, Service, Registry, xWebsite, Stb.)
• A fennmaradó paraméterek, amelyek közvetlenül megfelelnek a a DSC-erőforrás tulajdonságai (például DestinationPath, Ensure, Name, State, Stb.)

Amikor az Ansible végrehajtja a feladatot, ezeket a paramétereket egy ideiglenes DSC-konfigurációvá alakítja, alkalmazza azt a gazdagépre, és összegyűjti az eredményt (beleértve azt is, hogy történtek-e változások). Ez lehetővé teszi a teljes DSC-erőforrás-katalógus újrafelhasználását anélkül, hogy minden egyes esethez külön Ansible-modulokat kellene írni.

Alatta a végrehajtási folyamat egy konzisztens mintát követ: az Ansible WinRM-en keresztül küldi el a feladatot, a Windows rendszer a paraméterek alapján generál egy DSC-konfigurációt, a DSC-motor először meghívja a Test-TargetResource az aktuális állapot ellenőrzésére, és ha eltéréseket észlel, végrehajtja Set-TargetResource a módosítások alkalmazásához. Az Ansible egy jelentést kap, amely jelzi, hogy történt-e módosítás, valamint a hibakereséshez kapcsolódó üzeneteket.

Ez a csatolás különösen erős, ha kombináljuk Ansible natív modulok Windowshoz (mint win_file, win_service, win_regedit, win_psmodulestb.) a DSC erőforrásaival azokon a területeken, ahol a DSC finomabb lehetőségeket vagy nagyobb funkcionális lefedettséget kínál.

DSC tulajdonságok típusai és azok leképezése az Ansible-ben

Minden DSC-erőforrás tulajdonságok halmazát határozza meg egy jól meghatározott típus (karakterlánc, logikai érték, tömbök, összetett PowerShell-típusok stb.). Amikor az Ansible-ből dolgozol, ezeket a tulajdonságokat le kell fordítanod a következőre: YAML szintaxis A helyes típus fenntartása. A modul win_dsc Sok automatikus konverziós munkát végez, de érdemes ismerni néhány kulcsfontosságú esetet.

Egyszerű típusokhoz, mint például o , a leképezés egyszerű: idézőjelek közé tett karakterláncok és kisbetűs logikai értékek YAML stílusban (true, false), kerülve az írást $true o $false ahogyan a PowerShellben tennéd. A típusú tulajdonságok esetén , a szokásos dolog az, hogy egy ISO 8601 formátum (például "2019-02-22T13:57:31Z") és idézőjelek közé téve győződjön meg arról, hogy az érték karakterláncként van szerializálva.

Típustulajdonságok Speciális esetet képviselnek. Mivel ez a típus nem szerializálható közvetlenül JSON-ba, az Ansible egy konvenciót használ: két paramétert definiálsz, amelyeket egy utótag választ el egymástól. _username y _password (például Credential_username y Credential_passwordA modul generálja az objektumot. PSCredential a távoli gépen e két érték alapján.

Típusokhoz Ezek egyéni erőforrásosztályon alapuló szótárakat jelentenek; a YAML-ben kulcs-érték térképként vannak kifejezve. Tekintse át az erőforrás dokumentációját (általában a fájlban). <nombre_recurso>.schema.mof), hogy megtudjuk, mely kulcsok engedélyezettek és milyen típusúak. A gyakorlatban a következőképpen definiáljuk őket: beágyazott szótárak a modulon belül win_dsc.

Végül a típustulajdonságok és a tömbök (], ]stb.) szótárakként vagy YAML listákként vannak ábrázolva. Tömbök esetén ajánlott a következőt használni: hiteles YAML lista és nem vesszővel elválasztott értékekkel rendelkező karakterlánc, mert ez elkerüli a manuális elemzést és csökkenti a finom hibák valószínűségét.

Gyakorlati példák az Ansible DSC használatára

Miután elsajátítottad a modul alapvető felépítését win_dscÖsszevonhatod az erőforrásokat az építéshez nagyon átfogó konfigurációs kézikönyvekNéhány gyakori forgatókönyv, amely jól működik a DSC-vel:

• Fájl- és könyvtárkezelés az erőforrással Filemappastruktúrák létrehozása, adott tartalmú konfigurációs fájlok telepítése, bizonyos elemek létezésének vagy eltávolításának biztosítása.
• Windows szerepkörök és szolgáltatások telepítése a WindowsFeatureIIS, .NET keretrendszer, Telnet kliens, adminisztrációs eszközök stb.
• Szolgáltatásvezérlés az erőforrással Serviceállapot (elindítva/leállítva), indítás típusa (automatikus, manuális), szolgáltatásfiók stb.
• Beállításjegyzék a Registry: biztonsági értékek, várakozási idők, protokollparaméterek, rendszerkeményítés.
• Speciális IIS-beállítások olyan modulokkal, mint xWebAdministration és erőforrások xWebsite, xWebAppPoolStb

Mindezen esetekben az Ansible egyszerűen leírja a DSC-erőforrás paramétereit, míg A DSC motor felelős az ellenőrzésért és az alkalmazásért. az állapot. Továbbá, az Ansible 2.8-as verziójától kezdődően a modul win_dsc Automatikusan ellenőrzi a paramétereket az erőforrás-definíció alapján: ha helytelen tulajdonságnevet használ, üresen hagy egy kötelező mezőt, vagy tartományon kívüli értéket ad át, a feladat egyértelmű hibával meghiúsul.

Ha az Ansible-t egy magas szintű bőbeszédűség (például -vvv)A kimenet részletes információkat fog tartalmazni a következőkről: invocation.module_args a használt és az elérhető opciókról, ami nagyon hasznos mind a hibakereséshez, mind annak felfedezéséhez, hogy mely mezőket konfigurálhatja az egyes erőforrásokban.

Azt is vedd figyelembe, hogy használhatod a paramétert PsDscRunAsCredential Ez lehetővé teszi, hogy a DSC-erőforrás a rendszertől eltérő felhasználóként fusson. Ez nagyon hasznos a regisztrációs struktúra eléréséhez. HKEY_CURRENT_USER az Ansible által csatlakoztatott felhasználó adatait, vagy olyan forgatókönyvek esetén, ahol adott biztonsági kontextusra van szükség.

Egyéni DSC-erőforrások és PowerShell-galéria

A Windowsba integrált DSC-erőforrások számos igényt lefednek, de az igazi erő akkor rejlik, ha a PowerShell-galériában vagy harmadik féltől származó csomagokban közzétett erőforrásokat használjuk . Mindenhez rendelkezésre állnak modulok: Active Directory, SQL Server, speciális IIS, biztonsági házirendek és egyebek.

A cmdlet segítségével felfedezheti az elérhető erőforrásokat Find-DscResource vagy közvetlenül a PowerShell-galéria böngészésével. Miután azonosította az Önt érdeklő modult (például xWebAdministration o SqlServerDsc), többféleképpen is telepítheted a gazdagépeidre:

• Kézi telepítés Install-Module a célkiszolgálón található PowerShellből.
• Az Ansible modul használata win_psmodule a PowerShell-galériából történő telepítés automatizálásához.
• Előzetesen töltsd le és másold le kézzel internet-hozzáféréssel nem rendelkező szerverek esetén a modul mentése a benne található könyvtárba PSModulePath (például C:\Program Files\WindowsPowerShell\Modules).

Amikor kapcsolat nélküli környezetben dolgozunk, egy gyakori stratégia egy internet-hozzáféréssel rendelkező szerver használata. mentse el a modult a következővel: Save-Module egy helyi elérési úton, majd másolja át ezt a könyvtárat az éles gépekre. Ezután konfigurálja a PSModulePath Ansible-lel is beállítható, például a modullal win_pathhogy a PowerShell manuális beavatkozás nélkül is észlelhesse ezeket az erőforrásokat.

A telepítés után a modul win_dsc bármely erőforrást meghívhat ezekből a csomagokból egyszerűen csak a név megadása resource_nameEz megnyitja az utat a jól bevált megoldások, például az Active Directory DSC modulok újrafelhasználása előtt olyan feladatokhoz, mint a felhasználók, szervezeti egységek, csoportok létrehozása vagy szabályzatok konfigurálásamindezt a saját forgatókönyveidből irányítva.

Továbbá van egy PowerShell modul is, amely lehetővé teszi Ansible modulok automatikus generálását DSC erőforrásokból . Az ötlet az, hogy megvizsgáljuk a DSC erőforrást, létrehozunk egy Ansible modult, amely egyenként leképezi a paramétereit, és úgy használjuk, mintha egy szabványos modul lenne. Ezek a generátorok letölthetnek erőforrásokat a PowerShell Galériából, és tucatnyi modult hozhatnak létre, amelyek tovább bővítik a Windows automatizálási ökoszisztémát az Ansible segítségével.

A DSC-n és az Ansible-en túl: további automatizálási eszközök az Azure-ban

Ha az infrastruktúrád az Azure-ban fut (vagy fog futni), érdemes figyelemmel kísérni a PowerShell DSC-t és az Ansible-t kiegészítő egyéb eszközöket . Nem arról van szó, hogy csak egyet válasszunk, hanem arról, hogy megértsük, hogyan illeszkednek a teljes láncba: infrastruktúra létrehozása, rendszerkonfiguráció, alkalmazástelepítés és folyamatos műveletek.

Az „infrastruktúra mint kód” területén olyan megoldások, mint a Terraform vagy az Azure natív nyelvei (ARM Templates és Bicep), lehetővé teszik hálózatok, virtuális gépek, tárolók és felügyelt szolgáltatások definiálását deklaratív fájlok segítségével. A Terraform a saját HCL nyelvét használja, míg a Bicep leegyszerűsíti a régebbi ARM sablonok szintaxisát, de mindegyik jól integrálható a CI/CD folyamatokba, és kombinálható az Ansible-lel a virtuális gépek konfigurálásához azok létrehozása után.

A fázishoz Linux gépek kezdeti konfigurációjaAzure-támogatások felhő-initamely az első rendszerindításkor szkripteket hajt végre és felhasználókat, csomagokat vagy konfigurációs fájlokat konfigurál. A fájlok #cloud-config, amelyek általában base64-ben vannak kódolva, disztribúciófüggetlenek, és minden disztribúció saját csomagkezelőjére támaszkodnak anélkül, hogy aggódnod kellene.

Az operatív automatizálás területén az Azure Automation érdekes szerepet játszik. Runbookokat (általában PowerShell vagy Python szkripteket) használ , amelyek igény szerint vagy ütemterv szerint futtathatók, mind Azure-erőforrásokon, mind helyszíni környezetekben a Hybrid Runbook Worker használatával. Továbbá egy felügyelt DSC szolgáltatást is kínál , amely lehetővé teszi a konfigurációk közzétételét és a megfelelőség monitorozását egy gépcsoporton keresztül.

Végül, a CI/CD és az alkalmazáséletciklus-kezelő eszközök, mint például az Azure DevOps, a Jenkins, a Chef, a Puppet és a Packer teszik teljessé az ökoszisztémát. Mindegyik lefedi a kirakós egy darabját: a kód fordításától és tesztelésétől kezdve az egyéni gépi képek létrehozásán át a szabályozási megfelelés biztosításáig automatizált tesztelésen keresztül.

Windows frissítések, csomagok és alkalmazáskezelés

Az egyik legfontosabb feladat minden rendszercsapat számára a Windows naprakészen tartása a javításokkal és frissítésekkel . A Microsoft a Windows Update-et és számos vállalati környezetben a Microsoft Configuration Managert (SCCM) is kínálja a telepítés kezeléséhez. Azonban, ha többszöri újraindítás, szoros karbantartási időszakok vagy összetett vezénylési követelmények merülnek fel, ezek a mechanizmusok elégtelennek vagy megbízhatatlannak bizonyulhatnak.

Az Ansible Automation Platform megkönnyíti a frissítések ellenőrzött végrehajtását , integrálódik a Windows Update-tel és automatikusan kezeli a szükséges újraindításokat, így egyetlen feladattal több tucat vagy több száz javítást is telepíthet, miközben megőrzi a csomópontok végső állapotának ellenőrzését.

Az alkalmazások telepítését illetően a Windowsból hiányzik az egységes natív csomagkezelő, mint amilyenek a Linux disztribúciókban találhatók. A Microsoft Store nem automatizált tömeges telepítésekre készült: hiányoznak belőle a kiforrott CLI eszközök, és nagymértékben támaszkodik a grafikus felületre, ami megnehezíti a használatát az automatizált folyamatokban.

Ennek a korlátozásnak a kiküszöbölésére az Ansible olyan modulokat integrál, amelyek lehetővé teszik az alapvető csomagkezelést Windows rendszerben , és mindenekelőtt nagyon jól működik olyan megoldásokkal, mint a Chocolatey vagy a Winget Windows rendszerben , idempotens megközelítést biztosítva, hasonlóan a klasszikus csomagkezelőkhöz. A Chocolatey, a DSC és az Ansible playbookjainak kombinálásával nagyon kevés manuális erőfeszítéssel szabványosíthatja a szerverek vagy a VDI szoftverkatalógusait .

Ha ehhez hozzávesszük a DSC-erőforrások használatát a beállításjegyzék-konfigurációk, szolgáltatások és az alkalmazásokkal kapcsolatos szabályzatok betartatására, akkor a szoftverek életciklusának átfogó automatizálását érheti el a Windows-környezetekben, a kezdeti telepítéstől a konfigurációk megerősítéséig és az időszakos frissítésekig.

Képzés, ajánlott gyakorlatok és bevezetése Windows csapatokban

Sok tisztán Windows-alapú IT-csapatban a kiindulópont továbbra is a grafikus konzolon és varázslókban történő kattintásokon alapuló adminisztráció . Gyakori, hogy több tucat vagy több száz virtuális gép fut VMware vagy Hyper-V alatt, ahol a szerver létrehozási folyamata manuálisan történik. Az automatizálásra való áttérés általában akkor következik be, amikor a csapat valamelyik tagja megunja ugyanazon feladatok ismétlődését, és PowerShell-szkripteket kezd írni.

Ebben az összefüggésben felmerül egy ésszerű kérdés: „Továbbra is használjam a PowerShellt önmagában, váltsak DSC-re, állítsam be az Ansible-t… vagy tegyem meg mindezt egyszerre?” A legpragmatikusabb válasz általában az, hogy kombináljuk őket: kihasználjuk a PowerShell és a DSC meglévő ismereteit , és egyidejűleg bevezetjük az Ansible-t orchestrációs rétegként a szabványosítás és az integrációs képességek növelése érdekében más platformokkal.

Vannak speciális tanfolyamok Windows rendszergazdák számára, amelyek az Ansible-ben a nulláról indulnak, és pontosan erre összpontosítanak: hogyan konfigurálják a Windows rendszereket az Ansible-lel való felügyelethez, hogyan írjanak hatékony playbookokat, hogyan integrálják az Ansible Towert vagy az AWX-et az automatizálások központosított és biztonságos webes felületről történő elindításához, és hogyan használják fel újra a playbookokból származó DSC kódot, hogy ne dobják ki a már elvégzett munkát.

A gyakorlatban sok csapat evolúciós stratégiát alkalmaz: kezdve az egyszerű feladatok (szolgáltatások, szerepkörök, PowerShell modul telepítése) automatizálásával, folytatva a DSC-erőforrásokkal az ismétlődő konfigurációkhoz (IIS, AD, SQL, biztonsági szabályzatok), és fokozatosan integrálva az automatizálást az alkalmazásszállítási folyamatba és az ismétlődő működési feladatokba.

Fontos meghatározni a stílusirányelveket, a forráskód-ellenőrzést, valamint a playbookok és DSC-konfigurációk tesztelését is, hogy az automatizálás valódi „infrastruktúra mint kód” legyen, és ne csak egy maroknyi laza szkript verziókövetés vagy javítások nélkül.

A PowerShell DSC, az Ansible modulok, a WinRM, a Chocolatey és az Azure eszközök kombinálásával egy robusztus ökoszisztéma jön létre, ahol a gépi létrehozás, a részletes konfiguráció, az alkalmazások telepítése és a folyamatos karbantartás már nem manuális RDP-munkamenetekre támaszkodik. Az eredmény egy konzisztensebb, auditálhatóbb és reprodukálhatóbb környezet, ahol a változtatások automatikusan dokumentálódnak a kódban, és az emberi hibák száma drasztikusan csökken.