Geavanceerde automatisering in Windows met PowerShell DSC en Ansible

Informatic Digital » Middelen » Geavanceerde automatisering in Windows met PowerShell DSC en Ansible

Als je met Windows-infrastructuur werkt en termen als PowerShell, DSC, Ansible en automatisering je bekend voorkomen , weet je waarschijnlijk al dat een effectieve combinatie ervan de manier waarop je servers beheert volledig kan veranderen. De overstap van handmatig klikken in de Windows-wizard naar een volledig declaratieve en herhaalbare configuratie maakt het verschil tussen constant brandjes blussen en een volledig gecontroleerde omgeving.

In dit artikel gaan we dieper in op hoe PowerShell Desired State Configuration (DSC) en Ansible vullen elkaar perfect aan. Welke rol spelen technologieën zoals WinRM, Azure Automation, Terraform of cloud-init bij het grootschalig beheren van Windows (en Linux), en hoe kunt u bestaande DSC-resources van Ansible benutten dankzij de module? win_dscJe ziet praktische voorbeelden, praktijkvoorbeelden en criteria om te bepalen wanneer je native DSC, Ansible-modules of andere automatiseringsmethoden moet gebruiken.

Overzicht: Windows-automatisering met PowerShell, DSC en Ansible

PowerShell en Ansible hebben hetzelfde doel : de configuratie en het beheer van uw systemen op een reproduceerbare manier automatiseren. Het verschil zit hem in hun aanpak. DSC is het configuratiebeheerplatform dat is geïntegreerd in PowerShell en is sterk gericht op Windows (hoewel het ook met Linux werkt via OMI), terwijl Ansible een veelzijdige, platformonafhankelijke automatiseringsengine is die is ontworpen om hybride en heterogene infrastructuren vanuit één centraal punt te beheren.

Met Red Hat Ansible Automation Platform kunt u Windows-servers automatiseren zonder extra agents te installeren. U maakt gebruik van WinRM of OpenSSH als verbindingskanalen en van DSC-resources, Ansible-modules en PowerShell-scripts. Dit alles wordt georganiseerd via YAML-playbooks , waarin u de gewenste status voor elke host definieert, zowel op Windows als op Linux.

PowerShell Desired State Configuration biedt daarentegen honderden gespecialiseerde resources voor het configureren van vrijwel elk Windows-onderdeel: services, systeemfuncties, IIS, SQL Server, Active Directory, register, bestanden, enzovoort. Deze resources bevatten de logica voor het controleren en toepassen van de gewenste status, zodat u alleen hoeft aan te geven "hoe u wilt dat de machine functioneert".

Het belangrijkste is dat je vanuit Ansible die DSC-resources rechtstreeks via de module kunt gebruiken. ansible.windows.win_dscDoor de orkestratiekracht van Ansible te combineren met de Windows-specifieke configuratiemogelijkheden van DSC, bereikt u het volgende: Het beste van beide werelden zonder dubbel werk.

WinRM en toegang op afstand tot Windows voor Ansible

Om Ansible Windows-servers te laten beheren, is het essentieel om te begrijpen hoe WinRM (Windows Remote Management) werkt . WinRM is Microsofts ingebouwde technologie voor beheer op afstand, gebaseerd op HTTP/HTTPS, en het is het standaardkanaal dat Ansible gebruikt om taken uit te voeren op Windows-machines.

De eerste stap is het correct configureren van WinRM op de doelhosts en het controleknooppunt waar Ansible draait. Dit houdt in dat authenticatie, versleuteling en machtigingen moeten worden aangepast, en vaak ook functies zoals niet-interactieve aanmelding, waarbij opdrachten worden uitgevoerd zonder een actieve gebruikerssessie. Deze niet-interactieve sessieomgeving bemoeilijkt taken zoals Windows-updates of scenario's met tweefactorauthenticatie , waarbij toegang tot een tweede externe bron nodig is (bijvoorbeeld een gedeelde map op een andere server).

Het voordeel van het gebruik van Red Hat Ansible Automation Platform is dat het centraal en veilig codeert voor inloggegevens en authenticatiemechanismen , waardoor de afhandeling van deze complexe gevallen wordt vereenvoudigd. Bovendien kan het platform ook OpenSSH gebruiken om toegang te krijgen tot Windows Server , wat steeds gebruikelijker wordt bij moderne Windows-versies.

In de praktijk maakt de combinatie van WinRM, Ansible's credential management en DSC-functionaliteit het mogelijk om robuuste automatiseringsworkflows te bouwen die onbeheerd draaien, zelfs in omgevingen met strenge beveiligingsvoorschriften.

