28.03.2017

Desired State Configuration für PowerShell 5.0

Als der mutmaßlich beste Dienstleister der Welt versuchen wir immer, am Ball zu bleiben, was aktuelle Technik angeht. Ein heißes Eisen ist ja die verrückte Cloud. So sind wir natürlich auch dabei, tief in das Thema einzusteigen: Wir bauen unsere eigene Cloud bzw. bauen sie weiter aus! Coole Sache, aber wenn man Dienste in der Cloud anbieten will, muss man eine Menge Server bzw. Server-VMs managen. Und das so, dass der Kunde keine Ausfälle abbekommt, schließlich bezahlt er dafür ja schwerverdiente Goldmünzen!

Was aber, wenn man nun Änderungen an Systemen vornehmen will/muss, um Sicherheitslücken in Betriebssystemen zu stopfen? Oder Software und Systeme aktualisieren muss? Klar, man testet es vorher in einem Testsystem. Aber dann muss man die Änderungen (nach erfolgreichem Test) in die Produktion übernehmen. Auf vielleicht unfassbar vielen Servern … Sicher kein Job, den man per Hand machen will. Jede Änderung muss also maximal automatisiert werden, sodass keine Fehler passieren und man einen schnellen Weg zurück hat, falls es doch mal klemmt. Vor allem braucht man Nachvollziehbarkeit, was auf welchem Server passiert ist, und man benötigt Standardisierung. Also im Prinzip rede ich hier von DevOps-Problemen.

Ich bin ein Windows-Typ und begeisterter PowerShell-Fuzzi. Diese genannten Problemstellungen haben mich dazu angeregt, mich in ein Thema einzuarbeiten, das mich seit PowerShell 3.0 interessiert: das magische DSC aka Desired State Configuration!

Was ist das? Es ist blaues Licht. Was macht es? Es leuchtet blau.

DSC ist also eine Möglichkeit, Konfigurationen eines Betriebssystems vorzugeben und auf ein OS zu deployen. 

Was?

Ich kann sagen: „Ihr da, Server 1 bis 4, sollt so aussehen: <Du bist ein sicherer (https-)Webserver und hast die Webseite MeineSeite.html und lauschst auf Anfragen auf Port 443. Dein Zertifikat liegt hier. >“

Und DSC sorgt dafür, dass es so ist und vor allem: so bleibt!

Oh, cool! Auch wenn jemand was ändert, z.B. den listener port des Webservers?

Ja! Dann macht DSC einfach wieder den ursprünglichen Webserver daraus. Fett, oder?

Absolut! Ist das kompliziert?

Das liegt im Auge des Betrachters! Aber eigentlich: Ja. Man sollte sich schon in der PowerShell gut auskennen und die Prinzipien durchschauen, bevor man sich da ranwagt. (Wir bieten hervorragende Kurse zu PowerShell-Grundlagen an! Verpasst nicht den Zug!)

Microsoft hat hier das Rad nicht neu erfunden. Wie so oft schauen sich die Kumpels von Microsoft das woanders ab. Daran ist nichts Schlechtes, es zeigt nur, dass das Prinzip schon länger etabliert ist und sichtlich funktioniert! „Puppet“ z.B. ist eine Software, die ebenfalls zentrales „Configuration Management“ ermöglicht und das schon seit 2005. Es gibt sogar Schnittstellen, die es ermöglichen, PowerShell DSC zusammen mit Puppet zu verwenden.

Okay, genug gefaselt. Wie funktioniert es nun?

Ich habe mich durchgequält und es soll gesagt sein, es war kein einfacher Weg! Das Erste, was man wissen sollte, ist, dass man über die PowerShell in einem Configuration-Skript beschreibt, wie ein Server aussehen soll. Hier ein Beispiel:

Ich werde vorerst nicht im Detail erklären, wie die Syntax funktioniert, es soll erstmal einen Eindruck vermitteln, wie der Code aussieht. Definiert wird hier lediglich, dass die IIS-Rolle installiert sein muss und das Rollenfeature ASP.NET 4.5.

