Entender a Automação do Azure
O Azure oferece vários modos de automatizar processos. O Azure Functions e os Aplicativos Lógicos são serviços do Azure que permitem habilitar cargas de trabalho sem servidor. Os dois serviços criam fluxos de trabalho que são uma coleção de etapas criadas para executar tarefas complexas. Por exemplo, um Aplicativo Lógico poderá ser criado para preencher uma tabela em um Banco de Dados SQL do Azure quando uma entrada for criada em uma lista do SharePoint. Uma explicação completa sobre esses serviços está fora do escopo deste curso.
Para obter controle e granularidade mais completos da automação, a Automação do Azure permite automação de processos, gerenciamento de configuração, integração completa com opções de plataforma do Azure (como controle de acesso baseado em função e Microsoft Entra ID) e pode gerenciar recursos do Azure e locais.
Um dos benefícios exclusivos do serviço de Automação do Azure é a possibilidade de gerenciar recursos no Azure ou em VMs locais. Por exemplo, caso tenha uma VM que normalmente é mantida em um estado inoperante para economizar custos (exceto quando ela precisa ser usada), você tem a capacidade de usar um recurso chamado runbooks híbridos no serviço de Automação do Azure para executar um script e iniciar a VM, depois disparar um backup do SQL Server de dentro da VM e por fim desligá-la.
Outro cenário comum é usar Automação do Azure para operações de manutenção periódica, como a limpeza de dados obsoletos ou antigos, ou reindexar um banco de dados SQL.
Componentes de Automação do Azure
O serviço de Automação do Azure é compatível com atividades de automação e gerenciamento de configuração. Vamos nos concentrar nos componentes de automação, mas a Automação do Azure também poderá ser usada para gerenciar atualizações do servidor e o Desired State Configuration. Os componentes de Automação do Azure necessários para executar tarefas automatizadas são os seguintes:
Runbooks – runbooks são a unidade de execução na Automação do Azure. Os runbooks podem ser definidos em três tipos: um runbook gráfico baseado no PowerShell, um script do PowerShell ou um script do Python. Os runbooks do PowerShell são usados com mais frequência para gerenciar recursos do SQL do Azure.
Módulos – a Automação do Azure define um contexto de execução para o código do PowerShell ou do Python em execução no runbook. É preciso importar módulos de suporte para executar o código. Por exemplo, caso precise executar o cmdlet
Get-AzSqlDatabasedo PowerShell, será preciso importar o módulo Az.SQL do PowerShell em sua conta de automação.Credenciais – As credenciais armazenam informações confidenciais que runbooks ou configurações podem usar em um runtime.
Agendamentos – Os agendamentos são vinculados a runbooks e disparam um runbook em um horário específico.
Azure Policy
As Políticas de Grupo ou os GPOs têm sido usados há muito tempo por administradores do Windows Server para gerenciar a segurança e fornecer consistência em todo o ambiente do Windows Server de sua organização. Alguns exemplos de políticas de grupo incluem: a imposição de complexidade de senha, o mapeamento de unidades de rede compartilhadas e a configuração de impressoras em rede.
O Azure Policy inclui definições de iniciativa para ajudar a estabelecer e manter a conformidade com diferentes padrões de segurança na sua conta da Automação. Recursos semelhantes também estão disponíveis no Azure Resource Manager. Uma política fornece um nível de governança sobre suas assinaturas do Azure. Uma política pode impor regras e controles sobre seus recursos do Azure. Alguns exemplos de como será possível usar uma política incluem: limitação das regiões em que é possível implantar um recurso, imposição de padrões de nomenclatura ou controle do tamanho dos recursos. O Azure fornece várias políticas de exemplo que poderão ser usadas. Como alternativa, será possível definir políticas personalizadas usando o JSON.
As políticas são atribuídas a um escopo específico, que poderá ser um grupo de gerenciamento (um grupo de assinaturas gerenciadas em conjunto), uma assinatura, um grupo de recursos ou até mesmo um recurso individual. A política mais usada será aplicada no nível da assinatura ou do grupo de recursos. As políticas individuais podem ser agrupadas usando uma estrutura conhecida como iniciativas, que às vezes são chamadas de conjuntos de políticas. As políticas têm um escopo de atribuição que pode ser definido no recurso individual, no grupo de recursos, na assinatura, no grupo de gerenciamento (um grupo de assinaturas gerenciadas em conjunto) ou em todas as assinaturas de determinado locatário.
Outro exemplo de como será possível implementar o Azure Policy é a marcação de recursos. As tags do Azure, que serão descritas abaixo, armazenam metadados sobre recursos do Azure em pares chave-valor. Além disso, elas geralmente são usadas para realçar o tipo de ambiente (teste, garantia de qualidade ou produção) ou o centro de custo de determinado recurso. Uma política exigindo que todos os recursos tenham uma tag para o ambiente e o centro de custo causará um erro e bloqueará a implantação de recursos do Azure que não tenham as tags necessárias.
Assinaturas e tags do Azure
As organizações usam várias assinaturas por diversos motivos, incluindo: gerenciamento de orçamento, segurança ou isolamento de recursos. Uma organização com recursos internos e voltados para o cliente é um exemplo disso. Os recursos internos podem existir em uma assinatura e os recursos do cliente em outra a fim de facilitar a separação da cobrança e para isolar recursos internos. Essas assinaturas poderão ser gerenciadas em conjunto em um grupo de gerenciamento. Isso permitirá gerenciar a política e a conformidade entre assinaturas.
As tags são apenas metadados usados para descrever recursos do Azure de modo mais adequado. Essas tags são armazenadas como pares key:value e aparecem no portal do Azure associadas aos recursos do Azure. Como as tags estão associadas a um recurso, será possível filtrar comandos com base nelas ao usar comandos do PowerShell ou da CLI do Azure. Desse modo, é possível considerá-las uma cláusula WHERE em uma consulta SQL. Um exemplo básico será mostrado abaixo:
$rg=(get-AzResourceGroup)
$rg=($rg|where-object {($_.tags['Use'] -ne 'Internal')}).ResourceGroupName
Na segunda linha deste exemplo de código, é possível conferir que a lista de grupos de recursos está sendo filtrada por uma tag chamada 'Use' e retornará somente os grupos de recursos em que essa tag não tenha um valor de 'Internal'. As tags podem ser aplicadas no portal do Azure ou de modo programático por meio do PowerShell, da CLI do Azure ou como parte do processo de implantação. As tags também podem ser aplicadas na assinatura, no grupo de recursos ou em um nível do recurso individual. As tags também podem ser modificadas a qualquer momento. O Azure é compatível com uma aplicação de até 15 tags em cada recurso do Azure.
As tags também serão incluídas nas informações de cobrança do Azure. Portanto, a marcação por centro de custo significa que pode ser muito mais fácil para o gerenciamento dividir os encargos do Azure. As tags estão na seção de visão geral da folha de cada recurso do Azure. Para adicionar tags a um recurso usando o portal do Azure, selecione as tags e insira a chave e o valor de sua tag. Selecione Salvar depois de aplicar tags aos recursos.
Também é possível usar o PowerShell ou a CLI para adicionar tags. Um exemplo do PowerShell será mostrado abaixo:
$tags = @{"Dept"="Finance"; "Status"="Normal"}
$resource = Get-AzResource -Name demoStorage -ResourceGroup demoGroup
New-AzTag -ResourceId $resource.id -Tag $tags
Um exemplo da CLI do Azure será mostrado abaixo:
az resource tag --tags 'Dept=IT' 'Environment=Test' -g examplegroup -n examplevnet `
--resource-type "Microsoft.Network/virtualNetworks"
As tags permitem que os clientes organizem os recursos do Azure e a hierarquia de gerenciamento em uma taxonomia.
Observação
As marcações são armazenadas como texto sem formatação. Jamais adicione valores confidenciais às marcações. Valores confidenciais podem ser expostos por meio de muitos métodos, incluindo relatórios de custo, taxonomias de marcação, históricos de implantação, modelos exportados e logs de monitoramento.