Partilhar via


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

Nota

A Configuração do Estado de Automação do Azure será desativada em 30 de setembro de 2027, faça a transição para a Configuração de Máquina do Azure até essa data. Para obter mais informações, consulte o anúncio da postagem no blog. O serviço de Configuração de Máquina do Azure combina recursos de Extensão DSC, Configuração de Estado de Automação do Azure e os recursos mais comumente solicitados dos comentários dos clientes. A Configuração de Máquina do Azure também inclui suporte a máquinas híbridas por meio de servidores habilitados para Arc.

Atenção

O Azure Automation DSC para Linux foi desativado em 30 de setembro de 2023. Para mais informações, consulte o anúncio.

Em um mundo de DevOps, há muitas ferramentas para ajudar com vários pontos no pipeline de integração contínua. A Configuração do Estado de Automação do Azure é uma nova adição bem-vinda às opções que as equipes de DevOps podem 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, agendas e variáveis globais. A Configuração do Estado de Automação do Azure estende esse recurso de automação para incluir ferramentas de Configuração de Estado Desejado (DSC) do PowerShell. Aqui está uma ótima visão geral.

Este artigo demonstra como configurar a implantação contínua (CD) para um computador Windows. Você pode facilmente estender 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 IaaS

A um nível elevado

Há muita coisa acontecendo aqui, mas felizmente pode ser dividido em dois processos principais:

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

Depois que ambos os processos principais estiverem em vigor, é fácil atualizar automaticamente o pacote em suas VMs à medida que novas versões são criadas e implantadas.

Visão geral do componente

Gerenciadores de pacotes como o apt-get são bem conhecidos no mundo Linux, mas não tanto no mundo Windows. Chocolatey é um gerenciador de pacotes para Windows. O post do blog de Scott Hanselman sobre Chocolatey é uma ótima introdução. Chocolatey permite que você use a linha de comando para instalar pacotes de um repositório central em um sistema operacional Windows. Você pode criar e gerenciar seu próprio repositório, e o Chocolatey pode instalar pacotes de qualquer número de repositórios que você designar.

O PowerShell DSC é uma ferramenta do PowerShell que permite declarar a configuração desejada para uma máquina. Por exemplo, se você quiser que o Chocolatey seja instalado, o IIS instalado, a porta 80 aberta e a versão 1.0.0 do seu site instalada, o DSC Local Configuration Manager (LCM) implementará essa configuração. Um servidor de receção DSC contém um repositório de configurações para suas máquinas. O LCM em cada máquina faz check-in periodicamente para ver se sua configuração corresponde à configuração armazenada. Ele pode relatar o status ou tentar alinhar a máquina com a configuração armazenada. Você pode editar a configuração armazenada no servidor pull para fazer com que uma máquina ou um conjunto de máquinas entre em alinhamento com a configuração alterada.

Um recurso DSC é um módulo de código que tem recursos específicos, como gerenciamento de rede, Ative Directory ou SQL Server. O Chocolatey DSC Resource sabe como acessar um NuGet Server, baixar pacotes, instalar pacotes e executar outras tarefas. Há muitos outros Recursos DSC na Galeria do PowerShell. Você instala esses módulos em seu servidor pull de Configuração do Estado de Automação do Azure para uso 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
  • encaminhamento,
  • 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 recurso importante de um modelo do Resource Manager é sua 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 DSC. Existem muitos outros tipos de extensões de VM.

Viagem rápida ao redor do diagrama

Começando na parte superior, você escreve seu código, compila-o, testa-o e, em seguida, cria um pacote de instalação. Chocolatey pode lidar com vários tipos de pacotes de instalação, como MSI, MSU, ZIP. E você tem todo o poder do PowerShell para fazer a instalação real se os recursos nativos do Chocolatey não estiverem à altura. Coloque o pacote em algum lugar acessível - 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 lugar. O Chocolatey trabalha nativamente com servidores NuGet e alguns outros para gerenciamento de metadados de pacotes. Este artigo descreve as opções. O exemplo de uso usa NuGet. Um Nuspec são metadados sobre seus pacotes. As informações do Nuspec são compiladas em um NuPkg e armazenadas em um servidor NuGet. Quando sua configuração solicita um pacote pelo nome e faz referência a um servidor NuGet, o recurso Chocolatey DSC na VM pega o pacote e o instala. Você também pode solicitar uma versão específica de um pacote.

