Nossa empresa está em processo de integração de uma equipe SRE. Entrei em toda essa história do lado do desenvolvimento. No processo, tive ideias e ideias que quero compartilhar com outros desenvolvedores. Neste artigo de reflexão falo sobre o que está acontecendo, como está acontecendo e como todos podem continuar convivendo com isso.
Continuação de uma série de artigos escritos com base em palestras em nosso evento interno :
2. Infraestrutura como código. (Você está aqui)
3. Geração de contratos Typescript utilizando modelos C#. (Em andamento...)
4. Introdução ao algoritmo de consenso Raft. (Em andamento...)
...
Decidimos criar uma equipe SRE, implementando as ideias . Eles recrutaram programadores entre seus próprios desenvolvedores e os enviaram para treinar por vários meses.
A equipe teve as seguintes tarefas de treinamento:
- Descreva nossa infraestrutura, que está principalmente no Microsoft Azure na forma de código (Terraform e tudo ao redor).
- Ensine os desenvolvedores a trabalhar com infraestrutura.
- Prepare os desenvolvedores para o trabalho.
Apresentamos o conceito de Infraestrutura como código
No modelo usual do mundo (administração clássica), o conhecimento sobre infraestrutura está localizado em dois lugares:
- Ou na forma de conhecimento nas cabeças de especialistas.
- Ou esta informação está em algumas máquinas de escrever, algumas das quais são conhecidas pelos especialistas. Mas não é fato que alguém de fora (no caso de toda a nossa equipe morrer repentinamente) será capaz de descobrir o que funciona e como funciona. Pode haver muita informação em uma máquina: acessórios, cronjobs, intimidados (veja. ) disco e apenas uma lista interminável do que pode acontecer. É difícil entender o que realmente está acontecendo.
Em ambos os casos, ficamos presos na dependência:
- ou de uma pessoa mortal, sujeita a doenças, enamoramentos, alterações de humor e simplesmente demissões banais;
- ou de uma máquina que funciona fisicamente, que também cai, é roubada e apresenta surpresas e inconvenientes.
Nem é preciso dizer que, idealmente, tudo deve ser traduzido em código legível, sustentável e bem escrito.
Assim, infraestrutura como código (Incfastructure as Code - IaC) é uma descrição de toda a infraestrutura existente na forma de código, bem como ferramentas relacionadas para trabalhar com ela e implementar infraestrutura real a partir dela.
Por que traduzir tudo em código?As pessoas não são máquinas. Eles não conseguem se lembrar de tudo. A reação de uma pessoa e de uma máquina é diferente. Qualquer coisa automatizada é potencialmente mais rápida do que qualquer coisa feita por um ser humano. O mais importante é uma única fonte de verdade.
De onde vêm os novos engenheiros de SRE?Então decidimos contratar novos engenheiros de SRE, mas onde consegui-los? Livro com respostas corretas () nos diz: dos desenvolvedores. Afinal, eles trabalham com o código e você atinge o estado ideal.
Há muito tempo procuramos muito por eles no mercado de pessoal fora da nossa empresa. Mas temos que admitir que não encontramos ninguém que atendesse aos nossos pedidos. Tive que procurar entre meu próprio povo.
Infraestrutura de problemas como código
Agora vamos ver exemplos de como a infraestrutura pode ser codificada em código. O código é bem escrito, de alta qualidade, com comentários e recuos.
Código de exemplo do Terraforma.
Código de exemplo do Ansible.
Senhores, se fosse tão simples! Estamos no mundo real e ele está sempre pronto para te surpreender, te apresentar surpresas e problemas. Também não posso ficar 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ê deveria ter: Json, Yaml, modificações de algumas grandes empresas que criaram seu próprio dsl (HCL é usado no terraform).
O problema é que pode facilmente não conter coisas familiares como:
- variáveis;
- condições;
- em algum lugar não há comentários, por exemplo, em Json, eles não são fornecidos por padrão;
- funções;
- e nem estou falando de coisas de alto nível como classes, herança e tudo mais.
2. O segundo problema com esse código é que na maioria das vezes é um ambiente heterogêneo. Normalmente você senta e trabalha com C#, ou seja, com uma linguagem, uma pilha, um ecossistema. E aqui você tem uma enorme variedade de tecnologias.
É uma situação muito real quando o bash com python inicia algum processo no qual o Json está inserido. Você analisa e outro gerador produz outros 30 arquivos. Para tudo isso, as variáveis de entrada são recebidas do Azure Key Vault, que são reunidas por um plugin para drone.io escrito em Go, e essas variáveis passam pelo yaml, que foi gerado a partir da geração do mecanismo de template jsonnet. É muito difícil ter um código estritamente bem descrito quando você tem um ambiente tão diversificado.
O desenvolvimento tradicional no âmbito de uma tarefa vem com um idioma. Aqui trabalhamos com um grande número de idiomas.
3. O terceiro problema é o ajuste. Estamos acostumados com editores legais (Ms Visual Studio, Jetbrains Rider) que fazem tudo por nós. E mesmo que sejamos estúpidos, dirão que estamos errados. Parece normal e natural.
Mas em algum lugar próximo existe o VSCode, no qual existem alguns plug-ins que são de alguma forma instalados, suportados ou não. Novas versões foram lançadas e 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 simples renomeação de uma variável é uma repetição em um projeto de uma dúzia de arquivos. Você terá sorte se ele colocar o que você precisa. Claro, há luz de fundo aqui e ali, há preenchimento automático, em algum lugar há formatação (embora não tenha funcionado para mim no terraform no Windows).
No momento em que este livro foi escrito ainda não foi lançado para suportar a versão 0.12, embora já tenha sido lançado há 3 meses.
É hora de esquecer...
- Depurando.
- Ferramenta de refatoração.
- Conclusão automática.
- Detectando erros durante a compilação.
É engraçado, mas isso 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, organizar arquivos em pastas, decompor, tornar o código sustentável, legível e assim por diante, mas em como posso escrever esse comando corretamente, porque de alguma forma o escrevi incorretamente .
Como iniciante, você está tentando aprender terraformas e o IDE não está ajudando em nada. Quando houver documentação, entre e veja. Mas se você estivesse entrando em uma nova linguagem de programação, o IDE lhe diria que existe tal tipo, mas não existe tal coisa. Pelo menos no nível int ou string. Isso geralmente é útil.
E os testes?
Você pergunta: “E os testes, senhores programadores?” Caras sérios testam tudo na produção e é difícil. Aqui está um exemplo de teste de unidade para um módulo terraform do site .
Eles têm uma boa documentação. Sempre gostei da Microsoft pela sua abordagem à documentação e formação. Mas você não precisa ser o tio Bob para entender que este não é um código perfeito. Observe a validação à direita.
O problema com um teste de unidade é que você e eu podemos verificar a exatidão da saída Json. Adicionei 5 parâmetros e recebi uma palmilha Json com 2000 linhas. Posso analisar o que está acontecendo aqui, validar o resultado do teste...
É difícil analisar Json em Go. E você precisa escrever em Go, porque o terraform em Go é uma boa prática para testar no idioma em que você escreve. A organização do código em si é muito fraca. Ao mesmo tempo, esta é a melhor biblioteca para testes.
A própria Microsoft escreve seus módulos, testando-os desta forma. Claro que é código aberto. Tudo que estou falando você pode vir consertar. Posso sentar e consertar tudo em uma semana, abrir plug-ins de código VS, terraforms, criar um plug-in para o piloto. Talvez escreva alguns analisadores, adicione linters, contribua com uma biblioteca para testes. Eu posso fazer tudo. Mas não é isso que eu deveria estar fazendo.
Melhores práticas Infraestrutura como código
Vamos continuar. Se não houver testes no IaC, o IDE e o ajuste estiverem ruins, então deve haver pelo menos práticas recomendadas. Acabei de acessar o Google Analytics e comparei duas consultas de pesquisa: práticas recomendadas do Terraform e práticas recomendadas do c#.
O que vemos? Estatísticas implacáveis não estão a nosso favor. A quantidade de material é a mesma. No desenvolvimento em C#, estamos simplesmente inundados de materiais, temos ótimas práticas, existem livros escritos por especialistas e também livros escritos em livros por outros especialistas que criticam esses livros. Um mar de documentação oficial, artigos, cursos de treinamento e agora também desenvolvimento de código aberto.
Quanto à solicitação IaC: aqui você está tentando coletar informações aos poucos dos relatórios highload ou HashiConf, da documentação oficial e de vários problemas no Github. Como distribuir esses módulos em geral, o que fazer com eles? Parece que este é um problema real... Existe uma comunidade, senhores, onde para qualquer dúvida vocês receberão 10 comentários no Github. Mas não é exatamente.
Infelizmente, neste momento, os especialistas estão apenas começando a surgir. Existem muito poucos deles até agora. E a própria comunidade está em um nível rudimentar.
Para onde tudo isso vai e o que fazer
Você pode largar tudo e voltar para C#, para o mundo do rider. Mas não. Por que você se incomodaria em fazer isso se não consegue encontrar uma solução? Abaixo apresento minhas conclusões subjetivas. Você pode discutir comigo nos comentários, será interessante.
Pessoalmente, aposto em algumas coisas:
- O desenvolvimento nesta área está acontecendo muito rapidamente. Aqui está um cronograma de solicitações de DevOps.
O assunto pode ser exagerado, mas o próprio fato de a esfera estar crescendo já dá alguma esperança.Se algo cresce tão rapidamente, certamente aparecerão pessoas inteligentes que lhe dirão o que fazer e o que não fazer. O aumento na popularidade leva ao fato de que talvez alguém tenha tempo para finalmente adicionar um plugin ao jsonnet para vscode, o que permitirá que você prossiga com a implementação da função, em vez de procurá-la via ctrl+shift+f. À medida que as coisas evoluem, mais materiais aparecem. O lançamento de um livro do Google sobre SRE é um excelente exemplo disso.
- 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, ferramentas insuficientes, mas foi acumulado um grande número de práticas que podem ser úteis e úteis.
Um exemplo trivial: colaboração através de programação em pares. Isso ajuda muito a descobrir. Quando você tem um vizinho por perto que também está tentando entender alguma coisa, juntos vocês entenderão melhor.
Compreender como a refatoração é feita ajuda a realizá-la mesmo em tal situação. Ou seja, você não pode mudar tudo de uma vez, mas mudar a nomenclatura, depois mudar a localização, aí você pode destacar alguma parte, ah, mas não tem comentários suficientes aqui.
Conclusão
Apesar de meu raciocínio parecer pessimista, olho para o futuro com esperança e espero sinceramente que tudo dê certo para nós (e para você).
A segunda parte do artigo está sendo preparada a seguir. Nele falarei sobre como tentamos utilizar práticas de desenvolvimento ágil para melhorar nosso processo de aprendizagem e trabalhar com infraestrutura.
Fonte: habr.com