Aus diesem Skript lassen sich MOF-Dateien (Managed Object File) generieren, die ein Dienst auf dem Zielserver interpretieren und umsetzen kann.

Das MOF-File muss auf den Server gebracht und dort von dem Dienst „LCM“ (Local Configuration Manager) eingelesen und umgesetzt werden.

Wie kommt das MOF nun auf den Server? Da wird es spannend. Ich bin ganz aufgeregt!

  1. Ich kopiere es da „händisch“ hin. Anschließend sage ich dem LCM: „Mach mal.“ – Buuuuh! Laaangweilig!
  2. Oder ich schiebe es per PowerShell mit einem Skript dorthin und sage dem Server gleich in dem Zug: „Mach mal!“ – Joah, schon besser, kann man ja dann automatisieren, aber auch noch nicht so toll.
  3. Ich definiere einen Webserver, lege da das File ab und sage dem Zielserver: Da findest du deine Config und guck da alle 30 Minuten nach, ob deine Config stimmt und ob es eine neue Config gibt. – Oh, echt jetzt? Ist ja cool!

Fall 3 ist der komplexeste und nicht zu empfehlen, wenn man „mal schnell“ ein Ergebnis sehen will. Aaaaaaber: Der zentrale Server sorgt quasi für eine zentrale Ablage von verschiedenen Config-Files (MOFs) und ist für die Zielserver (DSC-Nodes) entspannt über http/https erreichbar. Also wenn es clever gemacht wird: von ÜBERALL aus erreichbar! So ein Server wird dann „Pull-Server“ genannt, weil sich die DSC-Nodes (Pull-Clients) die Config-Files vom Webserver „ziehen“.

Bauen wir das mal weiter aus: Ich habe nun auf meinem Pull-Server verschiedene Config-Files für verschiedene Zwecke abgelegt: Webserver, Fileserver und Applikationsserver. Nun erstelle ich aus einem VM-Template eine neue virtuelle Maschine und sage ihr nur noch „Das ist deine Pull-Server-URL und deine Config ist diese hier.“ Diese Schritte lassen sich über ein einzelnes PowerShell-Skript erledigen, den Rest macht Windows selbst. Sobald ich eine Änderung auf meine Webserverfarm ausrollen möchte, lege ich eine neue Webserver-Config auf dem Pull-Server ab und verschiebe die alte Config ins „Archiv“.

Auf diese Weise habe ich nicht nur viel automatisiert, sondern gleich eine Art Doku, was auf meinen Servern passiert ist. Das ist zwar etwas utopisch formuliert, aber es ist auch viel Wahres dran!

Das war jetzt einiges an Theorie und viel Gerede – lasst uns was bauen! Wir nehmen das Skript von oben und bauen uns ein MOF. Wir halten uns jetzt mal an die einfachste Push-Konfiguration. Einen Pull-Server bauen wir vielleicht mal in einem anderen Blog-Artikel auf, wenn es positive Resonanz gibt, es also auch irgendwen interessiert! ;-)

Dem Skript habe ich noch etwas hinzugefügt, nämlich den Aufruf der Konfiguration über seinen Namen. Das funktioniert genauso wie bei PowerShell-Funktionen!

