Terraform e EaC

(sim, com E).

Autor:
André “Ramoni” Guimarães, Mecânico de infraestrutura no Cloud Team M4U.

As ferramentas de infraestrutura como código, não só para cloud, têm ficado bastante populares por aqui de uns 8 anos para cá, mas em poucos casos exploram todo o seu potencial.

Digo isso porque, antes de pensar em qualquer ferramenta de IaC, devemos nos questionar para que precisamos delas:

Se tudo o que você quer é subir um servidor de forma automatizada, tudo bem, mas muitas ferramentas fazem muito mais que isso. De que adianta subir uma aplicação de forma completamente automatizada se, depois que subir, você ainda precisar adicioná-la no monitoramento manualmente?

Meu desejo, por exemplo, é que eu consiga subir uma cópia de todos os serviços e aplicações da empresa em outra região qualquer da cloud que usamos, na hora em que eu quiser e sem nenhuma intervenção humana (ok, talvez apenas um “play” num pipeline).
Por mais estranho que pareça, é mais simples do que muita gente acha. Não seria uma coisa rápida, é claro, pois são muitas coisas que precisam ser configuradas como: DNS, redes, interligar todas as novas redes, gateways, load balancers, serviços de infraestrutura e, por fim, as aplicações. Além de possível, é bem mais simples caso você se prepare para isso.

Mas porque alguém iria querer subir uma cópia EXATA de todas as aplicações da empresa em outra região da cloud? É para caso a cloud caia? Não. Muita coisa precisa acontecer para uma região inteira de uma cloud sair do ar. Não é para isso que estamos nos preparando.
Então é “Because we can”? Mais ou menos. A palavra chave é “EXATA”. A possibilidade de subir todos os sistemas e aplicações onde e quantas vezes quisermos, por si só já é bem útil, porém o próprio processo de desenvolver a infra e as apps pensando nisso é que gera os maiores benefícios.

Quando uma aplicação precisa de mudanças, nós não alteramos a aplicação que está rodando, nós codificamos uma nova versão e fazemos o deploy dela. Não tocamos (em circunstâncias normais) o ambiente em si, quem faz a intervenção é o sistema de deploy e não um humano.
Porque não tratamos infraestrutura da mesma forma?

O termo “Infraestrutura imutável”, resumindo muito, significa exatamente isso: não altere o avião voando, substitua-o. Quando você opta pela infraestrutura imutável, praticamente todo deploy é um deploy de infraestrutura. Codifique as mudanças necessárias naquela parte da infraestrutura e siga com seu sistema de deploy. Você ganhará para a sua infra todos os benefícios que os desenvolvedores já tem há anos, como versionamento, rollback fácil, mudanças auditáveis, “backup” (configurações, não dados) etc.
Ok, mas como fazer isso?

Aí entram as ferramentas. Uma vez que você define onde quer chegar e quais problemas quer resolver, você escolhe as ferramentas para tal. Em nosso caso escolhemos o Terraform porque ele é uma ferramenta na qual nós descrevemos o que precisamos e ele toma as ações necessárias para alcançar isso. Além disso, o Terraform tem suporte para praticamente todos os provedores de cloud e muitos outros serviços e ferramentas.

Definição vs Orquestração
Precisamos esclarecer que nem toda automação é bem-vinda. Qualquer automação que simule e substitua uma intervenção manual, principalmente reativa, deve ser evitada.

Exemplo: se os servidores de uma determinada aplicação ficam sobrecarregados, você cria uma automação que detecta isso e toma a ação de subir mais instâncias dessa aplicação.
Isso é uma ação manual que, por acaso, agora será executada por software, mas continua sendo uma intervenção reativa.

Isso é um problema por 2 motivos:

Mas porque nós não devemos alterar nem estes simples parâmetros de escalabilidade “na mão”? Simples.
Se uma aplicação exibir métricas de CPU e/ou memória muito mais altas ou baixas depois de um deploy, é porque houve uma mudança de performance, certo?

Esta mudança pode ter sua origem entendida pelos commits e comentários no repositório da aplicação.
Aí repito: porque infra não pode seguir o mesmo caminho? Idealmente, a infra da aplicação, que é feita sob medida especificamente pra ela, com suas configurações de autoscaling, estarão no mesmo repositório, logo as alterações desses parâmetros devem seguir o fluxo normal do desenvolvimento da aplicação.

