Uma história sobre a irmandade entre Microsoft Cloud Adoption Framework para Azure, Terraform e Terragrunt

Bem-vindos companheiros de viagem!

Este e os próximos artigos desta série com várias partes serão nossa melhor tentativa para descrever a jornada de projetar e implementar uma framework de operação que possa conciliar:

Boas práticas recomendadas pela Microsoft Cloud Adoption Framework para Azure;
Princípios e ferramentas de Infrastructure as Code (IaC): Terraform/Terragrunt;

O objetivo não será apresentar uma explicação exaustiva sobre a Microsoft Cloud Adoption Framework (CAF) ou Terraform/Terragrunt, mas sim descrever a forma como estes sistemas podem interagir para criar um ambiente robusto e gerível e fazer uma implementação escalável em Azure Cloud.

Se não estiver familiarizado com estes conceitos, pode ficar a saber um pouco mais sobre eles aqui e tornar a sua jornada menos assustadora:

Se, por outro lado, está pronto para continuar, então vamos em frente!

Parte 1

Deixando o Shire: Primer em IaC com Terraform/Terragrunt

Aqui, tentaremos fazer um breve resumo dos princípios essenciais de IaC e como eles se apresentam ao usar o Terraform.

Mas primeiro…

A Regra de Ouro de IAC

Todas as alterações na infraestrutura devem ser realizadas com a ferramenta e pipelines definidos para este fim! Não são permitidas alterações manuais!

Isso significa que não há chamadas diretas à API, ferramentas CLI, alterações no portal/consola do fornecedor, telepatia, magia, etc…

Lembre-se: para colher os benefícios da abordagem IaC, devemos ter a certeza de que o que está definido no código = o que foi realmente implementado! Se as alterações manuais não puderem ser erradicadas do fluxo de trabalho da equipa ou utilizadas apenas em caso de necessidade absoluta mais extrema (e depois imediatamente “assimiladas” em código), o IaC não é apenas inútil, mas contraproducente e perigoso!

Dito isto, vamos discutir a nossa abordagem de 3 camadas de IaC com Terraform/Terragrunt: Modules, Stacks e Live.

Módulos

Estes são os blocos que serão usados para construir a infraestrutura a ser implementada. Normalmente, eles irão encapsular um ou mais recursos de fornecedor de cloud, tornando esta operação “atómica”. Os módulos terão parâmetros de entrada e parâmetros de saída.

Isto permitirá que eles sejam reutilizáveis e combináveis.

Os módulos Terraform são, em outras linguagens de programação, funções!

Um exemplo simples pode ser um módulo para definir um resource group do Azure, incluindo definições de bloqueio. Um exemplo mais complicado pode ser um módulo que é uma composição de outros módulos, por exemplo, um módulo de rede que chamará módulos de rede virtual, sub-rede, nsg, para implantar uma rede inteira no Azure.

Normalmente, todos os principais fornecedores de cloud oferecem repositórios públicos de módulos utilizáveis, por isso, na maioria das vezes, não precisaremos nos preocupar muito a esse respeito.

Como veremos mais adiante, o Azure lida com isso de uma maneira “especial”…

Stacks

Aqui é onde a “infraestrutura” real do projeto/cliente é definida, “empilhando” módulos uns nos outros.

O código do Terraform será construído usando módulos previamente definidos e implementados na camada de módulos (sempre que necessário, novas funcionalidades devem ser implementadas com módulos, para que possam ser chamadas para atender não apenas às necessidades atuais, mas também às futuras). Referências diretas a recursos de cloud devem ser evitadas.

Assim como os módulos, a stack deve sempre receber parâmetros de entrada que serão usados em todo o código.

A definição do código de infraestrutura nesta camada deve seguir os mesmos princípios básicos da camada de módulos, pois a própria stack será “tratada” como um módulo, na próxima camada.

Assim como os módulos, veremos que o Azure possibilita uma abordagem peculiar nessa camada…

Live

Esta camada será a responsável por implantar os recursos no fornecedor de cloud e chamará diretamente o código de infraestrutura definido na camada anterior, passando todas as variáveis de entrada necessárias.

Aqui é onde os ambientes (sandbox, dev, QA, prod, etc…) e regiões (West Europe, Central US, etc…) serão definidos.

O pipeline de automação para implantação no fornecedor de cloud será vinculado a repositórios nessa camada.

Essa separação vai-nos permitir usar a mesma base de código (menos copiar e colar → menos desvio de código → menos diferenças estruturais entre ambientes → menos surpresas desagradáveis), conforme definido na camada anterior, para implementar infraestruturas semelhantes ou iguais, simplesmente alterando os parâmetros de entrada .

Concretamente, isso vai permitir:

replicar facilmente a infraestrutura entre ambientes. Por exemplo, dev e prod terão a mesma estrutura, mas dev usará menos instâncias de VM de uma família mais barata do que prod;
implantar infraestruturas multirregionais com facilidade;
promover implantações entre ambientes (sandbox → dev → QA → prod) facilmente e livre de riscos, simplesmente alterando as referências (tag) para um repositório GIT.

Uma imagem vale mais que mil palavras…

Nota importante sobre o GIT:

Em todas estas camadas, é imperativo que o uso adequado do código no Git seja garantido! O IaC não funciona de outra maneira!

Em todos os repositórios, o código deve ser assinalado com a versão e deve ser mantido um registo de alterações adequado, com base nas alterações confirmadas: isso tornará possível o tracking preciso do código (o status da infraestrutura) ao longo do tempo, permitindo, por exemplo, reversões simples, se necessário.

Sempre que módulos ou stacks são referenciados (ou seja, chamados de outros módulos ou outro código), essas referências devem sempre ser criadas para um tag ou versão apropriada. Nunca devem ser referenciadas “branches” main/master/develop, pois elas estão em permanente atualização.

Nenhuma alteração de código nos repositórios de stack ou módulo pode afetar os ambientes “live” de qualquer estágio!

O Fim (para já…)

Parabéns! Chegou ao fim da primeira parte desta jornada!

Sabemos que este ainda não é um artigo muito “prático”, mas esperamos que tenha uma ideia sobre os princípios essenciais do IaC, pois eles serão aplicados nos próximos artigos desta série.

Se quiser ir mais longe no universo de IaC, Terraform ou Terragrunt, aconselhamos este artigo, pois foi uma das nossas principais fontes de inspiração!

Obrigado por ficar connosco até aqui e esperamos encontrá-lo novamente em breve!