Dela via


Konfigurera kontinuerlig distribution med Chocolatey

Kommentar

Innan du aktiverar Automation State Configuration vill vi att du ska veta att en nyare version av DSC nu är allmänt tillgänglig, som hanteras av en funktion i Azure Policy med namnet gästkonfiguration. Gästkonfigurationstjänsten kombinerar funktioner i DSC-tillägget, Azure Automation State Configuration och de vanligaste funktionerna från kundfeedback. Gästkonfigurationen omfattar även stöd för hybriddatorer via Arc-aktiverade servrar.

I en DevOps-värld finns det många verktyg för att hjälpa till med olika punkter i pipelinen för kontinuerlig integrering. Azure Automation State Configuration är ett välkommet nytt tillägg till de alternativ som DevOps-team kan använda.

Azure Automation är en hanterad tjänst i Microsoft Azure som gör att du kan automatisera olika uppgifter med hjälp av runbooks, noder och delade resurser, till exempel autentiseringsuppgifter, scheman och globala variabler. Azure Automation State Configuration utökar den här automatiseringsfunktionen till att omfatta DSC-verktyg (PowerShell Desired State Configuration). Här är en bra översikt.

Den här artikeln visar hur du konfigurerar kontinuerlig distribution (CD) för en Windows-dator. Du kan enkelt utöka tekniken till att inkludera så många Windows-datorer som behövs i rollen, till exempel en webbplats, och gå därifrån till ytterligare roller.

Continuous Deployment for IaaS VMs

På hög nivå

Det är ganska mycket som händer här, men lyckligtvis kan det delas upp i två huvudprocesser:

  • Skriva kod och testa den och sedan skapa och publicera installationspaket för större och mindre versioner av systemet.
  • Skapa och hantera virtuella datorer som installerar och kör koden i paketen.

När båda dessa kärnprocesser är på plats är det enkelt att automatiskt uppdatera paketet på dina virtuella datorer när nya versioner skapas och distribueras.

Komponentöversikt

Pakethanterare som apt-get är välkända i Linux-världen, men inte så mycket i Windows-världen. Chocolatey är en sådan sak, och Scott Hanselmans blogg om ämnet är en bra introduktion. I ett nötskal låter Chocolatey dig använda kommandoraden för att installera paket från en central lagringsplats till ett Windows-operativsystem. Du kan skapa och hantera din egen lagringsplats, och Chocolatey kan installera paket från valfritt antal lagringsplatser som du anger.

PowerShell DSC är ett PowerShell-verktyg som gör att du kan deklarera den konfiguration som du vill använda för en dator. Om du till exempel vill ha Chocolatey installerat, IIS installerat, port 80 öppnat och version 1.0.0 av webbplatsen installerad, implementerar DSC Local Configuration Manager (LCM) den konfigurationen. En DSC-pull-server innehåller en lagringsplats med konfigurationer för dina datorer. LCM på varje dator checkar in regelbundet för att se om dess konfiguration matchar den lagrade konfigurationen. Den kan antingen rapportera status eller försöka anpassa datorn till den lagrade konfigurationen igen. Du kan redigera den lagrade konfigurationen på hämtningsservern så att en dator eller uppsättning datorer hamnar i linje med den ändrade konfigurationen.

En DSC-resurs är en kodmodul som har specifika funktioner, till exempel hantering av nätverk, Active Directory eller SQL Server. Chocolatey DSC-resursen vet hur du kommer åt en NuGet Server (bland annat), ladda ned paket, installera paket och så vidare. Det finns många andra DSC-resurser i PowerShell-galleriet. Du installerar dessa moduler på din Azure Automation State Configuration-pull-server för användning av dina konfigurationer.

Resource Manager-mallar är ett deklarativt sätt att generera din infrastruktur, till exempel nätverk, undernät, nätverkssäkerhet och routning, lastbalanserare, nätverkskort, virtuella datorer och så vidare. Här är en artikel som jämför Resource Manager-distributionsmodellen (deklarativ) med Distributionsmodellen för Azure Service Management (ASM eller klassisk) (imperativ). Den här artikeln innehåller en diskussion om kärnresursprovidrar: beräkning, lagring och nätverk.

En viktig funktion i en Resource Manager-mall är dess möjlighet att installera ett VM-tillägg på den virtuella datorn när det etableras. Ett VM-tillägg har specifika funktioner, till exempel att köra ett anpassat skript, installera antivirusprogram och köra ett DSC-konfigurationsskript. Det finns många andra typer av VM-tillägg.

Snabb resa runt diagrammet

