Compartilhar via

Configurar a implantação contínua com o Chocolatey

  • Artigo

Observação

O State Configuration da Automação do Azure será desativado em 30 de setembro de 2027, faça a transição para a Configuração de Máquina do Azure até essa data. Para saber mais, confira a postagem no blog sobre o anúncio. O serviço de Configuração de Máquina do Azure combina recursos da Extensão DSC, da Configuração de Estado da Automação do Azure e dos recursos mais solicitados por meio de comentários dos clientes. A Configuração de Máquinas do Azure também inclui suporte a máquina híbrida por meio servidores habilitados para Arc.

Cuidado

O DSC de Automação do Azure para Linux foi desativado em 30 de setembro de 2023. Para obter mais informações, confira o comunicado.

Em um mundo de DevOps, há várias ferramentas para ajudá-lo em vários pontos no pipeline de integração contínua. A State Configuration da Automação do Azure é uma nova adição bem-vinda às opções que as equipes do DevOps pode empregar.

A Automação do Azure é um serviço gerenciado no Microsoft Azure que permite automatizar várias tarefas usando runbooks, nós e recursos compartilhados, como credenciais, agendamentos e variáveis globais. A Configuração de Estado da Automação do Azure amplia esse recurso de automação para incluir ferramentas da DSC (Desired State Configuration) do PowerShell. Confira uma excelente visão geral.

Este artigo demonstra como configurar a CD (Implantação Contínua) para um computador com Windows. Você pode ampliar facilmente a técnica para incluir quantos computadores Windows forem necessários na função, por exemplo, um site e ir de lá para mais funções.

Implantação contínua para VMs do IaaS

Em um alto nível

Há bem pouco acontecendo aqui, mas, felizmente, é possível dividir tudo em dois processos principais:

  • Escrever código e testá-lo e, depois, criar e publicar pacotes de instalação para as versões principais e secundárias do sistema.
  • Criar e gerenciar VMs que instalam e executam o código nos pacotes.

Quando esses dois processos principais estiverem em vigor, será fácil atualizar automaticamente o pacote na sua VM específica à medida que novas versões são criadas e implantadas.

Visão geral do componente

Os gerenciadores de pacotes como apt-get são conhecidos no mundo do Linux, mas nem tanto no mundo do Windows. Chocolatey é um gerenciador de pacotes para Windows. A postagem no blog de Scott Hanselman sobre Chocolatey é uma ótima introdução. O Chocolatey permite usar a linha de comando para instalar pacotes de um repositório central para um sistema operacional Windows. Você pode criar e gerenciar seu próprio repositório, e o Chocolatey pode instalar pacotes de qualquer repositório que você designar.

A DSC do PowerShell é uma ferramenta do PowerShell que permite declarar a configuração que você deseja usar em um computador. Por exemplo, se você quiser que o Chocolatey esteja instalado, o IIS instalado, a porta 80 aberta e a versão 1.0.0 do seu site instalado, o LCM (Local Configuration Manager) de DSC implementa essa configuração. Um servidor de recepção da DSC mantém um repositório de configurações para seus computadores. O LCM em cada computador verifica periodicamente se sua configuração corresponde à configuração armazenada. Ele pode relatar o status ou tentar realinhar o computador com a configuração armazenada. Você pode editar a configuração armazenada no servidor de recepção para alinhar um computador ou um conjunto de computadores com a configuração alterada.

Um recurso DSC é um módulo de código que tem recursos específicos, como gerenciar redes, o Active Directory ou o SQL Server. O Recurso DSC do Chocolatey sabe como acessar um Servidor do NuGet, baixar e instalar pacotes e executar outras tarefas. Há muitos outros Recursos de DSC na Galeria do PowerShell. Você instala esses módulos no servidor de pull de State Configuration da Automação do Azure para que possam ser usados por suas configurações.

Os modelos do Resource Manager fornecem uma maneira declarativa de gerar recursos para sua infraestrutura, como:

  • redes e sub-redes
  • segurança de rede
  • roteamento,
  • balanceadores de carga,
  • NICs, VMs e outros

Para obter uma comparação do modelo de implantação do Resource Manager (declarativo) com o modelo de implantação clássico do Azure (imperativo), consulte Azure Resource Manager vs. implantação clássica. Este artigo inclui uma discussão sobre os principais provedores de recursos, computação, armazenamento e rede.

