Infraestrutura como código: primeiro conhecido

Nossa empresa está no processo de integração da equipe SRE. Eu entrei nessa história inteira do lado do desenvolvimento. No processo, tive pensamentos e idéias que quero compartilhar com outros desenvolvedores. Neste artigo de meditação, falo sobre o que acontece, como acontece e como todos os outros podem viver com isso.

Continuação de uma série de artigos baseados em discursos em nosso evento interno do DevForum :

1. Gato de Schrodinger sem caixa: o problema do consenso em sistemas distribuídos.
2. Infraestrutura como código. (Você está aqui)
3. Geração de contratos datilografados para modelos c #. (Em andamento ...)
4. Como os servidores concordam: O algoritmo de consenso distribuído Raft.
5. Infraestrutura como código: como superar problemas com o XP.
...

Decidimos fazer a equipe do SRE implementar as idéias do Google Sre . Recrutamos programadores de seus próprios desenvolvedores e os enviamos para estudar por vários meses.

A equipe enfrentou as seguintes tarefas de treinamento:

• Descreva nossa infraestrutura, que está principalmente no Microsoft Azure na forma de código (Terraform e tudo o que existe).
• Ensine os desenvolvedores a trabalhar com infraestrutura.
• Prepare os desenvolvedores para o serviço.

Introduzindo o conceito de infraestrutura como código

No modelo usual do mundo (administração clássica), o conhecimento sobre infraestrutura está em dois lugares:

1. Ou na forma de conhecimento nas mentes dos especialistas.
2. Ou esta informação está em algumas máquinas de escrever, algumas das quais os especialistas sabem. Mas não é fato que uma pessoa de fora (caso toda a nossa equipe morra de repente) seja capaz de descobrir o que funciona e como. Pode haver muitas informações sobre a máquina: acessadores, plugues de coroa, uma unidade (consulte montagem em disco ) e apenas uma lista interminável do que pode acontecer. É difícil entender o que está acontecendo na realidade.

Nos dois casos, estamos presos, ficando dependentes:

• ou de uma pessoa mortal, propensa a doenças, apaixonar-se, mudanças de humor e simplesmente despedimentos banais;
• ou de uma máquina que funcione fisicamente que também cai, rouba, apresenta inesperados e inconvenientes.

Escusado será dizer que, idealmente, tudo deve ser traduzido em código escrito legível, suportado e de alta qualidade.

Assim, a infraestrutura como código (Incfastructure as Code - IaC) é uma descrição de toda a infraestrutura disponível na forma de código, bem como ferramentas relacionadas para trabalhar com ela e realizar a infraestrutura real a partir dela.

Infraestrutura como problemas de código

Agora vamos ver exemplos de como a infraestrutura pode ser conectada ao código. O código está bem escrito, de alta qualidade, com comentários e recuos.

Código de exemplo da Terraforma.



Código de exemplo do Ansible.



Senhores, mas se tudo fosse tão simples! Estamos com você no mundo real, e ele está sempre pronto para surpreendê-lo, apresentar surpresas, problemas. Não sem eles aqui.

1. O primeiro problema é que, na maioria dos casos, o IaC é algum tipo de dsl.

E o DSL, por sua vez, é uma descrição da estrutura. Mais precisamente, o que você deve ter: Json, Yaml, modificações de algumas grandes empresas que criaram seu próprio dsl (o HCL é usado no terraform).

O problema é que nele pode facilmente não haver coisas familiares para nós, como:

• Variáveis
• condições;
• em algum lugar não há comentários, por exemplo, no Json, por padrão, eles não são fornecidos;
• funções
• e não estou falando de coisas de alto nível, como classes, herança e tudo mais.

2. O segundo problema com esse código é geralmente um ambiente heterogêneo . Normalmente, você senta e trabalha com C #, ou seja, com um idioma, uma pilha, um ecossistema. E aqui você tem uma enorme variedade de tecnologias.

É uma situação muito real quando um bash com python inicia algum processo no qual Json está escorregando. Você o analisa e outro gerador gera outros 30 arquivos. Por tudo isso, entram as variáveis ​​de entrada do Azure Key Vault, que são reunidas pelo plug-in para drone.io escrito em Go, e essas variáveis ​​passam pelo yaml, obtido como resultado da geração do mecanismo de modelo jsonnet. É muito difícil ter um código estritamente bem descrito quando você tem um ambiente tão diverso.

O desenvolvimento tradicional dentro da estrutura de uma tarefa vem com um idioma. Aqui trabalhamos com um grande número de idiomas.

3. O terceiro problema é o tingimento . Estamos acostumados a esfriar editores (Ms Visual Studio, Jetbrains Rider) que fazem tudo por nós. E mesmo se formos chatos, eles dirão que estamos errados. Parece ser normal e natural.

Mas em algum lugar próximo há o VSCode, no qual existem alguns plugins que são de alguma forma instalados, suportados ou não. Novas versões foram lançadas e elas não eram suportadas. Uma transição banal para a implementação de uma função (mesmo que exista) torna-se um problema complexo e não trivial. Uma renomeação simples de uma variável é uma repetição em um projeto de uma dúzia de arquivos. É uma sorte se é algo que precisa ser corrigido. É claro que há luz de fundo em alguns lugares, há compilação automática, em algum lugar há formatação (embora eu não tenha iniciado o Windows em terraform).

No momento da redação deste artigo, o plug-in vscode-terraform ainda não havia sido lançado para oferecer suporte à versão 0.12, embora já tenha sido lançado por 3 meses.

É hora de esquecer ...

