Napredna avtomatizacija v sistemu Windows s PowerShell DSC in Ansible

Informatec Digital » Viri » Napredna avtomatizacija v sistemu Windows s PowerShell DSC in Ansible

Če delate z infrastrukturo sistema Windows in se vam izrazi, kot so PowerShell, DSC, Ansible in avtomatizacija, slišijo znani , verjetno že veste, da lahko njihova učinkovita kombinacija popolnoma spremeni način upravljanja strežnikov. Prehod z ročnih klikov v čarovniku za Windows na popolnoma deklarativno in ponovljivo konfiguracijo naredi vso razliko med nenehnim gašenjem požarov in popolnoma nadzorovanim okoljem.

V tem članku se bomo podrobneje poglobili v to, kako Konfiguracija želenega stanja PowerShella (DSC) in Ansible se ujemata Kakšno vlogo imajo tehnologije, kot so WinRM, Azure Automation, Terraform ali cloud-init, za upravljanje sistema Windows (in Linux) v velikem obsegu in kako lahko s pomočjo modula izkoristite obstoječe vire DSC iz Ansiblea? win_dscVideli boste praktične primere, primere uporabe iz resničnega sveta in merila za odločanje o tem, kdaj uporabiti izvorni DSC, module Ansible ali druge avtomatizacijske pristope.

Pregled: Avtomatizacija sistema Windows s PowerShellom, DSC in Ansibleom

PowerShell in Ansible imata isti cilj : avtomatizirati konfiguracijo in upravljanje vaših sistemov na ponovljiv način. Razlika je v njunem pristopu. DSC je platforma za upravljanje konfiguracije, integrirana v PowerShell, močno osredotočena na Windows (čeprav lahko deluje tudi z Linuxom prek OMI), medtem ko je Ansible večnamenski, medplatformski avtomatizacijski mehanizem, zasnovan za orkestriranje hibridnih in heterogenih infrastruktur z ene same točke.

Z avtomatizacijsko platformo Red Hat Ansible lahko avtomatizirate strežnike Windows brez nameščanja dodatnih agentov, pri čemer kot povezovalne kanale uporabljate WinRM ali OpenSSH ter vire DSC, module Ansible in skripte PowerShell. Vse to je organizirano prek priročnikov YAML , kjer določite stanje, ki ga mora doseči vsak gostitelj, tako v sistemu Windows kot Linux.

PowerShell Desired State Configuration pa ponuja na stotine specializiranih virov za konfiguriranje skoraj vseh komponent sistema Windows: storitev, sistemskih funkcij, IIS, SQL Server, Active Directory, registra, datotek itd. Ti viri zajemajo logiko preverjanja in uporabe želenega stanja, zato morate le določiti, »kako želite, da je računalnik«.

Ključno je, da lahko iz Ansiblea te DSC vire uporabljate neposredno prek modula ansible.windows.win_dscZdruževanje orkestracijske moči Ansiblea z globino konfiguracije, specifično za Windows, ki jo ponuja DSC. Na ta način dosežete Najboljše iz obeh svetov brez podvajanja prizadevanj.

WinRM in oddaljeni dostop do sistema Windows za Ansible

Da bi Ansible lahko upravljal strežnike Windows, je bistveno razumeti, kako deluje WinRM (Windows Remote Management) . WinRM je Microsoftova vgrajena tehnologija za oddaljeno upravljanje, ki temelji na HTTP/HTTPS, in je standardni kanal, ki ga Ansible uporablja za izvajanje nalog v računalnikih z operacijskim sistemom Windows.

Prvi korak je pravilna konfiguracija WinRM na ciljnih gostiteljih in nadzornem vozlišču, kjer se izvaja Ansible. To vključuje prilagajanje preverjanja pristnosti, šifriranja, dovoljenj in pogosto delo s funkcijami, kot je neinteraktivna prijava, kjer se ukazi izdajajo brez aktivne uporabniške seje. To neinteraktivno okolje seje otežuje naloge, kot so posodobitve sistema Windows ali scenariji dvosmerne avtentikacije , kjer morate dostopati do drugega oddaljenega vira (na primer do skupne rabe na drugem strežniku).

Prednost uporabe platforme Red Hat Ansible Automation Platform je, da omogoča centralno in varno kodiranje poverilnic in mehanizmov za preverjanje pristnosti , s čimer se abstrahira obravnava teh zapletenih primerov. Poleg tega lahko platforma uporablja tudi OpenSSH za dostop do sistema Windows Server , kar postaja vse pogostejše pri sodobnih različicah sistema Windows.

