Apresentar a infraestrutura como código em formato de texto repetitivo é uma prática recomendada simples para sistemas que você não precisa carregar. Essa prática tem um nome - Infraestrutura como código , e até agora existem duas ferramentas populares para sua implementação, especialmente na AWS: Terraform e CloudFormation .
Compare a experiência com Terraform e CloudFormation
Antes de ingressar no Twitch (também conhecido como Amazon Jr. ), trabalhei em uma startup e usei o Terraform por três anos. Em um novo local, também usei o Terraform com poder e principal e, em seguida, a empresa empurrou a transição para tudo na Amazônia, incluindo o CloudFormation. Trabalhei duro para desenvolver as melhores práticas para ambos e usei as duas ferramentas em fluxos de trabalho muito complexos em toda a organização. Mais tarde, depois de considerar cuidadosamente as consequências da mudança do Terraform para o CloudFormation, fiquei convencido de que o Terraform era provavelmente a melhor escolha para a organização.
Beta Software
O Terraform nem sequer lançou a versão 1.0, e este é um bom motivo para não usá-lo. Desde que eu o testei pela primeira vez, ele mudou muito, mas o terraform apply frequência interrompido após várias atualizações ou logo após alguns anos de operação. Eu diria que "agora tudo está diferente", mas ... então todo mundo parece dizer não? Existem alterações incompatíveis com as versões anteriores, embora sejam apropriadas, e até a sensação é de que a sintaxe e as abstrações dos armazenamentos de recursos agora são o que você precisa. A ferramenta parecia estar melhor, mas ...: -0
A AWS, por outro lado, fez um bom trabalho em manter a compatibilidade com versões anteriores. Tudo, provavelmente, porque seus serviços costumam ser bem testados dentro da organização e somente então, renomeados, publicados. Então, "se esforçou" ainda é fracamente dito. Manter a compatibilidade com versões anteriores da API para um sistema tão multivariado e complexo como o AWS é incrivelmente difícil. Qualquer pessoa que tenha suportado APIs publicamente disponíveis e usadas com a mesma amplitude deve entender o quão difícil tem sido por tantos anos. Mas o comportamento do CloudFormation em minha memória nunca mudou ao longo dos anos.
Conheça a perna ... é uma bala
Tanto quanto eu sei, não é possível remover um recurso de pilha CloudFormation de terceiros da minha pilha CF. A situação é semelhante com o Terraform. Permite importar recursos existentes para sua pilha. Pode-se dizer que a função é impressionante, mas com grande poder vem uma grande responsabilidade. É necessário apenas colocar o recurso na pilha e, enquanto você trabalha com a pilha, não é possível excluir ou alterar esse recurso. Uma vez que apareceu. De alguma forma, em um site do Twitch, alguém, sem planejar nada errado, importou acidentalmente um grupo de segurança da AWS para sua própria pilha Terraform. Digitei vários comandos e ... o grupo de segurança (junto com o tráfego recebido) desapareceu.
Recuperação parcial
Às vezes, o CloudFormation não pode fazer a transição completa de um estado para outro. Ao mesmo tempo, ele tentará retornar ao anterior. Desculpe, isso nem sempre é viável. A depuração do que aconteceu é assustadora - você nunca sabe se o CloudFormation ficará encantado por estar rachado - mesmo para reparo. Mas será que ele conseguirá ou não voltar ao estado anterior, ele realmente não sabe como determinar e, por padrão, ele fica por horas esperando um milagre.
O Terraform, pelo contrário, está inclinado a se recuperar de transições sem êxito com muito mais elegância e oferece ferramentas avançadas de depuração.
Alterações mais claras no status do documento
"Ok, balanceador de carga, você está mudando. Mas como?"
- Um engenheiro preocupado, pronto para pressionar o botão Aceitar.
Às vezes, preciso fazer algumas manipulações com o balanceador de carga na pilha do CloudFormation - por exemplo, adicionar um número de porta ou alterar um grupo de segurança. As alterações do CloudFormation são exibidas fracamente. Eu, como alfinetes e agulhas, checo duas vezes o arquivo yaml dez vezes para ter certeza de que não apaguei tudo o que preciso e não adicionei muito.
Terraform é muito mais transparente a esse respeito. Às vezes, é transparente demais (leia-se: entende). Felizmente, a versão mais recente incluiu uma exibição aprimorada de alterações - agora você pode ver claramente o que está mudando.
Flexibilidade
Escreva software do contrário.
Para ser franco, a característica distintiva mais importante do software de longa duração é sua capacidade de se adaptar às mudanças. Escreva qualquer software do contrário. Muitas vezes, percebi que recebi um serviço "simples" e comecei a colocar tudo em uma única pilha CloudFormation ou Terraform. E é claro, meses depois, foi revelado que eu entendi tudo errado, e o serviço não é realmente simples! E, portanto, preciso de alguma forma dividir uma pilha grande em componentes pequenos. Quando você trabalha com o CloudFormation, é possível fazer isso apenas recriando primeiro a pilha existente, mas eu 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 código Terraform em várias pilhas é muito mais fácil do que compartilhar código CloudFormation. Com o Terraform, você pode colocar o código em um repositório git e acessá-lo usando o controle de versão semântico. Qualquer pessoa com acesso a este repositório pode reutilizar o código compartilhado. O equivalente ao CloudFormation é o S3, mas não possui as mesmas vantagens, e não há uma única razão pela qual devemos abandonar completamente o git em favor do S3.
A organização cresceu e a capacidade de compartilhar pilhas compartilhadas atingiu um nível crítico. Com o Terraform, tudo isso é fácil e natural, enquanto o CloudFormation fará você pular pelos anéis antes de obter algo semelhante.
Operações como código
"Vamos escrever e tudo bem."
- Um engenheiro três anos antes de inventar a bicicleta Terraform.
Quando se trata de desenvolvimento de software, o Go ou um programa Java não é apenas código.
Código como código
Afinal, ainda existe a infraestrutura na qual trabalha.
Infraestrutura como código
Mas de onde ela é? Como monitorar isso? Onde seu código reside? Os desenvolvedores precisam de permissão para acessar?
Operações como código
Ser desenvolvedor de software não é apenas escrever código.
Não AWS One: você deve estar usando outros provedores. SignalFx, PagerDuty ou Github. Talvez você tenha um servidor Jenkins interno para CI / CD ou um painel de controle Grafana interno para monitoramento. O Infra as Code é escolhido por vários motivos, e qualquer um é igualmente importante para tudo relacionado ao software.
Quando eu trabalhava na Twitch, aceleramos os serviços nos sistemas embarcados mistos da Amazon e nos sistemas da AWS. Carimbamos e suportamos muitos microsserviços, aumentando os custos operacionais. As discussões foram realizadas aproximadamente na seguinte linha:
- Eu : Droga, muitos gestos para dispersar um microsserviço. Vou precisar usar esse lixo para criar uma conta da AWS (passamos a 2 contas para microsserviço ), depois essa para configurar notificações, essa para o repositório de códigos e esta para a lista de endereços de e-mail e esta .. .
- Chumbo : Vamos fazer um script e tudo bem.
- Eu : Frets, mas o script em si vai mudar. Você precisará de uma maneira de verificar se todos esses aparelhos amazon integrados estão atualizados.
- Chumbo : Parece bom. E para isso, escreveremos um script.
- Eu : Ótimo! E o script provavelmente ainda precisará definir os parâmetros. Ele os aceitará?
- Chumbo : Sim, ele irá, para onde ele irá!
- Eu : o processo pode mudar, a compatibilidade com versões anteriores será perdida. Será necessário algum controle de versão semântico.
- Chumbo : Ótima idéia!
- Eu : as ferramentas podem ser alteradas manualmente, dentro da interface do usuário. Precisamos de uma maneira de verificar e corrigir isso.
... 3 anos depois:
- Chumbo : E temos terraform.
A moral da fábula é a seguinte: mesmo se você está de cabeça para baixo em toda a Amazon , ainda usa algo que não é da AWS, e esses serviços têm um estado que o idioma usa para configuração, a fim de sincronizar esse estado.
lambda é a solução da CloudFormation para problemas de lógica personalizada. Com o lambda, você pode criar macros ou um recurso personalizado . Essa abordagem apresenta dificuldades adicionais que o Terraform não possui no controle de versão semântica dos módulos git. Para mim, o problema mais urgente era gerenciar permissões para todos esses lambda personalizados (que são dezenas de contas da AWS). Outro ponto importante foi um problema como “o que aconteceu antes - uma galinha ou um ovo?”: Estava associado ao código lambda. Essa função em si é infraestrutura e código e precisa de monitoramento e atualizações. O último destaque no caixão foi a dificuldade de atualizar semanticamente as alterações do código lambda; também era necessário garantir que as ações da pilha sem um comando direto não mudassem entre as partidas.
Lembro que, de alguma forma, eu queria criar uma implantação canária para o ambiente Elastic Beanstalk com um balanceador de carga clássico. A maneira mais fácil seria fazer uma segunda implantação do EB ao lado do ambiente de produção, dando outro passo: combinando o grupo de implantação de canários escalável automaticamente com o LB de implantação no ambiente de produção. E como o Terraform usa o beangalk ASG como saída , serão necessárias 4 linhas de código extras no Terraform. Quando perguntei se havia uma solução comparável no CloudFormation, eles me indicaram um repositório inteiro no git com um pipeline de implantação e muito mais: tudo isso em prol do que as infelizes 4 linhas do código Terraform poderiam fazer.
Ele detecta melhor a deriva
Certifique-se de que a realidade atenda às expectativas.
A detecção de deriva é uma operação muito poderosa como código, porque ajuda a garantir que a realidade atenda às expectativas. Está disponível com CloudFormation e Terraform. Mas, à medida que a pilha de trabalho crescia, a busca por desvios do CloudFormation retornava cada vez mais falsos positivos.
Com o Terraform, você tem ganchos de ciclo de vida muito mais avançados para detecção de deriva. Por exemplo, você insere o comando ignore_changes diretamente na definição de uma tarefa do ECS se desejar ignorar alterações na definição de uma tarefa específica sem ignorar as alterações em toda a implantação do ECS.
É difícil gerenciar o CloudFormation em uma escala grande de infraestrutura cruzada. Muitas dessas dificuldades são reconhecidas e a ferramenta precisa de coisas como o aws-cdk , uma estrutura para definir uma infraestrutura de nuvem no código e transmiti-la pelo AWS CloudFormation. Ele ficará curioso para ver o que o aws-cdk terá no futuro, mas será difícil para ele competir com os outros benefícios do Terraform; Para reforçar o CloudFormation, serão necessárias alterações globais.
Isso é "infraestrutura como código", não "como texto".
Minha primeira impressão do Terraform foi muito ruim. Eu acho que simplesmente não entendi a abordagem. Quase todos os engenheiros inicialmente o percebem involuntariamente como um formato de texto que deve ser convertido na infraestrutura desejada. NÃO ASSIM.
Vi quantas práticas adotadas para criar um bom código são ignoradas no Terraform. Você estudou por anos para se tornar um bom programador. Não desista dessa experiência simplesmente porque você trabalha com o Terraform. Verdades comuns do bom desenvolvimento de software também se aplicam ao Terraform.
Como o código não pode ser documentado?
Me deparei com enormes pilhas de Terraform sem nenhuma documentação. Como posso escrever código em páginas - completamente sem documentação? Adicione documentação que explique seu código Terraform (a ênfase aqui na palavra "código"), por que esta seção é tão importante e o que você faz.
Como você pode implantar serviços que antes eram uma grande função main ()?
Conheci pilhas Terraform muito complexas, apresentadas como um único módulo. Por que não implantamos software como este? Por que dividir 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?
Vi como os engenheiros, desenvolvendo um novo projeto usando o Terraform, estupidamente copiam e colam enormes pedaços de outros projetos em seus próprios projetos e os escolhem até que comece a funcionar. Então, você trabalha na sua empresa com o código de "combate"? Nós não usamos apenas bibliotecas. Sim, nem tudo deve ser uma biblioteca, mas onde estamos sem bibliotecas compartilhadas em princípio ?!
Você não usa PEP8 ou gofmt?
A maioria dos idiomas possui um esquema de formatação padrão aceito. No Python, esse é o PEP8. Em Go - gofmt. O Terraform tem o seu: terraform fmt . Use para a saúde!
Você usará o React sem saber o JavaScript?
Os módulos Terraform podem simplificar parte da infraestrutura complexa que você está criando, mas isso não significa que você pode ignorá-la. Deseja usar o Terraform corretamente sem entender os recursos? Você está condenado: o tempo passará, mas você não dominará o Terraform.
Você codifica singletones ou apresenta dependências?
A injeção de dependência é a melhor prática reconhecida para o desenvolvimento de software, preferida por singletones. Como isso é útil no Terraform? Eu conheci os módulos Terraform, dependendo de um estado remoto. Em vez de escrever módulos extraídos de um estado remoto, escreva um módulo que aceite parâmetros. E depois passe esses parâmetros para o módulo.
Suas bibliotecas fazem dez coisas bem ou uma coisa ótima?
Bibliotecas que se concentram em uma única tarefa que executa bem funcionam melhor. Em vez de escrever grandes módulos Terraform que tentam fazer tudo de uma vez, faça partes deles que fazem uma coisa bem. E depois combine-os da maneira que desejar.
Como você faz alterações nas bibliotecas sem compatibilidade com versões anteriores?
O módulo Terraform geral, como uma biblioteca comum, precisa de alguma forma informar os usuários sobre alterações sem compatibilidade com versões anteriores. Quando tais alterações ocorrem nas bibliotecas, é irritante e igualmente irritante quando são feitas alterações sem compatibilidade com versões anteriores nos módulos Terraform. Recomenda-se o uso de tags git e semver ao usar os módulos Terraform.
O serviço de produção foi lançado no seu laptop ou em um data center?
A Hashicorp possui ferramentas como a terraform cloud para iniciar sua terraform. Esses serviços centralizados facilitam o gerenciamento, a auditoria e a aprovação de alterações no terraform.
Você não escreve testes?
Os engenheiros admitem que o código precisa ser testado, mas eles próprios costumam usar verificações ao trabalhar com o Terraform. Para infraestrutura, isso é repleto de momentos insidiosos. Aconselho que você "teste" ou "crie exemplos" de pilhas usando módulos que podem ser implantados corretamente para verificação durante o IC / CD.
A vida e a morte das empresas de microsserviço dependem da velocidade, atualização e destruição de novas pilhas de trabalho de microsserviço.
O ponto negativo mais comum relacionado às arquiteturas de microsserviço e que não pode ser eliminado de forma alguma está relacionado ao trabalho, e não ao código. Se você usar o Terraform, apenas como uma maneira de automatizar apenas o lado da infraestrutura da arquitetura de microsserviços, estará se privando das verdadeiras vantagens deste sistema. Agora tudo é como código .