No final do dia, se houve alguma alteração de performance nos indicadores, pode ter sido por causa do código da aplicação ou do código de infra e, estando no mesmo repositório, você saberá.

Voltando ao Terraform
O Terraform utiliza um arquivo para persistir o estado. O objetivo aqui não é explicar como ele funciona, mas dizer que ele pode guardar este arquivo remotamente, como num bucket. Além de facilitar muito o trabalho em equipe, permite uma coisa muito legal: outros projetos Terraform consultarem informações de qualquer projeto. Claro, limitado pelas permissões que você puser no bucket.

Dito isso, como temos feito aqui na M4U:
Para cada time ou grupo de aplicações, nós criamos um repositório contendo apenas código Terraform para gerar esses dados que serão utilizados pelos projetos subsequentes.
Normalmente colocamos informações de endereçamento IP das subnets, DNS interno e outras coisas bem básicas de acordo com cada ambiente (dev/stg/prd1/prd2 etc.), e separamos os seus estados usando o recurso de workspaces do Terraform.
Logo em seguida vem um outro projeto (ou seja, outro repositório), que cria toda a topologia de rede usando as informações do repositório anterior. A preparação para subir em qualquer lugar começa aí, pois só precisaremos acrescentar informações de ambientes no primeiro repositório, já que a partir deste segundo projeto não fazemos mais referência ao ambiente, podendo rodar em qualquer workspace para o qual existam os dados necessários.

Depois disso, se a aplicação for rodar em instâncias (não containers), vem o repositório da aplicação com o código ansible e packer para gerar a imagem da instância e o Terraform para subir essa imagem no ambiente e configurar toda a parte de load balance, dns e autoscaling das instâncias.

Temos poucos casos assim, mas é possível ter uma aplicação rodando em instâncias com um autoscaling muito bom. Se a aplicação roda em container, nós teremos duas opções aqui na M4U: rodar direto na cloud no serviço de containers ou rodar no nosso PaaS interno (que, quando é o caso, o repositório da aplicação é o único que você precisa).

Rodando no serviço de containers da cloud, nós então criamos um repositório apenas com código Terraform para criar o cluster de containers e o load balancer desse cluster, que poderá ser usado por todas as aplicações de um mesmo time, por exemplo.
A partir daí, cada repositório de aplicação terá o código da app e o código Terraform para colocar a app no cluster e no load balancer.

Alguns benefícios
O fluxo de desenvolvimento e teste de cada aplicação é bem flexível com este modelo, podendo usar somente dois ambientes como staging e produção ou mesmo um modelo com mais ambientes, como: dev/qa/stg/homolog/preprod/prod1/prod2/cliente1/cliente2 etc. Afinal,

Como o ambiente todo está definido como código, podemos instanciá-lo onde e quantas vezes quisermos e destruirmos tão logo não precisemos mais. Essa é a base, por exemplo, para fazermos sharding de infraestrutura, que nos possibilita ter uma infra totalmente separada a cada tantos clientes ou mesmo uma infra dedicada para algum cliente.

Você pode deixar alguém subir todo um ambiente novo em uma nova conta da cloud para ter seu próprio ambiente de teste, como também pode ter mais de um ambiente produtivo, ou ate mesmo chavear entre dois ambientes completos num deploy, fazendo um verdadeiro blue/green ao nível de infraestrutura.

As pessoas novas nos times serão capazes de efetuar deploys mesmo antes de saberem como a app funciona. Poderão subir um ambiente somente seu para aprendizado e para elas entenderem o que está sendo feito basta olhar os repositórios.

Gerentes e diretores ficarão mais tranquilos, pois confiam que toda a infraestrutura e aplicações estão salvas em repositórios e não na cabeça de algumas pessoas.

Seja qual for a ferramenta que você escolheu, ou um conjunto de ferramentas, tente entender bem o potencial delas para que atendam ao seu objetivo da melhor forma possível.

Aqui o objetivo é esse e, para isso, tudo deve ser feito como código.
(daí o EaC – Everything as Code)

Related posts:

Following the previous partnership with PolkaFoundry, TribeOne is launching the IDO of its $HAKA on the Red Kite launchpad on June 23. The whitelist is open for registrations from June 14. Over the…