DSC – Einführung in Desired State Configuration

Da bin ich neulich über ein (nicht nur) Azure Feature gestolpert, das klang recht interessant, nämlich DSC, ausgeschrieben Desired State Configuration. Das denke ich lohnt sich ein bisschen genauer zu betrachten. Also dann…

Was genau kann man mit DSC tun?

DSC ist nicht nur für Azure verfügbar, aber über eine Azure VM Extension eben auch dort. Und da dies hier ein Azure Blog ist, beschränke ich mich mal auf die Beschreibung des Azure Szenarios. Einfach ausgedrückt kann man mit DSC vorgeben, welche Services, Features, Dateien etc in einer Azure VM vorhanden sein sollen oder auch nicht. Zwei Umstände machen das Feature noch interessanter:

• die Konfiguration (oder besser der gewünschte Zustand) kann einfach über Textdateien per Azure Extension von außen vorgegeben werden
• das Ganze lässt sich prima in PowerShell bewerkstelligen.

Was lässt sich genau damit konfigurieren? Nun, man kann

• Rollen/Features aktivieren bzw. deaktivieren
• Dienste konfigurieren
• Registry Einstellungen tätigen 
• Dateien/Verzeichnisse bereitstellen
• Gruppen/Benutzer vorgeben
• neue Software installieren
• Skripte ausführen
• Umgebungsvariablen setzen

Klingt soweit interessant? Los geht’s! Die komplette Liste der Möglichkeiten findet sich hier.

Das Grundprinzip

Wie funktioniert DSC grob betrachtet?

• wir erzeugen lokal eine Textdatei (quasi ein PowerShell-Script), in der die gewünschte Konfiguration beschrieben ist
• wir veröffentlichen diese Konfiguration in Azure (genauer gesagt in einem Azure Blob Storage Container) als zip-Datei
• wir weisen diese Konfiguration einer VM zu (über die Extension)
• die Extension holt sich das ZIP-File und entpackt es in der VM
• analysiert die Konfiguration (Soll-Ist Vergleich)
• und führt Änderungen durch

Diese Schritte lassen sich entweder gleich beim Ausrollen einer neuen VM durchführen, oder nachträglich auf bereits vorhandene VMs anwenden. Wir werden erst mal eine vorhandene VM nehmen.

Voraussetzungen

Für DSC sind nur minimale Voraussetzungen zu erfüllen, nämlich mindestens die Version 0.8.6 der Azure PowerShell Cmdlets. Eigentlich sollte das ja mittlerweile jeder haben, zur Sicherheit schauen wir aber mal nach, ob die DSC-Extension auch wirklich zur Verfügung steht:

Get-AzureVMAvailableExtension –Publisher Microsoft.PowerShell

Da sollte dann eine Extension mit dem ExtensionName “DSC” erscheinen. Wunderbar. Alle Voraussetzungen erfüllt.

Erzeugen der Konfiguration

Für unser Beispiel nehmen wir mal an, wir möchten nachträglich einen IIS in der VM installieren. Wir bauen folgendes Textfile:

configuration IISInstall
{
node ("localhost")
{
WindowsFeature IIS
{
Ensure = "Present"
Name = "Web-Server"
}
}
}

(Vielen Dank an dieser Stelle übrigens an das PowerShell Team, von dem ich die Beispiele ausgeliehen habe…)

Liest sich eigentlich ganz locker runter, oder? Die Konfiguration bekommt einen Namen (IISInstall), die für den jeweiligen localhost gelten soll, wir reden von einem Windows-Feature (nicht von Registry, Dateien etc) und wollen, dass der Dienst “Web-Server” präsent ist. Kein Hexenwerk.

Wer sich jetzt fragt, welche Bezeichnung für das Feature benötigt werden… Hinter “WindowsFeature” ist das ganz egal, aber bei “Name=” steht die Name-Eigenschaft aus “Get-WindowsFeature”.

Veröffentlichen der Konfiguration

Wir haben die obige erste Konfigurationsdatei abgespeichert als c:\test\iisinstall.ps1, und sind jetzt bereit, die Konfiguration zu “publishen”, also zu paketieren und auf dem Azure Storage abzulegen. Wir legen die Datei erst mal nur lokal ab, um mal reinschauen zu können, und erst dann nach Azure.

Lokales Verzeichnis

publish-AzureVMDscConfiguration –ConfigurationPath C:\test\iisinstall.ps1 -ConfigurationArchivePath C:\test\iisinstall.ps1.zip

