5 lições que aprendemos escrevendo mais de 300.000 linhas de código de infraestrutura

Uma breve aula sobre desenvolvimento de código de infraestrutura

Em outubro deste ano, fiz uma apresentação na conferência HashiConf 2018, onde conversamos sobre as 5 principais lições que eu e meus colegas da Gruntwork aprendemos no processo de criação e manutenção de uma biblioteca de mais de 300.000 linhas de código de infraestrutura usadas por centenas de empresas em sistemas de produção. Nesta publicação, compartilharei vídeos e slides da apresentação, bem como uma versão resumida da descrição das 5 lições principais.

Vídeos e slides

Introdução: DevOps Agora na Idade da Pedra

Apesar do setor estar cheio de palavras progressistas da moda: Kubernetes, microsserviços, redes de serviço, infraestrutura imutável, big data, data lake, etc., a realidade é que, quando você está imerso na criação da infraestrutura, não sente tão elegante e progressivo.

Pessoalmente, o DevOps me lembra mais disso:

Criar uma infraestrutura no nível da produção é difícil. Isso é estresse real. E come muito tempo. Muito tempo.

Mostra quanto tempo levará para implementar o próximo projeto de infraestrutura. Contamos com dados empíricos que coletamos no decorrer do trabalho com centenas de empresas diferentes:

Lição 1. Lista de verificação para infraestrutura de manufatura

Os projetos do DevOps sempre demoram mais do que o esperado. Sempre. Porque
A primeira razão é um corte de cabelo de iaque . Abaixo está uma ilustração vívida desse fenômeno (este é um trecho da série "Malcolm in the Spotlight")

A segunda razão é que o processo de criação de uma infraestrutura em nível de produção (por exemplo, a infraestrutura na qual você colocaria sua empresa) consiste em milhares de pequenas peças. A grande maioria dos desenvolvedores não tem conhecimento desses detalhes; portanto, ao avaliar um projeto, geralmente você esquece muitas tarefas críticas (e demoradas).
Para evitar isso, sempre que começar a trabalhar em uma nova seção da infraestrutura, use a seguinte lista de verificação:

Nem todos os elementos da lista serão necessários para cada parte individual da infraestrutura, mas você deve documentar consciente e explicitamente quais elementos implementou e quais decidiu ignorar e por quê.

Lição 2. Caixa de Ferramentas

Listamos as principais ferramentas que usamos na Gruntwork para criar e gerenciar infraestrutura (a partir de 2018):

• Terraform . Usamos o Terraform para implantar toda a infraestrutura subjacente, incluindo a rede, subsistemas de balanceamento de carga, bancos de dados, ferramentas de gerenciamento de usuários e permissões e todos os nossos servidores.
• Packer . Usamos o Packer para configurar e criar imagens de máquinas virtuais executadas em nossos servidores.
• Docker . Alguns de nossos servidores formam clusters nos quais executamos aplicativos como contêineres do Docker. Para clusters do Docker, usamos principalmente as seguintes ferramentas: Kubernetes , ECS e Fargate .

Todas essas ferramentas são úteis, mas esse não é o ponto. Você precisa entender que algumas ferramentas não são suficientes. Você também deve mudar o comportamento da equipe.

Em particular, mesmo as melhores ferramentas do mundo não ajudarão sua equipe se elas não quiserem usá-las ou se não tiverem tempo suficiente para aprender a usá-las. Portanto, a principal conclusão é que o uso da "infraestrutura como código" é um investimento, ou seja, certos custos iniciais serão exigidos de você. Se você investir com sabedoria, receberá grandes dividendos a longo prazo.

Lição 3. Grandes módulos são ruins

Os recém-chegados à aplicação da “infraestrutura como código” geralmente definem toda a infraestrutura para todos os seus ambientes (ambiente de desenvolvimento, ambiente intermediário, ambiente de produção etc.) em um único arquivo ou em um conjunto de arquivos implantados como um todo. Em vão.

Aqui estão apenas algumas das desvantagens dessa abordagem:

