Einrichten von Continuous Deployment mit Chocolatey

In einer DevOps-Umgebung gibt es viele Tools, die an den verschiedenen Punkten der Continuous Integration-Pipeline als Hilfe dienen. Azure Automation State Configuration ist eine willkommene neue Option für DevOps-Teams.

Azure Automation ist ein verwalteter Dienst in Microsoft Azure, mit dem Sie verschiedene Aufgaben automatisieren können, indem Sie Runbooks, Knoten und freigegebene Ressourcen verwenden, z. B. Anmeldeinformationen, Zeitpläne und globale Variablen. Azure Automation State Configuration erweitert diese Automatisierungsfunktion auf PowerShell DSC-Tools (Desired State Configuration). Hier ist eine gute Übersicht.

In diesem Artikel wird das Einrichten von Continuous Deployment (CD) für einen Windows-Computer veranschaulicht. Sie können das Verfahren problemlos so erweitern, dass in der Rolle (z. B. einer Website) so viele Windows-Computer wie nötig enthalten sind, und von diesem Punkt aus noch eine Erweiterung auf zusätzliche Rollen durchführen.

Allgemeines

Dieser Bereich ist recht komplex, aber glücklicherweise lässt er sich in zwei Hauptprozesse unterteilen:

• Das Schreiben und Testen von Code und das anschließende Erstellen und Veröffentlichen von Installationspaketen für größere und kleinere Versionen des Systems.
• Das Erstellen und Verwalten von virtuellen Computern, mit denen der Code in den Paketen installiert und ausgeführt wird.

Nachdem diese beiden Kernprozesse eingerichtet wurden, ist es nur noch ein kleiner Schritt zum automatischen Aktualisieren des Pakets auf Ihren VMs, wenn neue Versionen erstellt und bereitgestellt werden.

Übersicht über die Komponenten

Paket-Manager (z. B. apt-get) sind in der Linux-Welt recht bekannt, aber dies gilt nicht so sehr für die Windows-Welt. Chocolatey ist ein Paket-Manager für Windows. Scott Hanselmans Blogbeitrag über Chocolatey ist eine großartige Einführung. Mit Chocolatey können Sie Pakete über die Befehlszeile aus einem zentralen Paketrepository auf einem Windows-Betriebssystem installieren. Sie können ein eigenes Repository erstellen und verwalten, und Chocolatey kann Pakete aus allen Repositorys installieren, die Sie angeben.

PowerShell DSC ist ein PowerShell-Tool, mit dem Sie die gewünschte Konfiguration für einen Computer deklarieren können. Wenn Sie beispielsweise Chocolatey und IIS installieren und Port 80 öffnen möchten und Version 1.0.0 Ihrer Website installiert werden soll, wird diese Konfiguration vom DSC Local Configuration Manager (LCM) implementiert. Ein DSC-Pullserver enthält ein Repository mit Konfigurationen für Ihre Computer. Der LCM jedes Computers checkt sich regelmäßig ein, um zu überprüfen, ob die Konfiguration mit der gespeicherten Konfiguration übereinstimmt. Es kann entweder der Status gemeldet werden, oder es kann versucht werden, den Computer wieder auf den Stand der gespeicherten Konfiguration zu bringen. Sie können die gespeicherte Konfiguration auf dem Pullserver bearbeiten, um einen Computer oder eine Gruppe von Computern auf den Stand der geänderten Konfiguration zu bringen.

Eine DSC-Ressource ist ein Codemodul mit speziellen Funktionen, z. B. zur Verwaltung von Netzwerken, Active Directory oder SQL Server. Die Chocolatey DSC-Ressource kann unter anderem zum Zugreifen auf einen NuGet-Server, Herunterladen von Paketen und Installieren von Paketen verwendet werden. Der PowerShell-Katalog enthält noch viele weitere DSC-Ressourcen. Sie installieren diese Module auf Ihrem Pullserver für Azure Automation State Configuration, damit sie für die Konfigurationen verwendet werden können.

