Avanceret automatisering i Windows med PowerShell DSC og Ansible

Informatec Digital » Ressourcer » Avanceret automatisering i Windows med PowerShell DSC og Ansible

Hvis du arbejder med Windows-infrastruktur, og termer som PowerShell, DSC, Ansible og automatisering lyder bekendte , ved du sikkert allerede, at en effektiv kombination af dem fuldstændig kan transformere den måde, du administrerer servere på. At skifte fra manuelle klik i Windows-guiden til en fuldt deklarativ og gentagelig konfiguration gør hele forskellen mellem konstant at slukke brande og at have et fuldt kontrolleret miljø.

I denne artikel vil vi dykke dybere ned i, hvordan PowerShell Desired State Configuration (DSC) og Ansible passer sammen Hvilken rolle spiller teknologier som WinRM, Azure Automation, Terraform eller cloud-init for at administrere Windows (og Linux) i stor skala, og hvordan kan du udnytte eksisterende DSC-ressourcer fra Ansible takket være modulet? win_dscDu vil se praktiske eksempler, brugsscenarier fra den virkelige verden og kriterier for at beslutte, hvornår du skal bruge native DSC, Ansible-moduler eller andre automatiseringsmetoder.

Oversigt: Windows-automatisering med PowerShell, DSC og Ansible

PowerShell og Ansible deler det samme mål : at automatisere konfigurationen og administrationen af ​​dine systemer på en reproducerbar måde. Forskellen ligger i deres tilgang. DSC er den konfigurationsstyringsplatform, der er integreret i PowerShell, og som er stærkt fokuseret på Windows (selvom den kan fungere med Linux via OMI), mens Ansible er en multifunktionel, tværplatforms automatiseringsmotor, der er designet til at orkestrere hybride og heterogene infrastrukturer fra et enkelt punkt.

Med Red Hat Ansible Automation Platform kan du automatisere Windows-servere uden at installere yderligere agenter, udnytte WinRM eller OpenSSH som forbindelseskanaler og bruge DSC-ressourcer, Ansible-moduler og PowerShell-scripts. Alt dette er organiseret via YAML-playbooks , hvor du definerer den tilstand, som hver vært skal opnå, både på Windows og Linux.

PowerShell Desired State Configuration tilbyder derimod hundredvis af specialiserede ressourcer til konfiguration af næsten alle Windows-komponenter: tjenester, systemfunktioner, IIS, SQL Server, Active Directory, registreringsdatabase, filer osv. Disse ressourcer indkapsler logikken bag at kontrollere og anvende den ønskede tilstand, så du kun behøver at erklære "hvordan du ønsker, at maskinen skal være".

Nøglen er, at du fra Ansible kan bruge disse DSC-ressourcer direkte gennem modulet ansible.windows.win_dscVed at kombinere Ansibles orkestreringskraft med den Windows-specifikke konfigurationsdybde, som DSC tilbyder. På denne måde opnår du Det bedste fra begge verdener uden overlapning.

WinRM og fjernadgang til Windows til Ansible

For at Ansible kan administrere Windows-servere, er det vigtigt at forstå, hvordan WinRM (Windows Remote Management) fungerer . WinRM er Microsofts indbyggede teknologi til fjernadministration baseret på HTTP/HTTPS, og det er standardkanalen, som Ansible bruger til at udføre opgaver på Windows-maskiner.

Det første trin er at konfigurere WinRM korrekt på målværterne og den kontrolnode, hvor Ansible kører. Dette involverer justering af godkendelse, kryptering, tilladelser og ofte håndtering af funktioner som ikke-interaktiv login, hvor kommandoer udstedes uden en aktiv brugersession. Dette ikke-interaktive sessionsmiljø komplicerer opgaver som Windows-opdateringer eller tovejsgodkendelsesscenarier , hvor du har brug for adgang til en anden fjernressource (f.eks. en deling på en anden server).

Fordelen ved at bruge Red Hat Ansible Automation Platform er, at det giver dig mulighed for centralt og sikkert at kode legitimationsoplysninger og godkendelsesmekanismer , hvilket abstraherer håndteringen af ​​disse komplekse sager. Derudover kan platformen også bruge OpenSSH til at få adgang til Windows Server , hvilket bliver mere og mere almindeligt med moderne versioner af Windows.