No canto inferior esquerdo da imagem, há um modelo do Azure Resource Manager. Neste exemplo de uso, a extensão VM registra a VM com o servidor pull Configuração do Estado de Automação do Azure como um nó. A configuração é armazenada no servidor pull duas vezes: uma vez como texto simples e uma vez compilada como um arquivo MOF. No portal do Azure, o MOF representa uma configuração de nó, em oposição a uma configuração simples.

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

  • Configurar o servidor pull
  • Registre 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 pull quando atualizar e implantar pacotes no repositório.

Se você não estiver começando com um modelo do Gerenciador de Recursos, há comandos do PowerShell para ajudá-lo a registrar suas VMs com o servidor de recebimento. Para obter mais informações, consulte Integração de máquinas para gerenciamento pela Configuração de Estado 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ê pode começar a partir de qualquer imagem armazenada e, em seguida, ajustar a partir daí com a configuração DSC. No entanto, alterar a configuração que é incorporada em uma imagem é muito mais difícil do que atualizar dinamicamente a configuração usando DSC.

Não é necessário usar um modelo do Gerenciador de Recursos e a extensão de VM para usar essa técnica com suas VMs. E suas 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 tirar essa VM da rotação enquanto a atualização está instalada. A forma como o faz varia muito. Por exemplo, com uma VM atrá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 causar essa alteração pode estar dentro da sua configuração, assim como o ajuste para voltar a retornar um 200 assim que a atualização for concluída.

A fonte completa para este exemplo de uso está neste projeto do Visual Studio no GitHub.

Etapa 1: Configurar o servidor 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

Esta etapa leva alguns minutos enquanto o servidor de pull está configurado.

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

  • E.U.A. Leste 2
  • E.U.A. Centro-Sul
  • US Gov - Virginia
  • Europa Ocidental
  • Sudeste Asiático
  • Leste do Japão
  • Índia Central
  • Austrália Sudeste
  • Canadá Central
  • Europa do Norte

Etapa 2: Fazer ajustes de extensão de VM para o modelo do Gerenciador de Recursos

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

Etapa 3: Adicionar os recursos DSC necessários ao servidor 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 que você obtenha novos módulos ou atualize módulos existentes. Selecione o ícone Procurar Galeria para ver a lista de módulos na galeria, analise os detalhes e importe 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 fique fora de sincronia.

Há também uma abordagem manual, usada apenas uma vez por recurso, a menos que você queira atualizá-la mais tarde. Para obter mais informações sobre como criar módulos de integração do PowerShell, consulte Criação de módulos de integração para automação do Azure.

Nota

A estrutura de pastas de um módulo de integração do PowerShell para um computador 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 uma pasta temporária.

  4. Exclua amostras e 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 armazenamento de blob em uma conta de Armazenamento do Azure.

  7. Execute o seguinte comando.

    $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 essas etapas para cChoco e xNetworking.

Etapa 4: Adicionar a configuração do nó ao servidor pull

Não há nada de especial na primeira vez que você importa sua configuração para o servidor pull e compila. Todas as importações ou compilações posteriores da mesma configuração têm exatamente a mesma aparência. Cada vez que você atualiza seu pacote e precisa enviá-lo para a produção, você faz esta etapa depois de garantir que o arquivo de configuração esteja correto - incluindo a nova versão do seu pacote. Aqui está o arquivo ISVBoxConfig.ps1de configuração:

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 a seguir New-ConfigurationScript.ps1 foi modificado para usar o módulo 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 do pacote

Para cada pacote colocado no repositório de pacotes, você precisa de um Nuspec que o descreva. Ele deve ser compilado e armazenado em seu servidor NuGet. Para obter mais informações, consulte [Criar um pacote NuGet usando nuget.exe CLI].

Você pode usá MyGet.org como um servidor NuGet. Você pode comprar este serviço, mas você é um SKU iniciante gratuito. Para obter instruções sobre como instalar seu próprio servidor NuGet para seus pacotes privados, consulte a documentação em Nuget.org.

Passo 6: Amarre tudo junto

Cada vez que uma versão passa pelo QA e é aprovada para implantação, o pacote é criado e nuspec e nupkg são atualizados e implantados no servidor NuGet. Você deve atualizar a configuração (etapa 4) com o novo número de versão. Em seguida, envie-o para o servidor pull e compile-o.

A partir desse ponto, cabe às VMs que dependem dessa configuração puxar 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 compilação que você pode encadear em uma compilação. Este artigo fornece mais detalhes. Este repositório GitHub detalha as tarefas de compilação disponíveis.

Próximos passos