Resource Manager-Vorlagen bieten eine deklarative Methode zum Generieren von Ressourcen für Ihre Infrastruktur, z. B.:

• Netzwerke und Subnetze
• Netzwerksicherheit
• Routing
• Lastenausgleich
• NICs, VMs und sonstige

Einen Vergleich des Resource Manager-Bereitstellungsmodells (deklarativ) mit dem klassischen Azure-Bereitstellungsmodell (imperativ) finden Sie unter Azure Resource Manager im Vergleich zur klassischen Bereitstellung. In diesem Artikel geht es um die Bereiche Kernressourcenanbieter: Compute, Speicher und Netzwerk.

Ein wichtiges Merkmal einer Resource Manager-Vorlage ist die Möglichkeit, während Bereitstellung eines virtuellen Computers eine VM-Erweiterung zu installieren. Eine VM-Erweiterung verfügt über bestimmte Funktionen, z. B. das Ausführen eines benutzerdefinierten Skripts, das Installieren einer Antivirensoftware oder das Ausführen eines DSC-Konfigurationsskripts. Es gibt noch viele andere Arten von VM-Erweiterungen.

Kurzvorstellung des Diagramms

Sie beginnen oben und schreiben Ihren Code, führen die Erstellung und das Testen durch und erstellen dann ein Installationspaket. Chocolatey kann verschiedene Arten von Installationspaketen verarbeiten, z. B. MSI, MSU, ZIP. Außerdem verfügen Sie über die volle Leistungsfähigkeit von PowerShell zum Durchführen der eigentlichen Installation, falls die nativen Funktionen von Chocolatey nicht ausreichen sollten. Legen Sie das Paket an einem erreichbaren Ort ab, z. B. in einem Paketrepository. In diesem Anwendungsbeispiel wird ein öffentlicher Ordner in einem Azure Blob Storage-Konto verwendet, aber er kann sich an einem beliebigen Ort befinden. Chocolatey arbeitet standardmäßig mit NuGet-Servern und einigen anderen zusammen, was die Verwaltung der Paketmetadaten betrifft. Die Optionen werden in diesem Artikel beschrieben. Im Anwendungsbeispiel wird NuGet verwendet. Bei „Nuspec“ handelt es sich um Metadaten zu Ihren Paketen. Die NUSPEC-Informationen werden in einem NuPkg kompiliert und auf einem NuGet-Server gespeichert. Wenn Ihre Konfiguration ein Paket anhand des Namens anfordert und auf einen NuGet-Server verweist, verwendet die Chocolatey DSC-Ressource auf dem virtuellen Computer das Paket und installiert es. Sie können auch eine bestimmte Version eines Pakets anfordern.

Im Bildbereich links unten ist eine Azure Resource Manager-Vorlage dargestellt. In diesem Anwendungsbeispiel wird der virtuelle Computer von der VM-Erweiterung beim Pullserver für Azure Automation State Configuration als Knoten registriert. Die Konfiguration wird zweimal auf dem Pullserver gespeichert: einmal als Nur-Text und einmal als kompilierte MOF-Datei. Im Azure-Portal ist die MOF-Datei eine Knotenkonfiguration (im Gegensatz zu einer normalen Konfiguration).

Es ist relativ einfach, die Nuspec zu erstellen, zu kompilieren und auf einem NuGet-Server zu speichern. Der nächste Schritt für die kontinuierliche Bereitstellung erfordert die folgenden einmaligen Aufgaben:

• Einrichten des Pullservers
• Registrieren der Knoten beim Server
• Erstellen der Erstkonfiguration auf dem Server

Sie müssen die Konfiguration und die Knotenkonfiguration nur auf dem Pullserver aktualisieren, wenn Sie Pakete für das Repository aktualisieren und bereitstellen.

Wenn Sie nicht mit einer Resource Manager-Vorlage beginnen, gibt es PowerShell-Befehle, mit denen Sie Ihre virtuellen Computer beim Pullserver registrieren können. Weitere Informationen finden Sie unter Onboarding von Computern zur Verwaltung durch Azure Automation DSC.

