Share via

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

  • Artigo

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

OE:05 Prepare recursos e suas configurações usando uma abordagem de IaC (infraestrutura como código) padronizada. Como outros códigos, crie 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 IaC como o padrão para suas implantações de infraestrutura. O uso de 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 para todos os componentes da 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 se destina a ser substituída por uma nova infraestrutura que executa a nova configuração a cada implantação. Ele não deve ser alterado em vigor.
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 se destina a 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 na cadeia de fornecedores e padronizando ferramentas e guias de processos , você deve ter uma política estrita de implantação de alterações de infraestrutura (incluindo alterações de configuração) somente por meio do 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 em 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 guia de estilo incluem:

Prefira ferramentas declarativas em vez de imperativas. Ferramentas declarativas e seus arquivos associados são uma escolha geral melhor para implantar e gerenciar IaC do que 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, para que os arquivos possam 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 manutenção do código imperativo, como scripts de implantação, que podem se acumular ao longo do tempo.

Use as ferramentas nativas da 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 de IaC fácil e simples. 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 têm suporte na plataforma e incluem funcionalidades internas para a maioria das suas necessidades. Eles são atualizados continuamente pelo provedor de plataforma, tornando-os mais úteis à medida que a plataforma evolui.

Observação

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

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 de 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 cada operação de gerenciamento.

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

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

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 configurações. 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 mudar ao longo do ciclo de vida da carga de trabalho ou que raramente podem mudar. Eles não devem ser abstraídos.

Observação

Evite usar diferentes ativos de IaC 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 ambientes diferentes, conforme necessário.

Estratize 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 atencioso, no entanto, sobre como você usá-los. Uma estratégia de abstração padronizada ajuda a garantir que os módulos sejam criados 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, em, por exemplo, cenários sem sentido.

Padrões de documento para etapas manuais. Pode haver etapas relacionadas à implantação e manutenção da infraestrutura que são específicas ao seu ambiente e que exigem intervenção manual. Verifique se essas etapas são minimizadas o máximo possível e documentadas claramente. No guia de estilo e nos procedimentos operacionais padrão, padronizar as etapas manuais para garantir que as tarefas sejam executadas de forma segura e consistente.

Padrões de documento para lidar com recursos órfãos. Dependendo das ferramentas usadas 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 de PaaS para alguma função e que as ferramentas de IaC não têm lógica para remover os recursos desativados. Esses recursos poderão ficar órfãos se a equipe de carga de trabalho não se lembrar de excluí-los manualmente. Para lidar com esses cenários, padronizar 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.

Outras estratégias de IaC

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

Use uma abordagem em camadas para alinhar os pipelines de IaC na pilha de carga de trabalho. Separar os pipelines de IaC em camadas ajuda você 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 correspondem de perto facilita o gerenciamento de implantações de IaC.

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 criar um pipeline de IaC de baixo toque . Você pode ter um ou mais pipelines de IaC de toque médio e alto toque 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 por clusters, recursos de armazenamento e serviços de banco de dados. Camadas de alto toque seriam compostas pelos contêineres de aplicativo que são atualizados com muita frequência em um modo de entrega contínua.

Trate sua IaC e o código do aplicativo da mesma forma. Tratar seus artefatos de 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 de IaC devem espelho práticas de aplicativo. Os padrões de 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 os ativos de código do aplicativo. Isso ajuda a garantir que os mesmos processos sejam seguidos com cada implantação e ajuda você a evitar problemas como implantar inadvertidamente a infraestrutura antes do código do aplicativo necessário ou vice-versa.

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 as equipes para concordar com os 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 é prático.

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 de IaC. Examine os repositórios de IaC em busca de chaves e segredos expostos. Uma vantagem de usar IaC é que os membros da equipe focados em segurança podem examinar o código antes da implantação para garantir que a configuração aprovada para lançamento por segurança seja, na verdade, o que é implantado na produção. Para obter diretrizes detalhadas, consulte Recomendações para proteger um ciclo de vida de desenvolvimento.

Rotina de teste e atividades 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.

Infraestrutura mutável versus imutável

A escolha entre implantar uma infraestrutura mutável versus imutável depende de alguns fatores. Se sua carga de trabalho for comercialmente crítica, é melhor usar a infraestrutura imutável. Da mesma forma, se você tiver um design de infraestrutura maduro baseado em selos de implantação, o uso da infraestrutura imutável poderá fazer sentido, pois você pode implantar o código do aplicativo e a nova infraestrutura de forma confiável. Por outro lado, usar a infraestrutura mutável pode ser uma opção melhor se suas práticas de implantação seguras determinarem que avançar com implantações quando surgirem problemas de implantação atenuados é a opção preferencial. 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 bloqueio do fornecedor pode torná-lo uma escolha ruim. É necessário treinar os membros da equipe e analisar a ferramenta certa com base no suporte de ferramentas dos 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 a implementação de IaC atual e segura. Acompanhe corretamente sua dívida técnica e promova uma cultura em que 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 as 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 excesso de engenharia.

Facilitação do Azure

Modelos do ARM (modelos do Azure Resource Manager) e Bicep são ferramentas nativas do Azure para implantar a infraestrutura usando 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 aos pipelines do Azure ou GitHub Actions pipelines de CI/CD.

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 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 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