Från början skriver du koden, skapar den, testar den och skapar sedan ett installationspaket. Chocolatey kan hantera olika typer av installationspaket, till exempel MSI, MSU, ZIP. Och du har den fulla kraften i PowerShell för att göra den faktiska installationen om Chocolateys interna funktioner inte klarar det. Placera paketet på någon plats som kan nås – en paketlagringsplats. I det här användningsexemplet används en gemensam mapp i ett Azure Blob Storage-konto, men det kan finnas var som helst. Chocolatey fungerar internt med NuGet-servrar och några andra för hantering av paketmetadata. I den här artikeln beskrivs alternativen. Användningsexemplet använder NuGet. En Nuspec är metadata om dina paket. Nuspec-informationen kompileras till en NuPkg och lagras på en NuGet-server. När konfigurationen begär ett paket med namn och refererar till en NuGet-server hämtar Chocolatey DSC-resursen på den virtuella datorn paketet och installerar det. Du kan också begära en specifik version av ett paket.

Längst ned till vänster i bilden finns en Azure Resource Manager-mall. I det här användningsexemplet registrerar VM-tillägget den virtuella datorn med Azure Automation State Configuration-hämtningsservern som en nod. Konfigurationen lagras på pull-servern två gånger: en gång som oformaterad text och en gång kompilerad som en MOF-fil. I Azure-portalen representerar MOF en nodkonfiguration i stället för en enkel konfiguration. Det är artefakten som är associerad med en nod så att noden känner till dess konfiguration. Information nedan visar hur du tilldelar nodkonfigurationen till noden.

Att skapa Nuspec, kompilera den och lagra den på en NuGet-server är en liten sak. Och du hanterar redan virtuella datorer.

Nästa steg för kontinuerlig distribution kräver att du konfigurerar pull-servern en gång, registrerar noderna med den en gång och skapar och lagrar den första konfigurationen på servern. När paket uppgraderas och distribueras till lagringsplatsen behöver du bara uppdatera konfigurationen och nodkonfigurationen på pull-servern efter behov.

Om du inte börjar med en Resource Manager-mall går det bra. Det finns PowerShell-kommandon som hjälper dig att registrera dina virtuella datorer med hämtningsservern. Mer information finns i Registrera datorer för hantering av Azure Automation State Configuration.

Om användningsexemplet

Användningsexemplet i den här artikeln börjar med en virtuell dator från en allmän Windows Server 2012 R2-avbildning från Azure-galleriet. Du kan börja från valfri lagrad avbildning och sedan justera därifrån med DSC-konfigurationen. Det är dock mycket svårare att ändra konfigurationen som bakas till en avbildning än att dynamiskt uppdatera konfigurationen med hjälp av DSC.

Du behöver inte använda en Resource Manager-mall och VM-tillägget för att använda den här tekniken med dina virtuella datorer. Och dina virtuella datorer behöver inte vara på Azure för att vara under CD-hantering. Allt som krävs är att Chocolatey installeras och LCM konfigureras på den virtuella datorn så att den vet var hämtningsservern finns.

När du uppdaterar ett paket på en virtuell dator som är i produktion måste du ta den virtuella datorn ur rotation medan uppdateringen är installerad. Hur du gör detta varierar kraftigt. Med en virtuell dator bakom en Azure Load Balancer kan du till exempel lägga till en anpassad avsökning. När du uppdaterar den virtuella datorn måste avsökningens slutpunkt returnera 400. Den justering som krävs för att orsaka den här ändringen kan finnas i konfigurationen, liksom justeringen för att växla tillbaka den till att returnera en 200 när uppdateringen är klar.

Fullständig källa för det här användningsexemplet finns i det här Visual Studio-projektet på GitHub.

Steg 1: Konfigurera pull-servern och Automation-kontot

På en autentiserad (Connect-AzAccount) PowerShell-kommandorad: (kan ta några minuter medan pull-servern har konfigurerats)

New-AzResourceGroup -Name MY-AUTOMATION-RG -Location MY-RG-LOCATION-IN-QUOTES
New-AzAutomationAccount -ResourceGroupName MY-AUTOMATION-RG -Location MY-RG-LOCATION-IN-QUOTES -Name MY-AUTOMATION-ACCOUNT

Du kan placera ditt Automation-konto i någon av följande regioner (kallas även platser): USA, östra 2, USA, södra centrala, US Gov Virginia, Europa, västra, Asien, sydöstra, Japan, östra, Indien, centrala och Australien, sydöstra, Kanada, centrala, Europa, norra.

Steg 2: Gör vm-tilläggsjusteringar till Resource Manager-mallen

Information om registrering av virtuella datorer (med hjälp av PowerShell DSC VM-tillägget) finns i den här Azure-snabbstartsmallen. Det här steget registrerar den nya virtuella datorn med pull-servern i listan över tillståndskonfigurationsnoder. En del av den här registreringen är att ange den nodkonfiguration som ska tillämpas på noden. Den här nodkonfigurationen behöver inte finnas ännu i pull-servern, så det är bra att steg 4 är den plats där detta görs för första gången. Men här i steg 2 måste du ha bestämt namnet på noden och namnet på konfigurationen. I det här användningsexemplet är noden "isvbox" och konfigurationen är "ISVBoxConfig". Nodkonfigurationsnamnet (som ska anges i DeploymentTemplate.json) är alltså "ISVBoxConfig.isvbox".

Steg 3: Lägg till nödvändiga DSC-resurser till pull-servern

