O que é a State Configuration da Automação do Azure?
Você pode utilizar o State Configuration da 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 funcionalidades da Automação do Azure, examinará o modelo declarativo de Desired State Configuration (DSC) do PowerShell e explorará seus benefícios.
A State Configuration da Automaçã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 Automação do Azure fornece ferramentas para definir configurações e aplicá-las a máquinas reais e virtuais.
Por que usar a State Configuration da Automação do Azure?
A manutenção manual de uma configuração correta e consistente para os servidores que executam seus serviços pode ser difícil e sujeita a erros. A State Configuration da Automação do Azure usa a DSC do PowerShell para ajudar a enfrentar esses desafios. Ela gerencia centralmente os artefatos e o processo da DSC.
A State Configuration da Automação do Azure tem um servidor de pull interno. Você pode direcioná-la a nós para que eles recebam configurações automaticamente desse servidor de pull, estejam em conformidade com o estado desejado e relatem a respectiva conformidade. Você pode direcioná-la a computadores Windows ou Linux físicos ou virtuais, na nuvem ou localmente.
Você pode utilizar os logs do Azure Monitor para examinar a conformidade dos seus nós, definindo a Configuração do State Configuration do Azure para enviar esses dados.
O que é a DSC do PowerShell?
A DSC do PowerShell é uma plataforma de gerenciamento declarativa que a State Configuration de Automação do Azure usa para configurar, implantar e controlar sistemas. Uma linguagem de programação declarativa separa a intenção (o que você deseja fazer) da execução (como deseja fazer isso). Você especifica o estado desejado e deixa a DSC fazer o trabalho para chegar lá. Você não precisa saber como implementar ou implantar um recurso quando um recurso da DSC está disponível. Em vez disso, você pode focar na sua estrutura de implantação.
Se você já usa o PowerShell, pode estar se perguntando “Por que preciso da DSC?”. Considere o exemplo a seguir.
Quando você deseja criar um compartilhamento em um servidor Windows, pode usar o seguinte comando do PowerShell:
# Create a file share
New-SmbShare -Name MyFileShare -Path C:\Shared -FullAccess User1 -ReadAccess User2
Esse script é direto e fácil de entender. No entanto, se usar esse script em produção, você 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 do acesso somente leitura.
Essa abordagem não é idempotente. Idempotência descreve uma operação que terá o mesmo efeito se você executá-la uma vez ou 10.001 vezes. Para obter a idempotência no PowerShell, é necessário adicionar lógica e manipulação de erros. Se o compartilhamento de arquivo não existir, será necessário criá-lo. Se o compartilhamento existir, não será necessário criá-lo. Se User2 existir, mas não tiver acesso de leitura, será necessário adicionar o acesso de leitura.
Seu script do PowerShell seria semelhante a:
$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 você não considerou poderão ocorrer apenas quando surgirem problemas. A DSC lida com casos inesperados automaticamente. Com a DSC, você descreve o resultado, e não o processo para obtê-lo.
O snippet de código da DSC a seguir é 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 utiliza o módulo xSmbShare, que diz ao DSC como verificar o estado de um compartilhamento de arquivos. O Kit de Recursos do DSC tem mais de 100 módulos de recursos, incluindo um para a instalação de um site do IIS. Você encontrará um link para o Kit de Recursos do DSC na unidade Resumo, no final deste módulo.
Você saberá mais sobre a estrutura de código do DSC do PowerShell na próxima unidade.
O que é o LCM?
O LCM (gerenciador de configuração local) é um componente do WMF (Windows Management Framework) em um sistema operacional Windows. O LCM é responsável por atualizar o estado de um nó, como uma VM, para corresponder ao estado desejado. Sempre que o LCM é executado, ele realiza as seguintes etapas:
- Obter: obtém o estado atual do nó.
- Testar: compara o estado atual de um nó com o estado desejado usando um script da DSC compilado (arquivo .mof).
- Definir: atualiza o nó para corresponder ao estado desejado descrito no arquivo .mof.
Você configurará o LCM quando registrar uma VM na Automação do Azure.
Arquiteturas de push e pull na DSC
O LCM em cada nó pode operar em dois modos.
Modo de push: um administrador envia manualmente ou efetua push das configurações para um ou mais nós. O LCM garante que o estado em cada nó corresponda ao que a configuração especifica.
Modo de pull: Um servidor de pull mantém as informações de configuração. O LCM em cada nó consulta 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 de pull envia os detalhes de todas as alterações de configuração de volta para cada nó.
No modo de pull, cada nó deve ser registrado no serviço de pull.
Ambos os modos têm vantagens:
- O modo de push é fácil de configurar. Ele não precisa de sua própria infraestrutura dedicada e pode ser executado em um laptop. O modo de push é útil para testar a funcionalidade da DSC. Você também pode usar o modo de push para colocar um computador com uma nova imagem no estado de linha de base desejado.
- O modo de pull é útil em uma implantação corporativa que abrange um grande número de computadores. O LCM sonda regularmente o servidor de pull para garantir que os nós estejam no estado desejado. Se uma ferramenta ou equipe externa aplicar hotfixes que resultem em dessincronização da configuração em computadores individuais, esses computadores serão rapidamente trazidos de volta à configuração que você definiu. Esse processo pode ajudar você a atingir um estado de conformidade contínua para cumprir suas obrigações de segurança e regulatórias.
Sistemas operacionais e plataformas com suporte
A DSC de Automação do Azure é compatível com os Serviços de Nuvem do Azure e outros provedores de nuvem, com sua infraestrutura local ou com um híbrido de todos esses ambientes.
A DSC de Automação do Azure é compatível com os seguintes sistemas operacionais:
- Windows
- Server 2022
- Server 2019
- Server 2016
- Server 2012 R2
- Server 2012
- Server 2008 R2 SP1
- 11
- 10
- 8.1
- 7
- Linux
- A extensão DSC do Linux dá suporte a todas as distribuições do Linux listadas na Documentação de DSC do PowerShell.
O DSC do PowerShell está instalado em todos os computadores Linux com suporte no DSC de Automação do Azure.
Requisitos da DSC para Windows
Para computadores Windows, a extensão de VM do Desired State Configuration (DSC) do Azure utiliza o WMF para gerenciar as versões de recursos do Windows, como o Windows PowerShell DSC e o Gerenciamento Remoto do Windows (WinRM). O Azure DSC dá suporte ao WMF 4.0 e posterior, portanto, os computadores Windows devem executar o Windows Server 2008 R2 SP1, o Windows 7 ou posterior.
Na primeira vez que a extensão da DSC do Azure é chamada, ela instala uma versão compatível com o sistema operacional do WMF em todas as versões do Windows, exceto o Windows Server 2016 e posterior. O Windows Server 2016 e versões posteriores já têm a versão mais recente do WMF instalada. Após a instalação do WMF, o computador precisará ser reiniciado.
O WinRM está habilitado nos nós do computador que executam o Windows Server 2012 ou posterior e o Windows 7 ou posterior.
O suporte de proxy para o agente de DSC está disponível em builds Windows 1809 e posteriores. O suporte de proxy não está disponível na DSC para versões anteriores do Windows.
Outros requisitos da DSC
Se seus nós estiverem localizados em uma rede privada, a DSC precisará da porta e das URLs a seguir para se comunicar com a Automação do Azure:
- Porta: Somente o TCP 443 é obrigatório para o acesso à Internet de saída
- URL global: *.azure-automation.net
- URL global do US Gov – Virgínia: *.azure automation.us
- Serviço de agente: https://
<workspaceId>.agentsvc.azure-automation.net