Desired State Configuration | Let’s start

Meiner Meinung nach ist das Thema DSC für viele noch ein rotes Tuch. Ich habe selbst erst recht spät angefangen mich intensiv mit dem Thema auseinander zu setzen. Viele deutschsprachige Blogs habe ich zu diesem Thema auch nicht gefunden. So will ich euch in einer Serie von Blogs das Thema DSC etwas näher bringen. Ich weiß noch nicht wieviel Teile es sein werden. Im Groben werde ich auf die Grundlagen, Ressourcen , Configurations , Local Configuration Manager (LCM) , und auf die Verteilmethoden eingehen. Es wird noch ein Abstecher zum Thema DSC in Azure geben.

Was ist Desired State Configuration (DSC)

Mit der Windows PowerShell Version 4.0 hat Microsoft DSC mitgebracht. Auf den ersten Blick sah es aus wie eine andere Methode um Files zu kopieren und Features zu installieren. Nach den ersten Experimenten war mir jedoch klar, dass es wesentlich mächtiger ist. Für kopieren und Feature Installation kommt man mit copy-Item und Add-WindowsFeature wohl noch schneller. Wenn es sich um mehr als drei, vier, fünf .. Server handelt, sieht die Sache schon ganz anders aus. Dazu aber später mehr. Denn erst nach der Systeminstallation kommt DSC ins Spiel. Nun gibt es die Möglichkeit einen Wunschzustand zu definieren und diesen auf eine große Anzahl von Systemen zu spielen.

Was heißt das? Ich kann ein System konfigurieren und sagen: mach das, mach das, mach das und wenn es mir gefällt, kann ich es auf so viel Systeme wie ich möchte bringen. DSC und deren Konfiguration beruht auf bestimmten Regeln. So gibt es die Möglichkeit auf Lösungen aus der Cumminty zurückgreifen. Mit diesen Ressourcen werde ich mich etwas später beschäftigen. In PowerShell 4 und in PowerShell 5 fixiert man sich hier auf die Server von Microsoft. Es gibt jedoch auch die Möglichkeit, Zustände von Linux Systemen zu definieren und diese anzuwenden. DSC arbeitet mit Providern wie WMI. Um DSC nicht nur auf Windows Geräten möglich zu machen, sondern auf jedem Gerät, wurde 2012 die Open Management Infrastruktur implementiert. Mit diesem Provider und dem CIM ist es für Entwickler möglich, Ressourcen für jedes Produkt zu Programmieren. In Zukunft könnten so auch Netzwerkkomponenten wie Router oder Switche über DSC konfiguriert werden. Zum Beispiel bietet die Firma ARISTA die Möglichkeit, Switche mit OMI/ CIM zu konfigurieren Link. In meinem Blog werde ich meine Beispiele auf Server 2012 R2 beziehen. Mein Ziel ist es, einige Mysterien zu beseitigen und Informationen so einfach wie möglich darzustellen. Voraussetzung an den Lesern ist jedoch, dass fundierte Grundlagen in dem Umgang mit der PowerShell und PowerShell ISE vorhanden sind.

Voraussetzungen

Um den vollen Umfang von DSC zu nutzen, ist es am besten die aktuellste Version von Windows Management Framework installiert zu haben. Für eine Testumgebung reicht eine kleine Umgebung aus zwei Servern, minimal reicht sogar ein Server. Um den vollen Umfang der Flexibilität und Komplexität zu testen, ist eine kleine AD Umgebung mit 4 Servern sinnvoller. In älteren Versionen hat man eventuell nicht die Möglichkeit den vollen Funktionsumfang zu nutzen und außerdem gab es in älteren Versionen Probleme beim Einrichten des LCM und der http-pull-Methode.

Die Architektur

Die Funktionsweise von DSC ist an sich recht einfach. Im Groben kann man es in drei Schritte unterteilen. Eine Designphase, eine Initialisierungsphase und eine “Mach es Phase”.

Im Design wird über deklarative oder imperative Befehle eine MOF-Definition erstellt. Deklarativ heißt, ich will das du so bist und imperativ heißt so viel wie, ich will das du das so machst. In der zweiten Phase werden die MOF-Dateien erstellt. Die MOFs definieren den Zustand eines des Systems (Node). Es gibt pro Node eine eigene MOF-Datei. Wie dies in der Praxis aussieht werden wir uns später anschauen. In der dritten und letzten Phase werden die Konfigurationen der MOFs durch einem Provider auf dem System ausgelesen und interpretiert. So muss man sich keine Gedanken machen wie es gemacht wird. Das macht der Provider. Es muss jedoch gleich klar sein, welcher Zustand erreicht werden soll. Dieser Provider ist auf einem Server der LCM oder Local Configuration Manager.

