DSC Extension verfügbar


Nach den CustomScript Extensions (siehe früheren Blog-Eintrag) ist nun auch die Extension für die "Desired State Configuration", kurz DSC, verfügbar in der Microsoft Cloud Deutschland. Damit ist es nun auch möglich, einen Soll- bzw. Wunsch-Stand zu definieren und neue oder vorhandene Server dagegen abzugleichen und auf den gewünschten Stand zu bringen. Wie das grob funktioniert, dazu ein kleines Beispiel.

Wir legen per ARM Template einen Windows Server 2012R2 an und möchten, dass der IIS aktiviert wird. Die Installation besteht - wie bei den CustomScript Extensions - aus zwei Teilen. Zuerst wird ganz gewöhnlich in einem Template die üblichen Ressourcen definiert wie Netzwerk, Storage, Compute etc. Für DSC benötigen wir noch zwei zusätzliche Parameter:

    "modulesUrl": {
      "type": "string",
      "defaultValue": "https://github.com/gitralf/mytemplates/raw/master/dsc-extension-iis-server-windows-vm/ContosoWebsite.ps1.zip",
      "metadata": {
        "description": "URL for the DSC configuration module. NOTE: Can be a Github url(raw) to the zip file"
      }
    },
    "configurationFunction": {
      "type": "string",
      "defaultValue": "ContosoWebsite.ps1\\ContosoWebsite",
      "metadata": {
        "description": "DSC configuration function to call"
      }
    }

Parallel zu den anderen Ressourcen fügen wir dann die Definition für DSC an:

    {
      "type": "Microsoft.Compute/virtualMachines/extensions",
      "name": "[concat(parameters('vmName'),'/', variables('vmExtensionName'))]",
      "apiVersion": "2015-05-01-preview",
      "location": "[resourceGroup().location]",
      "dependsOn": [
        "[concat('Microsoft.Compute/virtualMachines/', parameters('vmName'))]"
      ],
      "properties": {
        "publisher": "Microsoft.Powershell",
        "type": "DSC",
        "typeHandlerVersion": "2.19",
        "autoUpgradeMinorVersion": true,
        "settings": {
          "ModulesUrl": "[parameters('modulesUrl')]",
          "ConfigurationFunction": "[parameters('configurationFunction')]",
          "Properties": {
            "MachineName": "[parameters('vmName')]"
          }
        },
        "protectedSettings": null
      }

Der obere Teil ist nicht weiter spektakulär: type, name, apiVersion und location sind übliche Bestandteile einer Ressourcendefinition. Mittels dependsOn wird auf die Fertigstellung der Ressource "virtualMachine" gewartet, und dann geht DSC los. Hier eine komplette Einführung in alle Möglichkeiten von DSC zu bringen, würden den Artikel sprengen, aber ganz kurz sei der Aufbau doch erklärt. DSC erwartet Dateien in einem ZIP-File zum Download. Das ist der Inhalt des Parameters "ModulesUrl". Eine der darin verpackten Dateien wird ausgeführt, und welche das ist, steht in "ConfigurationFunction". Sollen dieser Funktion noch Parameter übergeben werden, dann folgen diese im Block "Properties", hier wird zum Beispiel der Name der VM als "MachineName" übergeben.

Die "ConfigurationFunction" ist für unser Beispiel sehr einfach und sieht so aus:

Configuration ContosoWebsite
{
  param ($MachineName)

  Node $MachineName
  {
    #Install the IIS Role
    WindowsFeature IIS
    {
      Ensure = "Present"
      Name = "Web-Server"
    }

    #Install ASP.NET 4.5
    WindowsFeature ASP
    {
      Ensure = "Present"
      Name = "Web-Asp-Net45"
    }

     WindowsFeature WebServerManagementConsole
    {
        Name = "Web-Mgmt-Console"
        Ensure = "Present"
    }
  }
} 

Wie leicht zu erkennen ist, erwarten wir zuerst den Parameter "MachineName", und definieren für diesen Knoten dann, dass die Windows Features IIS, ASP und die WebServerManagementConsole verfügbar sein sollen. ("Present"). Das war's auch schon.

Diese Datei wird dann (zusammen mit weiteren Dateien, zum Beispiel auch der kompletten Website) komprimiert und als ZIP bereitgestellt, entweder auf einer öffentlichen URL oder auch in Azure Storage, die dafür notwendigen Authentifizierungsinformationen können über die "ProtectedSettings" angegeben werden und tauchen dann später nicht mehr in der Zusammenfassung auf.

Beim Deployment wird dann die ZIP-Datei auf die fertige VM gespielt, entpackt und der Script ausgewertet. Hierbei wird die geforderte Konfiguration mit der aktuellen verglichen und Differenzen beseitigt. Da wir eine frische VM haben, sind die Services zuerst nicht verfügbar und werden daher von DSC nachinstalliert. Genauso können wir auch unerwünschte Services abschalten etc.

Das war's dann auch schon. Die ganzen restlichen Möglichkeiten von DSC, die sich auf PowerShell zum Beispiel noch bieten, kann man zum Beispiel in einem älteren Artikel von mir nachlesen oder im Artikel von Eric Slesar.

Das obige Beispiel findet sich auch zum Ausprobieren fertig angepasst für die Microsoft Cloud Deutschland auf GitHub.

Viel Spaß mit DSC!


Comments (0)

Skip to main content