Usar a automação para reduzir esforços e erros
O gerenciamento da infraestrutura de qualquer tipo de carga de trabalho envolve tarefas de configuração. Você pode fazer essa configuração manualmente, mas etapas manuais não são bem dimensionadas. Além disso, elas podem ser trabalhosas, propensas a erros e ineficientes. E se você fosse designado para liderar um projeto que requer a implantação de centenas de sistemas no Azure? Como você criaria e configuraria esses recursos? Quanto tempo isso levaria? Você conseguiria garantir que cada sistema fosse configurado corretamente, sem nenhuma variação entre eles?
Usando a automação em seu design de arquitetura, você consegue superar esses desafios. Nesta unidade, você aprenderá sobre algumas das maneiras de automatizar no Azure.
Infraestrutura como código
A IaC (infraestrutura como código) é o gerenciamento de infraestrutura em um modelo descritivo. A IaC usa um sistema de controle de versão semelhante ao que é usado para o código-fonte. O código em um modelo de IaC descreve a infraestrutura, como redes, máquinas virtuais, balanceadores de carga e topologia de conexão. Ao criar um aplicativo, o mesmo código-fonte gera o mesmo binário sempre que ele é compilado. De maneira semelhante, um modelo de IaC gera o mesmo ambiente sempre que é aplicado. A IaC é uma prática-chave de DevOps geralmente usada em conjunto com a entrega contínua.
A IaC foi desenvolvida para resolver o problema de descompasso de ambientes. Sem a IaC, as equipes precisam manter as configurações dos ambientes de implantação individual. Com o tempo, cada ambiente se torna um floco de neve cada vez mais único que não pode ser reproduzido automaticamente. A administração e a manutenção da infraestrutura desses ambientes floco de eve envolve processos manuais que são difíceis de acompanhar e que contribuem para erros. As inconsistências resultantes entre esses ambientes floco de neve levam a problemas durante as implantações.
Ao automatizar a implantação de serviços e infraestrutura, há duas abordagens diferentes que você pode adotar: imperativa e declarativa.
Com uma abordagem imperativa, você declara explicitamente os comandos que são executados para produzir o resultado que você está procurando.
Com uma abordagem declarativa, você especifica o que deseja que o resultado seja em vez de especificar como deseja que ele seja produzido.
As duas abordagens são boas, portanto, não existe uma escolha errada. Como essas diferentes abordagens são no Azure e como elas podem ser usadas?
Automação imperativa
Vamos começar com a automação imperativa. Com a automação imperativa, estamos especificando como as coisas devem ser feitas. Essa especificação normalmente é feita de maneira programática por meio de uma linguagem de script ou de um SDK. Para os recursos do Azure, é possível usar o Azure PowerShell ou a CLI do Azure. Veja o seguinte exemplo de uso da CLI do Azure para criar uma conta de armazenamento:
az group create \
--name storage-resource-group \
--location eastus
az storage account create \
--name mystorageaccount \
--resource-group storage-resource-group \
--kind BlobStorage \
--access-tier hot
Neste exemplo, estamos especificando como criar esses recursos: execute um comando para criar um grupo de recursos e execute outro comando para criar uma conta de armazenamento. Estamos dizendo explicitamente ao Azure quais comandos devem ser executados para produzir a saída necessária.
Com essa abordagem, podemos automatizar completamente a infraestrutura. Podemos fornecer áreas para entrada e saída e garantir que sempre sejam executados os mesmos comandos. Com a automatização dos recursos, eliminamos as etapas manuais do processo, aumentando a eficiência operacional da administração de recursos.
No entanto, há algumas desvantagens nessa abordagem. Os scripts para criar recursos podem se tornar complexos rapidamente conforme a arquitetura fica mais complexa. Pode ser necessário adicionar tratamento de erro e a validação de entrada para garantir a execução completa. Os comandos podem mudar, exigindo a manutenção contínua dos scripts.
Automação declarativa
Com a automação declarativa, estamos especificando o que desejamos que o resultado seja, deixando os detalhes de como isso é feito para o sistema que está sendo usado. No Azure, é possível realizar a automação declarativa usando modelos do ARM (Azure Resource Manager), que são arquivos estruturados em JSON que especificam o que deve ser criado. Os modelos do ARM têm quatro seções: parâmetros, variáveis, recursos e saídas.
- Os parâmetros manipulam a entrada a ser usada no modelo.
- As variáveis fornecem uma maneira de armazenar valores para uso em todo o modelo.
- Os recursos são as coisas que estão sendo criadas.
- As saídas fornecem detalhes ao usuário sobre o que foi criado.
No exemplo a seguir, estamos dizendo ao Azure que ele deve criar uma conta de armazenamento com os nomes e as propriedades que especificamos. As etapas que realmente são executadas nos bastidores para criar essa conta de armazenamento são deixadas para o Azure decidir.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"name": {
"type": "string"
},
"location": {
"type": "string"
},
"accountType": {
"type": "string",
"defaultValue": "Standard_RAGRS"
},
"kind": {
"type": "string"
},
"accessTier": {
"type": "string"
},
"httpsTrafficOnlyEnabled": {
"type": "bool",
"defaultValue": true
}
},
"variables": {
},
"resources": [
{
"apiVersion": "2018-02-01",
"name": "[parameters('name')]",
"location": "[parameters('location')]",
"type": "Microsoft.Storage/storageAccounts",
"sku": {
"name": "[parameters('accountType')]"
},
"kind": "[parameters('kind')]",
"properties": {
"supportsHttpsTrafficOnly": "[parameters('httpsTrafficOnlyEnabled')]",
"accessTier": "[parameters('accessTier')]",
"encryption": {
"services": {
"blob": {
"enabled": true
},
"file": {
"enabled": true
}
},
"keySource": "Microsoft.Storage"
}
},
"dependsOn": []
}
],
"outputs": {
"storageAccountName": {
"type": "string",
"value": "[parameters('name')]"
}
}
}
É possível usar modelos do ARM para criar e manipular a maioria dos serviços no Azure. Você pode armazenar seus modelos em repositórios de código e herdar todos os benefícios do uso de um sistema de controle do código-fonte. Você também pode compartilhar seus modelos entre ambientes para garantir que a infraestrutura usada para o ambiente de desenvolvimento corresponda ao seu ambiente de produção. Os modelos do ARM são uma ótima forma de automatizar implantações, ajudar a garantir a consistência e eliminar problemas de configuração de implantação. Além disso, eles podem aumentar a velocidade operacional.
Automatizar a implantação da infraestrutura é um ótimo primeiro passo, mas ao implantar máquinas virtuais, ainda há mais coisas a serem feitas. Vamos analisar algumas das abordagens para automatizar a configuração pós-implantação.
Configuração de imagens de VM versus pós-implantação
Para muitas implantações de máquina virtual, o trabalho não está completo quando uma VM simplesmente está funcionando. Em muitas situações, mais configuração é necessária antes que a VM possa atender à finalidade pretendida. Por exemplo: discos adicionais podem precisar de formatação, a VM pode precisar ingressar em um domínio, ou talvez a carga de trabalho de um pacote de software de gerenciamento precise ser instalada e configurada.
Há duas estratégias comuns que você pode usar para o trabalho de configuração, que para todas as intenções e finalidades são consideradas como parte do processo de configuração da própria VM. Cada uma dessas estratégias tem vantagens e desvantagens.
As imagens personalizadas são geradas ao implantar uma máquina virtual e, em seguida, configurar ou instalar um software nessa instância em execução. Quando tudo está configurado corretamente, a máquina virtual pode ser desligada e uma imagem é criada da VM. É possível usar essa imagem como base para implantar outras máquinas virtuais. Trabalhar com imagens personalizadas pode acelerar o tempo geral de implantação. Assim que a máquina virtual é implantada e está em execução, nenhuma configuração extra é necessária. Quando a velocidade de implantação é um fator importante, realmente vale a pena explorar as imagens personalizadas.
O script pós-implantação normalmente aplica uma imagem base básica e conta com scripts ou com uma plataforma de gerenciamento de configuração para executar a configuração necessária após a implantação da VM. O script pós-implantação pode ser feito pela execução de um script na VM por meio da Extensão de Script do Azure ou utilizando uma solução mais robusta, como a DSC (Desired State Configuration) da Automação do Azure.
Cada uma dessas abordagens tem alguns aspectos específicos e algumas considerações compartilhadas para se ter em mente.
Ao usar imagens, você precisará garantir que haja um processo para lidar com atualizações de imagem, patches de segurança e gerenciamento de inventário das imagens propriamente ditas.
Com o script pós-implantação, os tempos de build podem ser estendidos, pois a VM não pode ser adicionada a cargas de trabalho ativas enquanto o build não é concluído. Para sistemas autônomos, um tempo de build mais longo pode não ser um problema significativo. Mas ao usar serviços com dimensionamento automático, por exemplo, os Conjuntos de Dimensionamento de Máquinas Virtuais, esse tempo de build estendido pode afetar a velocidade do dimensionamento.
Com ambas as abordagens, você deseja garantir que o descompasso de configuração seja resolvido. À medida que novas configurações são implementadas, você precisa garantir que os sistemas existentes sejam atualizados adequadamente.
A automatização da implantação de recursos pode ser um grande benefício para o ambiente. A quantidade de tempo economizada e o número de erros reduzidos podem elevar suas capacidades operacionais a outro nível.
Automação de tarefas operacionais
Quando suas soluções estão em funcionamento, há atividades operacionais contínuas que você também pode automatizar. A automatização dessas tarefas com a Automação do Azure e outros serviços do Azure reduz as cargas de trabalho manuais, permite o gerenciamento de configurações e de atualizações dos recursos de computação, fornece uma estrutura para executar qualquer tipo de tarefa do Azure e centraliza os recursos compartilhados, como agendas, credenciais e certificados.
Exemplos dessa automação podem incluir:
- Pesquisar periodicamente se há discos órfãos
- Instalar os patches de segurança mais recentes nas VMs
- Pesquisar e desligar máquinas virtuais fora do horário comercial
- Executar relatórios diários e produzir um painel para mostrar os relatórios ao gerenciamento sênior
Como exemplo, vamos supor que você deseja reduzir os custos de computação configurando uma de suas máquinas virtuais de desenvolvimento para serem executadas somente durante o horário comercial da sua organização. Você pode usar o recurso Iniciar/Parar VMs v2, que depende do Azure Functions para tratar o início e a parada de execução da VM.
Automatizar ambientes de desenvolvimento
Na outra extremidade do pipeline da infraestrutura de nuvem, está uma coleção de computadores de desenvolvimento que seus desenvolvedores usam para escrever os aplicativos e serviços que são o núcleo da empresa. Você pode usar o Azure DevTest Labs para implantar as VMs com todas as ferramentas e os repositórios certos de que seus desenvolvedores precisam. Os desenvolvedores que trabalham em vários serviços podem alternar entre ambientes de desenvolvimento sem precisar provisionar uma nova VM. Esses ambientes de desenvolvimento podem ser desligados quando não estiverem em uso e reiniciados quando forem necessários novamente.