Compartilhar via

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

  • Artigo

Aplica-se a esta recomendação da lista de verificação do Azure Well-Architected Framework Operational Excellence:

OE:05 Prepare os recursos e suas configurações usando uma abordagem de infraestrutura como código (IaC) padronizada. Como outros códigos, projete a IaC com estilos consistentes, modularização apropriada e garantia de qualidade. Prefira uma abordagem declarativa quando possível.

Este guia descreve as recomendações para usar a IaC como o padrão para suas implantações de infraestrutura. O uso da IaC permite que você integre suas implantações e gerenciamento de infraestrutura às suas práticas de desenvolvimento de software existentes. Ele fornece uma metodologia padrão consistente para desenvolvimento e implantação de 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

Termo Definição
Ferramentas declarativas Uma categoria de ferramentas que definem o estado final de uma implantação e dependem do sistema para determinar como implantar os recursos para corresponder ao estado final definido.
Infraestrutura imutável Uma infraestrutura que deve ser substituída por uma nova infraestrutura que executa a nova configuração a cada implantação. Não deve ser alterado no local.
Ferramentas imperativas Uma categoria de ferramentas que lista as etapas de execução que resultam no estado final desejado.
Módulo Uma unidade de abstração para dividir grupos de recursos para simplificar implantações complexas.
Infraestrutura mutável Uma infraestrutura que deve ser alterada no local. As implantações alteram a configuração da infraestrutura em vez de substituí-la por uma nova infraestrutura.

Principais estratégias de design

Conforme discutido nos guias de cadeia de suprimentos e padronização de ferramentas e processos , 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 a IaC por meio de seus pipelines de CI/CD (integração contínua e entrega contínua). A adoção dessas políticas impõe consistência nos processos para todas as implantações de IaC, minimiza o risco de descompasso de configuração em seus ambientes e garante a consistência da infraestrutura em seus ambientes. Além disso, você deve padronizar suas ferramentas e processos de desenvolvimento e implantação de 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 opção geral melhor para implantar e gerenciar 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 de você definir as 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 o 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 da 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 atualizados continuamente pelo provedor da plataforma, tornando-os mais úteis à medida que a plataforma evolui.

Observação

Lembre-se de que, à medida que os provedores de nuvem e desenvolvedores terceirizados atualizam suas ferramentas e APIs, você pode correr o risco de problemas imprevistos ao usar a versão mais recente em sua carga de trabalho. Certifique-se de testar completamente as novas versões de ferramentas e APIs antes de adotá-las. Da mesma forma, evite usar o sinalizador "mais recente" ao chamar uma ferramenta ou API em seu código de implantação. Seja intencional ao chamar a versão válida mais recente para sua carga de trabalho.

Use a ferramenta certa para a tarefa

Use as ferramentas certas para tarefas e tipos de infraestrutura específicos. Várias tarefas, além das implantações, estão envolvidas em um ciclo de vida de infraestrutura. A configuração precisa ser aplicada e mantida, por exemplo, e a ferramenta que você usa 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 PaaS (plataforma como serviço) podem fornecer ferramentas diferentes para gerenciamento de configuração (como Configuração de Aplicativos do Azure) que podem ser tratadas por meio da IaC. Os serviços de software como serviço (SaaS) podem ser mais limitados porque são mais rigidamente controlados 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 podem ser integradas às suas práticas de desenvolvimento e gerenciamento.

Ofereça 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 implantação e algumas definições de configuração. Tenha cuidado para não abstrair muito, no entanto. Há configurações que podem ser abstraídas com um parâmetro ou variável que podem não ser alteradas ao longo do ciclo de vida da carga de trabalho ou que podem ser alteradas raramente. Eles não devem ser abstraídos.

Observação

Evite usar ativos de IaC diferentes para ambientes diferentes. Você não deve ter arquivos Terraform diferentes para ambientes de produção e teste, por exemplo. Todos os ambientes devem usar um arquivo. Você pode manipular esse arquivo para implantar em diferentes ambientes, conforme necessário.