I praksis giver kombinationen af ​​WinRM, Ansibles legitimationsstyring og DSC-funktioner dig mulighed for at opbygge robuste automatiseringsflows , der kører uovervåget, selv i miljøer med høje sikkerhedsrestriktioner.

PowerShell DSC: Deklarativ konfigurationsplatform

PowerShell Desired State Configuration er en deklarativ konfigurationsstyringsplatform, der er integreret i Windows. Med DSC definerer du i kode, hvordan en maskine skal konfigureres: hvilke roller og funktioner der skal installeres, hvilke tjenester der skal være aktive, hvilke registreringsparametre, hvilke filer eller mapper der skal findes, og så videre.

DSC -konfigurationer beskriver den ønskede tilstand for et sæt noder. Hver administreret maskine kører en Local Configuration Manager (LCM) , som er den motor, der læser disse konfigurationer, kontrollerer den faktiske tilstand og anvender de nødvendige ændringer. Derudover kan du oprette en pull-server , der centraliserer konfigurationerne, og hvorfra noderne opdaterer og rapporterer overholdelse.

DSC er ikke begrænset til Windows: via Open Management Infrastructure ( OMI )-serveren kan det også fungere med Linux-maskiner . Men hvor det virkelig skinner, er det i Windows-miljøer, hvor fællesskabet har udviklet en omfattende samling af specialiserede ressourcer til opgaver så forskellige som konfiguration af IIS, SQL Server eller Active Directory.

En af de store fordele ved DSC er, at den fokuserer på resultatet, ikke trinnene . Du deklarerer tilstanden (for eksempel "denne funktion skal være til stede, denne tjeneste er startet, denne registerværdi er konfigureret"), og motoren sørger for at nå dertil, kontrollere og rette, hvis noget afviger over tid.

Hvordan Ansible passer sammen med DSC: win_dsc-modul og orkestrering

I teorien kunne man bruge DSC isoleret, men i praksis er det meget mere nyttigt, når det kombineres med Ansible som et orkestreringslag . Ansible håndterer lagerstyring, ordnet opgaveudførelse, koordinering mellem systemer og integration med CI/CD-pipelines, mens DSC leverer de specifikke ressourcer til at manipulere Windows' indre funktioner.

Modulet ansible.windows.win_dsc Det er broen mellem de to verdener. Dette modul påkalder en DSC-ressourceklasse på den ønskede Windows-vært. I playbooken skal du kun definere:

• ressourcenavn: navnet på den DSC-ressource, du vil bruge (for eksempel, File, WindowsFeature, Service, Registry, xWebsiteOsv.).
• De resterende parametre, som svarer direkte til egenskaber for DSC-ressourcen (f.eks. DestinationPath, Ensure, Name, StateOsv.).

Når Ansible udfører opgaven, oversætter den disse parametre til en midlertidig DSC-konfiguration, anvender den på værten og indsamler resultatet (inklusive om der er sket ændringer). Dette giver dig mulighed for at genbruge hele DSC-ressourcekataloget uden at skulle skrive specifikke Ansible-moduler for hver sag.

Nedenfor følger udførelsesflowet et ensartet mønster: Ansible sender opgaven via WinRM, Windows-systemet genererer en DSC-konfiguration baseret på parametrene, og DSC-motoren kalder først Test-TargetResource for at kontrollere den aktuelle status, og hvis den registrerer forskelle, udføres den Set-TargetResource for at anvende ændringerne. Ansible modtager en rapport, der angiver, om noget er blevet ændret, og eventuelle relevante meddelelser til fejlfinding.

Denne kobling er især effektiv, når du kombinerer Ansible native moduler til Windows (f.eks win_file, win_service, win_regedit, win_psmoduleosv.) med DSC-ressourcer til de områder, hvor DSC tilbyder bedre muligheder eller større funktionel dækning.

Typer af DSC-egenskaber og hvordan man kortlægger dem i Ansible

Hver DSC-ressource definerer et sæt egenskaber med en velspecificeret type (streng, boolsk, arrays, komplekse PowerShell-typer osv.). Når du arbejder fra Ansible, skal du oversætte disse egenskaber til YAML-syntaks Vedligeholdelse af den korrekte type. Modulet win_dsc Den udfører en masse automatisk konverteringsarbejde, men det er værd at kende til nogle nøgleeksempler.

