Desired State Configuration (DSC) und Windows Server 2016 – Teil 1: Ein Einstieg
Die neueste Version der Server Plattform Windows Server 2016 bringt im Bereich “Verwaltung und Automatisierung” einige interessante Neuerungen und Weiterentwicklungen mit, die bei den Highlights meistens nicht oder nur am Rande erwähnt werden. Ich meine damit z.B. das Thema “Desired State Configuration (DSC)”. DSC gibt es zwar schon länger, aber mit dem Server 2016 wird diese Technologie meines Erachtens zukünftig an Bedeutung gewinnen. Sicher wird sich der eine oder andere nun fragen, was sich dahinter verbirgt und was man damit anfangen kann. Ich habe deshalb beschlossen, mir auf Basis dieser Technologie eine Lab-Umgebung mit virtuellen Maschinen für eine Private Cloud zu erstellen und hier im Blog in einigen Beiträgen dieses Projekt zu beschreiben.
Bevor wir jedoch beginnen, unsere Wolke mit DSC aufziehen zu lassen, sollten wir uns erst mal mit den Grundlagen dieser Technologie vertraut machen, was ich mit diesem ersten Beitrag versuchen will.
DSC wurde erstmals mit der Powershell 4.0 eingeführt und basierte auf dem Windows Management Framework (WMF) 4.0, das standardmäßig in Windows 8.1 und Windows Server 2012 R2 enthalten war. Für den Windows Server 2016 in allen Editionen einschließlich dem Nano Server und auch Windows 10 in der aktuellen Version 1607 wurde die Technologie weiterentwickelt und steht nun in der Version 5.0 zur Verfügung. Für ältere Windows Versionen (ab Windows 7 bzw. Windows Server 2008) steht WMF 5 zum Download bei Microsoft zur Verfügung. Dieser und die weiteren Artikel beziehen sich auf die Version 5.0. Wenn Sie die Beispiele nachvollziehen wollen, empfehle ich Ihnen, Ihr System unbedingt auf diese neue Version zu aktualisieren. Über die globale Powershell Variable $PSVersionTable können Sie die WMF / Powershell Version, die auf Ihrem System installiert ist, überprüfen. Beim Windows Server 2016 werden aktuell folgende Informationen angezeigt:
PS C:\Windows\system32> $PSVersionTable
Name Value
---- -----
PSVersion 5.1.14393.206
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14393.206
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Nachdem dieser Artikel etwas umfangreicher ist, hier erst mal eine Inhaltsübersicht zur leichteren Navigation:
Das Modell, das hinter DSC steckt
Konfigurationsskripte
– Die Ressourcen-Eigenschaften Ensure und DependsOn
– Kompilieren der Konfiguration
– MOF-Dateien
– Anwenden der kompilierten Konfiguration
DSC Ressourcen
– Die Powershell Gallery
– Community Websites
– Eigene Ressourcen
– Versionsverwaltung
Konfiguration des LCM (Local Configuration Manager)
Spielereien mit dem Einführungsbeispiel
DSC in Projektteams – Partielle Konfigurationen
Nächste Schritte
Das Modell, das hinter DSC steckt
Bei vielen Projekten, an denen ich in der Vergangenheit mitgearbeitet habe, war die Beschreibung der Konfiguration der beteiligten Systeme und Komponenten eine zentrale Aufgabe. Es wurden detaillierte Checklisten erstellt, in denen Schritt für Schritt die notwendigen Aktionen dokumentiert wurden, um später eine einmal erzeugte Umgebung erneut aufbauen zu können und auch Vorgehensweisen für Fehleranalyse und Korrektur festzulegen. Diese Checklisten waren sicherlich hilfreich, wenn sich neue Mitarbeiter in ein Projekt einarbeiten mussten. Sie hatten jedoch einen Schönheitsfehler: Sie mussten immer von einem Menschen abgearbeitet werden und konnten nicht direkt von einem Computer ausgeführt werden.
Mit DSC (Desired State Configuration) kann dieser Medienbruch beseitigt werden. Spezielle Powershell-Sprachelemente erlauben es, die einzelnen Konfigurationsschritte für die beteiligten Systeme und die darauf benötigten Komponenten in Powershell Konfigurationsskripten zu beschreiben und diese dann bei Bedarf an die jeweiligen Zielsysteme zur Abarbeitung zu verteilen.
Auf den Zielsystemen gibt es einen lokalen Prozess – den Local Configuration Manager (LCM) – der die gesendeten Konfigurationsskripte entgegennimmt und die darin enthaltenen Konfigurationsschritte ausführt.
Damit der LCM die erhaltenen Konfigurationsschritte ausführen kann, benötigt er als Ressourcen bezeichnete Komponenten, die in Powershell-Modulen (.PSM1-Dateien) bereitgestellt werden müssen und die die Logik für die eigentlichem Konfigurationsschritte enthalten. Sie bieten außerdem entsprechende Parameter z.B. für Pfad-, Benutzer- oder komponentenspezifische Eigenschaften an. Der LCM entnimmt den erhaltenen Konfigurationsskripten die Werte dieser Parameter und startet damit die Ressourcen.
Der LCM startet aber nicht nur die Ressourcen für die Erstkonfiguration, sondern er ruft auch in konfigurierbaren Zeitintervallen die Ressourcen auf, um zu überprüfen, ob die Konfiguration noch den ursprünglichen Parametern entspricht. Bei Abweichungen kann er dann die Ressource veranlassen, die ursprünglichen Einstellungen wieder herzustellen.
Bleibt die Frage, wie der LCM seine Konfigurationsskripte erhält. Es gibt 2 Betriebsmodi: Den Push und den Pull Modus. Im Push Modus müssen die Konfigurationsskripte und Ressourcen von einem Administrator manuell an den LCM übermittelt und gestartet werden Im Pull Modus wird der LCM eines Zielsystems einmalig angewiesen, sich von einem zentralen Pull-Server regelmäßig seine für ihn bestimmten Konfigurationsskripte und Ressourcen zu holen und diese mit der vorhandenen Konfiguration abzugleichen. Das Ergebnis kann dann an einen zentralen Report-Server zurückgemeldet werden.
Jetzt könnte der Einwand kommen, warum man für die Konfiguration eines Systems einen solchen Aufwand über mehrere Stufen betreiben soll. Für ein einzelnes System mag dies berechtigt sein, da kommt man oftmals mit speziell geschriebenen “klassischen” Powershell-Skripten schneller ans Ziel. Aber betrachten wir mal die Situation eines Service Providers (egal ob in einer Public Cloud oder in einem unternehmenseigenen Rechenzentrum), der auf Anforderung mehrere – unter Umständen Hunderte oder Tausende – Systeme mit der gleichen Konfiguration bereitstellen, überwachen und im Fehlerfall korrigieren soll. Hier können die Automatismen von DSC eine große Hilfe sein. Und genau solche Massenszenarien hatte man beim Design von DSC im Fokus.
Eine weitere Frage möchte ich hier auch gleich ansprechen: Wie schaut es denn aus mit DSC in Nicht-Windows Umgebungen wie Linux oder IOS? Nun, die Antwort ist ganz einfach. Microsoft hat vor einiger Zeit ganz offiziell die Powershell und auch DSC als Open Source zur Verfügung gestellt und damit die Möglichkeit geschaffen, Powershell und DSC auch in einer Nicht-Windows Welt einzusetzen. Details dazu würden hier jedoch zu weit führen. Aber hier ist schon mal der Link zur offiziellen MSDN-Dokumentation für DSC und Linux: Erste Schritte mit DSC für Linux.
Konfigurationsskripte
Der erste Schritt, um mit DSC zu arbeiten, besteht im Erstellen von Konfigurationsskripten. Es handelt sich dabei um Powershell Skripte (.PS1-Dateien), die eine Configuration definieren. Schauen wir uns als Einstieg ein einfaches Konfigurationsskript an:
Configuration DscDemo # Name der configuration (wie bei einer Powershell Funktion)
{
Param # optionale Parameterliste
(
[Parameter()]
[string[]]$NodeName = 'localhost'
)
# Wir sollten alle Powershell Module, aus denen wir Ressourcen verwenden,
# zuerst importieren.
# PSDesiredStateConfiguration ist das Standardmodul von Windows, das die
# 'Out of the Box' Ressourcen enthält, zu finden unter
# C:\Windows\System32\WindowsPowerShell\v1.0\Modules\PSDesiredStateConfiguration
Import-DscResource –ModuleName ’PSDesiredStateConfiguration’
$DemoFolder = "C:\DscDemo"
# Mindestens 1 Node Block muss vorhanden sein, der das Zielsystem angibt.
Node $NodeName
{
# Zu konfigurierende Ressourcen
File DscDemoDir # Erzeugen eines Verzeichnisses
{
Type = 'Directory'
DestinationPath = $DemoFolder
Ensure = 'Present'
}
File DscDemoFile # Erzeugen einer Textdatei mit Inhalt
{
Type = 'File'
DestinationPath = Join-Path -Path $DemoFolder -ChildPath "DemoFile.txt"
Contents = 'Dies ist ein Demo-Text.'
Ensure = 'Present'
# Textdatei nur Erzeugen, wenn die Konfiguration der obigen
# Ressource erfolgreich war
DependsOn = '[File]DscDemoDir'
}
}
}
# Aufruf der Konfiguration, damit sie kompiliert wird
DscDemo
Eine Configuration ist eine spezielle Form einer Powershell Funktion, die mit dem Schlüsselwort Configuration beginnt. Den Namen der Configuration können wir frei wählen wie für Funktionen (hier DscDemo) und wir können auch eine Parameterliste festlegen. Innerhalb des Configuration Blocks können beliebige Powershell-Befehle stehen. Es muss aber mindestens ein Node Block vorhanden sein, mit dem der Name des Zielsystems festgelegt wird, für das die Configuration gelten soll. Innerhalb des Node Blocks können jetzt die Ressourcen, die auf dem Knoten konfiguriert werden sollen, mit ihren Parametern aufgeführt werden. Ein Ressourcen-Block beginnt immer mit dem Namen einer Ressource gefolgt von einer Bezeichnung des Ressource-Blocks. Die Bezeichnung eines Ressourcen-Blocks können wir frei wählen. Das vorstehende Beispiel enthält 2 Ressourcen Blöcke. Beide beziehen sich auf die Standard-Ressource File aus dem DSC Standardmodul PSDesiredStateConfiguration. Der erste Ressourcenblock erhält die Bezeichnung DscDemoDir, den zweiten benennen wir DscDemoFile
Zur Erläuterung: Die File Ressource ermöglicht verschiedene Dateisystem-Operationen wie z.B. das Anlegen oder Löschen von Verzeichnissen oder Dateien mit Inhalt.
Eine Ressource offeriert verschiedene Eigenschaften bzw. Properties, die für das Konfigurieren mit Werten versehen werden müssen. Die File Ressource erwartet z.B. eine Eigenschaft für den Typ der Dateisystem-Operation (Verzeichnis- oder Datei-Operation) und dann natürlich einen Pfadnamen für die Operation (Property DestinationPath).
Beim Erstellen eines Konfigurationsskripts empfiehlt es sich, alle Powershell-Module, die Ressourcen enthalten, auf die wir in den Ressourcen-Blöcken Bezug nehmen, gleich am Beginn der Configuration mit Import-DscResource zu importieren (siehe Zeile 14 im vorstehenden Beispiel). Import-DscResource ist ein dynamisches Schlüsselwort, das nur innerhalb eines Configuration Blocks erkannt wird. Damit ermöglichen wir es insbesondere der Powershell ISE bereits beim Erstellen von Ressourcen-Blöcken, jeweils die für eine Ressource verfügbaren Eigenschaften als Liste im Editor anzuzeigen und auch gleich eine Syntaxprüfung durchzuführen. Außerdem kann damit die Powershell angewiesen werden, eine bestimmte Version eines Moduls einzubinden, falls mehrere Versionen des Moduls auf dem System existieren.
Die Ressourcen-Eigenschaften Ensure und DependsOn
Ensure: Diese Eigenschaft kann bei vielen Ressourcen angegeben werden. Ihr kann als Stringwert entweder ‘Present’ oder ‘Absent’ zugewiesen werden.‘Present’ bedeutet, dass die Konfiguration wie angegeben vorhanden sein muss. Falls nicht, wird sie erzeugt. Mit ‘Absent’ wird angegeben, dass die Konfiguration entfernt werden soll, falls sie vorhanden ist.
In unserem Beispiel wird also mit dem ersten Ressource-Block ein Verzeichnis erzeugt, falls es noch nicht vorhanden ist. Mit dem zweiten Ressource-Block wird in diesem Verzeichnis eine Textdatei mit einem bestimmten Inhalt erstellt. Hier sorgt die Angabe von ‘Present’ nicht nur dafür, dass die Datei vorhanden ist, sondern ihr Inhalt auch dem Wert der Content Eigenschaft entspricht.
DependsOn: Normalerweise werden die Ressourcen-Blöcke in der Reihenfolge abgearbeitet, in der sie im Konfigurationsskript aufgeführt sind. Mit der DependsOn Eigenschaft kann diese Reihenfolge beeinflusst werden. Somit können Abhängigkeiten zwischen Ressourcen festgelegt werden. Ein Ressourcen-Block wird erst dann abgearbeitet, wenn die bei DependsOn angegebenen Ressourcen-Blöcke zuvor erfolgreich ausgeführt wurden. Der Eigenschaft kann als Wert ein Stringarray zugewiesen werden, das Verweise auf andere Ressource-Blöcke enthält. Jeder Eintrag im Stringarray muss die Form haben: ‘[<RessourceName>]<RessourceblockBezeichner>’. In unserem Beispiel wird also der Block DscDemoFile nur dann berücksichtigt, wenn der Ressourcen-Block DscDemoDir zuvor erfolgreich ausgeführt wurde.
Kompilieren der Konfiguration
Unser Konfigurationsskript speichern wir jetzt in einer Powershell (.PS1) Datei (z.B. DscDemo.ps1). Um die Configuration für die weitere Verarbeitung vorzubereiten, müssen wir sie kompilieren. Hierzu muss die Configuration aufgerufen werden wie eine Powershell-Funktion. Es gibt mehrere Möglichkeiten dazu:
Über die Powershell-Konsole per “Dot Sourcing”: Führen Sie folgende Powershell-Befehle aus:
. .\DscDemo.ps1 # Lädt die Konfiguration in den globalen Arbeitsraum der Powershell DscDemo # Aufruf der Konfiguration, gegebenenfalls mit Parametern
In der Powershell ISE mit der Taste F5 bzw. über den Menüpunkt “Run Script”
Direkt im Konfigurationsskript – siehe letzte Zeile im obigen Beispiel:
PS D:\Downloads\DSC\Test> .\DscDemo.ps1
Verzeichnis: D:\Downloads\DSC\Test\DscDemo
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 05.11.2016 18:10 2950 localhost.mof
PS D:\Downloads\DSC\Test>
Beim Kompilieren geschieht folgendes:
– Alle Variablen werden aufgelöst und eingebettete Befehle werden ausgeführt.
– Im aktuellen Verzeichnis wird ein Unterordner mit dem Namen der Konfiguration erzeugt.
– Für jeden Node-Block wird in diesem Unterverzeichnis eine Datei NodeName.MOF erzeugt.
Anmerkung: Will man das Ergebnis der Kompilierung in einem beliebigen anderen Ordner als in einem Unterordner des aktuellen Verzeichnisses ablegen, so kann beim Aufruf der Configuration zum Kompilieren über den Parameter –OutputPath der gewünschte Pfad angegeben werden, also z.B.
PS D:\Downloads\DSC\Test> . .\DscDemo.ps1
PS D:\Downloads\DSC\Test> dscdemo -OutputPath C:\Temp
Verzeichnis: C:\Temp
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 06.11.2016 16:21 2950 localhost.mof
PS D:\Downloads\DSC\Test>
Der Parameter –OutputPath steht immer zur Verfügung. Er muss nicht in der Parameterliste der Configuration aufgeführt sein.
zurück zum Inhaltsverzeichnis
MOF-Dateien
Die beim Kompilieren einer Configuration erzeugten MOF-Dateien enthalten nun alle Informationen für den Local Configuration Manager (LCM) des jeweiligen Zielsystems. Doch was sind MOF-Dateien?
MOF steht für Managed Object Format. Es handelt sich um ein Text-Dateiformat, das von der Distributed Management Task Force (DMTF) – einer herstellerübergreifenden Organisation, der auch Microsoft angehört – definiert wurde mit dem Ziel, plattformübergreifend Softwarekomponenten und Systeme zu konfigurieren und zu verwalten. So gesehen, können DSC-Konfigurationsskripte auch für Nicht-Windows Systeme erstellt werden, z.B. für verschiedene Linux Derivate, sofern diese MOF-Dateien unterstützen. Andererseits besteht auch die Möglichkeit, mit Tools von Fremdherstellern (z.B. Chef oder Puppet) Konfigurationen zu beschreiben, sie als MOF-Dateien bereitzustellen und mit DSC weiterzuverarbeiten.
Anwenden der kompilierten Konfiguration
- Ich habe weiter oben bereits beschrieben, dass die Konfiguration eines Systems durch dessen Local Configuration Manager (LCM) durchgeführt wird und dass hierzu die Konfigurationsdaten (genauer die .MOF-Dateien) und die benötigten Ressourcen verfügbar sein müssen. Dazu gibt es 2 Betriebsmodi für den LCM, den Push und den Pull Mode. Für den Pull Mode benötigen wir einen zentralen Pull Server, von dem sich der LCM selbständig die Informationen besorgt.
- Aktuell haben wir jedoch noch keinen solchen zentralen Pull Server. Um unsere Beispiel-Konfiguration anwenden zu können, müssen wir deshalb auf den Push Mode zurückgreifen. Dazu gibt es das Cmdlet Start-DscConfiguration. Diesem Cmdlet übergeben wir als Parameter den Pfadnamen des beim Kompilieren der Konfiguration erzeugten Ordners mit den .MOF-Dateien. Über weitere Parameter können wir den Ablauf beeinflussen, z.B. warten bis die Aktion beendet ist (-Wait), ein Protokoll mitlaufen lassen (-Verbose) oder Erzwingen, dass die Konfiguration vollständig neu gestartet wird und eine bereits zuvor angestoßene (und möglicherweise wegen Fehlern “hängengebliebene”) Instanz beendet wird (-Force). Um unser Beispiel anzuwenden, können wir also nach dem Kompilieren folgenden Befehl eingeben und erhalten das gezeigte Ergebnis:
PS D:\Downloads\DSC\Test> Start-DscConfiguration -Path .\DscDemo -Wait -Verbose -Force AUSFÜHRLICH: Vorgang "CIM-Methode aufrufen" mit den folgenden Parametern durchführen, "'methodName' = SendConfigu rationApply,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' = root/Microsoft/Windows/DesiredState Configuration". AUSFÜHRLICH: Vom Computer 'M6500PRO' mit Benutzer-SID 'S-1-5-21-2204300359-590443393-3658835497-1001' ist ein LCM -Methodenaufruf eingegangen. AUSFÜHRLICH: [M6500PRO]: LCM: [ StartenFestlegen] AUSFÜHRLICH: [M6500PRO]: LCM: [ StartenRessource] [[File]DscDemoDir] AUSFÜHRLICH: [M6500PRO]: LCM: [ StartenTesten ] [[File]DscDemoDir] AUSFÜHRLICH: [M6500PRO]: [[File]DscDemoDir] Das System kann die angegebene Datei nicht finden. AUSFÜHRLICH: [M6500PRO]: [[File]DscDemoDir] Zugehörige(s) Datei/Verzeichnis: C:\DscDem o. AUSFÜHRLICH: [M6500PRO]: LCM: [ BeendenTesten ] [[File]DscDemoDir] in 0.0540 Sekunden. AUSFÜHRLICH: [M6500PRO]: LCM: [ StartenFestlegen] [[File]DscDemoDir] AUSFÜHRLICH: [M6500PRO]: [[File]DscDemoDir] Das System kann die angegebene Datei nicht finden. AUSFÜHRLICH: [M6500PRO]: [[File]DscDemoDir] Zugehörige(s) Datei/Verzeichnis: C:\DscDem o. AUSFÜHRLICH: [M6500PRO]: LCM: [ BeendenFestlegen] [[File]DscDemoDir] in 0.0150 Sekunden. AUSFÜHRLICH: [M6500PRO]: LCM: [ BeendenRessource] [[File]DscDemoDir] AUSFÜHRLICH: [M6500PRO]: LCM: [ StartenRessource] [[File]DscDemoFile] AUSFÜHRLICH: [M6500PRO]: LCM: [ StartenTesten ] [[File]DscDemoFile] AUSFÜHRLICH: [M6500PRO]: [[File]DscDemoFile] Das System kann die angegebene Datei nich t finden. AUSFÜHRLICH: [M6500PRO]: [[File]DscDemoFile] Zugehörige(s) Datei/Verzeichnis: C:\DscDe mo\DemoFile.txt. AUSFÜHRLICH: [M6500PRO]: LCM: [ BeendenTesten ] [[File]DscDemoFile] in 0.0000 Sekunden. AUSFÜHRLICH: [M6500PRO]: LCM: [ StartenFestlegen] [[File]DscDemoFile] AUSFÜHRLICH: [M6500PRO]: [[File]DscDemoFile] Das System kann die angegebene Datei nich t finden. AUSFÜHRLICH: [M6500PRO]: [[File]DscDemoFile] Zugehörige(s) Datei/Verzeichnis: C:\DscDe mo\DemoFile.txt. AUSFÜHRLICH: [M6500PRO]: LCM: [ BeendenFestlegen] [[File]DscDemoFile] in 0.0160 Sekunden. AUSFÜHRLICH: [M6500PRO]: LCM: [ BeendenRessource] [[File]DscDemoFile] AUSFÜHRLICH: [M6500PRO]: LCM: [ BeendenFestlegen] AUSFÜHRLICH: [M6500PRO]: LCM: [ BeendenFestlegen] in 0.6010 Sekunden. AUSFÜHRLICH: Vorgang "CIM-Methode aufrufen" wurde abgeschlossen. AUSFÜHRLICH: Die Ausführung des Konfigurationsauftrags hat 0.844 Sekunden gedauert. PS D:\Downloads\DSC\Test>
Wie man sieht, ruft das Cmdlet Start-DscConfiguration den LCM auf dem Zielsystem (in unserem Fall localhost) auf und übergibt ihm den Pfad für den Ordner mit der .MOF-Datei. Um die Ressource File, die in diesem Beispiel verwendet wird, brauchen wir uns dabei nicht zu kümmern, da es sich um eine Standard-Ressource handelt, die in jedem DSC-fähigen System verfügbar ist.
DSC Ressourcen
Ich habe es weiter oben schon erwähnt: Damit eine DSC-Konfiguration vom Local Configuration Manager (LCM) auf einem Zielsystem durchgeführt werden kann, müssen dort die Ressourcen, die in einem Konfigurationsskript mit Parametern angegeben sind, in Form von Powershell Modulen verfügbar sein. Aber wo verstecken sich diese DSC-Module?
Es gibt in der Powershell eine Environmentvariable $env:PSModulePath, die eine Liste von Pfaden enthält, in denen der LCM nach Modulen sucht, u.a.
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
– hier liegen die DSC-Module, die standardmäßig mit Windows installiert werden. Sie ermöglichen das Konfigurieren einiger grundlegender Funktionen des Betriebssystems wie z.B. Datei-, Registry-, Prozess- oder Benutzer-Operationen sowie die Installation von Windows Betriebssystemkomponenten. Eine Übersicht findet man in der MSDN-Library.
C:\Program Files\WindowsPowerShell\Modules\
– hier sollten die DSC-Module liegen, die vom Benutzer zusätzlich bereitgestellt werden. Doch woher bekommt man die?
Im Wesentlichen gibt es folgende Quellen
Die Powershell Gallery
Für weiterführende Aufgaben gibt es DSC-Ressourcen zum Download im Internet. Microsoft veröffentlicht in regelmäßigen Abständen sogenannte “DSC Resource Kits”. Dabei handelt es sich allerdings nicht um komplette Download-Pakete, sondern vielmehr um eine Auflistung von verfügbaren DSC-Ressourcen in der Powershell Gallery. Eine aktuelle Liste erhält man, wenn man in der Powershell Gallery bei der Suche unter “Items” die Kategorie “DSC Resource” markiert.
Für das Herunterladen einzelner Ressourcen stellt die Powershell direkt ein eigenes Cmdlet Install-Module zur Verfügung, z.B. aus dem vorstehenden Screenshot:
Install-Module -Name xNetworking -Force
Install-Module sucht standardmäßig in der Powershell Gallery nach dem Modul mit dem bei -Name angegebenen Namen und kopiert es in den Pfad
C:\Program Files\WindowsPowerShell\Modules\
Mit -Force können wir die aktuelle Version der Ressource herunterladen, auch wenn bereits eine ältere Version vorhanden ist (“Side by Side” Installation). Auf die Versionsverwaltung von DSC-Ressourcen werden wir gleich zu sprechen kommen. Install-Module bietet noch weitere Parameter an wie z.B. die Internet-Adresse eines anderen Repositories als die Powershell Gallery oder die explizite Angabe einer Versionsnummer der DSC-Ressource. Ich werde bei meinen Beispielen noch darauf zurückkommen.
Community Websites
DSC ist wie die gesamte Powershell ein Open Source Software (OSS) Angebot von Microsoft. Entsprechend gibt es neben den “offiziellen” Microsoft Quellen auch eine Reihe von Community Websites, auf denen man weitere DSC-Ressourcen findet oder die Derivate bereits vorhandener Module anbieten. Gute Quellen sind die Seiten des Powershell Teams von Microsoft (https://github.com/powershell), die Seiten von Powershell Magazin (http://www.powershellmagazine.com) und die der Powershell.org Community (https://powershell.org). Und natürlich wird eine Bing oder Google Suche weitere Quellen aufzeigen.
Die auf Community Websites angebotenen DSC-Ressourcen lassen sich nicht immer mit Install-Module installieren, sondern werden häufig in Form von .ZIP-Dateien angeboten. Um solche Ressourcen nutzen zu können, muss man die .ZIP-Dateien manuell herunterladen und dann in den Standardpfad
C:\Program Files\WindowsPowerShell\Modules\
entpacken. Ein paar Tipps dazu:
– Vergessen Sie nach dem Herunterladen nicht, eine Virenprüfung durchzuführen!
– Falls der Name der .ZIP-Datei nicht dem Namen des Powershell-Moduls entspricht, geben sie ihr vor dem Entpacken den passenden Namen. Ich habe z.B. vor einiger Zeit aus dem Github Repository von Powershell.Org eine ZIP-Datei cHyper-V-master.zip heruntergeladen, die eine Ressource cHyperV enthält. Also benennen wir die Datei zunächst um in cHyper-V.zip.
– Aus Sicherheitsgründen werden von den aktuellen Windows Versionen heruntergeladene Dateien mit einer Sicherheitssperre versehen, die man vor dem Entpacken entfernen sollte. Vergisst man dies, sind die entpackten Daten ebenfalls mit dieser Sperre belegt und es kommt zu Fehlermeldungen beim Zugriff, die nicht sofort auf die Sperre hindeuten. Zum Aufheben der Sperre rufen Sie im Explorer die Eigenschaften der Datei auf und setzen auf der Registerkarte Allgemein einen Haken im Kästchen Zulassen.
– Jetzt können Sie den Inhalt der .ZIP-Datei in das Modul-Verzeichnis der Powershell entpacken, z.B. mit
Expand-Archive -Path .\cHyper-V.zip -DestinationPath „C:\Program Files\WindowsPowerShell\Modules“
Eigene Ressourcen
Auch wenn es mittlerweile sehr viele DSC Ressourcen im Internet gibt, kann man auf eine Anforderung stoßen, zu der man nichts geeignetes findet. In diesem Fall ist es durchaus möglich, sich selbst Powershell Module mit geeigneten Ressourcen zu erstellen. Spezielle Entwicklungswerkzeuge sind dafür nicht notwendig, es genügt ein Powershell Editor wie z.B. die Powershell ISE.
Die selbst geschriebenen Module können dann in das globale Modulverzeichnis „C:\Program Files\WindowsPowerShell\Modules“ zusammen mit den notwendigen Verwaltungsinformationen kopiert werden und stehen sofort für die Verwendung in Konfigurationsskripten zur Verfügung.
Im Verlauf meines angedachten Cloud Projekts werde ich sicherlich auf dieses Thema ausführlicher zurückkommen.
Versionsverwaltung
Mit der Powershell 5 – also mit Windows Server 2016 bzw. Windows 10 Version 1607 – wurde eine Versionsverwaltung für DSC-Ressourcen eingeführt. Dadurch ist es möglich Powershell-Module gleichen Namens, aber mit verschiedenen Versionsnummern auf dem gleichen System zu halten (“Side by Side” Installation). Dies ist sehr einfach und übersichtlich gelöst. Unter dem Verzeichnis des Moduls gibt es für jede Version einen eigenen Unterordner mit der jeweiligen Versionsnummer. Erst in diesem sind dann die Dateien der jeweiligen Modulversion abgelegt. Das Cmdlet Install-Module erzeugt diese Verzeichnisstruktur automatisch, sofern die Download-Quelle eine Versionsnummer definiert. Beispielsweise wird beim Herunterladen der Ressource xNetworking aus der Powershell Gallery mit Install-Module folgende Verzeichnisstruktur erzeugt
Ich habe bei den Konfigurationsskripten empfohlen, alle Module, aus denen DSC-Ressourcen benötigt werden, gleich am Anfang der Configuration mit dem Befehl Import-DscResource aufzuführen. Insbesondere muss dies geschehen, wenn verschiedene Versionen des gleichen Moduls auf dem System vorhanden sind. Um die richtige Version zu referenzieren, gibt es bei Import-DscResource einen zusätzlichen Parameter –ModuleVersion, bei dem die Versionsnummer als String anzugeben ist:
Import-DscResource –ModuleName ’xNetworking’ -ModuleVersion '2.12.0.0'
Konfiguration des LCM (Local Configuration Managers)
Der LCM (Local Configuration Manager) ist integraler Bestandteil der Powershell in allen aktuellen Windows Versionen. Um ihn verwenden zu können, sind also keine Nachinstallationen notwendig. Allerdings muss bzw. kann er konfiguriert werden. Dazu erstellen wir ein spezielles Konfigurationsskript, in dem der Configuration Block mit dem Attribut [DSCLocalConfigurationManager()] markiert ist. Innerhalb einer solchen LCM-Konfiguration steht nur eine begrenzte Auswahl an Ressourcen zur Verfügung. Eine der wichtigsten Ressourcen heißt Settings. Über sie kann festgelegt werden, ob der LCM im Push oder Pull Mode arbeiten soll. Über weitere Eigenschaften der Settings Ressource kann z.B. festgelegt werden, ob der LCM regelmäßig bereits konfigurierte Ressourcen überprüft und diese gegebenenfalls korrigiert. Eine minimale LCM-Konfiguration wie sie für unser Einführungsbeispiel ausreichend ist, könnte wie folgt aussehen:
[DSCLocalConfigurationManager()]
configuration LCMConfig
{
Node localhost
{
Settings
{
RefreshMode = 'Push' # alternativ: 'Pull'
ConfigurationMode = 'ApplyAndMonitor' # Alternativ: 'ApplyOnly', 'ApplyAndAutoCorrect'
# viele weitere Einstellungen verfügbar
}
}
}
LCMDconfig
Eine solche LCM-Konfiguration müssen wir wie üblich kompilieren. Interessant dabei ist, dass jetzt für jeden Node-Block im Verzeichnis mit dem Kompilierungsergebnisen eine .MOF-Datei mit dem Namen <Nodename>.meta.mof erzeugt wird.
.\LCMconfig.ps1
Verzeichnis: D:\Downloads\DSC\test\LCMConfig
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 07.11.2016 21:40 1162 localhost.meta.mof
Um diese Konfiguration anzuwenden, können wir jetzt jedoch nicht das übliche Cmdlet Start-DscConfiguration verwenden. Vielmehr gibt es hierfür ein eigenes Cmdlet Set-DscLocalConfigurationManager.
set-DscLocalConfigurationManager -Path .\LCMConfig -Force -Verbose AUSFÜHRLICH: Ausführen des Vorgangs "Start-DscConfiguration: SendMetaConfigurationApply" für das Ziel "MSFT_DSCLo calConfigurationManager". AUSFÜHRLICH: Vorgang "CIM-Methode aufrufen" mit den folgenden Parametern durchführen, "'methodName' = SendMetaCon figurationApply,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' = root/Microsoft/Windows/DesiredS tateConfiguration". AUSFÜHRLICH: Vom Computer 'M6500PRO' mit Benutzer-SID 'S-1-5-21-2204300359-590443393-3658835497-1001' ist ein LCM -Methodenaufruf eingegangen. AUSFÜHRLICH: [M6500PRO]: LCM: [ StartenFestlegen] AUSFÜHRLICH: [M6500PRO]: LCM: [ StartenRessource] [MSFT_DSCMetaConfiguration] AUSFÜHRLICH: [M6500PRO]: LCM: [ StartenFestlegen] [MSFT_DSCMetaConfiguration] AUSFÜHRLICH: [M6500PRO]: LCM: [ BeendenFestlegen] [MSFT_DSCMetaConfiguration] in 0.0160 Sekunden. AUSFÜHRLICH: [M6500PRO]: LCM: [ BeendenRessource] [MSFT_DSCMetaConfiguration] AUSFÜHRLICH: [M6500PRO]: LCM: [ BeendenFestlegen] AUSFÜHRLICH: [M6500PRO]: LCM: [ BeendenFestlegen] in 0.1000 Sekunden. AUSFÜHRLICH: Vorgang "CIM-Methode aufrufen" wurde abgeschlossen. AUSFÜHRLICH: "Set-DscLocalConfigurationManager" wurde in 0.3 Sekunden beendet.
Zum Anzeigen der aktuellen LCM-Konfiguration gibt es ebenfalls ein eigenes Cmdlet Get-DscLocalConfigurationManager
Get-DscLocalConfigurationManager
ActionAfterReboot : ContinueConfiguration
AgentId : 1A4F8F00-BC75-11E5-8360-B8AC6F79C4F4
AllowModuleOverWrite : False
CertificateID :
ConfigurationDownloadManagers : {}
ConfigurationID :
ConfigurationMode : ApplyAndMonitor
ConfigurationModeFrequencyMins : 15
Credential :
DebugMode : {NONE}
DownloadManagerCustomData :
DownloadManagerName :
LCMCompatibleVersions : {1.0, 2.0}
LCMState : Idle
LCMStateDetail :
LCMVersion : 2.0
StatusRetentionTimeInDays : 10
SignatureValidationPolicy : NONE
SignatureValidations : {}
MaximumDownloadSizeMB : 500
PartialConfigurations :
RebootNodeIfNeeded : False
RefreshFrequencyMins : 30
RefreshMode : PUSH
ReportManagers : {}
ResourceModuleManagers : {}
PSComputerName :
All diese Einstellungen können über die Settings und weitere LCM-spezifische Ressourcen beeinflusst werden. Bei Bedarf werde ich in den weiteren Folgen darauf näher eingehen.
Spielereien mit dem Einführungsbeispiel
Jetzt können wir mit dem vorstehenden Einführungsbeispiel ein bisschen spielen, z.B.
– Wenden Sie die Konfiguration mit Start-DscConfiguration an ==> Die Datei C:\DscDemo\DemoFile.txt wird mit dem angegebenen Inhalt erzeugt.
– Ändern Sie jetzt den Inhalt der Datei, z.B. mit Notepad
– Wenden Sie die Konfiguration erneut mit Start-DscConfiguration an ==> Die Datei C:\DscDemo\DemoFile.txt hat wieder den in der Konfiguration angegebenen Inhalt.
DSC in Projektteams – Partielle Konfigurationen
In unserem vorstehendes Einführungsbeispiel haben wir mit einer einzelnen Konfiguration für ein Zielsystem experimentiert, d.h. das Erstellen und auch Pflegen des Konfigurationsskripts wird von einer einzelnen Person durchgeführt. Spannend wird es bei einem Zielsystem, das von verschiedenen Gruppen konfiguriert und verwaltet wird. In einer Cloud-Umgebung wird es z.B. ein Team geben, das für die Netzwerk-Konfiguration zuständig ist, ein anderes kümmert sich um das Thema Storage oder um Management Tools wie System Center. Jedes Team erstellt seine eigenen Konfigurationsskripte. Brauchen wir jetzt einen “Chefredakteur”, der für das Zusammenführen der verschiedenen Konfigurationen zuständig ist? Ja und nein.
Arbeitet man mit der Powershell 5.0, können die Teams auf eine neue Funktionalität zurückgreifen, die sich “Partielle Konfigurationen” nennt. Dabei erstellt jede Gruppe ihr eigenes Konfigurationsskript und stellt es dem Local Configuration Manager einzeln zur Verfügung. Das kann sowohl im Push als auch im Pull Mode oder sogar gemischt geschehen. Entscheidend ist der LCM des Zielsystems. Bei ihm müssen die verschiedenen Einzelkonfigurationen als partielle Konfigurationen registriert werden und dabei der Betriebsmodus angegeben werden. Soll nun eine partielle Konfiguration im Push-Modus an den LCM übergeben werden, verwendet man statt des Cmdlet Start-DscConfiguration das Cmdlet Publish-DscConfiguration. Die Konfiguration wird dann zwischengespeichert. Sind alle Einzelkonfigurationen mit Publish-DscConfiguration dem LCM übergeben worden, kann die Gesamtkonfiguration auf dem Zielsystem mit Start-DscConfiguration initiiert werden, wobei als Parameter –UseExisting angegeben wird.
Im weiteren Verlauf unseres Cloud Projekts werde ich dies mit einem Beispiel verdeutlichen.
Nächste Schritte
Mit diesem Überblick haben wir uns ein bisschen die Idee von DSC und die damit verbundenen wichtigsten Arbeitsschritte angesehen. Ich denke, es ist nun an der Zeit, sich an konkreten Anwendungsszenarien zu versuchen. Im nächsten Beitrag werde ich Ihnen zeigen, wie man im Hyper-V mit DSC virtuelle Maschinen erzeugen und auf diesen dann spezielle Serverrollen wie z.B. einen DSC Web Pull Server konfigurieren kann.
