Representar a infraestrutura como código em um formato de texto repetível é uma prática recomendada simples para sistemas que não exigem a manipulação de mouses. Esta prática tem um nome - , e até agora existem duas ferramentas populares para implementá-lo, especialmente na AWS: и .
Comparando experiência com Terraform e CloudFormation
Antes de vir para (Aka ) Eu trabalhei e usei o Terraform por três anos. No novo local, também usei o Terraform com todas as minhas forças, e então a empresa empurrou a transição para tudo à la Amazon, incluindo CloudFormation. Desenvolvi diligentemente as melhores práticas para ambos e usei ambas as ferramentas em fluxos de trabalho muito complexos em toda a organização. Mais tarde, depois de avaliar cuidadosamente as implicações da migração do Terraform para o CloudFormation, fiquei convencido de que o Terraform era provavelmente a melhor escolha para a organização.
Terraform Horrível
Software beta
O Terraform ainda nem lançou a versão 1.0, o que é um bom motivo para não usá-lo. Mudou muito desde que tentei pela primeira vez, mas naquela época terraform apply muitas vezes quebrava após várias atualizações ou simplesmente após alguns anos de uso. Eu diria que “tudo está diferente agora”, mas... é o que todo mundo parece dizer, não? Existem mudanças que são incompatíveis com versões anteriores, embora sejam apropriadas, e até parece que a sintaxe e as abstrações dos armazenamentos de recursos são agora o que precisamos. O instrumento parece ter realmente melhorado, mas... :-0
Por outro lado, a AWS fez um bom trabalho mantendo a compatibilidade com versões anteriores. Provavelmente, isso ocorre porque seus serviços são frequentemente testados minuciosamente dentro da organização e só então, renomeados, são publicados. Portanto, “eles tentaram muito” é um eufemismo. Manter a compatibilidade retroativa com APIs para um sistema tão variado e complexo como o AWS é incrivelmente difícil. Qualquer pessoa que tenha tido que manter APIs públicas tão amplamente utilizadas deve entender como é difícil fazer isso há tantos anos. Mas o comportamento do CloudFormation, na minha memória, nunca mudou ao longo dos anos.
Conheça a perna... é uma bala
Pelo que eu sei, exclua o recurso estranho A pilha CloudFormation da sua pilha CF não é possível. O mesmo acontece com o Terraform. Ele permite importar recursos existentes para sua pilha. Pode-se dizer que a função é incrível, mas com grande poder vem uma grande responsabilidade. Você só precisa adicionar um recurso à pilha e, enquanto estiver trabalhando com sua pilha, não poderá excluir ou alterar esse recurso. Um dia o tiro saiu pela culatra. Um dia, no Twitch, alguém importou acidentalmente o grupo de segurança AWS de outra pessoa para sua própria pilha Terraform, sem causar nenhum dano. Digitei vários comandos e... o grupo de segurança (junto com o tráfego de entrada) desapareceu.
Terraform ótimo
Recuperação de estados incompletos
Às vezes, o CloudFormation não consegue fazer a transição completa de um estado para outro. Ao mesmo tempo, ele tentará voltar ao anterior. É uma pena que isso nem sempre seja viável. Pode ser bastante assustador depurar o que aconteceu mais tarde - você nunca sabe se o CloudFormation ficará feliz por estar sendo hackeado - mesmo que seja apenas para consertar. Se será ou não possível voltar ao estado anterior, ele realmente não sabe determinar e, por padrão, fica horas esperando por um milagre.
O Terraform, por outro lado, tende a se recuperar de transições com falha com muito mais facilidade e oferece ferramentas avançadas de depuração.
Mudanças mais claras no estado do documento
“Ok, balanceador de carga, você está mudando. Mas como?"
—engenheiro ansioso, pronto para apertar o botão “aceitar”.
Às vezes preciso fazer algumas manipulações com o balanceador de carga na pilha do CloudFormation, como adicionar um número de porta ou alterar um grupo de segurança. ClouFormation exibe mal as alterações. Eu, com alfinetes e agulhas, verifico novamente o arquivo yaml dez vezes para ter certeza de que não apaguei nada necessário e não adicionei nada desnecessário.
O Terraform é muito mais transparente nesse aspecto. Às vezes ele é até transparente demais (leia-se: chato). Felizmente, a versão mais recente inclui uma exibição aprimorada de alterações para que agora você possa ver exatamente o que está mudando.
Flexibilidade
Escreva software ao contrário.
Para ser franco, a característica mais importante do software de longa duração é a capacidade de se adaptar às mudanças. Escreva qualquer software ao contrário. Na maioria das vezes, cometi erros ao escolher um serviço “simples” e, em seguida, começar a amontoar tudo em uma única pilha CloudFormation ou Terraform. E claro, meses depois foi revelado que eu tinha entendido tudo errado, e o atendimento na verdade não era simples! E agora preciso dividir de alguma forma uma pilha grande em pequenos componentes. Quando você trabalha com CloudFormation, isso só pode ser feito recriando primeiro a pilha existente, mas não faço isso com meus bancos de dados. O Terraform, por outro lado, tornou possível dissecar a pilha e dividi-la em partes menores mais compreensíveis.
Módulos no git
Compartilhar o código do Terraform em várias pilhas é muito mais fácil do que compartilhar o código do CloudFormation. Com o Terraform, você pode colocar seu código em um repositório git e acessá-lo usando controle de versão semântico. Qualquer pessoa com acesso a este repositório pode reutilizar o código compartilhado. O equivalente do CloudFormation é o S3, mas não tem os mesmos benefícios 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 atingiu um nível crítico. O Terraform torna tudo isso fácil e natural, enquanto o CloudFormation fará você pular obstáculos antes de fazer algo assim funcionar.
Operações como código
“Vamos fazer o roteiro e tudo bem.”
—um engenheiro 3 anos antes de inventar a bicicleta Terraform.
Quando se trata de desenvolvimento de software, Go ou um programa Java não é apenas código.
Código como código
Há também a infraestrutura em que funciona.
Infraestrutura como código
Mas de onde ela é? Como monitorar isso? Onde está seu código? Os desenvolvedores precisam de permissão de acesso?
Operações como código
Ser desenvolvedor de software não significa apenas escrever código.
AWS não é o único: você provavelmente usa outros provedores. SignalFx, PagerDuty ou Github. Talvez você tenha um servidor Jenkins interno para CI/CD ou um painel Grafana interno para monitoramento. Infra as Code é escolhido por diferentes motivos, e cada um é igualmente importante para tudo relacionado a software.
Quando trabalhei na Twitch, aceleramos serviços dentro dos sistemas mistos incorporados e AWS da Amazon. Produzimos e oferecemos suporte a muitos microsserviços, aumentando os custos operacionais. As discussões foram mais ou menos assim:
- Я: Droga, são muitos gestos para fazer overclock em um microsserviço. Terei que usar esse lixo para criar uma conta AWS (fomos para 2 contas em microsserviço), então este para configurar alertas, este para um repositório de código, e este para uma lista de e-mail, e então este...
- Pista: Vamos fazer o script e tudo bem.
- Я: Ok, mas o script em si mudará. Precisaremos de uma maneira de verificar se todos esses dispositivos integrados da Amazon estão atualizados.
- Pista: Parece bom. E escreveremos um script para isso.
- Я: Ótimo! E o script provavelmente ainda precisará definir parâmetros. Ele os aceitará?
- Pista: Deixe ele levar para onde for!
- Я: O processo pode mudar e a compatibilidade com versões anteriores será perdida. Será necessário algum tipo de controle de versão semântico.
- Pista: Boa ideia!
- Я: As ferramentas podem ser alteradas manualmente, dentro da interface do usuário. Precisaremos de uma maneira de verificar e corrigir isso.
…3 anos depois:
- Pista: E temos terraforma.
A moral da história é: mesmo que você de ponta-cabeça em tudo Amazon, você ainda está usando algo que não é da AWS e esses serviços têm um estado que usa uma linguagem de configuração para manter esse estado sincronizado.
CloudFormation lambda vs módulos git terraform
lambda é a solução do CloudFormation para o problema de lógica personalizada. Com lambda você pode ou . Essa abordagem introduz complexidades adicionais que não estão presentes no versionamento semântico dos módulos git do Terraform. Para mim, o problema mais urgente era gerenciar permissões para todos esses lambdas de usuários (e são dezenas de contas da AWS). Outro problema importante foi o problema “o que veio primeiro, o ovo ou a galinha?”: estava relacionado ao código lambda. Essa função em si é infraestrutura e código e precisa de monitoramento e atualizações. O último prego no caixão foi a dificuldade de atualizar semanticamente as alterações no código lambda; também tivemos que garantir que as ações da pilha sem um comando direto não mudassem entre as execuções.
Lembro-me de uma vez que quis criar uma implantação canário para o ambiente Elastic Beanstalk com um balanceador de carga clássico. A coisa mais fácil a fazer seria fazer uma segunda implantação para o EB próximo ao ambiente de produção, dando um passo adiante: combinando o grupo de implantação canário de escalonamento automático com o LB de implantação no ambiente de produção. E como o Terraform usa , isso exigirá 4 linhas extras de código no Terraform. Quando perguntei se havia uma solução comparável no CloudFormation, eles me indicaram um repositório git completo com um pipeline de implantação e tudo mais, tudo por causa de algo que 4 linhas de código Terraform pobres poderiam fazer.
Ele detecta melhor a deriva
Certifique-se de que a realidade corresponda às expectativas.
é um recurso de operações como código muito poderoso porque ajuda a garantir que a realidade corresponda às expectativas. Está disponível com CloudFormation e Terraform. Mas à medida que a pilha de produção crescia, a busca por desvios no CloudFormation produzia cada vez mais detecções falsas.
Com o Terraform você tem ganchos de ciclo de vida muito mais avançados para detecção de desvios. Por exemplo, você insere o comando diretamente na definição de tarefa do ECS se desejar ignorar alterações em uma definição de tarefa específica sem ignorar alterações em toda a implantação do ECS.
CDK e o futuro do CloudFormation
O CloudFormation é difícil de gerenciar em grandes escalas de infraestrutura cruzada. Muitas dessas dificuldades são reconhecidas e a ferramenta precisa de coisas como , uma estrutura para definir infraestrutura de nuvem em código e executá-la por meio do AWS CloudFormation. Será interessante ver o que o futuro reserva para o aws-cdk, mas será difícil competir com os outros pontos fortes do Terraform; para atualizar o CloudFormation, serão necessárias mudanças globais.
Para que o Terraform não decepcione
Isto é “infraestrutura como código” e não “como texto”.
Minha primeira impressão do Terraform foi bastante ruim. Acho que simplesmente não entendi a abordagem. Quase todos os engenheiros involuntariamente o percebem como um formato de texto que precisa ser convertido na infraestrutura desejada. NÃO FAÇA ASSIM.
Os truísmos do bom desenvolvimento de software também se aplicam ao Terraform.
Já vi muitas práticas adotadas para criar um bom código sendo ignoradas no Terraform. Você estudou durante anos para se tornar um bom programador. Não desista dessa experiência só porque está trabalhando com Terraform. Os truísmos do bom desenvolvimento de software se aplicam ao Terraform.
Como o código pode não ser documentado?
Já vi enormes pilhas do Terraform sem absolutamente nenhuma documentação. Como você pode escrever código em páginas - sem absolutamente nenhuma documentação? Adicione documentação que explique seu código Terraform (ênfase na palavra “código”), por que esta seção é tão importante e o que você faz.
Como podemos implantar serviços que antes eram uma grande função main()?
Já vi pilhas Terraform muito complexas apresentadas como um único módulo. Por que não implantamos software dessa maneira? Por que dividimos funções grandes em funções menores? As mesmas respostas se aplicam ao Terraform. Se o seu módulo for muito grande, você precisará dividi-lo em módulos menores.
Sua empresa não usa bibliotecas?
Eu vi como os engenheiros, criando um novo projeto usando o Terraform, estupidamente copiaram grandes pedaços de outros projetos em seus próprios e depois mexeram neles até que começasse a funcionar. Você trabalharia assim com código de “combate” na sua empresa? Não usamos apenas bibliotecas. Sim, mas onde estamos sem bibliotecas compartilhadas em princípio?!
Você não está usando PEP8 ou gofmt?
A maioria dos idiomas possui um esquema de formatação padrão aceito. Em Python, isso é PEP8. Em Go - gofmt. Terraform tem seu próprio: terraform fmt. Aproveite para sua saúde!
Você usará React sem conhecer JavaScript?
Os módulos Terraform podem simplificar alguma parte da infraestrutura complexa que você cria, mas isso não significa que você não possa mexer nela. Quer usar o Terraform corretamente sem entender os recursos? Você está condenado: o tempo passará e você nunca dominará o Terraform.
Você está codificando com singletons ou injeção de dependência?
A injeção de dependência é uma prática recomendada reconhecida para desenvolvimento de software e é preferida aos singletons. Como isso é útil no Terraform? Já vi módulos Terraform que dependem do estado remoto. Em vez de escrever módulos que recuperam o estado remoto, escreva um módulo que receba parâmetros. E então passe esses parâmetros para o módulo.
Suas bibliotecas fazem dez coisas bem ou uma coisa ótima?
As bibliotecas que funcionam melhor são aquelas que se concentram em uma tarefa que realizam muito bem. Em vez de escrever grandes módulos Terraform que tentam fazer tudo de uma vez, construa partes deles que façam bem uma coisa. E então combine-os conforme necessário.
Como você faz alterações em bibliotecas sem compatibilidade com versões anteriores?
Um módulo Terraform comum, como uma biblioteca normal, precisa comunicar de alguma forma as alterações aos usuários sem ser compatível com versões anteriores. É irritante quando essas alterações acontecem nas bibliotecas e é igualmente irritante quando alterações não compatíveis com versões anteriores são feitas nos módulos do Terraform. É recomendado usar tags git e semver ao usar módulos Terraform.
Seu serviço de produção está sendo executado em seu laptop ou em um data center?
A Hashicorp possui ferramentas como para executar seu terraform. Esses serviços centralizados facilitam o gerenciamento, a auditoria e a aprovação de alterações no terreno.
Você não escreve testes?
Os engenheiros reconhecem que o código precisa ser testado, mas eles próprios muitas vezes se esquecem dos testes ao trabalhar com o Terraform. Para a infra-estrutura, isto está repleto de momentos traiçoeiros. Meu conselho é “testar” ou “criar exemplos” de pilhas usando módulos que possam ser implantados corretamente para testes durante CI/CD.
Terraform e microsserviços
A vida ou a morte das empresas de microsserviços depende da velocidade, da inovação e da disrupção das novas pilhas de trabalho de microsserviços.
O aspecto negativo mais comum associado às arquiteturas de microsserviços, e que não pode ser eliminado, está relacionado ao trabalho, não ao código. Se você pensa no Terraform apenas como uma forma de automatizar apenas o lado da infraestrutura de uma arquitetura de microsserviços, então você está perdendo os verdadeiros benefícios do sistema. Agora já está .
Fonte: habr.com