Um dos principais recursos de um modelo do Resource Manager é a capacidade de instalar uma extensão de VM durante o provisionamento de VM. Uma extensão de VM tem recursos específicos, como executar um script personalizado, instalar software antivírus e executar um script de configuração de DSC. Há muitos outros tipos de extensões de VM.

Explicação rápida do diagrama

Começando pela parte superior, você escreve o código, compila e testa e, depois, cria um pacote de instalação. O Chocolatey pode manipular vários tipos de pacotes de instalação, como MSI, MSU e ZIP. Você conta com toda a capacidade do PowerShell para realizar a instalação real, caso os recursos nativos do Chocolatey não sejam suficientes. Coloque o pacote em um lugar acessível, como um repositório de pacotes. Este exemplo de uso usa uma pasta pública em uma conta de armazenamento de blob do Azure, mas pode estar em qualquer outro lugar. O Chocolatey funciona nativamente com servidores do NuGet e alguns outras para o gerenciamento de metadados de pacote. Este artigo descreve as opções. Este exemplo de uso usa o NuGet. Um Nuspec consiste em metadados sobre seus pacotes. As informações do Nuspec são compiladas em um NuPkg e armazenadas em um servidor NuGet. Quando a configuração solicita um pacote por nome e faz referência a um servidor do NuGet, o Recurso DSC do Chocolatey (na VM) obtém o pacote e o instala. Você também pode solicitar uma versão específica de um pacote.

Na parte inferior esquerda da imagem, há um modelo do Azure Resource Manager. Nesse exemplo de uso, a extensão da VM registra a VM com o servidor de pull de State Configuration da Automação do Azure como um nó. A configuração é armazenada no servidor de pull duas vezes: uma vez como texto sem formatação e uma vez compilada como um arquivo MOF. No portal do Microsoft Azure, o MOF representa uma configuração de nó, em vez de simplesmente uma configuração.

É relativamente simples criar o Nuspec, compilá-lo e armazená-lo em um servidor NuGet. A próxima etapa para implantação contínua requer as seguintes tarefas pontuais:

  • Configurar o servidor de pull
  • Registrar seus nós com o servidor
  • Criar a configuração inicial no servidor

Você só precisa atualizar a configuração e a configuração do nó no servidor de pull ao atualizar e implantar pacotes no repositório.

Se você não estiver começando com um modelo do Resource Manager, haverá comandos do PowerShell para ajudá-lo a registrar suas VMs com o servidor pull. Para saber mais, veja Máquinas de integração para o gerenciamento pela State Configuration de Automação do Azure.

Sobre o exemplo de uso

O exemplo de uso neste artigo começa com uma VM de uma imagem genérica do Windows Server 2012 R2 da galeria do Azure. Você poderá iniciar de qualquer imagem armazenada e ajustá-la com a configuração da DSC. No entanto, é muito mais difícil alterar a configuração incorporada a uma imagem do que atualizar de forma dinâmica a configuração usando a DSC.

Não é necessário usar um modelo do Resource Manager e a extensão da VM para usar essa técnica com as VMs. E as VMs não precisam estar no Azure para estar sob gerenciamento de CD. Basta instalar o Chocolatey e configurar o LCM na VM para que ele saiba onde está o servidor pull.

Ao atualizar um pacote em uma VM que está em produção, você precisa colocar a VM fora de rotação enquanto a atualização é instalada. A maneira de fazer isso varia muito. Por exemplo, com uma VM por trás de um Balanceador de Carga do Azure, você pode adicionar uma Sonda Personalizada. Ao atualizar a VM, faça com que o ponto de extremidade da sonda retorne um 400. O ajuste necessário para fazer essa alteração pode ser dentro de sua configuração, da mesma forma como o ajuste para que 200 volte a ser retornado depois que a atualização for concluída.

O código-fonte completo deste exemplo de uso está neste projeto do Visual Studio no GitHub.

Etapa 1: Configure o servidor de pull e a conta de automação

Execute os seguintes comandos em uma sessão autenticada (Connect-AzAccount) do PowerShell:

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

Essa etapa leva alguns minutos enquanto o servidor de pull é configurado.

Você pode criar sua conta de Automação em qualquer uma das seguintes regiões do Azure:

  • Leste dos EUA 2
  • Centro-Sul dos Estados Unidos
  • Gov. dos EUA – Virgínia
  • Europa Ocidental
  • Sudeste Asiático
  • Leste do Japão
  • Índia Central
  • Sudeste da Austrália
  • Canadá Central
  • Norte da Europa

