Representar infraestrutura como código em um formato textual repetível é uma das melhores práticas para sistemas, que não exige muita engenharia. Essa prática ficou conhecida como — , e atualmente, para implementá-la, especialmente na AWS, existem duas ferramentas populares: e .
Comparo minha experiência com Terraform e CloudFormation
Antes de entrar na (também conhecida como ) trabalhei e durante cerca de três anos utilizei o Terraform. No novo emprego, continuei usando o Terraform, até que a empresa pressionou pela transição para tudo da Amazon, incluindo o CloudFormation. Esforcei-me ao máximo para desenvolver as melhores práticas para ambos, e usei as duas ferramentas em processos de trabalho complexos em larga escala. Mais tarde, ao refletir sobre as consequências da mudança do Terraform para o CloudFormation, percebi que o Terraform, provavelmente, é a melhor escolha para a organização.
Terraform Horrível
Versão Beta do Software
O Terraform ainda não lançou uma versão 1.0, e essa é uma razão significativa para não usá-lo. Desde a primeira vez que o experimentei, ele mudou bastante, mas naquela época terraform apply costumava falhar após algumas atualizações ou simplesmente após alguns anos de uso. Eu diria que "agora tudo é diferente", mas... parece que todos dizem isso, não é? Existem mudanças que são incompatíveis com versões anteriores, embora sejam adequadas, e até parece que a sintaxe e as abstrações de armazenamento de recursos agora estão no ponto. A ferramenta parece realmente ter melhorado, mas... :-0
Por outro lado, a AWS fez um bom trabalho ao manter a compatibilidade com versões anteriores. Provavelmente, tudo isso porque seus serviços costumam ser bem testados dentro da organização e somente depois, renomeados, são publicados. Então, "fizeram um bom trabalho" é um eufemismo. Manter a compatibilidade com versões anteriores da API em um sistema tão variado e complexo como a AWS é incrivelmente desafiador. Qualquer um que tenha tido que manter APIs públicas, que são amplamente utilizadas, deve entender o quão difícil é fazer isso por tantos anos. Em contraste, o comportamento do CloudFormation, até onde me lembro, nunca mudou ao longo dos anos.
Conheça, pé… isso é uma bala
Pelo que sei, excluir um recurso de terceiros Não é possível importar um stack do CloudFormation para seu próprio stack CF. A mesma situação ocorre com o Terraform. Ele permite a importação de recursos existentes para seu stack. A funcionalidade, pode-se dizer, é impressionante, mas com grande poder vem grande responsabilidade. Assim que você adiciona um recurso ao stack, não é possível excluir ou alterar esse recurso enquanto trabalha nele. Uma vez isso custou caro. Em um site como o Twitch, alguém, sem más intenções, acidentalmente importou um grupo de segurança da AWS para seu próprio stack Terraform. Digitou alguns comandos e... o grupo de segurança (junto com o tráfego de entrada) desapareceu.
Terraform O Grande
Recuperação de estados incompletos
Às vezes, o CloudFormation não consegue fazer a transição completa de um estado para outro. Nesse caso, ele tentará voltar ao estado anterior. Infelizmente, isso nem sempre é possível. Depurar o que resultou pode ser assustador — você nunca sabe se o CloudFormation ficará feliz por estar sendo hackeado — mesmo que seja para consertar. E ele não consegue determinar se voltará ou não ao estado anterior, e por padrão fica horas esperando por um milagre.
O Terraform, por outro lado, tende a restabelecer-se após transições malsucedidas de forma mais elegante e oferece um conjunto de ferramentas de depuração avançadas.
Alterações mais claras nos estados do documento
“Tudo bem, balanceador de carga, você está mudando. Mas como?”
— um engenheiro preocupado, pronto para pressionar o botão 'concordar'.
Às vezes, preciso fazer algumas manipulações com o balanceador de carga no stack do CloudFormation — por exemplo, adicionar um número de porta ou alterar o grupo de segurança. O CloudFormation exibe as mudanças de forma fraca. Eu, por outro lado, como se estivesse em uma agulha, verifico o arquivo yaml cerca de dez vezes para ter certeza de que não apaguei nada importante e não adicionei nada desnecessário.
O Terraform é muito mais transparente nesse aspecto. Às vezes, ele é até excessivamente transparente (leia-se: irritante). Felizmente, a última versão incluiu uma visualização melhorada das mudanças — agora é claramente visível o que está sendo alterado.
Flexibilidade
Desenvolva software ao contrário.
Falando diretamente, a característica mais importante de um software duradouro é a capacidade de se adaptar a mudanças. Escreva qualquer software do final para o começo. Na maioria das vezes, eu cometia o erro de pegar um serviço "simples" e depois tentar encaixar tudo em uma única pilha CloudFormation ou Terraform. E, claro, depois de meses, descobria que eu havia entendido tudo errado e que o serviço não era simples, na verdade! E eu precisava de alguma forma dividir a grande pilha em partes menores. Quando você trabalha com CloudFormation, isso só é possível recriando a pilha existente, coisa que eu, com meus bancos de dados, não faço. Já o Terraform permitia dissecar a pilha e dividi-la em partes menores mais compreensíveis.
Módulos no git
Compartilhar código Terraform entre várias pilhas é muito mais fácil do que com o código CloudFormation. Com o Terraform, você pode colocar o código em um repositório git e acessá-lo usando controle de versão semântico. Qualquer um com acesso a esse repositório pode reutilizar o código comum. O equivalente no CloudFormation é o S3, mas ele não tem as mesmas vantagens, e não há razão para abandonarmos o git em favor do S3.
A organização cresceu e a capacidade de compartilhar pilhas comuns alcançou um nível crítico. Com o Terraform, tudo isso acontece de forma fácil e natural, enquanto o CloudFormation faz você pular por vários obstáculos antes que algo semelhante funcione.
Operações como código
"Vamos scriptar e pronto."
— um engenheiro três anos antes de inventar a bicicleta Terraform.
Quando se trata de desenvolvimento de software, Go ou um programa em Java não é apenas código.
Código como Código
Há também a infraestrutura na qual ele opera.
Infraestrutura como Código
Mas de onde ela vem? Como monitorá-la? Onde está o seu código? Os desenvolvedores precisam de permissão para acesso?
Operações como Código
Ser um desenvolvedor de software não é apenas escrever código.
Não é só AWS: você provavelmente usa serviços de outros fornecedores. SignalFx, PagerDuty ou GitHub. Talvez você tenha um servidor Jenkins interno para CI/CD ou um painel de controle Grafana interno para monitoramento. A Infraestrutura como Código é escolhida por várias razões, e todas elas são igualmente importantes para tudo relacionado ao software.
Enquanto eu trabalhava na Twitch, acelerávamos serviços dentro de sistemas embarcados mistos e sistemas da AWS da Amazon. Nós criávamos e mantínhamos muitos microsserviços, aumentando os custos operacionais. As discussões se davam mais ou menos assim:
- Eu: Caramba, é muita movimentação para fazer um único microsserviço funcionar. Vou ter que usar essa coisa para criar uma conta na AWS (estávamos indo para 2 contas em microsserviço), depois esta — para configurar alertas, ainda esta — para o repositório de código, e esta — para a lista de endereços de e-mail, e esta aqui…
- Líder: Vamos escrever um script e é isso.
- Eu: Beleza, mas o próprio script vai mudar. Vai ser necessário um jeito de verificar se todas essas coisinhas da Amazon estão com estado atual.
- Líder: Parece bom. E para isso vamos escrever um script.
- Eu: Ótimo! E o script com certeza precisará de parâmetros. Ele vai aceitar?
- Líder: Sim, ele vai aceitar, onde mais ele iria?
- Eu: O processo pode mudar, e a compatibilidade retroativa pode se perder. Vai ser necessário algum tipo de controle de versão semântico.
- Líder: Ótima ideia!
- Eu: As ferramentas podem ser alteradas manualmente, pelo interface do usuário. Vamos precisar de uma maneira de verificar e corrigir isso.
…3 anos depois:
- Líder: E acabou que temos o terraform.
A moral da história é que mesmo se você estiver até o pescoço com tudo da Amazon, você ainda está usando algo que não é da AWS, e esses serviços têm um estado que utiliza uma linguagem de configuração para sincronizar esse estado.
CloudFormation lambda vs módulos git do terraform
lambda é a solução do CloudFormation para questões de lógica do usuário. Com lambda, você pode ou . Essa abordagem traz complexidades adicionais que não existem no controle de versão semântico dos módulos git do Terraform. Para mim, o problema mais urgente se tornou a gestão de permissões para todas essas lambdas personalizadas (e isso são dezenas de contas AWS). Outro problema importante foi o tipo 'o que veio primeiro — a galinha ou o ovo?': isso estava relacionado ao código da lambda. Essa função em si é infraestrutura e código, e ela mesma precisa de monitoramento e atualizações. O último prego no caixão foi a dificuldade de atualizar semanticamente as mudanças no código da lambda; também foi necessário garantir que as ações da pilha não mudassem entre execuções sem um comando direto.
Lembro que, em uma ocasião, eu quis criar um deploy canário para o ambiente Elastic Beanstalk com um balanceador de carga clássico. O mais simples seria fazer um segundo deploy para o EB ao lado do ambiente de produção, dando mais um passo: combinando automaticamente o grupo escalável do deploy canário com o LB do deploy no ambiente de produção. E já que o Terraform usa , isso exigirá 4 linhas adicionais de código no Terraform. Quando perguntei se havia uma solução comparável no CloudFormation, me apontaram para um repositório inteiro no git com um pipeline de deploy e outras coisas: tudo isso só para algo que poderíamos fazer com 4 simples linhas de código no Terraform.
Ele percebe melhor o drift
Verifique se a realidade corresponde às expectativas.
— é uma função muito poderosa de operações como código, porque ajuda a garantir que a realidade corresponda às expectativas. Está disponível tanto no CloudFormation quanto no Terraform. Mas à medida que o stack de trabalho cresce, a busca por drift no CloudFormation apresentava cada vez mais falsos positivos.
Com o Terraform, você tem ganchos de ciclo de vida muito mais avançados para detecção de drift. Por exemplo, você insere o comando diretamente na definição da tarefa ECS, se quiser ignorar mudanças na definição de uma tarefa específica, sem ignorar mudanças em todo o deploy do ECS.
CDK e o futuro do CloudFormation
O CloudFormation é difícil de gerenciar em grandes escalas interinfraestruturais. Muitas dessas dificuldades são reconhecidas, e a ferramenta precisa de coisas como , uma estrutura para definir a infraestrutura de nuvem em código e passar isso pelo AWS CloudFormation. Será curioso ver o que aguarda o aws-cdk no futuro, mas será difícil para ele competir com outras vantagens do Terraform; para igualar o CloudFormation, serão necessárias mudanças globais.
Para que o Terraform não decepcione
É 'infraestrutura como CÓDIGO', e não 'como texto'.
Minha primeira impressão do Terraform foi bastante negativa. Acredito que eu simplesmente não entendi a abordagem. Quase todos os engenheiros, à primeira vista, o percebem involuntariamente como um formato de texto que precisa ser transformado na infraestrutura desejada. NÃO É ASSIM QUE FUNCIONA.
As verdades básicas de um bom desenvolvimento de software se aplicam ao Terraform
Eu vi que muitas práticas adotadas para criar um bom código são ignoradas no Terraform. Você aprendeu durante anos para se tornar um bom programador. Não abandone essa experiência só porque está trabalhando com Terraform. Verdades fundamentais sobre o desenvolvimento de software se aplicam ao Terraform.
Como é possível escrever código e não documentá-lo?
Eu encontrei enormes pilhas de Terraform completamente sem documentação. Como é possível escrever código em várias páginas — completamente sem documentação? Adicione documentação que explique seu código Terraform (com ênfase na palavra 'código'), por que esta seção é tão importante e o que você está fazendo.
Como você pode implantar serviços que antes eram uma única grande função main()?
Eu encontrei pilhas de Terraform muito complexas, apresentadas como um único módulo. Por que não implantamos software dessa forma? Por que fracionamos grandes funções em partes menores? As mesmas respostas se aplicam ao Terraform. Se o seu módulo é muito grande — divida-o em módulos menores.
Sua empresa não usa bibliotecas?
Eu vi engenheiros, ao iniciar um novo projeto com Terraform, simplesmente copiando e colando enormes trechos de outros projetos nos seus próprios, e depois mexendo neles até funcionarem. Você, na sua empresa, trabalharia assim com código 'de produção'? Não usamos bibliotecas à toa. Sim, mas onde estaríamos sem bibliotecas comuns, afinal?!
Você não usa PEP8 ou gofmt?
Na maioria das linguagens, existe um padrão de formatação aceito. Em Python, é o PEP8. Em Go, é o gofmt. O Terraform tem o seu: terraform fmt. Sinta-se à vontade para usar!
Você começaria a usar React sem saber JavaScript?
Os módulos do Terraform podem simplificar alguma parte da infraestrutura complexa que você está construindo, mas isso não significa que você possa ignorar completamente o funcionamento. Quer usar o Terraform corretamente sem entender os recursos? Você está fadado ao fracasso: o tempo vai passar e você ainda não dominará o Terraform.
Você codifica singletons ou injetando dependências?
A injeção de dependências é considerada a melhor prática para o desenvolvimento de software, preferida por singletons. Como isso pode ser útil no Terraform? Eu encontrei módulos do Terraform que dependem de estado remoto. Em vez de escrever módulos que extraem do estado remoto, escreva um módulo que aceita parâmetros. Depois, passe esses parâmetros para o módulo.
As suas bibliotecas fazem dez coisas bem ou uma — excepcionalmente?
As bibliotecas funcionam melhor quando estão focadas em uma única tarefa, que realizam com excelência. Em vez de escrever grandes módulos do Terraform que tentam fazer tudo de uma vez, divida-os em partes que fazem bem algo específico. E depois combine-as conforme necessário.
Como você faz alterações em bibliotecas sem compatibilidade retroativa?
Um módulo do Terraform, assim como uma biblioteca comum, precisa informar aos usuários sobre alterações sem compatibilidade retroativa. Quando ocorrem tais mudanças em bibliotecas, é irritante, e da mesma forma é frustrante quando mudanças de incompatibilidade ocorrem em módulos do Terraform. Recomenda-se usar git tags e semver ao usar módulos do Terraform.
O serviço de produção está rodando no seu laptop ou no data center?
A Hashicorp tem ferramentas como para executar seu terraform. Esses serviços centralizados facilitam a gestão, auditoria e aprovação de alterações no terraform.
Você não escreve testes?
Engenheiros reconhecem que o código precisa ser testado, mas frequentemente negligenciam as verificações ao trabalhar com Terraform. Para a infraestrutura, isso pode resultar em problemas traiçoeiros. Eu aconselho a "testar" ou "criar exemplos" de pilhas usando módulos que podem ser corretamente implantados para verificação durante o CI/CD.
Terraform e microsserviços
A vida e a morte das empresas de microsserviços dependem da velocidade, atualização e destruição de novas pilhas de trabalho de microsserviços.
O aspecto mais comum negativo associado às arquiteturas de microsserviços, do qual não se pode escapar, está relacionado ao trabalho e não ao código. Se você considerar o Terraform apenas como uma forma de automatizar apenas o lado da infraestrutura da arquitetura de microsserviços, você se priva das verdadeiras vantagens desse sistema. Agora já .
Fonte: habr.com