V praksi vam kombinacija WinRM, upravljanja poverilnic Ansible in zmogljivosti DSC omogoča izgradnjo robustnih avtomatizacijskih tokov , ki delujejo brez nadzora, tudi v okoljih z visokimi varnostnimi omejitvami.

PowerShell DSC: Deklarativna konfiguracijska platforma

Konfiguracija želenega stanja PowerShella je deklarativna platforma za upravljanje konfiguracij, integrirana v sistem Windows. Z DSC v kodi določite, kako naj bo računalnik konfiguriran: katere vloge in funkcije naj bodo nameščene, katere storitve naj bodo aktivne, kateri parametri registra, katere datoteke ali imeniki naj obstajajo in tako naprej.

Konfiguracije DSC opisujejo želeno stanje za niz vozlišč. Vsak upravljani računalnik izvaja Lokalni upravitelj konfiguracij (LCM) , ki je mehanizem, ki bere te konfiguracije, preverja dejansko stanje in uporablja potrebne spremembe. Poleg tega lahko nastavite strežnik za prevzem , ki centralizira konfiguracije in s katerega vozlišča posodabljajo in poročajo o skladnosti.

DSC ni omejen na Windows: prek strežnika Open Management Infrastructure ( OMI ) lahko deluje tudi z računalniki Linux . Vendar pa resnično sije v okoljih Windows, kjer je skupnost razvila obsežno zbirko specializiranih virov za naloge, ki so tako raznolike, kot so konfiguriranje IIS, SQL Server ali Active Directory.

Ena od velikih prednosti DSC je, da se osredotoča na rezultat, ne na korake . Deklarira se stanje (na primer »ta funkcija mora biti prisotna, ta storitev zagnana, ta vrednost registra konfigurirana«) in mehanizem poskrbi za to, da pride do tja, preveri in popravi morebitna odstopanja sčasoma.

Kako se Ansible ujema z DSC: modul win_dsc in orkestracija

Teoretično bi lahko DSC uporabljali ločeno, vendar je v praksi veliko bolj uporaben v kombinaciji z Ansibleom kot orkestracijsko plastjo . Ansible obravnava inventar, urejeno izvajanje nalog, koordinacijo med sistemi in integracijo s cevovodi CI/CD, medtem ko DSC zagotavlja specifične vire za manipulacijo notranjega delovanja sistema Windows.

Modul ansible.windows.win_dsc Je most med obema svetovoma. Ta modul sproži Razred virov DSC na ciljnem gostitelju sistema Windows. V priročniku morate definirati le:

• ime_vira: ime vira DSC, ki ga želite uporabiti (na primer, File, WindowsFeature, Service, Registry, xWebsite, Itd.)
• Preostali parametri, ki neposredno ustrezajo lastnosti vira DSC (npr. DestinationPath, Ensure, Name, State, Itd.)

Ko Ansible izvede nalogo, te parametre pretvori v začasno konfiguracijo DSC, jo uporabi za gostitelja in zbere rezultat (vključno s tem, ali so se pojavile kakršne koli spremembe). To vam omogoča ponovno uporabo celotnega kataloga virov DSC, ne da bi morali za vsak primer pisati posebne module Ansible.

Spodaj poteka izvajanje po doslednem vzorcu: Ansible pošlje nalogo prek WinRM, sistem Windows ustvari konfiguracijo DSC na podlagi parametrov, mehanizem DSC pa najprej pokliče Test-TargetResource preveriti trenutno stanje in če zazna razlike, izvesti Set-TargetResource za uveljavitev sprememb. Ansible prejme poročilo, ki navaja, ali je bilo kaj spremenjeno, in vsa ustrezna sporočila za odpravljanje napak.

Ta povezava je še posebej močna, če združite Izvorni moduli Ansible za Windows (kot win_file, win_service, win_regedit, win_psmoduleitd.) z viri DSC za tista področja, kjer DSC ponuja boljše možnosti ali večjo funkcionalno pokritost.

Vrste lastnosti DSC in kako jih preslikati v Ansibleu

Vsak vir DSC definira niz lastnosti z dobro določen tip (niz, logične vrednosti, polja, kompleksni tipi PowerShell itd.). Pri delu iz Ansiblea morate te lastnosti prevesti v Sintaksa YAML Vzdrževanje pravilnega tipa. Modul win_dsc Opravi veliko samodejne pretvorbe, vendar je vredno poznati nekaj ključnih primerov.