For simple typer som o , kortlægningen er ligetil: citationsstrenge og små booleske værdier i YAML-stil (true, false), undgår at skrive $true o $false som du ville gøre i PowerShell. For egenskaber af typen , det sædvanlige er at bruge en ISO 8601-format (f.eks. "2019-02-22T13:57:31Z") og sørg for, at værdien er serialiseret som en streng, ved at omgive den med anførselstegn.

Typeegenskaber De er et specialtilfælde. Da denne type ikke kan serialiseres direkte til JSON, bruger Ansible en konvention: du definerer to parametre adskilt af et suffiks. _username y _password (f.eks. Credential_username y Credential_passwordModulet genererer objektet. PSCredential på den eksterne vært baseret på disse to værdier.

For typer Disse repræsenterer ordbøger baseret på en brugerdefineret ressourceklasse; i YAML udtrykkes de som et nøgle-værdi-kort. Du bør gennemgå ressourcedokumentationen (normalt i filen). <nombre_recurso>.schema.mof) for at vide, hvilke nøgler der er tilladte, og hvilken type hver enkelt er. I praksis er de defineret som indlejrede ordbøger inden for modulet win_dsc.

Endelig typeegenskaberne og arraysene (], ]osv.) er repræsenteret som ordbøger eller YAML-lister. For arrays anbefales det at bruge en autentisk YAML-liste og ikke en streng med kommaseparerede værdier, da dette undgår manuel parsing og reducerer sandsynligheden for subtile fejl.

Praktiske eksempler på brug af DSC fra Ansible

Når du mestrer modulets grundlæggende struktur win_dscDu kan kombinere ressourcer for at bygge meget omfattende konfigurationshåndbøgerNogle almindelige scenarier, der fungerer godt med DSC, er:

• Fil- og mappehåndtering med ressourcen FileOprettelse af mappestrukturer, implementering af konfigurationsfiler med specifikt indhold, sikring af at bestemte elementer findes eller er blevet fjernet.
• Installation af Windows-roller og -funktioner med WindowsFeatureIIS, .NET Framework, Telnet-klient, administrationsværktøjer osv.
• Servicekontrol med ressourcen Servicestatus (startet/stoppet), starttype (automatisk, manuel), servicekonto osv.
• Indstillinger for registreringsdatabasen med Registrysikkerhedsværdier, ventetider, protokolparametre, systemhærdning.
• Avancerede IIS-indstillinger med moduler som f.eks. xWebAdministration og ressourcer xWebsite, xWebAppPoolOsv

I alle disse tilfælde beskriver Ansible blot parametrene for DSC-ressourcen, mens DSC-motoren er ansvarlig for at kontrollere og anvende staten. Desuden, startende med Ansible 2.8, modulet win_dsc Den validerer automatisk parametre i forhold til ressourcedefinitionen: Hvis du bruger et forkert egenskabsnavn, lader et obligatorisk felt være tomt eller angiver en værdi uden for området, vil opgaven mislykkes med en klar fejl.

Hvis du kører Ansible med en højt niveau af ordgængelighed (for eksempel -vvv)Outputtet vil indeholde detaljerede oplysninger i invocation.module_args om de anvendte muligheder og dem, der var tilgængelige, hvilket er meget nyttigt både til fejlfinding og til at finde ud af, hvilke felter du kan konfigurere i hver ressource.

Bemærk også, at du kan bruge parameteren PsDscRunAsCredential Dette gør det muligt for DSC-ressourcen at køre som en anden bruger end systemet. Dette er meget nyttigt til at få adgang til registreringsdatabasen. HKEY_CURRENT_USER af den bruger, som Ansible er forbundet til, eller til scenarier, hvor du har brug for en specifik sikkerhedskontekst.

Brugerdefinerede DSC-ressourcer og PowerShell-galleri

Windows-integrerede DSC-ressourcer dækker mange behov, men den virkelige styrke kommer, når du bruger ressourcer, der er udgivet i PowerShell Gallery eller tredjepartspakker. Der er moduler til alt: Active Directory, SQL Server, avanceret IIS, sikkerhedspolitikker og meget mere.