Use o equilíbrio certo ao encapsular a funcionalidade

Crie estratégias e padronize o uso de módulos. Assim como parâmetros e variáveis, os módulos podem tornar suas implantações de infraestrutura repetíveis. Seja atencioso, no entanto, sobre como você os usa. Uma estratégia de abstração padronizada ajuda a garantir que os módulos sejam construídos para atender a metas específicas e acordadas. Use módulos para encapsular configurações complexas ou combinações de recursos. Evite módulos se você 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 software livre mantidos quando apropriado, por exemplo, em cenários não confidenciais.

Documentar etapas manuais

Documente os padrões 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 o máximo 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.

Documente os padrões para lidar com recursos órfãos. Dependendo das ferramentas que você usa para 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 migrando de VMs para um serviço de PaaS para alguma função e as ferramentas de IaC não tenham lógica para remover os recursos desativados. Esses recursos podem se tornar ó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 de IaC para entender o que você pode precisar planejar nessas situações.

Considere as recomendações a seguir que se aplicam ao uso da 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 na pilha de carga de trabalho. Separar seus pipelines de IaC em camadas ajuda a gerenciar ambientes complexos. A implantação de dezenas ou centenas de recursos como um pacote monolítico é ineficiente e pode introduzir vários problemas, como dependências interrompidas. O uso de vários pipelines alinhados com camadas compostas por recursos cujos ciclos de vida de implantação ou fatores como funcionalidade correspondem facilita o gerenciamento de implantações de IaC.

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

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

Tratar os artefatos de IaC da mesma forma que os artefatos de código do aplicativo ajuda 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 de IaC devem espelhar 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 colocar seus ativos de IaC junto com seus ativos de código de aplicativo. Isso ajuda a garantir que os mesmos processos sejam seguidos em todas as implantações e ajuda a evitar problemas como implantar inadvertidamente a infraestrutura antes do código do 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 dando suporte a 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 obter 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.

Impor 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 da IaC. Examine seus repositórios de IaC em busca de chaves e segredos expostos. Uma vantagem de usar a 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 lançamento pela segurança seja realmente o que está implantado na produção. Para obter diretrizes detalhadas, consulte Recomendações para proteger um ciclo de vida de desenvolvimento.

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

Adotar 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 design de infraestrutura maduro baseado em selos de implantação, o uso de infraestrutura imutável pode fazer sentido, pois 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 opção melhor se suas práticas de implantação seguras determinarem que a implementação de implantações quando surgirem problemas de implantação atenuáveis é a opção preferida. Nesse caso, você provavelmente atualizaria a infraestrutura em vigor.

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 o aprisionamento do fornecedor pode torná-lo 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 base de código e a manutenção de ferramentas são necessárias para manter sua implementação de IaC atualizada e segura. Acompanhe adequadamente sua dívida técnica e promova uma cultura em que a redução da dívida seja recompensada.

Maior tempo para alterações de configuração: a implantação da 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 as práticas recomendadas, como revisões de código e práticas de garantia de qualidade.

Maior complexidade da modularização: o uso de 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 ARM (modelos do Azure Resource Manager) e o Bicep são ferramentas nativas do Azure para implantar a infraestrutura usando a sintaxe declarativa. Os modelos do ARM são escritos em JSON, enquanto o Bicep é uma linguagem específica do domínio. Ambos podem ser facilmente integrados a pipelines do Azure ou pipelines de CI/CD do GitHub Actions.

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

Você pode usar o Microsoft Defender para Nuvem para descobrir configurações incorretas na IaC.

Exemplo

Consulte a arquitetura do acelerador de zona de destino 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 de arquivos fornecidos do Resource Manager, Bicep ou Terraform.

Lista de verificação de Excelência Operacional

Consulte o conjunto completo de recomendações.

Lista de verificação de Excelência Operacional