Recomendações para usar a infraestrutura como código

Aplica-se a esta recomendação de lista de verificação de Excelência Operacional do Azure Well-Architected Framework:

Este guia descreve as recomendações para usar o IaC como padrão para suas implantações de infraestrutura. O uso do IaC permite que você integre suas implantações e gerenciamento de infraestrutura em suas práticas de desenvolvimento de software existentes. Ele fornece uma metodologia padrão consistente para desenvolvimento e implantação para todos os componentes de sua carga de trabalho. Depender de implantações manuais coloca sua carga de trabalho em risco de configurações inconsistentes e design potencialmente inseguro.

Definições

Principais estratégias de design

Conforme discutido nos guias de ferramentas e processos de padronização e cadeia de suprimentos, você deve ter uma política rígida de implantação de alterações de infraestrutura (incluindo alterações de configuração) somente por meio de código. Você deve implantar o IaC por meio de seus pipelines de integração contínua e entrega contínua (CI/CD). A adoção dessas políticas impõe consistência nos processos para todas as implantações de IAC, minimiza o risco de desvio de configuração em seus ambientes e garante a consistência da infraestrutura em todos os ambientes. Além disso, você deve padronizar suas ferramentas e processos de desenvolvimento e implantação do IaC em um guia de estilo. As recomendações para o seu guia de estilo incluem:

Prefira ferramentas declarativas a imperativas

As ferramentas declarativas e seus arquivos associados são uma melhor escolha geral para implantar e gerenciar o IaC do que as ferramentas imperativas. As ferramentas declarativas usam uma sintaxe mais simples para seus arquivos de definição, definindo apenas o estado desejado do ambiente após a conclusão da implantação. As ferramentas imperativas dependem da definição das etapas necessárias para chegar ao estado final desejado, de modo que os arquivos podem ser muito mais complexos do que os arquivos declarativos. Os arquivos de definição declarativa também ajudam a reduzir a dívida técnica de manter código imperativo, como scripts de implantação, que podem se acumular ao longo do tempo.

Use ferramentas nativas e padrão do setor

Use as ferramentas nativas da sua plataforma de nuvem e outras ferramentas comprovadas pelo setor que se integram nativamente à plataforma. Sua plataforma de nuvem fornece ferramentas para tornar a implantação do IaC fácil e direta. Aproveite essas ferramentas e outras ferramentas de terceiros que têm integração nativa, como o Terraform, em vez de desenvolver suas próprias soluções. As ferramentas nativas são suportadas pela plataforma e incluem funcionalidade integrada para a maioria das suas necessidades. Eles são continuamente atualizados pelo provedor da plataforma, tornando-os mais úteis à medida que a plataforma evolui.

Use a ferramenta certa para a tarefa

Use as ferramentas certas para tarefas específicas e tipos de infraestrutura. Várias tarefas, além das implantações, estão envolvidas em um ciclo de vida da infraestrutura. A configuração precisa ser aplicada e mantida, por exemplo, e a ferramenta usada para criar scripts de implantações, como o Bicep, pode não ser a melhor ferramenta para todas as operações de gerenciamento.

Da mesma forma, a aplicação da configuração de estado desejado (DSC) para diferentes tipos de infraestrutura pode exigir ferramentas diferentes. Por exemplo, existem ferramentas específicas como o Ansible para gerenciar DSC para VMs, enquanto o Flux é uma boa ferramenta para gerenciar DSC em clusters Kubernetes. Os serviços de plataforma como serviço (PaaS) podem fornecer diferentes ferramentas para gerenciamento de configuração (como a Configuração de Aplicativo do Azure) que podem ser manipuladas por meio do IaC. Os serviços de software como serviço (SaaS) podem ser mais limitados porque são controlados de forma mais rígida pela plataforma.

Pense em todas as tarefas e tipos de infraestrutura que estão no escopo de suas práticas de IaC e padronize as ferramentas que fazem os trabalhos que você precisa que elas façam e possam ser integradas às suas práticas de desenvolvimento e gerenciamento.

Suporte a vários ambientes

Seus scripts e modelos devem ser flexíveis o suficiente para implantar facilmente uma variedade de ambientes. Use parâmetros, variáveis e arquivos de configuração para implantar um conjunto padrão de recursos que podem ser modificados para implantar qualquer ambiente em sua pilha de promoção de código. Configurações abstratas, como tamanho do recurso, contagem, nome, locais para implantar e algumas definições de configuração. No entanto, tenha cuidado para não abstrair demasiado. Há configurações que podem ser abstraídas com um parâmetro ou variável que pode realmente não mudar ao longo do ciclo de vida da carga de trabalho ou que pode mudar raramente. Eles não devem ser abstraídos.