Informationen zum Anwendungsbeispiel

Im Anwendungsbeispiel in diesem Artikel wird von einem virtuellen Computer aus einem generischen Windows Server 2012 R2-Image aus dem Azure-Katalog ausgegangen. Sie können mithilfe eines beliebigen gespeicherten Image starten und dann mit der Optimierung mithilfe der DSC-Konfiguration beginnen. Das Ändern einer Konfiguration, die in ein Image integriert ist, ist aber deutlich schwieriger als das dynamische Aktualisieren der Konfiguration per DSC.

Sie müssen keine Resource Manager-Vorlage und dann die VM-Erweiterung verwenden, um dieses Verfahren mit Ihren virtuellen Computern zu nutzen. Und Ihre virtuellen Computer müssen nicht unter Azure vorhanden sein, um in den Genuss der CD-Verwaltung zu kommen. Installieren Sie einfach Chocolatey, und konfigurieren Sie das LCM auf der VM, damit bekannt ist, wo sich der Pullserver befindet.

Wenn Sie ein Paket auf einem virtuellen Computer aktualisieren, der sich in der Produktion befindet, müssen Sie diesen virtuellen Computer aus der Rotation nehmen, während das Update installiert wird. Die Vorgehensweise kann dabei stark variieren. Beispielsweise können Sie bei einem virtuellen Computer hinter einem Azure Load Balancer einen benutzerdefinierten Test hinzufügen. Richten Sie dies so ein, dass der Testendpunkt während der Aktualisierung des virtuellen Computers eine „400“ zurückgibt. Die erforderliche Optimierung für diese Änderung kann sich innerhalb Ihrer Konfiguration befinden. Dies gilt auch für den Wechsel zurück zur Rückgabe einer „200“, nachdem das Update abgeschlossen ist.

Den vollständigen Quellcode für dieses Anwendungsbeispiel finden Sie in diesem Visual Studio-Projekt bei GitHub.

Schritt 1: Einrichten des Pullservers und des Automation-Kontos

Führen Sie die folgenden Befehle in einer authentifizierten (Connect-AzAccount) PowerShell-Sitzung aus:

New-AzResourceGroup -Name MY-AUTOMATION-RG -Location MY-RG-LOCATION-IN-QUOTES
$newAzAutomationAccountSplat = @{
    ResourceGroupName = 'MY-AUTOMATION-RG'
    Location = 'MY-RG-LOCATION-IN-QUOTES'
    Name = 'MY-AUTOMATION-ACCOUNT'
}
New-AzAutomationAccount @newAzAutomationAccountSplat

Dieser Schritt dauert einige Minuten, während der Pullserver eingerichtet wird.

Sie können Ihr Automatisierungskonto in einer der folgenden Azure-Regionen erstellen:

• USA (Ost) 2
• USA Süd Mitte
• US Government, Virginia
• Europa, Westen
• Asien, Südosten
• Japan, Osten
• Indien, Mitte
• Australien, Südosten
• Kanada, Mitte
• Nordeuropa

Schritt 2: Optimieren der VM-Erweiterung für die Resource Manager-Vorlage

Details zur VM-Registrierung (mit der PowerShell DSC-VM-Erweiterung) finden Sie in dieser Azure-Schnellstartvorlage. In diesem Schritt wird Ihr neuer virtueller Computer beim Pullserver in der Liste der Zustandskonfigurationsknoten registriert. Ein Teil dieser Registrierung ist das Angeben der Knotenkonfiguration, die auf den Knoten angewendet wird. Diese Knotenkonfiguration muss noch nicht auf dem Pullserver vorhanden sein, Sie müssen jedoch den Namen des Knotens und den Namen der Konfiguration auswählen. In diesem Beispiel ist der Knoten isvbox und der Konfigurationsname ISVBoxConfig. Der in DeploymentTemplate.json angegebene Knotenkonfigurationsname ist ISVBoxConfig.isvbox.

Schritt 3: Hinzufügen von erforderlichen DSC-Ressourcen auf dem Pullserver