Za preproste tipe, kot so o , preslikava je preprosta: nizi v narekovajih in male logične vrednosti v slogu YAML (true, false), izogibanje pisanju $true o $false kot bi to storili v PowerShellu. Za lastnosti tipa , običajna stvar je uporaba Oblika ISO 8601 (npr. "2019-02-22T13:57:31Z") in se prepričajte, da je vrednost serializirana kot niz, tako da jo obdate z narekovaji.

Lastnosti tipa So poseben primer. Ker te vrste ni mogoče neposredno serializirati v JSON, Ansible uporablja konvencijo: definirate dva parametra, ločena s pripono. _username y _password (npr. Credential_username y Credential_passwordModul generira objekt. PSCredential na oddaljenem gostitelju na podlagi teh dveh vrednosti.

Za vrste Ti predstavljajo slovarje, ki temeljijo na razredu virov po meri; v YAML so izraženi kot zemljevid ključ-vrednost. Pregledati morate dokumentacijo virov (običajno v datoteki). <nombre_recurso>.schema.mof) vedeti, kateri ključi so dovoljeni in katere vrste je vsak. V praksi so definirani kot vgnezdeni slovarji znotraj modula win_dsc.

Končno, lastnosti tipa in polja (], ]itd.) so predstavljeni kot slovarji ali seznami YAML. Za polja je priporočljiva uporaba avtentičen seznam YAML in ne niza z vrednostmi, ločenimi z vejicami, ker se s tem izognemo ročnemu razčlenjevanju in zmanjšamo verjetnost subtilnih napak.

Praktični primeri uporabe DSC iz Ansiblea

Ko osvojite osnovno strukturo modula win_dscZdružujete lahko vire za gradnjo zelo obsežni priročniki za konfiguracijoNekaj ​​pogostih scenarijev, ki dobro delujejo z DSC, je:

• Upravljanje datotek in imenikov z virom Fileustvarjanje struktur map, namestitev konfiguracijskih datotek z določeno vsebino, zagotavljanje obstoja ali odstranitve določenih elementov.
• Namestitev vlog in funkcij sistema Windows z WindowsFeatureIIS, .NET Framework, odjemalec Telnet, orodja za skrbništvo itd.
• Nadzor storitev z virom Service: stanje (zagnano/ustavljeno), vrsta zagona (samodejni, ročni), servisni račun itd.
• Nastavitve registra z Registryvarnostne vrednosti, čakalni časi, parametri protokola, utrjevanje sistema.
• Napredne nastavitve IIS-a z moduli, kot so xWebAdministration in virov xWebsite, xWebAppPool, Itd

V vseh teh primerih Ansible preprosto opiše parametre vira DSC, medtem ko Motor DSC je odgovoren za preverjanje in uporabo stanje. Poleg tega, začenši z Ansible 2.8, modul win_dsc Samodejno preveri parametre glede na definicijo vira: če uporabite napačno ime lastnosti, pustite obvezno polje prazno ali posredujete vrednost izven obsega, bo naloga spodletela z jasno napako.

Če zaženete Ansible z visoka raven besednosti (npr. -vvv)Izhod bo vključeval podrobne informacije v invocation.module_args o uporabljenih možnostih in tistih, ki so bile na voljo, kar je zelo koristno tako za odpravljanje napak kot za odkrivanje polj, ki jih lahko konfigurirate v posameznem viru.

Upoštevajte tudi, da lahko uporabite parameter PsDscRunAsCredential To omogoča, da se vir DSC izvaja kot drug uporabnik kot sistem. To je zelo uporabno za dostop do registracijskega panja. HKEY_CURRENT_USER uporabnika, s katerim je Ansible povezan, ali za scenarije, kjer potrebujete določen varnostni kontekst.

Prilagojeni viri DSC in galerija PowerShell

V sistem Windows integrirani viri DSC pokrivajo številne potrebe, prava moč pa se pokaže, ko uporabljate vire, objavljene v galeriji PowerShell ali paketih drugih ponudnikov. Na voljo so moduli za vse: Active Directory, SQL Server, napredni IIS, varnostne pravilnike in drugo.

Razpoložljive vire lahko odkrijete z ukazom »cmdlet« Find-DscResource ali z neposrednim brskanjem po galeriji PowerShell. Ko izberete modul, ki vas zanima (na primer xWebAdministration o SqlServerDsc), imate na voljo več načinov za namestitev na vaše gostitelje:

• Ročna namestitev z Install-Module iz PowerShella na ciljnem strežniku.
• Uporaba modula Ansible win_psmodule za avtomatizacijo namestitve iz galerije PowerShell.
• Prenesite vnaprej in kopirajte ročno na strežnike, ki nimajo dostopa do interneta, shranjevanje modula v imenik, ki je vključen v PSModulePath (npr. C:\Program Files\WindowsPowerShell\Modules).

Pri delu v nepovezanih okoljih je običajna strategija uporaba strežnika z dostopom do interneta shranite modul z Save-Module v lokalni poti in nato kopirajte ta imenik na produkcijske stroje. Po tem konfigurirajte PSModulePath Prilagodi se lahko tudi z Ansibleom, na primer z modulom win_pathtako da lahko PowerShell zazna te vire brez ročnega posredovanja.

Ko je modul nameščen, win_dsc lahko pokliče kateri koli vir iz teh paketov preprosto navedbo imena resource_nameTo odpira vrata ponovni uporabi uveljavljenih rešitev, kot so moduli Active Directory DSC, za naloge, kot so ustvarjanje uporabnikov, organizacijskih enot, skupin ali konfiguriranje pravilnikovvse upravljano iz vaših priročnikov.

Poleg tega obstaja celo modul PowerShell, ki omogoča samodejno generiranje modulov Ansible iz virov DSC . Ideja je, da pregledate vir DSC, ustvarite modul Ansible, ki preslika njegove parametre enega za drugim, in ga uporabite, kot da bi bil standardni modul. Ti generatorji lahko prenesejo vire iz galerije PowerShell in ustvarijo na desetine modulov, ki še dodatno širijo ekosistem avtomatizacije sistema Windows z Ansible.

Onkraj DSC in Ansible: druga orodja za avtomatizacijo v Azureju

Če vaša infrastruktura deluje (ali bo delovala) v okolju Azure, je vredno biti pozoren na druga orodja, ki dopolnjujejo PowerShell DSC in Ansible . Ne gre za izbiro samo enega, temveč za razumevanje, kako se ta orodja vklapljajo v celotno verigo: ustvarjanje infrastrukture, konfiguracija sistema, uvajanje aplikacij in tekoče delovanje.

Na področju »infrastrukture kot kode« rešitve, kot sta Terraform ali izvorni jeziki Azure (predloge ARM in Bicep), omogočajo definiranje omrežij, virtualnih strojev, shranjevanja in upravljanih storitev z uporabo deklarativnih datotek. Terraform uporablja svoj jezik HCL, medtem ko Bicep poenostavlja sintakso starejših predlog ARM, vendar se vse dobro integrirajo v cevovode CI/CD in jih je mogoče kombinirati z Ansible za konfiguriranje virtualnih strojev po njihovi izdelavi.

Za fazo začetna konfiguracija Linux strojevAzure podpira oblak-initki izvaja skripte in konfigurira uporabnike, pakete ali konfiguracijske datoteke ob prvem zagonu. Datoteke #cloud-config, običajno kodirani v base64, so neodvisni od distribucije in se zanašajo na lastnega upravitelja paketov vsake distribucije, ne da bi vam bilo treba skrbeti.

Na področju operativne avtomatizacije ima Azure Automation zanimivo vlogo. Uporablja runbooke (običajno skripte PowerShell ali Python), ki jih je mogoče izvajati na zahtevo ali po urniku, tako v virih Azure kot v lokalnih okoljih z uporabo Hybrid Runbook Worker. Poleg tega ponuja upravljano storitev DSC , ki omogoča objavljanje konfiguracij in spremljanje skladnosti v naboru naprav.

Končno ekosistem dopolnjujejo orodja za upravljanje CI/CD in življenjskega cikla aplikacij, kot so Azure DevOps, Jenkins, Chef, Puppet in Packer . Vsako od njih pokriva del sestavljanke: od prevajanja in testiranja kode do ustvarjanja slik strojev po meri ali zagotavljanja skladnosti s predpisi z avtomatiziranim testiranjem.

Posodobitve, paketi in upravljanje aplikacij za Windows

Ena najpomembnejših nalog katere koli sistemske ekipe je posodabljanje sistema Windows s popravki in posodobitvami . Microsoft ponuja Windows Update in v mnogih poslovnih okoljih tudi Microsoft Configuration Manager (SCCM) za upravljanje uvajanja. Ko pa pride do večkratnih ponovnih zagonov, kratkih vzdrževalnih časov ali kompleksnih zahtev za orkestracijo, lahko ti mehanizmi odpovedo ali se izkažejo za nezanesljive.