Use o equilíbrio certo ao encapsular a funcionalidade

Estrategizar e padronizar o uso de módulos. Como parâmetros e variáveis, os módulos podem tornar suas implantações de infraestrutura repetíveis. Seja pensativo, no entanto, sobre como você usá-los. Uma estratégia de abstração padronizada ajuda a garantir que os módulos sejam construídos para atender a objetivos específicos e acordados. Use módulos para encapsular configurações complexas ou combinações de recursos. Evite módulos se estiver usando apenas a configuração padrão do recurso. Além disso, seja criterioso no desenvolvimento de novos módulos. Use módulos de código aberto mantidos quando apropriado, por exemplo, em cenários não sensíveis.

Etapas manuais do documento

Documentar normas para etapas manuais. Pode haver etapas relacionadas à implantação e manutenção da infraestrutura que são específicas do seu ambiente e que exigem intervenção manual. Certifique-se de que essas etapas sejam minimizadas tanto quanto possível e claramente documentadas. Em seu guia de estilo e procedimentos operacionais padrão, padronize as etapas manuais para garantir que as tarefas sejam executadas com segurança e consistência.

Padrões de documentos para lidar com recursos órfãos. Dependendo das ferramentas que você usa para o gerenciamento de configuração e suas limitações, pode haver momentos em que um recurso específico não é mais necessário para sua carga de trabalho e suas ferramentas de IaC não podem remover automaticamente o recurso. Por exemplo, digamos que você esteja mudando de VMs para um serviço PaaS para alguma função e as ferramentas do IaC não tenham lógica para remover os recursos aposentados. Esses recursos podem ficar órfãos se a equipe de carga de trabalho não se lembrar de excluí-los manualmente. Para lidar com esses cenários, padronize uma estratégia para verificar recursos órfãos e excluí-los. Você também precisa considerar como garantir que seus modelos estejam atualizados. Pesquise as limitações de suas ferramentas IaC para entender o que você pode precisar planejar nessas situações.

Considere as seguintes recomendações que se aplicam ao uso do IaC para sua carga de trabalho.

Usar uma abordagem em camadas para pipelines de IaC

Use uma abordagem em camadas para alinhar seus pipelines de IaC dentro da pilha de carga de trabalho. Separar seus pipelines de IaC em camadas ajuda a gerenciar ambientes complexos. Implantar dezenas ou centenas de recursos como um pacote monolítico é ineficiente e pode introduzir vários problemas, como dependências quebradas. O uso de vários pipelines alinhados com camadas compostas por recursos cujos ciclos de vida de implantação ou fatores como a funcionalidade coincidem torna o gerenciamento de implantações de IAC mais fácil.

A infraestrutura principal, como recursos de rede, raramente precisa de alterações mais complexas do que as atualizações de configuração, portanto, esses recursos devem compor um pipeline de IaC de baixo toque . Você pode ter um ou mais pipelines de IAC de toque médio e alto para recursos, dependendo da complexidade da sua carga de trabalho. Usando uma pilha de aplicativos baseada em Kubernetes como exemplo, uma camada de toque médio pode ser composta por clusters, recursos de armazenamento e serviços de banco de dados. As camadas de alto toque seriam compostas pelos contêineres de aplicativos que são atualizados com muita frequência em um modo de entrega contínua.

Trate o IaC e o código do aplicativo da mesma forma

Tratar seus artefatos IaC da mesma forma que os artefatos de código do aplicativo ajuda você a aplicar o mesmo rigor para gerenciar o código em todos os pipelines. Além disso, as práticas de desenvolvimento e implantação do IaC devem refletir as práticas de aplicativos. Os padrões para controle de versão, ramificação, promoção de código e qualidade devem ser idênticos. Considere também a colocação de seus ativos de IaC juntamente com os ativos de código de aplicativo. Isso ajuda a garantir que os mesmos processos sejam seguidos em cada implantação e ajuda a evitar problemas como implantar inadvertidamente a infraestrutura antes do código de aplicativo necessário ou vice-versa.

Use padrões e recursos centralizados

Colabore com outras equipes em sua organização para padronização e reutilização. Às vezes, grandes organizações podem ter várias equipes desenvolvendo e suportando cargas de trabalho. A colaboração entre equipes para chegar a um acordo sobre padrões ajuda você a reutilizar bibliotecas, modelos e módulos para ganhar eficiência e consistência em ambientes de carga de trabalho. Da mesma forma, as ferramentas de IaC devem ser padronizadas em toda a organização, na medida em que isso seja prático.