Der PowerShell-Katalog kann DSC-Ressourcen in Ihrem Azure Automation-Konto installieren. Navigieren Sie zu der gewünschten Ressource, und wählen Sie In Azure Automation bereitstellen aus.

Ein weiteres Verfahren, das erst kürzlich im Azure-Portal hinzugefügt wurde, ermöglicht das Pullen neuer Module oder das Aktualisieren bereits vorhandener Module. Wählen Sie das Symbol Katalog durchsuchen aus, um die Liste der Module im Katalog anzuzeigen, Details anzuzeigen und in Ihr Automatisierungskonto zu importieren. Sie können diesen Prozess verwenden, um Ihre Module auf dem neuesten Stand zu halten. Das Importfeature überprüft zudem Abhängigkeiten von anderen Modulen, um zu gewährleisten, dass alles synchron ist.

Es gibt auch ein manuelles Verfahren, das nur einmal pro Ressource verwendet wird, sofern Sie später kein Upgrade ausführen möchten. Weitere Informationen zum Erstellen von PowerShell-Integrationsmodulen finden Sie unter Erstellen von Integrationsmodulen für Azure Automation.

1. Installieren Sie Windows Management Framework v5 (unter Windows 10 nicht erforderlich).

2. Installieren Sie das Integrationsmodul.

   Install-Module -Name MODULE-NAME`    <—grabs the module from the PowerShell Gallery
   

3. Kopieren Sie den Modulordner unter C:\Program Files\WindowsPowerShell\Modules\MODULE-NAME in einen temporären Ordner.

4. Löschen Sie Beispiele und Dokumentation aus dem Hauptordner.

5. Zippen Sie den Hauptordner, und benennen Sie die ZIP-Datei mit dem Namen des Ordners.

6. Speichern Sie die ZIP-Datei an einem zugänglichen HTTP-Speicherort, z. B. in Blob Storage in einem Azure Storage-Konto.

7. Führen Sie den folgenden Befehl aus.

   $newAzAutomationModuleSplat = @{
       ResourceGroupName = 'MY-AUTOMATION-RG'
       AutomationAccountName = 'MY-AUTOMATION-ACCOUNT'
       Name = 'MODULE-NAME'
       ContentLinkUri = 'https://STORAGE-URI/CONTAINERNAME/MODULE-NAME.zip'
   }
   New-AzAutomationModule @newAzAutomationModuleSplat
   

Im enthaltenen Beispiel werden diese Schritte für cChoco und xNetworking implementiert.

Schritt 4: Hinzufügen der Knotenkonfiguration auf dem Pullserver

Es ist nichts Besonderes zu beachten, wenn Sie Ihre Konfiguration zum ersten Mal in den Pullserver importieren und die Kompilierung durchführen. Alle nachfolgenden Import- und Kompiliervorgänge derselben Konfiguration sehen dann genau gleich aus. Bei jeder Aktualisierung des Pakets und der Umstellung auf die Produktion führen Sie diesen Schritt aus, nachdem Sie sichergestellt haben, dass die Konfigurationsdatei korrekt ist – einschließlich der neuen Version Ihres Pakets. Dies ist die Konfigurationsdatei ISVBoxConfig.ps1:

Configuration ISVBoxConfig
{
    Import-DscResource -ModuleName cChoco
    Import-DscResource -ModuleName xNetworking

    Node 'isvbox' {

        cChocoInstaller installChoco
        {
            InstallDir = 'C:\choco'
        }

        WindowsFeature installIIS
        {
            Ensure = 'Present'
            Name   = 'Web-Server'
        }

        xFirewall WebFirewallRule
        {
            Direction    = 'Inbound'
            Name         = 'Web-Server-TCP-In'
            DisplayName  = 'Web Server (TCP-In)'
            Description  = 'IIS allow incoming web site traffic.'
            Enabled       = 'True'
            Action       = 'Allow'
            Protocol     = 'TCP'
            LocalPort    = '80'
            Ensure       = 'Present'
        }

        cChocoPackageInstaller trivialWeb
        {
            Name      = 'trivialweb'
            Version   = '1.0.0'
            Source    = 'MY-NUGET-V2-SERVER-ADDRESS'
            DependsOn = '[cChocoInstaller]installChoco','[WindowsFeature]installIIS'
        }
    }
}

Das folgende New-ConfigurationScript.ps1-Skript wurde geändert, um das Az PowerShell-Modul zu verwenden:

$importAzAutomationDscConfigurationSplat = @{
    ResourceGroupName = 'MY-AUTOMATION-RG'
    AutomationAccountName = 'MY-AUTOMATION-ACCOUNT'
    SourcePath = 'C:\temp\AzureAutomationDsc\ISVBoxConfig.ps1'
    Published = -Published
    Force = -Force
}
Import-AzAutomationDscConfiguration @importAzAutomationDscConfigurationSplat

$startAzAutomationDscCompilationJobSplat = @{
    ResourceGroupName = 'MY-AUTOMATION-RG'
    AutomationAccountName = 'MY-AUTOMATION-ACCOUNT'
    ConfigurationName = 'ISVBoxConfig'
}
$jobData = Start-AzAutomationDscCompilationJob @startAzAutomationDscCompilationJobSplat

$compilationJobId = $jobData.Id

$getAzAutomationDscCompilationJobSplat = @{
    ResourceGroupName = 'MY-AUTOMATION-RG'
    AutomationAccountName = 'MY-AUTOMATION-ACCOUNT'
    Id = $compilationJobId
}
Get-AzAutomationDscCompilationJob @getAzAutomationDscCompilationJobSplat

Schritt 5: Erstellen und Verwalten von Paketmetadaten

Für jedes Paket, das Sie im Paketrepository speichern, benötigen Sie eine NUSPEC-Datei, in der das Paket beschrieben wird. Sie muss auf Ihrem NuGet-Server kompiliert und gespeichert werden. Weitere Informationen finden Sie unter Erstellen eines NuGet-Pakets mit der nuget.exe-CLI.

Sie können MyGet.org als NuGet-Server verwenden. Sie können diesen Dienst erwerben, aber es steht auch eine kostenlose Starter-SKU zur Verfügung. Anweisungen zum Installieren Ihres eigenen NuGet-Servers für Ihre privaten Pakete finden Sie in der Dokumentation zu Nuget.org.

Schritt 6: Zusammenfügen aller Komponenten

Bei jedem Bestehen des Qualitätssicherungstests durch eine Version und anschließender Genehmigung für die Bereitstellung wird das Paket erstellt, und die NUSPEC-Datei und das Nupkg werden aktualisiert und auf dem NuGet-Server bereitgestellt. Sie müssen die Konfiguration (Schritt 4) mit der neuen Versionsnummer aktualisieren. Senden Sie es dann an den Pullserver, und kompilieren Sie es.

Ab diesem Punkt liegt es an den virtuellen Computern, die von dieser Konfiguration abhängig sind, das Update abzurufen und zu installieren. Diese Updates sind einfach und umfassen nur ein oder zwei Codezeilen in PowerShell. Bei Azure DevOps sind einige davon in Buildaufgaben gekapselt, die in einem Build miteinander verkettet werden können. Dieser Artikel enthält hierzu weitere Details. In diesem GitHub-Repository finden Sie Details zu den verfügbaren Buildaufgaben.

Verwandte Artikel

• Azure Automation DSC – Übersicht
• Integrieren von Computern für die Verwaltung durch Azure Automation DSC

Nächste Schritte

• Eine Übersicht finden Sie unter Übersicht über Azure Automation State Configuration.
• Eine Einführung in dieses Feature finden Sie unter Erste Schritte mit Azure Automation State Configuration.
• Wie Sie DSC-Konfigurationen kompilieren und sie anschließend Zielknoten zuweisen, erfahren Sie unter Kompilieren von DSC-Konfigurationen in Azure Automation State Configuration.
• Eine Referenz zu den PowerShell-Cmdlets finden Sie unter Az.Automation.
• Eine Preisübersicht finden Sie unter Automation – Preise.