Du kan finde tilgængelige ressourcer med cmdlet'en Find-DscResource eller ved at gennemse PowerShell-galleriet direkte. Når du har identificeret det modul, du er interesseret i (f.eks. xWebAdministration o SqlServerDsc), har du flere måder at installere det på dine værter:

• Manuel installation med Install-Module fra PowerShell på målserveren.
• Brug af Ansible-modulet win_psmodule for at automatisere installationen fra PowerShell Gallery.
• Download på forhånd og kopier i hånden til servere, der ikke har internetadgang, og gemmer modulet i en mappe, der er inkluderet i PSModulePath (f.eks. C:\Program Files\WindowsPowerShell\Modules).

Når man arbejder i afkoblede miljøer, er en almindelig strategi at bruge en server med internetadgang til gem modulet med Save-Module i en lokal sti, og kopier derefter den mappe til produktionsmaskinerne. Konfigurer derefter PSModulePath Det kan også justeres med Ansible, for eksempel med modulet win_pathså PowerShell kan registrere disse ressourcer uden manuel indgriben.

Når modulet er installeret, win_dsc kan kalde enhver ressource fra disse pakker blot at angive navnet i resource_nameDette åbner døren for genbrug af veletablerede løsninger, såsom Active Directory DSC-moduler, til opgaver som Opret brugere, OU'er, grupper eller konfigurer politikkeralt administreret fra dine playbooks.

Derudover er der endda et PowerShell-modul, der giver dig mulighed for automatisk at generere Ansible-moduler fra DSC-ressourcer . Ideen er at inspicere DSC-ressourcen, oprette et Ansible-modul, der kortlægger dens parametre én efter én, og bruge det, som om det var et standardmodul. Disse generatorer kan downloade ressourcer fra PowerShell-galleriet og oprette snesevis af moduler, der yderligere udvider Windows-automatiseringsøkosystemet med Ansible.

Ud over DSC og Ansible: andre automatiseringsværktøjer i Azure

Hvis din infrastruktur kører (eller vil køre) på Azure, er det værd at holde øje med andre værktøjer, der supplerer PowerShell DSC og Ansible . Det handler ikke om at vælge kun ét, men om at forstå, hvordan de passer ind i den overordnede kæde: oprettelse af infrastruktur, systemkonfiguration, applikationsudrulning og løbende drift.

Inden for "infrastruktur som kode" giver løsninger som Terraform eller Azures native sprog (ARM Templates og Bicep) dig mulighed for at definere netværk, virtuelle maskiner, lagring og administrerede tjenester ved hjælp af deklarative filer. Terraform bruger sit eget HCL-sprog, mens Bicep forenkler syntaksen i ældre ARM-skabeloner, men alle integreres godt i CI/CD-pipelines og kan kombineres med Ansible til konfiguration af virtuelle maskiner, efter de er oprettet.

For fasen af indledende konfiguration af Linux-maskinerAzure understøtter cloud-initsom udfører scripts og konfigurerer brugere, pakker eller konfigurationsfiler ved første opstart. Filerne #cloud-config, normalt kodet i base64, er distributionsuafhængige og afhænger af hver distributions egen pakkehåndtering uden at du behøver at bekymre dig.

Inden for driftsautomatisering spiller Azure Automation en interessant rolle. Det bruger runbooks (generelt PowerShell- eller Python-scripts), der kan udføres on-demand eller efter en tidsplan, både på Azure-ressourcer og i lokale miljøer ved hjælp af Hybrid Runbook Worker. Derudover tilbyder det en administreret DSC- tjeneste , der giver dig mulighed for at udgive konfigurationer og overvåge compliance på tværs af et sæt maskiner.

Endelig fuldender CI/CD og applikationslivscyklusstyringsværktøjer som Azure DevOps, Jenkins, Chef, Puppet og Packer økosystemet. Hvert værktøj dækker en brik i puslespillet: fra kompilering og test af kode til generering af brugerdefinerede maskinbilleder eller sikring af overholdelse af lovgivningen gennem automatiseret testning.

Windows-opdateringer, pakker og programstyring

En af de vigtigste opgaver for ethvert systemteam er at holde Windows opdateret med sine programrettelser og opdateringer . Microsoft tilbyder Windows Update og, i mange virksomhedsmiljøer, Microsoft Configuration Manager (SCCM) til at administrere implementeringen. Men når flere genstarter, stramme vedligeholdelsesvinduer eller komplekse orkestreringskrav kommer i spil, kan disse mekanismer være utilstrækkelige eller vise sig upålidelige.