Etapa 2: Faça ajustes de extensão da VM para o modelo do Resource Manager

Detalhes do registro de VM (usando a extensão de VM de DSC do PowerShell) são fornecidos neste Modelo de Início Rápido do Azure. Esta etapa registra a nova VM com o servidor de pull na lista de Nós da Configuração de Estado. Parte do registro especifica a configuração de nó a ser aplicada ao nó. Essa configuração de nó ainda não precisa existir no servidor de pull, mas você precisa escolher o nome do nó e o nome da configuração. Para este exemplo, o nó é isvbox e o nome da configuração é ISVBoxConfig. O nome de configuração do nó especificado em DeploymentTemplate.json é ISVBoxConfig.isvbox.

Etapa 3: Adicione recursos de DSC necessários para o servidor de pull

A Galeria do PowerShell pode instalar recursos DSC em sua conta de Automação do Azure. Navegue até o recurso desejado e selecione Implantar na Automação do Azure.

Exemplo da Galeria do PowerShell

Outra técnica recentemente adicionada ao portal do Azure permite criar novos módulos ou atualizar módulos existentes. Selecione o ícone Procurar Galeria para ver a lista de módulos na galeria, detalhar e importar para sua conta de Automação. Você pode usar esse processo para manter seus módulos atualizados. Além disso, o recurso de importação verifica as dependências com outros módulos para garantir que nada saia da sincronização.

Há também uma abordagem manual, usada apenas uma vez por recurso, a menos que você queira atualizá-la mais tarde. Para saber mais sobre como criar módulos de integração do PowerShell, confira Criando Módulos de Integração para a Automação do Azure.

Observação

A estrutura de pastas de um módulo de integração do PowerShell para um computador com Windows é um pouco diferente da estrutura de pastas esperada pela Automação do Azure.

  1. Instale o Windows Management Framework, v5 (não é necessário para o Windows 10).

  2. Instale o módulo de integração.

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

  3. Copie a pasta do módulo de C:\Program Files\WindowsPowerShell\Modules\MODULE-NAME para uma pasta temporária.

  4. Exclua os exemplos e a documentação da pasta principal.

  5. Compacte a pasta principal, nomeando o arquivo ZIP com o nome da pasta.

  6. Coloque o arquivo ZIP em um local http acessível, como o armazenamento de blobs em uma conta do Armazenamento do Microsoft Azure.

  7. Execute o comando a seguir.

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

O exemplo incluído implementa estas etapas para cChoco e xNetworking.

Etapa 4: Adicione a configuração de nó ao servidor de pull

Não há nada de especial na primeira vez que você importa a configuração para o servidor de pull e compila. Todas as importações/compilações posteriores da mesma configuração têm exatamente a mesma aparência. Sempre que você atualizar o pacote e precisar enviá-lo para produção, realize esta etapa após garantir que o arquivo de configuração está correto, incluindo a nova versão do pacote. Aqui está o arquivo de configuração 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'
        }
    }
}

O script New-ConfigurationScript.ps1 a seguir foi modificado para usar o módulo do Az PowerShell:

$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

Etapa 5: Criar e manter metadados de pacote

Para cada pacote que você coloca no repositório de pacotes, é necessário um nuspec que o descreve. Isso deve ser compilado e armazenado em seu servidor do NuGet. Para obter mais informações, consulte [Criar um pacote NuGet usando nuget.exe CLI].

Você pode usar MyGet.org como um servidor do NuGet. Você pode comprar esse serviço, mas existe um SKU inicial gratuito. Para obter instruções sobre como instalar seu próprio servidor NuGet para seus pacotes particulares, consulte a documentação sobre Nuget.org.

Etapa 6: Coloque tudo isso junto

Sempre que uma versão passar na garantia de qualidade e for aprovada para implantação, o pacote será criado e o nuspec e o nupkg serão atualizados e implantados no servidor do NuGet. Você deve atualizar a configuração (etapa 4) com o novo número de versão. Em seguida, envie-o para o servidor de pull e compile-o.

Daí em diante, as VMs que dependem dessa configuração serão responsáveis por receber a atualização e instalá-la. Cada uma dessas atualizações é simples - apenas uma ou duas linhas do PowerShell. Para o Azure DevOps, alguns deles são encapsulados em tarefas de build que podem ser encadeadas em um build. Este artigo fornece mais detalhes. Este repositório GitHub fornece detalhes das várias tarefas de compilação disponíveis.

Próximas etapas