PowerShell DSC: Declaratief configuratieplatform

PowerShell Desired State Configuration (DSC) is een declaratief configuratiebeheerplatform dat is geïntegreerd in Windows. Met DSC definieert u in code hoe een machine geconfigureerd moet worden: welke rollen en functies geïnstalleerd moeten worden, welke services actief moeten zijn, welke registerparameters, welke bestanden of mappen aanwezig moeten zijn, enzovoort.

DSC- configuraties beschrijven de gewenste status voor een set knooppunten. Elke beheerde machine draait een Local Configuration Manager (LCM) , de engine die deze configuraties leest, de actuele status controleert en de nodige wijzigingen toepast. Daarnaast kunt u een pull-server instellen die de configuraties centraliseert en van waaruit de knooppunten hun updates ontvangen en de naleving rapporteren.

DSC is niet beperkt tot Windows: via de Open Management Infrastructure ( OMI )-server kan het ook met Linux-machines werken . Het komt echter pas echt tot zijn recht in Windows-omgevingen, waar de community een enorme verzameling gespecialiseerde hulpmiddelen heeft ontwikkeld voor uiteenlopende taken, zoals het configureren van IIS, SQL Server of Active Directory.

Een van de grote voordelen van DSC is dat het zich richt op het resultaat, niet op de stappen . Je definieert de gewenste status (bijvoorbeeld: "deze functionaliteit moet aanwezig zijn, deze service moet gestart zijn, deze registerwaarde moet geconfigureerd zijn") en de engine zorgt ervoor dat die status bereikt wordt, waarbij gecontroleerd en gecorrigeerd wordt als er in de loop van de tijd iets afwijkt.

Hoe Ansible samenwerkt met DSC: de win_dsc-module en orchestratie

Theoretisch gezien zou je DSC op zichzelf kunnen gebruiken, maar in de praktijk is het veel nuttiger in combinatie met Ansible als orchestratielaag . Ansible beheert de inventaris, zorgt voor een ordelijke uitvoering van taken, de coördinatie tussen systemen en de integratie met CI/CD-pipelines, terwijl DSC de specifieke resources levert om de interne werking van Windows te manipuleren.

De module ansible.windows.win_dsc Het is de brug tussen beide werelden. Deze module roept een functie aan. DSC-resourceklasse op de doel-Windows-host. In het playbook hoeft u alleen het volgende te definiëren:

• naam van de bron: de naam van de DSC-bron die u wilt gebruiken (bijvoorbeeld, File, WindowsFeature, Service, Registry, xWebsite, Enz.).
• De overige parameters, die rechtstreeks overeenkomen met de eigenschappen van de DSC-bron (bijvoorbeeld DestinationPath, Ensure, Name, State, Enz.).

Wanneer Ansible de taak uitvoert, vertaalt het die parameters naar een tijdelijke DSC-configuratie, past deze toe op de host en verzamelt het resultaat (inclusief of er wijzigingen zijn opgetreden). Hierdoor kunt u de volledige DSC-resourcecatalogus hergebruiken zonder voor elk geval specifieke Ansible-modules te hoeven schrijven.

De uitvoeringsstroom volgt in feite een consistent patroon: Ansible verzendt de taak via WinRM, het Windows-systeem genereert een DSC-configuratie op basis van de parameters, waarna de DSC-engine eerst een aanroep doet. Test-TargetResource om de huidige status te controleren, en als er verschillen worden geconstateerd, voert het de volgende actie uit. Set-TargetResource De wijzigingen worden toegepast. Ansible ontvangt een rapport met een melding of er iets is gewijzigd en eventuele relevante berichten voor debugging.

Deze combinatie is bijzonder krachtig wanneer je combineert Ansible native modules voor Windows (zoals win_file, win_service, win_regedit, win_psmoduleenz.) met DSC-middelen voor die gebieden waar DSC betere opties of een grotere functionele dekking biedt.

Soorten DSC-eigenschappen en hoe je ze in Ansible kunt toewijzen.

Elke DSC-resource definieert een set eigenschappen met een goed gespecificeerd type (strings, booleans, arrays, complexe PowerShell-typen, enz.). Wanneer je met Ansible werkt, moet je die eigenschappen vertalen naar YAML-syntaxis Het juiste type behouden. De module win_dsc Het voert veel automatische conversiewerkzaamheden uit, maar het is nuttig om enkele belangrijke voorbeelden te kennen.