PowerShell-galleriet är instrumenterad för att installera DSC-resurser i ditt Azure Automation-konto. Gå till den resurs du vill använda och klicka på knappen "Distribuera till Azure Automation".

PowerShell Gallery example

Med en annan teknik som nyligen har lagts till i Azure-portalen kan du hämta nya moduler eller uppdatera befintliga moduler. Klicka dig igenom Automation-kontoresursen, panelen Tillgångar och slutligen panelen Moduler. Med ikonen Bläddra galleri kan du se listan över moduler i galleriet, öka detaljnivån och slutligen importera till ditt Automation-konto. Det här är ett bra sätt att hålla dina moduler uppdaterade då och då. Och importfunktionen kontrollerar beroenden med andra moduler för att säkerställa att ingenting blir osynkroniserat.

Det finns också en manuell metod som endast används en gång per resurs, såvida du inte vill uppgradera den senare. Mer information om hur du redigerar PowerShell-integreringsmoduler finns i Redigera integreringsmoduler för Azure Automation.

Kommentar

Mappstrukturen för en PowerShell-integreringsmodul för en Windows-dator skiljer sig lite från den mappstruktur som förväntas av Azure Automation.

  1. Installera Windows Management Framework v5 (behövs inte för Windows 10).

  2. Installera integreringsmodulen.

    Install-Module -Name MODULE-NAME`    <—grabs the module from the PowerShell Gallery
    
  3. Kopiera modulmappen från c:\Program Files\WindowsPowerShell\Modules\MODULE-NAME till en tillfällig mapp.

  4. Ta bort exempel och dokumentation från huvudmappen.

  5. Zippa huvudmappen och namnge ZIP-filen med namnet på mappen.

  6. Placera ZIP-filen på en nåbar HTTP-plats, till exempel bloblagring i ett Azure Storage-konto.

  7. Kör följande kommando.

    New-AzAutomationModule `
      -ResourceGroupName MY-AUTOMATION-RG -AutomationAccountName MY-AUTOMATION-ACCOUNT `
      -Name MODULE-NAME -ContentLinkUri 'https://STORAGE-URI/CONTAINERNAME/MODULE-NAME.zip'
    

Det inkluderade exemplet implementerar de här stegen för cChoco och xNetworking.

Steg 4: Lägg till nodkonfigurationen på pull-servern

Det är inget speciellt med första gången du importerar konfigurationen till hämtningsservern och kompilerar. Alla senare importer eller kompileringar av samma konfiguration ser exakt likadana ut. Varje gång du uppdaterar paketet och behöver skicka ut det till produktion gör du det här steget när du har kontrollerat att konfigurationsfilen är korrekt – inklusive den nya versionen av paketet. Här är konfigurationsfilen 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'
        }
    }
}

Här är skriptet New-ConfigurationScript.ps1 (ändrad för att använda Az-modulen):

Import-AzAutomationDscConfiguration `
    -ResourceGroupName MY-AUTOMATION-RG -AutomationAccountName MY-AUTOMATION-ACCOUNT `
    -SourcePath C:\temp\AzureAutomationDsc\ISVBoxConfig.ps1 `
    -Published -Force

$jobData = Start-AzAutomationDscCompilationJob `
    -ResourceGroupName MY-AUTOMATION-RG -AutomationAccountName MY-AUTOMATION-ACCOUNT `
    -ConfigurationName ISVBoxConfig

$compilationJobId = $jobData.Id

Get-AzAutomationDscCompilationJob `
    -ResourceGroupName MY-AUTOMATION-RG -AutomationAccountName MY-AUTOMATION-ACCOUNT `
    -Id $compilationJobId

De här stegen resulterar i att en ny nodkonfiguration med namnet ISVBoxConfig.isvbox placeras på pull-servern. Nodkonfigurationsnamnet skapas som configurationName.nodeName.

Steg 5: Skapa och underhålla paketmetadata

För varje paket som du lägger till i paketlagringsplatsen behöver du en Nuspec som beskriver det. Den måste kompileras och lagras på NuGet-servern. Den här processen beskrivs här.

Du kan använda MyGet.org som NuGet-server. Du kan köpa den här tjänsten, men du är en kostnadsfri start-SKU. På NuGet hittar du instruktioner om hur du installerar din egen NuGet-server för dina privata paket.

Steg 6: Knyta ihop allt

Varje gång en version passerar QA och godkänns för distribution skapas paketet och nuspec och nupkg uppdateras och distribueras till NuGet-servern. Konfigurationen (steg 4) måste också uppdateras för att överensstämma med det nya versionsnumret. Den måste sedan skickas till pull-servern och kompileras.

Från och med då är det upp till de virtuella datorer som är beroende av den konfigurationen för att hämta uppdateringen och installera den. Var och en av dessa uppdateringar är enkel – bara en rad eller två av PowerShell. För Azure DevOps är vissa av dem inkapslade i bygguppgifter som kan kopplas samman i en version. Den här artikeln innehåller mer information. Den här GitHub-lagringsplatsen beskriver de tillgängliga bygguppgifterna.

Nästa steg