Es gibt zwei Herangehensweisen eine MOF-Konfiguration anzuwenden. Auf der einen Seite über das Push-Model und auf der anderen Seite über das Pull-Model. Bei der Push -Methode wird die Konfiguration zu dem Server geschickt. Dieser wird auch Staging Point genanntes. Der Punkt kann der eigene Desktop oder ein anderen Client im Netzwerk sein, von dem das Start-DSCConfiguration CmdLet ausgeführt wird und die Konfiguration auf die gewünschten Nodes schiebt. Es empfiehlt sich mit dieser Methode zu starten.
Das Pull-Model definiert einem Punkt im Netzwerk bei dem sich der LCM die MOF-Datei abholen kann. Dies kann ein SMB-Share, ein HTTP oder HTTPS – Server sein. Die meisten nutzen ein HTTPS-Server um die Konfigurationen zu verteilen. In Folge dieser Serie werde ich beschreiben wie man einen Pull-Server aufbaut und den LCM entsprechend konfiguriert.

Eines ist zu beachten: Es wird immer eine Konfiguration pro System / Server erstellt egal welches Model gewählt wird, es ändert sich nur wie Weise, wie und von wo es angestoßen wird.

Was sind DSC Configurations

Um den gewünschten Zustand eines Systems zu beschreiben, muss dieser in einer Configuration beschrieben werden. Wie sieht eine solche Konfiguration nun aus?

Die Konfiguration wird mit dem Keyword configuration eingeleitet, wie bei einer Funktion. Das Wort Node leitet den Namen des Systems ein. Dies geht auch in Abhängigkeiten, oder mit mehreren Nodes. Dazu später mehr. In dem Node – Block werden die Ressourcen definiert. Alles zum Thema Ressourcen wird in einem folgenden Blog nochmal näher erläutert. Wichtig ist zu verstehen, dass eine Konfiguration mehrere Nodes enthalten kann, die identische oder unterschiedliche Ressourcendefinitionen besitzen.

configuration
CopyAndFeature
{Node Clust1{
File cFile
{
Ensure =‘Present’
SourcePath =‘\Clust2File1Copy’
DestinationPath $env:SystemDrivetemp”
Recurse $true
Force $true
}
windowsFeature XPSFeature
{
Ensure ‘Present’
Name ‘XPS-Viewer’
}
}
}

Dies ist eine einfache Konfiguration. Das Keyword “configuration” als einleitendes Wort, gefolgt von dem Namen dieser Konfiguration. Im Weiteren wird der Node angegeben, hier Clust1 und wie der Node definiert sein soll. In diesem Fall soll ein Ordner rekursiv auf das System kopiert werden und das Windows Feature XPS-Viewer installiert werden. Beim ausführen dieses Skriptes wird nichts weiter passieren, außer dass die Konfiguration, wie eine Funktion, kompiliert wird. Erst durch das aufrufen der Konfiguration wird eine MOF Datei pro Node erstellt. Diese wird dann entweder auf das Ziel gepusht oder es wird eine der benannten Pull Methoden verwendet.

Die Zukunft von DSC

In Zukunft wird es mehr und mehr so sein, dass sich nicht mehr die Frage gestellt werden muss, wie ich etwas mache, sondern wie etwas aussehen soll. Die MOFs halten sich an einen industriellen Standard und müssen so nicht zwingend mit PowerShell geschrieben werden. Am Ende sind es “nur” Text Dateien. Eben durch solche Definitionen wird es in Zukunft einfach sein, jedes beliebige Device zu konfigurieren. Beispielsweise ist es jetzt schön möglich sein Linux-Apache Server unter Microsoft mithilfe der PowerShell ISE definieren. Da der Provider auf dem Zielsystem diese MOF interpretieren kann, weiß er was zu tun ist.

Im nächsten Teil wird es um Ressourcen gehen: Wie man diese findet, installiert und einsetzt. Dazu wird es viele interessante Beispiele geben.

Über Andreas Bittner

MCSA Server 2016, MCSA Server 2012R2, Exchange 2010 & SharePoint Devop
Dieser Beitrag wurde unter Allgemein, DSC, Grundlage, PowerShell abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.