Voor eenvoudige typen zoals o De mapping is eenvoudig: geciteerde strings en booleans in kleine letters in YAML-stijl (true, false), waarbij het vermijden van schrijven $true o $false zoals je dat in PowerShell zou doen. Voor eigenschappen van het type Het is gebruikelijk om een ​​te gebruiken. ISO 8601-formaat (bijvoorbeeld "2019-02-22T13:57:31Z") en zorg ervoor dat de waarde als een tekenreeks wordt geserialiseerd door deze tussen aanhalingstekens te plaatsen.

Type-eigenschappen Ze vormen een speciaal geval. Omdat dit type niet direct naar JSON kan worden geserialiseerd, gebruikt Ansible een conventie: je definieert twee parameters, gescheiden door een achtervoegsel. _username y _password (bijvoorbeeld Credential_username y Credential_passwordDe module genereert het object. PSCredential op de externe host op basis van die twee waarden.

Voor typen Deze representeren woordenboeken gebaseerd op een aangepaste resourceklasse; in YAML worden ze weergegeven als een sleutel-waardetabel. U dient de documentatie van de resource te raadplegen (meestal in het bestand). <nombre_recurso>.schema.mof) om te weten welke sleutels zijn toegestaan ​​en welk type elke sleutel is. In de praktijk worden ze gedefinieerd als geneste woordenboeken binnen de module win_dsc.

Tot slot de type-eigenschappen en de arrays (], ]enz.) worden weergegeven als woordenboeken of YAML-lijsten. Voor arrays wordt aangeraden een authentieke YAML-lijst en geen tekenreeks met door komma's gescheiden waarden, omdat dit handmatige verwerking voorkomt en de kans op subtiele fouten verkleint.

Praktische voorbeelden van het gebruik van DSC vanuit Ansible

Zodra je de basisstructuur van de module onder de knie hebt, win_dscJe kunt middelen combineren om te bouwen zeer uitgebreide configuratie-playbooksEnkele veelvoorkomende scenario's die goed werken met DSC zijn:

• Bestands- en mapbeheer met de bron FileDit omvat het creëren van mapstructuren, het implementeren van configuratiebestanden met specifieke inhoud en het controleren of bepaalde elementen aanwezig zijn of verwijderd zijn.
• Windows-rollen en -functies installeren met WindowsFeature: IIS, .NET Framework, Telnet-client, beheertools, enz.
• Servicecontrole met de bron Service: status (gestart/gestopt), starttype (automatisch, handmatig), serviceaccount, enz.
• Registerinstellingen met Registry: beveiligingswaarden, wachttijden, protocolparameters, systeembeveiliging.
• Geavanceerde IIS-instellingen met modules zoals xWebAdministration en middelen xWebsite, xWebAppPool, Etc.

In al deze gevallen beschrijft Ansible eenvoudigweg de parameters van de DSC-resource, terwijl De DSC-engine is verantwoordelijk voor het controleren en toepassen van de gegevens. de staat. Bovendien, vanaf Ansible 2.8, de module win_dsc Het valideert parameters automatisch aan de hand van de resourcedefinitie: als u een onjuiste eigenschapsnaam gebruikt, een verplicht veld leeg laat of een waarde buiten het bereik doorgeeft, mislukt de taak met een duidelijke foutmelding.

Als je Ansible uitvoert met een hoge mate van woordrijkheid (bijvoorbeeld, -vvv)De output zal gedetailleerde informatie bevatten in invocation.module_args Informatie over de gebruikte opties en de beschikbare opties is erg handig, zowel voor het debuggen als voor het ontdekken welke velden je in elke resource kunt configureren.

Houd er ook rekening mee dat u de parameter kunt gebruiken. PsDscRunAsCredential Hierdoor kan de DSC-resource als een andere gebruiker dan het systeem worden uitgevoerd. Dit is erg handig voor toegang tot de registratie-hive. HKEY_CURRENT_USER van de gebruiker waarmee Ansible verbinding heeft gemaakt, of voor scenario's waarin u een specifieke beveiligingscontext nodig hebt.

Aangepaste DSC-bronnen en PowerShell-galerij

De in Windows geïntegreerde DSC-resources voorzien in veel behoeften, maar de echte kracht komt pas tot uiting wanneer u gebruikmaakt van resources die zijn gepubliceerd in de PowerShell Gallery of van pakketten van derden. Er zijn modules voor alles: Active Directory, SQL Server, geavanceerd IIS, beveiligingsbeleid en nog veel meer.