Reforçar a segurança no código IaC

Aplique o princípio de "segurança como código" para garantir que a segurança faça parte do pipeline de implantação. Inclua a verificação de vulnerabilidades e a proteção de configuração como parte do processo de desenvolvimento do IaC. Analise seus repositórios IaC em busca de chaves e segredos expostos. Uma vantagem de usar o IaC é que os membros da equipe com foco em segurança podem revisar o código antes da implantação para garantir que a configuração aprovada para liberação por segurança seja realmente a implantada na produção. Para obter orientações detalhadas, consulte Recomendações para proteger um ciclo de vida de desenvolvimento.

Teste atividades rotineiras e não rotineiras. Testar implantações, atualizações de configuração e processos de recuperação, incluindo processos de reversão de implantação.

Adote um modelo de implantação imutável

A escolha entre implantar infraestrutura mutável versus imutável depende de alguns fatores. Se sua carga de trabalho for crítica para os negócios, é melhor usar uma infraestrutura imutável. Da mesma forma, se você tiver um projeto de infraestrutura maduro baseado em carimbos de implantação, usar infraestrutura imutável pode fazer sentido, porque você pode implantar o código do aplicativo e a nova infraestrutura de forma confiável. Por outro lado, o uso de infraestrutura mutável pode ser uma escolha melhor se suas práticas de implantação seguras ditarem que avançar com implantações quando surgirem problemas de implantação atenuáveis é a opção preferida. Nesse caso, você provavelmente atualizaria a infraestrutura instalada.

Considerações

Maior especialização: em alguns casos, a introdução de novos idiomas em sua equipe de carga de trabalho vem com uma curva de aprendizado, e a dependência do fornecedor pode torná-la uma escolha ruim. É necessário treinar os membros da sua equipe e analisar a ferramenta certa com base no suporte de ferramentas de seus provedores de nuvem.

Maior esforço de manutenção: A manutenção da base de código e das ferramentas é necessária para manter sua implementação de IaC atualizada e segura. Acompanhe adequadamente a sua dívida técnica e promova uma cultura onde a redução da dívida é recompensada.

Maior tempo para alterações de configuração: implantar a infraestrutura usando instruções de linha de comando ou diretamente de um portal não requer tempo de codificação e/ou artefatos de teste. Minimize o tempo de implantação seguindo práticas recomendadas, como revisões de código e práticas de garantia de qualidade.

Maior complexidade da modularização: Usar mais módulos e parametrização aumenta o tempo necessário para depurar e documentar o sistema e adiciona uma camada de abstração. Equilibre o uso da modularização para reduzir a complexidade e evitar o excesso de engenharia.

Facilitação do Azure

Os modelos do Azure Resource Manager (modelos ARM) e o Bicep são ferramentas nativas do Azure para implantar a infraestrutura usando sintaxe declarativa. Os modelos ARM são escritos em JSON, enquanto o Bicep é uma linguagem específica do domínio. Ambos podem ser facilmente integrados em pipelines do Azure ou pipelines de CI/CD do GitHub Actions.

O Terraform é outra ferramenta IaC declarativa totalmente suportada no Azure. Ele pode ser usado para implantar e gerenciar a infraestrutura e pode ser integrado ao seu pipeline de CI/CD.

Você pode usar o Microsoft Defender for Cloud para descobrir configurações incorretas no IaC.

Exemplo

Consulte a arquitetura do acelerador de zona de aterrissagem da Área de Trabalho Virtual do Azure e a implementação de referência associada para obter um exemplo de uma implementação da Área de Trabalho Virtual que pode ser implantada por meio dos arquivos fornecidos do Gerenciador de Recursos, Bíceps ou Terraform.

Ligações relacionadas

• O que é infraestrutura como código (IaC)?
• Infraestrutura corporativa como código usando Bicep e Azure Container Registry
• Descobrir configurações incorretas no IaC
• Recomendações para projetar uma cadeia de suprimentos de desenvolvimento de carga de trabalho
• Recomendações para padronização de ferramentas e processos
• Recomendações para garantir um ciclo de vida de desenvolvimento
• Recomendações para o uso de práticas de implantação seguras
• Padrão de selos de implantação
• Modelos do Azure Resource Manager (modelos ARM)
• Bicep
• Pipelines do Azure
• GitHub Actions
• Terraform

Lista de verificação de Excelência Operacional

Consulte o conjunto completo de recomendações.