Este artigo é o sexto da série de artigos "Como controlar a infraestrutura de rede". O conteúdo de todos os artigos dessa série e os links podem ser encontrados .
Deixando alguns tópicos para trás, decidi, no entanto, começar um novo capítulo.
Voltarei à segurança um pouco mais tarde. Aqui, quero discutir uma abordagem simples, mas eficaz, que, tenho certeza, de alguma forma pode ser útil para muitos. É mais uma breve história sobre como a automação pode mudar a vida de um engenheiro. Estarei falando sobre o uso de templates. No final, apresento uma lista dos meus projetos, onde você pode ver como tudo o que foi descrito aqui funciona.
DevOps para redes
A criação de configurações via script, o uso do GIT para controle de mudanças na infraestrutura de TI, o "upload" remoto — essas ideias vêm à mente primeiro quando se pensa na implementação técnica da abordagem DevOps. As vantagens são óbvias. Mas, infelizmente, existem também desvantagens.
Quando nossos desenvolvedores vieram até nós, os especialistas em redes, com essas propostas há mais de 5 anos, não estávamos exatamente empolgados.
Devo dizer que herdamos uma rede bem diversa, composta por equipamentos de cerca de 10 diferentes fornecedores. Algumas coisas eram convenientes para configurar através de nosso querido cli, mas em alguns casos preferíamos usar a GUI. Além disso, o longo trabalho em equipamentos "vivos" nos acostumou ao controle em tempo real. Eu, por exemplo, me sinto muito mais confortável fazendo mudanças diretamente pelo cli. Assim, posso rapidamente ver se algo deu errado e "reverter" as alterações. Tudo isso estava em certo conflito com suas ideias.
Outras questões surgem, como o fato de que a interface pode mudar de versão para versão do software. Isso, afinal, levará ao seu script gerar uma "configuração" incorreta. Não gostaria de usar o ambiente de produção para "testes".
Ou então, como saber se os comandos de configuração foram aplicados corretamente e o que fazer em caso de erro?
Não quero dizer que todas essas questões sejam insolúveis. Apenas, ao dizer "A", talvez seja razoável dizer também "B" e, se você quiser usar os mesmos processos para controle de mudanças que na desenvolvimento, deve ter, além do ambiente de produção, também ambientes de dev e staging. Assim, essa abordagem parece completa. Mas quanto isso custará?
Mas há uma situação em que as desvantagens praticamente se anulam, e só permanecem as vantagens. Estou falando sobre trabalhos de projeto.
Projeto
Nos últimos dois anos, participei de um projeto para construir um data center para um grande provedor. Eu sou responsável neste projeto pela F5 e Palo Alto. Do ponto de vista da Cisco, isso é "equipamento de terceiros".
Para mim, há duas fases bem definidas nesse projeto.
Primeira fase
No primeiro ano, estive infinitamente ocupado, trabalhei à noite e nos fins de semana. Eu não conseguia levantar a cabeça. A pressão da gerência e do cliente era forte e contínua. Na rotina constante, não consegui nem tentar otimizar o processo. Não se tratava apenas de configurar o equipamento, mas também de elaborar a documentação do projeto.
Então começaram os primeiros testes, e fiquei surpreso com quantos pequenos erros e imprecisões foram cometidos. Claro, tudo funcionava, mas havia uma letra faltando no nome, uma linha perdida no comando... Os testes continuaram e continuaram, e eu estava em uma luta constante e diária com os erros, os testes e a documentação.
Isso continuou por um ano. O projeto, pelo que entendi, não era fácil para ninguém, mas gradualmente o cliente se tornava cada vez mais satisfeito, e isso nos permitiu contratar engenheiros adicionais que poderiam assumir parte da rotina.
Agora era possível olhar ao redor.
E isso foi o início da segunda fase.
Segunda fase
Decidi automatizar o processo.
O que percebi da comunicação com os desenvolvedores na época (e devo reconhecer, tínhamos uma equipe forte) é que o formato de texto, embora à primeira vista pareça algo do mundo do sistema operacional DOS, possui uma série de propriedades valiosas.
Por exemplo, o formato de texto será útil se você quiser aproveitar ao máximo as vantagens do GIT e suas ramificações. E eu queria.
Bem, à primeira vista, poderia parecer que era simples armazenar a configuração ou a lista de comandos, mas fazer mudanças enquanto isso é bastante inconveniente. Além disso, ao projetar, há mais uma tarefa importante. Você deve ter uma documentação que descreva seu design como um todo (Low Level Design) e a implementação específica (Network Implementation Plan). E neste caso, o uso de templates parece ser uma opção muito adequada.
Assim, ao usar YAML e Jinja2, o arquivo YAML com parâmetros de configuração, como endereços IP, números BGP AS,… desempenha perfeitamente o papel de NIP, enquanto os templates Jinja2 incluem a sintaxe correspondente ao design, ou seja, são essencialmente um reflexo do LLD.
O estudo das linguagens YAML e Jinja2 levou dois dias. Para entender como funciona, são necessários alguns bons exemplos. Em seguida, foram cerca de duas semanas para criar todos os templates que correspondiam ao nosso design: uma semana para Palo Alto e mais uma semana para F5. Tudo isso foi disponibilizado no GitHub corporativo.
Agora, o processo de mudanças parecia o seguinte:
- modifiquei o arquivo YAML
- criei um arquivo de configuração usando o template (Jinja2)
- salvei no repositório remoto
- enviei a configuração criada para o equipamento
- vi um erro
- modifiquei o arquivo YAML ou o template Jinja2
- criei um arquivo de configuração usando o template (Jinja2)
- …
É claro que, no início, muito tempo era gasto em correções, mas após uma ou duas semanas isso já se tornava mais rarefeito.
Uma boa verificação e oportunidade para debugar tudo foi o desejo do cliente de mudar a convenção de nomenclatura. Quem trabalhou com F5 entende a complexidade da situação. Mas, para mim, tudo foi bastante simples. Eu mudei os nomes no arquivo YAML, removi toda a configuração do equipamento, gerei uma nova e fiz o upload. Para tudo isso, considerando as correções de bugs, levou 4 dias: dois dias para cada tecnologia. Depois disso, eu estava pronto para a próxima etapa, a saber, a criação dos data centers DEV e Staging.
Dev e Staging
O Staging replica quase completamente a produção. O Dev é uma cópia bastante reduzida e construída principalmente em hardware virtual. Uma situação ideal para aplicar uma nova abordagem. Se excluirmos do processo geral o tempo que gastei, o trabalho não levou mais de 2 semanas. O principal tempo foi o tempo de espera pela outra parte e a busca conjunta de problemas. A implementação de terceiros passou quase despercebida pelos outros. Até houve tempo para aprender algo e escrever alguns artigos no Habr 🙂
Em resumo
Então, o que eu tenho como resultado final?
- tudo o que preciso para mudar a configuração — é modificar um arquivo YAML simples e claramente estruturado com parâmetros de configuração. Eu nunca mudo o script Python e raramente (somente se houver um erro) modifico o template Jinja2.
- Do ponto de vista da documentação, parece uma situação quase perfeita. Você altera a documentação (os arquivos YAML desempenham o papel de NIP) e faz o upload dessa configuração para o equipamento. Assim, a sua documentação está sempre atualizada.
Tudo isso levou ao fato de que
- a porcentagem de erros caiu praticamente para 0
- 90% da rotina foi eliminada
- a velocidade de implementação aumentou significativamente
PAY, F5Y, ACY
Eu disse que alguns exemplos são suficientes para entender como isso funciona.
Aqui está uma versão breve (e, claro, modificada) do que foi criado durante o meu trabalho.
= implantação Palo Alto from Yaml = Palo Alto from Yaml
= implantação F5 Harvard University Yaml = F5 Harvard University Yaml (em breve)
= implantação ACi from Yaml = F5 Harvard University Yaml
Vou acrescentar algumas palavras sobre ACY (não confundir com ACI).
Aqueles que trabalharam com ACI sabem que essa maravilha (e no bom sentido também) foi criada definitivamente por não especialistas em redes :). Esqueça tudo o que você sabia sobre redes — isso não será útil!
É um pouco exagerado, mas transmite aproximadamente a sensação que tenho constantemente, há 3 anos, trabalhando com ACI.
E, neste caso, ACY não é apenas a possibilidade de estabelecer um processo de controle de mudanças (o que é especialmente importante em se tratando de ACI, porque pressupõe-se que essa é a parte central e mais crítica do seu data center), mas também fornece uma interface amigável para criação da configuração.
Os engenheiros deste projeto, para configurar ACI, ao invés de YAML, utilizam Excel para os mesmos fins. Existem, claro, vantagens em usar Excel:
- seu NIP em um único arquivo
- tabelas bonitas, que são agradáveis ao olhar do cliente
- você pode usar algumas ferramentas do Excel
Mas há uma desvantagem, e na minha opinião, ela supera as vantagens. Controlar mudanças e coordenar o trabalho da equipe se torna muito mais difícil.
ACY é, na verdade, a aplicação das mesmas abordagens que usei para terceiros, para configurar ACI.
Fonte: habr.com
