O que é o State Configuration da Automatização do Azure?

  • 10 minutos

Você pode usar a Configuração do Estado de Automação do Azure para garantir que as máquinas virtuais (VMs) em uma área de cluster estejam em um estado consistente, com o mesmo software instalado e as mesmas configurações.

Nesta unidade, você aprenderá sobre os recursos e as capacidades da Automação do Azure, analisará o modelo declarativo da Configuração de Estado Desejado (DSC) do PowerShell e explorará seus benefícios.

O State Configuration da Automatização do Azure é um serviço do Azure criado no PowerShell. Ele permite que você implante de forma consistente, monitore de forma confiável e atualize automaticamente o estado desejado de todos os seus recursos. A Automatização do Azure fornece ferramentas para definir as configurações e aplicá-las a máquinas reais e virtuais.

Porquê utilizar o State Configuration da Automatização do Azure?

Manter manualmente uma configuração correta e consistente para os servidores que executam seus serviços pode ser difícil e propenso a erros. O State Configuration da Automatização do Azure utiliza o DSC do PowerShell para ajudar a enfrentar estes desafios. Gere centralmente os artefactos do DSC e o processo do DSC.

O State Configuration da Automatização do Azure tem um servidor de extração incorporado. Pode definir nós para que recebam automaticamente as configurações deste servidor de extração, estejam de acordo com o estado pretendido e que indiquem a conformidade. Pode definir máquinas virtuais ou físicas Windows ou Linux, na cloud ou no local.

Você pode usar os logs do Azure Monitor para revisar a conformidade de seus nós configurando a Configuração de Estado de Automação do Azure para enviar esses dados.

O que é o DSC do PowerShell?

O Desired State Configuration (DSC) do PowerShell é uma plataforma de gestão declarativa que o State Configuration da Automatização do Azure utiliza para configurar, implementar e controlar os sistemas. Uma linguagem de programação declarativa separa a intenção (o que você deseja fazer) da execução (como você deseja fazê-lo). Especifique o estado pretendido e deixe que o DSC faça o trabalho. Não precisa de saber como implementar uma funcionalidade quando um recurso do DSC está disponível. Em vez disso, você pode se concentrar em sua estrutura de implantação.

Se já estiver a utilizar o PowerShell, talvez se questione por que precisa do DSC. Considere o seguinte exemplo.

Quando quer criar uma partilha num servidor Windows, poderá utilizar este comando do PowerShell:

# Create a file share
New-SmbShare -Name MyFileShare -Path C:\Shared -FullAccess User1 -ReadAccess User2

Este script é simples e fácil de entender. No entanto, se você usar esse script na produção, encontrará vários problemas. Considere o que pode acontecer se o script for executado várias vezes ou se User2 já tiver acesso total em vez de acesso somente leitura.

Esta abordagem é idempotente. A idempotência descreve uma operação que terá o mesmo efeito se a executar uma vez ou 10 001 vezes. Para alcançar a idempotência no PowerShell, tem de adicionar a lógica e o processamento de erros. Se o compartilhamento de arquivos não existir, você o criará. Se a partilha existir, não será necessário criá-la. Se User2 existir, mas não tiver acesso de leitura, deverá adicionar o acesso de leitura.

O script do PowerShell terá um aspeto semelhante ao seguinte:

$shareExists = $false
$smbShare = Get-SmbShare -Name $Name -ErrorAction SilentlyContinue
if($smbShare -ne $null)
{
    Write-Verbose -Message "Share with name $Name exists"
    $shareExists = $true
}

if ($shareExists -eq $false)
{
    Write-Verbose "Creating share $Name to ensure it is Present"
    New-SmbShare @psboundparameters
}
else
{
    # Need to call either Set-SmbShare or *ShareAccess cmdlets
    if ($psboundparameters.ContainsKey("ChangeAccess"))
    {
       #...etc., etc., etc
    }
}

Outros casos especiais que não tenha tido em consideração poderão aparecer apenas quando houver problemas. O DSC trata os casos inesperados de forma automática. Com o DSC, poderá descrever o resultado em vez do processo para obter o resultado.

O fragmento de código do DSC a seguir mostra um exemplo:

Configuration Create_Share
{
   Import-DscResource -Module xSmbShare
   # A node describes the VM to be configured

   Node $NodeName
   {
      # A node definition contains one or more resource blocks
      # A resource block describes the resource to be configured on the node
      xSmbShare MySMBShare
      {
          Ensure      = "Present"
          Name        = "MyFileShare"
          Path        = "C:\Shared"
          ReadAccess  = "User1"
          FullAccess  = "User2"
          Description = "This is an updated description for this share"
      }
   }
}

O exemplo anterior usa o módulo, que informa ao xSmbShare DSC como verificar o estado de um compartilhamento de arquivos. O DSC Resource Kit tem mais de 100 módulos de recursos, incluindo um para instalar um site do IIS. Você pode encontrar um link para o DSC Resource Kit na unidade Resumo no final deste módulo.