1. Depuração
2. Ferramenta de refatoração.
3. Conclusão automática.
4. Detectar erros de compilação.

É engraçado, mas também aumenta o tempo de desenvolvimento e aumenta o número de erros que inevitavelmente ocorrem.

O pior é que somos forçados a pensar não em como projetar, decompor arquivos em pastas, decompor, tornar o código suportado, legível etc., mas em como escrever esse comando corretamente, porque de alguma forma o escrevi incorretamente .

Como iniciante, você está tentando aprender terraforms, e o IDE não ajuda em nada disso. Quando há documentação - eles entraram, olharam. Mas se você inserir uma nova linguagem de programação, o IDE sugerirá que existe esse tipo, mas não existe. Pelo menos no nível int ou string. Isso geralmente é útil.

Mas e os testes?

Você pergunta: “E os testes, senhores programadores?” Caras sérios estão testando tudo no produto, e é difícil. Aqui está um exemplo do teste de unidade para o módulo terraform no site da Microsoft .



Eles têm boa documentação. Eu sempre gostei da Microsoft por sua abordagem de documentação e treinamento. Mas você não precisa ser tio Bob para entender que esse não é um código ideal. Observe a validação renderizada à direita.

O problema com o teste de unidade é que você e eu podemos verificar a correção da saída de Json. Joguei 5 parâmetros, recebi um calçado Json para 2000 linhas. Posso analisar o que acontece aqui, validar o resultado do teste ...

É difícil analisar Json no Go. E você precisa escrever no Go, porque os terraforms no Go são uma boa prática do que você testa no idioma em que escreve. A própria organização do código é muito fraca. Ao mesmo tempo, é a melhor biblioteca para testes.

A própria Microsoft grava seus módulos, testando-os dessa maneira. Claro, isso é Open Source. Tudo o que eu falo sobre você pode vir e reparar. Posso sentar e consertar tudo em uma semana, abrir plug-ins de código VS, terraforms, criar um plug-in de piloto. Talvez escreva alguns analisadores, roscas, copie a biblioteca para teste. Eu posso fazer tudo. Mas eu não tenho que fazer isso.

Infraestrutura de práticas recomendadas como código

Nós estamos indo além. Se não houver testes no IaC, ruins no IDE e no ajuste, deve haver pelo menos as melhores práticas. Acabei de acessar o google analytics e comparei duas consultas de pesquisa: práticas recomendadas do Terraform e práticas recomendadas de c #.



O que nós vemos? Estatísticas implacáveis ​​não estão a nosso favor. Pela quantidade de material - a mesma coisa. No desenvolvimento de C #, apenas tomamos banho em materiais, temos práticas recomendadas, existem livros escritos por especialistas e também livros escritos em livros por outros especialistas que criticam esses livros. O mar de documentação oficial, artigos, cursos de treinamento, agora também desenvolvimento de código aberto.

Quanto à solicitação de IaC: aqui você está tentando aos poucos coletar as informações dos relatórios do highload ou do HashiConf, da documentação oficial e das inúmeras edições no github. Como você espalha esses módulos, o que fazer com eles? Parece que este é um problema real ... Há uma comunidade, senhores, em que você receberá 10 comentários em um github para qualquer pergunta. Mas isso não é exato.

Infelizmente, neste momento, os especialistas estão apenas começando a aparecer. Embora existam muito poucos deles. E a própria comunidade paira no nível dos primórdios.

Para onde tudo vai e o que fazer

Você pode largar tudo e voltar ao C #, para o mundo de um piloto. Mas não. Por que você faria isso se não encontrou uma solução? Em seguida, dou minhas conclusões subjetivas. Você pode discutir comigo nos comentários, será interessante.

Pessoalmente, eu coloquei algumas coisas:

1. O desenvolvimento nesta área é muito rápido. Dou o cronograma de solicitações para DevOps.
   
   
   
   Talvez o assunto seja exagero, mas o fato de a esfera estar crescendo nos dá alguma esperança.
   
   Se algo cresce tão rápido, certamente pessoas inteligentes aparecerão quem dirá como fazê-lo e como não fazê-lo. O aumento da popularidade leva ao fato de que talvez alguém tenha tempo para finalmente adicionar o plugin jsonnet para vscode, o que nos permitirá prosseguir com a implementação da função, em vez de procurá-lo através de ctrl + shift + f. Quando tudo se desenvolve, mais materiais aparecem. O mesmo livro do Google sobre SRE é um ótimo exemplo.
2. Existem técnicas e práticas desenvolvidas no desenvolvimento convencional que podemos aplicar com sucesso aqui. Sim, existem nuances com testes e um ambiente heterogêneo, ajuste insuficiente, mas um grande número de práticas foram acumuladas que podem ser úteis e ajudar.
   
   Um exemplo trivial: colaboração por meio de programação em pares. Ajuda muito para descobrir isso. Quando você tem um vizinho próximo que também está tentando entender alguma coisa, juntos você entenderá melhor.
   
   Compreender como a refatoração é feita ajuda a produzi-la mesmo em tal situação. Ou seja, você pode alterar não tudo de uma só vez, mas alterar o nome, alterar o local e destacar alguma parte, ah, mas não há comentários suficientes.

Conclusão

Apesar de meu raciocínio parecer pessimista, estou ansioso pelo futuro e espero sinceramente que nós (e você) tenha sucesso.

Em seguida, vem a segunda parte do artigo . Nele, falo sobre como usamos práticas extremas de programação para melhorar nosso processo de aprendizado e trabalhar com a infraestrutura.