Na nossa empresa, estamos em processo de integração da equipe SRE. Eu entrei nessa história do ponto de vista do desenvolvimento. Durante o processo, surgiram pensamentos e insights que gostaria de compartilhar com outros desenvolvedores. Neste artigo de reflexão, falo sobre o que está acontecendo, como está acontecendo e como todos podem lidar com isso no futuro.
Continuação da série de artigos inspirados em palestras do nosso evento interno :
2. Infraestrutura como código. (Você está aqui)
3. Geração de contratos Typescript a partir de modelos C#. (Em andamento…)
4. Introdução ao algoritmo de consenso Raft. (Em andamento…)
…
Decidimos formar uma equipe SRE, incorporando as ideias do . Reunimos programadores de nossos próprios desenvolvedores e os enviamos para treinamento por alguns meses.
A equipe tinha as seguintes tarefas de aprendizado:
- Descrever nossa infraestrutura, que é em grande parte na Microsoft Azure, em forma de código (Terraform e tudo relacionado).
- Ensinar os desenvolvedores a trabalhar com infraestrutura.
- Preparar os desenvolvedores para os plantões.
Introduzimos o conceito de Infraestrutura como código
No modelo tradicional (administração clássica), o conhecimento sobre a infraestrutura está em dois lugares:
- Ou na forma de conhecimento na mente dos especialistas.
- Ou essas informações estão em algumas máquinas, parte das quais os especialistas conhecem. Mas não é certo que uma pessoa de fora (caso toda a nossa equipe morra de repente) consiga entender o que e como funciona. Uma máquina pode conter muitas informações: acessos, cron jobs, discos montados (veja ) e uma lista interminável do que pode estar acontecendo. É difícil entender o que de fato está ocorrendo.
Em ambos os casos, caímos em uma armadilha, tornando-nos dependentes:
- ou de uma pessoa que é mortal, sujeita a doenças, paixões, mudanças de humor e simplesmente demissões;
- ou de uma máquina física que também pode falhar, ser roubada, surpreender e causar inconvenientes.
É evidente que a solução ideal é que tudo deva ser convertido em código legível por humanos, mantido e bem escrito.
Assim, a infraestrutura como código (Infrastructure as Code – IaC) é a descrição de toda a infraestrutura existente na forma de código, bem como as ferramentas associadas para trabalhar com ela e implementar a infraestrutura real a partir do mesmo.
Por que traduzir tudo para códigoAs pessoas não são máquinas. Elas não conseguem lembrar de tudo. A reação de um ser humano e de uma máquina é diferente. Tudo que é automatizado potencialmente funciona mais rápido do que tudo que um ser humano faz. O mais importante é ter uma única fonte de verdade (single source of truth).
De onde vêm os novos engenheiros de SREEntão, decidimos contratar novos engenheiros de SRE, mas de onde vamos tirá-los? O livro com as respostas corretas () nos diz: dos desenvolvedores. Afinal, eles trabalham com código e você alcança um estado ideal.
Procuramos muito e por longo tempo no mercado de trabalho fora da nossa empresa. Mas temos que admitir que não encontramos nenhum que atendesse às nossas exigências. Tivemos que revistar entre os nossos.
Problemas da Infrastructure as Code
Agora vamos olhar exemplos de como a infraestrutura pode estar embutida no código. O código é bem escrito, de qualidade, com comentários e recuos.
Exemplo de código do Terraform.
Exemplo de código do Ansible.
Senhores, mas se tudo fosse tão simples! Estamos no mundo real, e ele sempre está pronto para surpreendê-lo, apresentando surpresas e problemas. Não falta isso aqui também.
1. O primeiro problema é que, na maioria dos casos, IaC é algum tipo de DSL.
E DSL, por sua vez, é uma descrição de estrutura. Mais precisamente, o que você deve ter: Json, Yaml, modificações de algumas grandes empresas que criaram seu próprio DSL (o Terraform usa HCL).
O problema é que pode não haver coisas tão familiares para nós como:
- variáveis;
- condições;
- em algum lugar pode não haver comentários, por exemplo, no Json, que por padrão não os permite;
- funções;
- e ainda nem estou falando de coisas de alto nível, como classes, herança e tudo mais.
2. O segundo problema desse código é que, na maioria das vezes, é um ambiente heterogêneo.Normalmente você se senta e trabalha com C#, ou seja, com uma única linguagem, uma única pilha, um único ecossistema. Mas aqui você tem uma enorme variedade de tecnologias.
É uma situação bem real em que um Bash com Python executa um processo que recebe um JSON. Você o analisa, e depois, algum gerador gera mais 30 arquivos. Todas essas variáveis de entrada vêm do Azure Key Vault, puxadas por um plugin para o drone.io, escrito em Go, e essas variáveis passam por um YAML gerado a partir do template jsonnet. É bastante difícil ter um código rigorosamente bem descrito quando você tem um ambiente tão diverso.
Desenvolvimento tradicional em uma tarefa única é feito com uma única linguagem. Aqui, por outro lado, trabalhamos com um grande número de linguagens.
3. O terceiro problema é a ferramenta.Estamos acostumados a editores incríveis (Ms Visual Studio, Jetbrains Rider) que fazem tudo por nós. E mesmo que cometamos um erro, eles nos avisam que estamos errados. Parece normal e natural.
Mas há por perto o VSCode, que tem alguns plugins que são instalados, mantidos ou não mantidos. Novas versões foram lançadas, mas não foram suportadas. A simples transição para a implementação de uma função (mesmo que já exista) se torna um problema complexo e não trivial. Apenas renomear uma variável é um substituto no projeto que consiste em dezenas de arquivos. Você terá sorte se ele substituir corretamente o que é necessário. Há, claro, algumas opções de destaque de sintaxe, autocompletar e formatação (embora eu não tenha conseguido fazer funcionar no Terraform no Windows).
No momento da escrita deste artigo ainda não foi lançado para suportar a versão 0.12, embora ela tenha sido liberada há 3 meses.
É hora de esquecer sobre…
- Depuração.
- Ferramenta de refatoração.
- Autocompletar.
- Detecção de erros durante a compilação.
É engraçado, mas isso aumenta o tempo de desenvolvimento e o número de erros que inevitavelmente ocorrem.
O pior é que somos obrigados a pensar não em como projetar, organizar arquivos em pastas, decompor, tornar o código manutenível e legível, mas em como escrever corretamente esse comando, porque o escrevi de maneira errada.
Como iniciante, você tenta entender o Terraform, e a IDE não ajuda nem um pouco. Quando há documentação, você acessa e verifica. Mas se você estivesse aprendendo uma nova linguagem de programação, a IDE indicaria que existe esse tipo e que não existe aquele. Pelo menos, no nível de int ou string. Isso costuma ser útil.
E quanto aos testes?
Você deve estar se perguntando: "E os testes, senhores programadores?" Os caras sérios testam tudo em produção, e isso é rigoroso. Aqui está um exemplo de teste unitário para um módulo Terraform do site. .
Eles têm uma boa documentação. A Microsoft sempre me agradou pelo seu enfoque em documentação e aprendizado. Mas não precisa ser o tio Bob para entender que o código aqui não é perfeito. Observe a validação deslocada para a direita.
O problema do teste unitário é que podemos verificar a correção do JSON de saída. Eu coloquei 5 parâmetros e recebi um JSON com 2000 linhas. Posso analisar o que está acontecendo aqui, validar o resultado do teste...
É difícil analisar JSON em Go. E precisamos escrever em Go, porque o Terraform em Go é uma boa prática testar na linguagem em que você está escrevendo. A organização do código em si é muito fraca. No entanto, esta é a melhor biblioteca para testes.
A própria Microsoft escreve seus módulos testando-os dessa forma. Claro, isso é Open Source. Tudo sobre o que estou falando, você pode vir e consertar. Posso me sentar e consertar tudo em uma semana, open-sourçar plugins do VS Code, do Terraform, criar um plugin para o Rider. Talvez escrever alguns analisadores, adicionar linters, contribuir para a biblioteca de testes. Posso fazer tudo isso. Mas não é nisso que devo me concentrar.
Melhores práticas de Infrastructure as Code.
Vamos em frente. Se em IaC não há testes, é ruim em IDE e ferramentas, pelo menos deve haver as melhores práticas. Simplesmente fui ao Google Analytics e comparei duas pesquisas: melhores práticas do Terraform e melhores práticas do C#.
O que vemos? Estatísticas implacáveis não são a nosso favor. Em termos de quantidade de material – é o mesmo. No desenvolvimento em C#, estamos simplesmente mergulhados em material, temos práticas extremamente boas, livros escritos por especialistas, bem como livros escritos por outros especialistas que criticam esses livros. Um mar de documentação oficial, artigos, cursos de aprendizado, e agora também um desenvolvimento open source.
Quanto à pesquisa sobre IaC: aqui você está tentando juntar informações de palestras de highload ou HashiConf, da documentação oficial e inúmeras issues no GitHub. Como você realmente distribui esses módulos, o que fazer com eles? Parece um problema real... Há uma comunidade, senhores, onde a cada pergunta você recebe 10 comentários no GitHub. Mas isso não é certeza.
Infelizmente, os especialistas estão apenas começando a surgir neste momento. Ainda são muito poucos. E a própria comunidade está em um estágio incipiente.
Para onde tudo isso está indo e o que fazer
Podemos simplesmente desistir e voltar para C#, no mundo do Rider. Mas não. Por que você realmente começaria a fazer isso, se não fosse para encontrar uma solução? A seguir, apresento minhas conclusões subjetivas. Você pode discordar de mim nos comentários, seria interessante.
Pessoalmente, eu aposto em algumas coisas:
- O desenvolvimento nesta área está acontecendo muito rapidamente. Apresento um gráfico de buscas sobre DevOps.
Pode ser um tema populista, mas o fato de que o setor está crescendo traz alguma esperança.Se algo está crescendo tão rapidamente, certamente aparecerão pessoas inteligentes que dirão o que fazer e o que não fazer. O aumento da popularidade leva a que, talvez, alguém tenha tempo para finalmente acabar de escrever o plugin para jsonnet no vscode, que permitirá navegar até a implementação da função, ao invés de procurá-la através de ctrl+shift+f. Quando tudo se desenvolve, há mais materiais disponíveis. O mesmo lançamento do livro do Google sobre SRE é um ótimo exemplo disso.
- Existem metodologias e práticas desenvolvidas em desenvolvimento convencional que podemos aplicar com sucesso aqui. Sim, existem nuances com testes e ambientes heterogêneos, ferramentas insuficientes, mas uma enorme quantidade de práticas foi acumulada que podem ser úteis e ajudar.
Um exemplo banal: o trabalho colaborativo através de pair programming. Isso ajuda muito a entender. Quando você tem um colega ao seu lado, que também está tentando entender algo, juntos vocês compreenderão melhor.
Compreender como é feito o refatoramento ajuda, mesmo em tal situação, a realizá-lo. Ou seja, você pode não alterar tudo de uma vez, mas modificar a nomenclatura, depois mudar o posicionamento, e talvez destacar uma parte, ah, e aqui faltam comentários.
Conclusão
Apesar de minhas reflexões poderem parecer pessimistas, olho para o futuro com esperança e sinceramente espero que nós (e vocês) consigamos.
Em seguida, a segunda parte do artigo está sendo preparada. Nela, contarei como tentamos aplicar práticas de desenvolvimento ágil para melhorar nosso processo de aprendizado e trabalho com a infraestrutura.
Fonte: habr.com