(natürlich alles in einer Zeile geschrieben) erzeugt eine zip-Datei, die wir uns (durch die Angabe von ConfigurationArchivePath) auch mal interessehalber anschauen können. Ist in unserem kleinen Beispiel wenig spektakulär, aber wenn wir auch Dateien oder Verzeichnisse automatisiert verteilen wollen, dann kämen die zum Beispiel auch hier rein.

Azure Storage

Etwas kürzer ist das Kommando, um die Konfiguration direkt im Azure Storage zu speichern:

publish-AzureVMDscConfiguration -ConfigurationPath C:\test\iisinstall.ps1

macht das gleiche wie im ersten Schritt, spielt aber die zip-Datei gleich in einen Storage-Container in Azure. DSC verwendet dabei einen Container namens “windows-powershell-dsc” im Standard-Azure Storage Account. Ein kurzer Einschub zum Standard-Azure Storage Account…

Standard Storage Account

Sobald man mit seinem Azure-Account per PowerShell verbunden ist, bitte  mal eingeben:

get-AzureSubscription

Es erscheinen ein paar Metadaten über die aktuelle Subscription, zum Beispiel die ID, der Name, und der CurrentStorageAccountName. Um genau letzteren geht es, der wird immer verwendet, wenn wir keinen anderen angegeben haben (so wie in unserem DSC-Beispiel). Oft steht hier nichts drin, dann muss der erst noch gesetzt werden. Eigentlich ganz einfach, wir brauchen die ID der Subscription (die wird uns grade angezeigt) und den Namen des Storage Accounts, und den bekommen wir über – ganz einfach:

get-AzureStorageAccount

Das Attribut, das uns interessiert, heißt “Label”, und meistens beginnt es mit “portalvhd…”. Es kann aber auch ein anders Storage Account verwendet werden. Um das Standard Storage Account zu setzen, brauchen wir also:

set-AzureSubscription –SubscriptionID <hier die lange ID> –CurrentStorageAccountName <hier das Label des Storages>

Zuweisen der Konfiguration

Wir gehen für diese Einführung mal davon aus, dass alles im Standard-Container im Standard-Storage liegt. Andere Fälle betrachten wir später.

Wir besorgen uns erst mal ein PowerShell-Objekt mit der VM. Wenn wir wissen, wie die VM heißt, umso einfacher, ansonsten erst mal alle VMs auflisten (mit get-AzureVM) und auswählen. Unsere heißt “dscvm1”:

$vm=get-AzureVM –Service dscservice1 –Name dscvm1

Jetzt verknüpfen wir unsere hochgeladene Konfiguration mit dieser VM:

Set-AzureVMDscExtension –VM $vm –ConfigurationArchive install.ps1.zip –ConfigurationName IISInstall

Die Angabe bei “ConfigurationArchiv” sollte klar sein, den “ConfigurationName” finden wir in unserem Konfigurationsfile (s.o.) hinter der Direktive “configuration”. Das ist zum Beispiel für den Fall, dass man mehrere Konfigurationen in einer Datei abspeichern möchte.

Das war es eigentlich auch schon. Wir machen noch schnell ein Update der VM:

$vm | update-azureVM

Ob alles klappt (oder warum nicht), sehen wir zum Beispiel in den Logfiles in der VM.

Logfiles

Die Logfiles liegen auf der jeweiligen VM. Wir fangen mal an mit dem Verzeichnis “c:\WindowsAzure\Logs\” und dem “WaAppAgent.*.log”. Da stehen generelle Informationen zur Installation der Extension drin.

Weiter unten im Verzeichnis, genauer “c:\WindowsAzure\Logs\Plugins\Microsoft.PowerShell.DSC\1.0.0.0” oder so, da stehen dann lauter Logfiles der DSC Extension drin für weitere Fehlersuche, einige davon mit Datum im Dateinamen.

Eine andere Möglichkeit ist, sich über das Portal die VM anzusehen, dort steht bei der VM dann auch der letzte Status der Extension angezeigt.

Zusammenfassung

Wir haben also gesehen, wie einfach es ist, in einer Textdatei diverse Konfigurationen vorzugeben und auf VMs in Azure anzuwenden. Im nächsten Teil des Artikels werde ich noch ein paar andere Fälle beschreiben, zum Beispiel

• verwenden eines anderen Storage Containers
• Anwenden der Konfiguration beim Erstellen neuer VMs
• weitere Beispiele für Konfigurationen

 

Bis dann!