Je kunt beschikbare resources ontdekken met de cmdlet. Find-DscResource of door rechtstreeks door de PowerShell Gallery te bladeren. Zodra u de module hebt gevonden waarin u geïnteresseerd bent (bijvoorbeeld, xWebAdministration o SqlServerDsc), heb je verschillende manieren om het op je hosts te installeren:

• Handmatige installatie met Install-Module vanuit PowerShell op de doelservver.
• Het Ansible-module gebruiken win_psmodule Om de installatie vanuit PowerShell Gallery te automatiseren.
• Download het document van tevoren en kopieer het met de hand. voor servers die geen internettoegang hebben, waarbij de module wordt opgeslagen in een map die is opgenomen in PSModulePath (bijvoorbeeld C:\Program Files\WindowsPowerShell\Modules).

Bij het werken in omgevingen zonder internetverbinding is een veelgebruikte strategie het gebruik van een server met internettoegang. sla de module op met Save-Module in een lokaal pad, en kopieer die map vervolgens naar de productiemachines. Configureer daarna de configuratie. PSModulePath Het kan ook worden aangepast met Ansible, bijvoorbeeld met de module win_pathzodat PowerShell die resources kan detecteren zonder handmatige tussenkomst.

Na installatie zal de module win_dsc kan elke bron uit die pakketten aanroepen simpelweg de naam vermelden in resource_nameDit maakt het mogelijk om beproefde oplossingen, zoals Active Directory DSC-modules, opnieuw te gebruiken voor taken zoals Gebruikers, organisatie-eenheden (OU's) en groepen aanmaken of beleidsregels configurerenAlles wordt beheerd vanuit uw draaiboeken.

Bovendien is er zelfs een PowerShell-module waarmee je automatisch Ansible-modules kunt genereren vanuit DSC-resources . Het idee is om de DSC-resource te inspecteren, een Ansible-module te maken die de parameters één voor één in kaart brengt, en deze te gebruiken alsof het een standaardmodule is. Deze generatoren kunnen resources downloaden uit de PowerShell Gallery en tientallen modules creëren die het Windows-automatiseringsecosysteem met Ansible verder uitbreiden.

Naast DSC en Ansible: andere automatiseringstools in Azure

Als uw infrastructuur op Azure draait (of gaat draaien), is het de moeite waard om andere tools in de gaten te houden die een aanvulling vormen op PowerShell DSC en Ansible . Het gaat er niet om er slechts één te kiezen, maar om te begrijpen hoe ze in de algehele keten passen: infrastructuurcreatie, systeemconfiguratie, applicatie-implementatie en het doorlopende beheer.

In het domein van "infrastructuur als code" stellen oplossingen zoals Terraform of de eigen talen van Azure (ARM Templates en Bicep) je in staat om netwerken, virtuele machines, opslag en beheerde services te definiëren met behulp van declaratieve bestanden. Terraform gebruikt zijn eigen HCL-taal, terwijl Bicep de syntaxis van oudere ARM-templates vereenvoudigt. Alle drie de oplossingen integreren goed in CI/CD-pipelines en kunnen worden gecombineerd met Ansible voor het configureren van virtuele machines nadat ze zijn aangemaakt.

Voor de fase van initiële configuratie van Linux-machinesAzure ondersteunt cloud-initdie scripts uitvoert en gebruikers, pakketten of configuratiebestanden configureert bij de eerste opstart. De bestanden #cloud-config, meestal gecodeerd in base64, zijn distributie-onafhankelijk en maken gebruik van de pakketbeheerder van elke distributie, zonder dat u zich daar zorgen over hoeft te maken.

Op het gebied van operationele automatisering speelt Azure Automation een interessante rol. Het maakt gebruik van runbooks (meestal PowerShell- of Python-scripts) die op aanvraag of volgens een schema kunnen worden uitgevoerd, zowel op Azure-resources als in on-premises omgevingen met behulp van Hybrid Runbook Worker. Bovendien biedt het een beheerde DSC- service waarmee u configuraties kunt publiceren en de naleving ervan kunt bewaken op een reeks machines.

Ten slotte completeren CI/CD- en applicatielevenscyclusbeheertools zoals Azure DevOps, Jenkins, Chef, Puppet en Packer het ecosysteem. Elk van deze tools dekt een deel van de puzzel: van het compileren en testen van code tot het genereren van aangepaste machine-images of het waarborgen van naleving van regelgeving door middel van geautomatiseerd testen.

Windows-updates, pakketten en applicatiebeheer

Een van de meest cruciale taken voor elk systeembeheerteam is het up-to-date houden van Windows met patches en updates . Microsoft biedt Windows Update en, in veel bedrijfsomgevingen, Microsoft Configuration Manager (SCCM) om de implementatie te beheren. Echter, wanneer er meerdere herstarts, strakke onderhoudsvensters of complexe orchestratievereisten een rol spelen, kunnen deze mechanismen tekortschieten of onbetrouwbaar blijken.

Het Ansible Automation Platform maakt de gecontroleerde uitvoering van updates mogelijk , integreert met Windows Update en beheert automatisch de benodigde herstarts, zodat één enkele taak tientallen of honderden patches kan installeren met behoud van controle over de uiteindelijke status van de nodes.

Wat betreft de installatie van applicaties, mist Windows een uniforme, ingebouwde pakketbeheerder zoals die in Linux-distributies te vinden zijn. De Microsoft Store is niet ontworpen voor geautomatiseerde massa-implementaties: er ontbreken volwaardige CLI-tools en de Store is sterk afhankelijk van de grafische interface, waardoor deze moeilijk te gebruiken is in geautomatiseerde pipelines.

Om deze beperking aan te pakken, integreert Ansible modules die basispakketbeheer in Windows mogelijk maken en, belangrijker nog, werkt het uitstekend samen met oplossingen zoals Chocolatey of Winget in Windows , waardoor een idempotente aanpak wordt geboden die vergelijkbaar is met een klassieke pakketbeheerder. Door Chocolatey, DSC en Ansible playbooks te combineren, kunt u softwarecatalogi voor servers of VDI standaardiseren met zeer weinig handmatige inspanning.

Als u hieraan het gebruik van DSC-bronnen toevoegt om registerconfiguraties, services en beleidsregels met betrekking tot deze toepassingen af ​​te dwingen, bereikt u een volledige automatisering van de softwarelevenscyclus in uw Windows-omgevingen, van de eerste installatie tot het beveiligen van configuraties en periodieke updates.

Training, best practices en implementatie in Windows-teams

In veel IT-teams die volledig op Windows werken, begint het beheer nog steeds met muisklikken in de grafische console en wizards. Het is gebruikelijk om tientallen of honderden virtuele machines te hebben draaien op VMware of Hyper-V, waarbij het aanmaken van de servers handmatig gebeurt. De overstap naar automatisering vindt meestal plaats wanneer iemand in het team het zat is om steeds dezelfde taken te herhalen en begint met het schrijven van PowerShell-scripts.

In deze context rijst een terechte vraag: "Blijf ik PowerShell op zichzelf gebruiken, stap ik over op DSC, configureer ik Ansible... of doe ik het allemaal tegelijk?" Het meest pragmatische antwoord is meestal om ze te combineren: gebruik de bestaande kennis van PowerShell en DSC en introduceer tegelijkertijd Ansible als orchestratielaag om te profiteren van standaardisatie en integratiemogelijkheden met andere platforms.

Er zijn specifieke cursussen voor Windows-beheerders die helemaal vanaf nul beginnen met Ansible en zich precies hierop richten: hoe Windows-systemen te configureren voor beheer met Ansible, hoe effectieve playbooks te schrijven, hoe Ansible Tower of AWX te integreren om automatiseringen te starten vanuit een gecentraliseerde en veilige webinterface, en hoe DSC-code uit deze playbooks te hergebruiken zodat het reeds gedane werk niet verloren gaat.

In de praktijk hanteren veel teams een evolutionaire strategie: ze beginnen met het automatiseren van eenvoudige taken (services, rollen, installatie van PowerShell-modules), gaan verder met DSC-resources voor repetitieve configuraties (IIS, AD, SQL, beveiligingsbeleid) en integreren geleidelijk automatisering in de applicatieleveringspipeline en terugkerende operationele taken.

Het is ook belangrijk om stijlrichtlijnen, versiebeheer van de broncode en het testen van playbooks en DSC-configuraties vast te stellen, zodat automatisering daadwerkelijk "infrastructuur als code" wordt en niet slechts een handvol losse scripts zonder versiebeheer of revisies.

Door PowerShell DSC, Ansible-modules, WinRM, Chocolatey en Azure-tools te combineren , ontstaat een robuust ecosysteem waarin het aanmaken van machines, gedetailleerde configuratie, applicatie-implementatie en doorlopend onderhoud niet langer afhankelijk zijn van handmatige RDP-sessies. Het resultaat is een consistentere, traceerbare en reproduceerbare omgeving waarin wijzigingen automatisch in de code worden gedocumenteerd en menselijke fouten drastisch worden verminderd.