Ansible Automation Platform muliggør kontrolleret udførelse af opdateringer , integrerer med Windows Update og administrerer automatisk nødvendige genstarter, så en enkelt opgave kan installere snesevis eller hundredvis af patches, samtidig med at kontrollen over nodernes endelige tilstand bevares.

Hvad angår programinstallation, mangler Windows en samlet, indbygget pakkehåndtering som dem, der findes i Linux-distributioner. Microsoft Store er ikke designet til automatiserede masseudrulninger: den mangler modne CLI-værktøjer og er i høj grad afhængig af den grafiske brugerflade, hvilket gør den vanskelig at bruge i automatiserede pipelines.

For at imødegå denne begrænsning integrerer Ansible moduler, der muliggør grundlæggende pakkehåndtering i Windows , og frem for alt fungerer det rigtig godt med løsninger som Chocolatey eller Winget i Windows , hvilket giver en idempotent tilgang, der ligner en klassisk pakkehåndtering. Ved at kombinere Chocolatey-, DSC- og Ansible-playbooks kan du standardisere softwarekataloger til servere eller VDI med meget lidt manuel indsats.

Hvis du dertil tilføjer brugen af ​​DSC-ressourcer til at håndhæve registreringsdatabasekonfigurationer, tjenester og politikker relateret til disse applikationer, opnår du omfattende automatisering af softwarelivscyklussen i dine Windows-miljøer, fra den første installation til hærdning af konfigurationer og periodiske opdateringer.

Træning, bedste praksis og implementering i Windows-teams

I mange rent Windows-baserede IT-teams er udgangspunktet stadig administration baseret på klik i den grafiske konsol og guider. Det er almindeligt at have snesevis eller hundredvis af virtuelle maskiner, der kører på VMware eller Hyper-V, hvor serveroprettelsesprocessen udføres manuelt. Skiftet til automatisering kommer normalt, når en person i teamet bliver træt af at gentage de samme opgaver og begynder at skrive PowerShell-scripts.

I denne sammenhæng opstår et rimeligt spørgsmål: "Skal jeg fortsætte med at bruge PowerShell alene, skifte til DSC, konfigurere Ansible ... eller gøre det hele på én gang?" Det mest pragmatiske svar er normalt at kombinere dem: udnytte eksisterende viden om PowerShell og DSC og samtidig introducere Ansible som et orkestreringslag for at opnå standardiserings- og integrationsmuligheder med andre platforme.

Der findes specifikke kurser for Windows-administratorer , der starter fra bunden i Ansible og fokuserer netop på dette: hvordan man konfigurerer Windows-systemer til at blive administreret med Ansible, hvordan man skriver effektive playbooks, hvordan man integrerer Ansible Tower eller AWX for at starte automatiseringer fra en centraliseret og sikker webgrænseflade, og hvordan man genbruger DSC-kode fra disse playbooks for ikke at smide det allerede udførte arbejde væk.

I praksis anvender mange teams en evolutionær strategi: de starter med at automatisere simple opgaver (tjenester, roller, installation af PowerShell-moduler), fortsætter med DSC-ressourcer til gentagne konfigurationer (IIS, AD, SQL, sikkerhedspolitikker) og integrerer gradvist automatisering i applikationsleveringspipelinen og tilbagevendende driftsopgaver.

Det er også vigtigt at definere stilretningslinjer, kildekodekontrol og test af playbooks og DSC-konfigurationer, så automatisering bliver ægte "infrastruktur som kode" og ikke blot en håndfuld løse scripts uden versionskontrol eller revisioner.

Ved at kombinere PowerShell DSC, Ansible-moduler, WinRM, Chocolatey og Azure-værktøjer skabes et robust økosystem, hvor maskinoprettelse, detaljeret konfiguration, applikationsimplementering og løbende vedligeholdelse ikke længere er afhængig af manuelle RDP-sessioner. Resultatet er et mere konsistent, auditerbart og reproducerbart miljø, hvor ændringer automatisk dokumenteres i kode, og menneskelige fejl reduceres drastisk.