Als Output bekommen wir ein File in die Pipeline und zwar unser MOF! Der Name des MOFs lautet genauso wie unser Nodename. Außerdem sehen wir mit unseren getrübten Adleraugen (we don’t C#) noch, dass das MOF in einem neuen Ordner gelandet ist, der wiederum so heißt wie der Configuration Name.

So weit, so gut. Dann packen wir das Ganze mal auf den Zielserver! Mein Zielserver wird eine VM auf VMware; ich setze, während ich hier tippe, gerade die Maschine auf.

Was, VMware? Kein Hyper-V?

Ja, ich weiß, schockierend, oder? Ich bin zwar ein Microsoftie, aber unsere VMware-Umgebung dominiert hier im Haus einfach und für mich gibt es keinen Grund, jetzt extra einen Hyper-V aufzusetzen. Oder kurz gesagt: netlogix kann beides.

So, VM fertig, ist kein Domänenmitglied oder sonst was, einfach ein nackter Server 2016 (mit GUI, damit wir auch was sehen können). Wie kopiere ich das jetzt am besten? Natürlich per PowerShell, weil ich etwas zeigen will, das einem das Leben erleichtert und weil es unfassbar viel cooler aussieht:

Der Part wird noch niemanden überraschen: Ich baue eine PowerShell-Session per WinRM (http) zum Zielserver auf.

Aber jetzt kopieren wir unseren „MyConfig“-Ordner über diese (http-)Session auf den Zielhost. Und das ist cool, finde ich, und geht eben erst seit PowerShell 5.0!

Nun liegt auf dem Zielserver der Ordner „MyConfig“ zusammen mit dem MOF auf C:.

Machen wir doch weiter mit der PowerShell Magic:

Und siehe da, der Typ hat nicht gelogen! Es liegt wirklich dort. Verrückt.

Schauen wir mal, welche Windows-Features installiert sind!

Oder per GUI:

Auf jeden Fall kein Webserver. Also wie erzählen wir jetzt dem Server, dass er machen soll, was im MOF steht? Wir müssen dem LCM sagen, wo sein Config-File ist:

Da passiert doch auch schon etwas:

Und fertig:

Tadaaaa! Ein per DSC konfigurierter Webserver.

Öhhh … Auf den ersten Blick nun nicht besonders spektakulär. Das hätte man per GUI oder einfachem PS-Skript schneller hinbekommen.

Das stimmt wohl. Aber das war ja auch nur die einfachste Variante von DSC! Configuration Management ist das Zauberwort, das DSC in den höheren Ausbaustufen zu einem unfassbar bedeutsamen Tool macht.

Es wird richtig abgefahren, wenn man den Pull-Server betrachtet und die detaillierte LCM-Konfiguration. Für den LCM gibt es z.B. auch Config-Files (MOFs), damit er weiß, wo er seine MOFs für die Serverkonfiguration herholt. Diese Serverkonfigurations-MOFs liegen dann auf dem Webserver und müssen ein passendes Checksum-File haben. Dazu kommen noch die PowerShell Resource Files, die ebenso auf dem Webserver liegen müssen, damit jeder Server sich die passende Version ziehen kann, und auch die brauchen Checksum-Files. Dann möchte man natürlich auch ein Reporting haben, sodass man auf dem Pull-Server nachsehen kann, welche Rechner „compliant“ und überhaupt registriert sind. Es kommt also noch eine Report-Datenbank ins Spiel. Außerdem muss man sich um die Authentifizierung am Pull-Server kümmern, damit nicht jeder dahergelaufene Rechner diese Dateien abziehen kann! Und so wird man ein bisschen wahnsinniger, wenn man sich mit jedem Bug und jedem Feature auseinandersetzt, was bei mir dafür sorgte, dass verwirrt aussehende Übersichtszeichnungen herauskommen, die eher dem Zimmer eines Verschwörungstheoretikers entsprungen sein könnten:

Im nächsten Teil des Blogs werde ich wohl mal erklären, wie man einen Pull-Server aufsetzt. Das alles habe ich mir natürlich nicht aus den Fingern gesogen, sondern nur ausgenutzt, was schlaue Kerle bereits an Arbeit reingesteckt haben. Pauschal einfach mal danke an all die Blogger und MPFEs usw., die ihr Wissen bereitwillig teilen.

Alle Angaben wie immer ohne Gewähr, alles bitte immer gut testen, bevor man etwas kaputtmacht!

Sebastian Reitter
Senior Consultant

Unsere Blogs