Você aprenderá mais sobre a estrutura de código DSC do PowerShell na próxima unidade.

O que é o LCM?

O gerenciador de configuração local (LCM) é um componente do Windows Management Framework (WMF) em um sistema operacional Windows. O LCM é responsável pela atualização do estado de um nó, como uma VM, para que corresponda ao estado pretendido. Sempre que o LCM é executado, conclui os seguintes passos:

  1. Get: Obtém o estado atual do nó.
  2. Test: Compara o estado atual de um nó com o estado desejado usando um script DSC compilado (arquivo .mof).
  3. Set: Atualiza o nó para corresponder ao estado desejado descrito no arquivo .mof.

Você configurará o LCM quando registrar uma VM com a Automação do Azure.

As arquiteturas de emissão e extração no DSC

O LCM em cada nó pode funcionar em dois modos.

  • Modo push: um administrador envia ou envia manualmente as configurações para um ou mais nós. O LCM garante que o estado em cada nó corresponde ao que a configuração especifica.

    Diagrama mostrando uma arquitetura push no DSC.

  • Modo de receção: um servidor de receção contém as informações de configuração. O LCM em cada nó sonda o servidor de pull em intervalos regulares — por padrão, a cada 15 minutos — para obter os detalhes de configuração mais recentes. Essas solicitações são indicadas como Etapa 1 no diagrama a seguir. Na Etapa 2, o servidor pull envia os detalhes sobre quaisquer alterações de configuração de volta para cada nó.

    No modo de extração, cada nó tem de estar registado no serviço de extração.

    Diagrama mostrando uma arquitetura pull no DSC.

Ambos os modos têm vantagens:

  • O modo de emissão é fácil de configurar. Não precisa de uma infraestrutura dedicada própria e pode ser executado num portátil. O modo de emissão é útil para testar a funcionalidade do DSC. Também pode utilizar o modo de emissão para colocar uma máquina criada recentemente no estado pretendido da linha base.
  • O modo de extração é útil numa implementação empresarial que abrange um grande número de máquinas. O LCM pesquisa regularmente o servidor de extração e garante que os nós estão no estado pretendido. Se uma ferramenta ou equipa externa aplicar correções que resultem num desvio da configuração nas máquinas individuais, estas máquinas serão rapidamente restituídas em conformidade com a configuração que definiu. Este processo pode ajudar a alcançar um estado de conformidade contínua para as suas obrigações regulamentares e de segurança.

Plataformas e sistemas operativos suportados

O Azure Automation DSC é suportado pelos Serviços Cloud do Azure e por outros fornecedores de serviços cloud, pela infraestrutura no local ou por um híbrido de todos estes ambientes.

O Azure Automation DSC suporta os seguintes sistemas operativos:

  • Windows
    • Servidor 2022
    • Server 2019
    • Server 2016
    • Server 2012 R2
    • Server 2012
    • Server 2008 R2 SP1
    • 11
    • 10
    • 8.1
    • 7
  • Linux
    • A extensão DSC Linux suporta todas as distribuições Linux listadas na documentação do PowerShell DSC.

O DSC do PowerShell é instalado em todas as máquinas Linux suportadas pelo Azure Automation DSC.

Requisitos do DSC para Windows

Para máquinas Windows, a extensão de VM de Configuração de Estado Desejado (DSC) do Azure usa WMF para gerenciar versões de recursos do Windows, como o Windows PowerShell DSC e o Windows Remote Management (WinRM). O Azure DSC dá suporte ao WMF 4.0 e posterior, portanto, as máquinas Windows devem executar o Windows Server 2008 R2 SP1, Windows 7 ou posterior.

Quando a extensão do DSC do Azure é chamada pela primeira vez, instala uma versão do WMF compatível com o SO em todas as versões do Windows, exceto no Windows Server 2016 e posterior. O Windows Server 2016 e versões posteriores já têm a última versão do WMF instalada. Após a instalação do WMF, o computador deverá ser reiniciado.

O WinRM está habilitado em nós de máquina que executam o Windows Server 2012 ou posterior e o Windows 7 ou posterior.

O suporte com proxy do agente do DSC está disponível nas compilações 1809 e posteriores do Windows. O suporte com proxy não está disponível no DSC com versões anteriores do Windows.

Outros requisitos do DSC

Se os nós estiverem localizados numa rede privada, o DSC precisará da porta e dos URLs seguintes para comunicar com a Automatização do Azure:

  • Porta: Apenas TCP 443 é necessário para acesso de saída à Internet
  • URL global: *.azure-automation.net
  • URL global do US Gov – Virginia: *.azure-automation.us
  • Serviço do agente: https://<workspaceId>.agentsvc.azure-automation.net

Verifique o seu conhecimento

1.

O que é o State Configuration da Automatização do Azure?

2.

Um script do DSC do PowerShell ______________.

3.

Por que motivo deve utilizar o modo de extração em vez do modo de emissão no DSC?