Platforma za avtomatizacijo Ansible omogoča nadzorovano izvajanje posodobitev , integracijo s storitvijo Windows Update in samodejno upravljanje potrebnih ponovnih zagonov, tako da lahko ena sama naloga namesti na desetine ali stotine popravkov, hkrati pa ohrani nadzor nad končnim stanjem vozlišč.

Kar zadeva namestitev aplikacij, Windows nima enotnega izvornega upravitelja paketov, kot so tisti v distribucijah Linuxa. Trgovina Microsoft Store ni zasnovana za avtomatizirano množično uvajanje: nima zrelih orodij CLI in se močno zanaša na grafični vmesnik, zaradi česar ga je težko uporabljati v avtomatiziranih cevovodih.

Da bi odpravili to omejitev, Ansible integrira module, ki omogočajo osnovno upravljanje paketov v sistemu Windows , in predvsem zelo dobro deluje z rešitvami, kot sta Chocolatey ali Winget v sistemu Windows , kar zagotavlja idempotenten pristop, podoben klasičnemu upravljalniku paketov. Z združevanjem priročnikov Chocolatey, DSC in Ansible lahko standardizirate kataloge programske opreme za strežnike ali VDI z zelo malo ročnega napora.

Če k temu dodate še uporabo virov DSC za uveljavljanje konfiguracij registra, storitev in pravilnikov, povezanih s temi aplikacijami, dosežete celovito avtomatizacijo življenjskega cikla programske opreme v vaših okoljih Windows, od začetne namestitve do konfiguracij utrjevanja in rednih posodobitev.

Usposabljanje, najboljše prakse in uvajanje v ekipah sistema Windows

V mnogih IT-ekipah, ki temeljijo izključno na sistemu Windows, je izhodišče še vedno administracija, ki temelji na klikih v grafični konzoli in čarovnikih. Pogosto se na VMware ali Hyper-V izvajajo desetine ali stotine virtualnih strojev, kjer se postopek ustvarjanja strežnika izvaja ročno. Prehod na avtomatizacijo običajno nastopi, ko se nekdo v ekipi naveliča ponavljanja istih nalog in začne pisati skripte PowerShell.

V tem kontekstu se postavlja smiselno vprašanje: »Ali naj še naprej uporabljam PowerShell samostojno, preidem na DSC, nastavim Ansible ... ali naredim vse naenkrat?« Najbolj pragmatičen odgovor je običajno kombinacija obeh: izkoristiti obstoječe znanje o PowerShellu in DSC ter hkrati uvesti Ansible kot orkestracijsko plast, da bi pridobili na zmogljivostih standardizacije in integracije z drugimi platformami.

Za skrbnike sistema Windows obstajajo posebni tečaji , ki se začnejo iz nič v Ansibleu in se osredotočajo prav na to: kako konfigurirati sisteme Windows za upravljanje z Ansibleom, kako napisati učinkovite priročnike, kako integrirati Ansible Tower ali AWX za zagon avtomatizacije iz centraliziranega in varnega spletnega vmesnika ter kako ponovno uporabiti kodo DSC iz teh priročnikov, da ne bi zavrgli že opravljenega dela.

V praksi številne ekipe sprejmejo evolucijsko strategijo: začnejo z avtomatizacijo preprostih nalog (storitve, vloge, namestitev modulov PowerShell), nadaljujejo z viri DSC za ponavljajoče se konfiguracije (IIS, AD, SQL, varnostne politike) in postopoma integrirajo avtomatizacijo v cevovod za dostavo aplikacij in ponavljajoče se operativne naloge.

Pomembno je tudi opredeliti slogovne smernice, nadzor izvorne kode ter testiranje playbookov in konfiguracij DSC, tako da avtomatizacija postane prava »infrastruktura kot koda« in ne le peščica ohlapnih skript brez nadzora različic ali revizij.

Z združevanjem PowerShell DSC, modulov Ansible, WinRM, Chocolatey in orodij Azure se ustvari robusten ekosistem, kjer ustvarjanje strojev, podrobna konfiguracija, uvajanje aplikacij in tekoče vzdrževanje niso več odvisni od ročnih sej RDP. Rezultat je bolj dosledno, pregledno in ponovljivo okolje, kjer se spremembe samodejno dokumentirajo v kodi, človeške napake pa so drastično zmanjšane.