Resources For IT Professionals
Desired State Configuration (DSC) er ny funksjonalitet i Windows Management Framework 4.0 (WMF 4.0), noe som i tidligere versjoner har inkludert Windows PowerShell, WMI (Windows Management Instrumentation) og WinRM (Windows Remote Management).
DSC gjør det mulig å definere deklarative konfigurasjoner for hvordan du vil at en maskin skal være konfigurert. Denne konfigurasjonen kan både rulles ut og verifiseres på gitte intervaller ved hjelp av DSC.
Med DSC kommer også utvidelser til Windows PowerShell, som gjør det mulig å definere DSC konfigurasjoner fra PowerShell. Spesifikt er det et nytt keyword i PowerShell 4.0 relatert til DSC som heter configuration, i tillegg flere DSC-relaterte cmdlets og moduler som vi skal se nærmere på. DSC i seg selv er altså ikke en del av Windows PowerShell, men det er mulig å bruke PowerShell for å definere, rulle ut og verifisere konfigurasjoner.
DSC kommer med flere innebygde såkalte resources som gjør det mulig å utføre ting som:
Har man behov for å utføre noe som ikke er dekket av de innebygde ressursene er det også mulig å bygge side egne ressurser, mer informasjon om DSC ressurser finner du på denne TechNet-siden.
Før vi begynner å se på det første PowerShell-eksempelet som definerer en konfigurasjon skal vi se nærmere på arkitekturen. DSC har to ulike modeller, en som heter pull og en som heter push:
I Pull mode vil en DSC klient med gitte intervaller sjekke og om nødvendig laste ned konfigurasjonsdefinisjoner fra en Pull server. I Push mode har en konfigurasjon blitt rullet ut til DSC klienten av en administrator.
Som vi ser på skissen over er det 3 faser i DSC:
I denne fasen defineres konfigurasjonen, noe som enten kan gjøres ved hjelp av PowerShell eller andre verktøy. Det som produseres i denne fasen er en eller flere MOF (Management Object Format) filer, og det er disse filene som kan konsumeres av en DSC klient. Disse filene kan i prinsippet skrives i Notepad, men siden dette er basert på CIM schemas og ikke veldig «IT Pro»-vennlig er det i praksis vesentlig enklere å benytte de mulighetene som er tilrettelagt i PowerShell for å opprette MOF-filer hvor konfigurasjoner er definert. Denne fases utføres typisk i Windows PowerShell ISE på en administrator`s klient-maskin.
Neste fase består av å tilgjengelig gjøre MOF-filene for DSC klienten på den maskinen som konfigurasjonen skal gjelde for. I en Pull modell vil MOF-filene kopieres til Pull-serveren hvor de er tilgjengelig for klientene. I en Push modell vil en DSC-konfigurasjon rulles ut til en DSC klient fra for eksempel en administrator`s klient-maskin eller en sentral management server.
Den siste fasen består av å faktisk bruke konfigurasjonen – «Make it So», som er en henvisning til hva Jean-Luc Picard ville sagt. På en DSC klient er det noe som heter en på den maskinen som konfigurasjonen skal gjelde for. I en Pull modell vil MOF-filene kopieres til Pull-serveren hvor de er tilgjengelig for klientene. I en Push modell vil en DSC-konfigurasjon rulles ut til en DSC klient fra for eksempel en administrator`s klient-maskin eller en sentral management Local Configuration Store hvor konfigurasjonene som enten er manuelt rullet ut eller hentet fra en sentral Pull server er lagret. Her lagres gjeldende konfigurasjon, forrige konfigurasjon og det som er den definerte konfigurasjonen. Konfigurasjonen blir parset og de relevante providerne implementerer nødvendige endringer.
DSC klienten
Det som hittil er referert til som «DSC klienten» heter egentlig DSC Local Configuration Manager (LCM), og er i praksis en såkalt CIM Method som trigges som standard hver halvtime av en scheduled task:
Vil man manuelt trigge DSC til å utføre en konfigurasjons-sjekk kan man altså enten kjøre denne oppgaven fra Task Scheduler eller PowerShell:
For konfigurasjon av DSC klienten er Get-DscLocalConfigurationManager og Set-DscLocalConfigurationManager tilgjengelig som en del av PowerShell-modulen PSDesiredStateConfiguration:
Her ser vi standard-innstillingene for en DSC klient som ikke er konfigurert:
ConfigurationMode er som standard konfigurert til ApplyAndMonitor, det vil si at ingen automatisk handling for å rette innstillinger som ikke er i henhold til den definerte konfigurasjonen utføres. To andre gyldige verdier for ConfigurationMode er ApplyOnly og ApplyAndAutoCorrect. På klienten som benyttes i demoen i neste avsnitt er ConfigurationMode satt til ApplyAndAutoCorrect. Mer informasjon om DSC Local Configuration Manager og hvordan den kan konfigureres er tilgjengelig på denne TechNet-siden.
Definere en DSC konfigurasjon
Som kjent har vi ulike keywords i PowerShell, for eksempel function for å definere en egendefinert funksjon. I PowerShell 4.0 har det kommet et nytt keyword for å definere DSC konfigurasjoner, den grunnleggende syntaksen er følgende:
I denne demoen skal vi definere en konfigurasjon som benytter den innebygde DSC resourcen «WindowsFeature» for å si at Telnet-klienten skal være installert:
Typisk vil man legge på flere parametre, for eksempel –ComputerName for å si hvilken maskin denne konfigurasjonen defineres for, men i dette eksempelet benyttes localhost for enkelhets skyld.
Når man kjører de 10 linjene over i PowerShell vil det ikke skje noen endring, det eneste som er gjort er å definere en konfigurasjon. Dette prinsippet er det samme som med functions i PowerShell, de må første defineres før de kan brukes.
Når konfigurasjonen er definert kan vi kalle den ved å skrive navnet etterfulgt av de parametre vi vil angi. –OutputPath er en standard-parameter på DSC-konfigurasjoner, og definerer hvor vi vil lagre MOF-filene som genereres:
Når dette er kjørt vil vi se at det er definert en MOF-fil i mappen som ble angitt:
Når dette er kjørt vil vi se at det er definert en MOF-fil i mappen som ble angitt:
Av ren nysgjerrighet kan vi åpne fila for å se hvordan den ser ut:
Dette er altså innholdet som ble generert av PowerShell, og som kan konsumeres av DSC klienten for å verifisere konfigurasjonen som er definert.
Rulle ut en DSC konfigurasjon
I denne artikkelen vil vi kun vise Push modellen, link til en artikkel som viser oppsett av Pull modellen er tilgjengelig i Ressurs-seksjonen nederst i artikkelen. For å rulle ut en DSC konfigurasjon (Push-mode) brukes Start-DscConfiguration hvor vi benytter –Path parameteren for å angi stien til mappen hvor MOF-fila vi genererte i forrige fase ligger. Vi kan også benytte –Wait for å angi at vi vil vente til konfigurasjonen er rullet ut. Etter å ha rullet ut konfigurasjonen bruker vi Get-WindowsFeature for å se status på om Telnet Client er installert:
Som en test vil vi deretter avinstallere Telnet Client:
I stedet for å vente inntil 30 minutter som er standard intervallet for når DSC klienten kjører en konsistens-sjekk kan vi manuelt trigge en sjekk:
La oss ta en ny sjekk på status for Telnet Client:
Nå ser vi at den er installert etter at DSC har kjørt en konsistens-sjekk.
Det er også mulig å sjekke om en maskin er i henhold til definert konfigurasjon ved å kjøre Test-DscConfiguration som vil returnere enten True eller False:
Logging
Vi har hittil sett på et enkelt eksempel på hvordan DSC fungerer, men hva om det er noe som ikke fungep://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-94-28-metablogapi/6180.image_5F00_5664A066.png" style="color:#00749e;">
Tilsvarende for Test-DscConfiguration:
Den andre muligheten er Event Viewer, siden DSC benytter ETW (Event Tracing for Windows). Under Applications and Services->Logs->Microsoft->Windows finner vi Desired State Configuration Operational loggen:
I eksempelet over ser vi at en konsistens-sjekk ble kjørt. Ved å aktivere «Show Analytic and Debug Logs» i Event Viewer kan vi få tilgang til 2 andre logger hvor vi også finner nyttig informasjon:
Her ser vi i Analytic loggen en hendelse hvor det ble logget at Telnet Client ble installert:
Denne informasjonen er også tilgjengelig via PowerShell ved å benytte Get-WinEvent:
Hva er fordelene med Desired State Configuration?
Oppsummering
DSC i Windows 8.1 og Windows Server 2012 R2 er første utgivelse av denne funksjonaliteten, og eventuell manglende funksjonalitet vil bygges på i kommende versjoner.
Det fins allerede produkter med tilsvarende funksjonalitet, slik som Puppet og Chef. Man skulle tro at disse blir direkte konkurrenter til DSC, men begge disse produktene kan dra nytte av å ha DSC innebygd i Windows. For eksempel kan et tenkt scenario være at man ikke trenger å rulle ut agenter for disse 3. parts produktene, siden de i stedet kan integreres direkte i noe som er innebygd i Windows. I TechEd-videoen det er linket til i ressurs-seksjonen under er det en demo hvor Chef viser hvordan deres produkt kan integreres med DSC i Windows. Blant fordelene med dette er at kunder som kjører både Linux og Windows kan administrere begge miljøene fra samme sted.
Ressurser
Ressurser