• Baixa velocidade Se toda a infraestrutura estiver definida em um único local, a execução de qualquer comando levará muito tempo. Enfrentamos situações nas empresas quando a equipe do terraform plan levou de 5 a 6 minutos para ser concluída!
• Baixa segurança . Se você gerencia toda a infraestrutura juntos, para alterar algo, você precisa de permissões para acessar tudo. Ou seja, quase todo usuário deve ser um administrador, e isso também é muito inconveniente.
• Riscos elevados . Se você colocar todos os seus ovos em uma cesta, crie uma situação em que um erro local possa atrapalhar a operação de toda a infraestrutura. Por exemplo, quando você faz pequenas alterações em um aplicativo externo no ambiente de desenvolvimento, um único erro de digitação ou um comando incorreto pode levar à exclusão do banco de dados de produção.
• Difícil de entender . Quanto mais código é colocado em um só lugar, mais difícil é para uma pessoa entender tudo isso. E quando tudo isso estiver conectado, partes incompreensíveis farão uma piada cruel com você.
• Difícil de testar . Testar o código da infraestrutura é difícil; testar grandes quantidades de código de infraestrutura é quase impossível. Voltaremos a isso mais tarde.
• Difícil de analisar . A saída de comandos como o plano de terraform se torna inútil, pois ninguém se incomoda em visualizar milhares de linhas. Além disso, a análise de código se torna inútil.

Em resumo, você deve criar seu código a partir de módulos compostos pequenos, independentes e reutilizáveis. Isso não é novidade nem descoberta. Você já ouviu isso milhares de vezes, embora em situações ligeiramente diferentes:

“Faça uma coisa e faça bem” - filosofia Unix.
“A primeira regra das funções é que elas devem ser pequenas. A segunda regra afirma que as funções devem ser ainda menores ". - "Código limpo"

Lição 4. O código da infraestrutura sem testes automáticos está com defeito

Se o seu código de infraestrutura não tiver testes automatizados, ele não funcionará corretamente. Você apenas não sabe ainda. Mas testar o código de infraestrutura é difícil. Você não possui um "host local" (por exemplo, não pode implantar a nuvem privada virtual da AWS VPC em seu laptop), nem "testes de unidade" reais (por exemplo, não é possível isolar o código Terraform do mundo "externo", pois é como vezes e foi projetado para se comunicar com o mundo exterior).

Portanto, para testar corretamente o código de infraestrutura, você geralmente precisa implantá-lo em um ambiente real, executar uma infraestrutura real, verificar se o código está funcionando e quebrá-lo (para obter uma descrição desse estilo de teste: consulte Terratest, esta é uma biblioteca de código aberto que inclui ferramentas para testar o código Terraform , Packer e Docker, trabalhando com APIs da AWS, GCP e Kubernetes, executando comandos de shell localmente e em servidores remotos via SSH, além de muitos outros recursos). Portanto, ao testar a infraestrutura, você precisa redefinir ligeiramente as condições:

Os testes de unidade implantam e testam um ou mais módulos de infraestrutura intimamente relacionados do mesmo tipo (por exemplo, módulos para um único banco de dados).

Os testes de integração implantam e testam vários módulos de infraestrutura de vários tipos para verificar se eles funcionam juntos (por exemplo, módulos de banco de dados e módulos de serviço da web).

Os testes de ponta a ponta (e2e) implantam e testam toda a arquitetura.
Observe que o diagrama é uma pirâmide: temos muitos testes de unidade, menos testes de integração e muito poucos testes e2e. Porque Depende da duração de cada tipo de teste:

Os testes de infraestrutura levam muito tempo, especialmente nos níveis superiores da pirâmide, e, é claro, você deseja encontrar e corrigir o máximo de erros possível na parte inferior. Para fazer isso, você precisa:

1. Crie módulos autônomos pequenos e simples (consulte Lição 3) e escreva vários testes de unidade para eles - verifique se eles funcionam corretamente.
2. Combine esses blocos pequenos, simples e comprovados para criar uma infraestrutura mais sofisticada que você teste com menos integração e testes E2E.

Lição 5. Processo de Liberação

Para resumir todas as opções acima. Veja como agora você criará e gerenciará sua infraestrutura:

• Verifique a lista de verificação para obter a infraestrutura de nível de produção e verifique se está trabalhando na direção certa.
• Defina sua “infraestrutura como código” com ferramentas como Terraform, Packer e Docker. Verifique se sua equipe tem tempo suficiente para aprender essas ferramentas (consulte Recursos do DevOps ).
• Crie código a partir de módulos compostos pequenos e independentes (ou use módulos padrão da infraestrutura como biblioteca de códigos ).
• Prepare testes automatizados para seus módulos com o Terratest .
• Conclua a solicitação para incluir suas alterações para revisar seu código.
• Libere a nova versão do código.
• Copie a nova versão do código de um ambiente para outro.