Este artigo é o sexto da série “Como assumir o controle de sua infraestrutura de rede”. O conteúdo de todos os artigos da série e links podem ser encontrados .
Tendo deixado vários tópicos para trás, decidi iniciar um novo capítulo.
Voltarei à segurança um pouco mais tarde. Quero discutir aqui uma abordagem simples, mas eficaz, que tenho certeza, de uma forma ou de outra, que pode ser útil para muitos. Esta é mais uma pequena história sobre como a automação pode mudar a vida de um engenheiro. Falaremos sobre o uso de modelos. No final há uma lista dos meus projetos onde você pode ver como funciona tudo o que foi descrito aqui.
DevOps para a rede
Criar uma configuração com um script, usar GIT para controlar mudanças na infraestrutura de TI, “upload” remoto – essas ideias vêm em primeiro lugar quando você pensa na implementação técnica da abordagem DevOps. As vantagens são óbvias. Mas, infelizmente, também existem desvantagens.
Quando, há mais de 5 anos, nossos desenvolvedores vieram até nós, os networkers, com essas propostas, não ficamos encantados.
Devo dizer que herdamos uma rede bastante heterogênea, composta por equipamentos de cerca de 10 fornecedores diferentes. Foi conveniente configurar algumas coisas através do nosso CLI favorito, mas em outras preferimos usar a GUI. Além disso, o longo trabalho em equipamentos “vivos” nos ensinou o controle em tempo real. Por exemplo, ao fazer alterações, me sinto muito mais confortável trabalhando diretamente pelo cli. Dessa forma, posso ver rapidamente que algo deu errado e reverter as alterações. Tudo isso estava em certa contradição com suas idéias.
Outras questões também surgem, por exemplo, a interface pode mudar ligeiramente de versão para versão do software. Isso eventualmente fará com que seu script crie a "configuração" errada. Eu não gostaria de usar a produção para “rodar”.
Ou como entender 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 dizer “A” provavelmente faz sentido dizer “B” também, e se você quiser usar os mesmos processos para controle de mudanças que no desenvolvimento, então você precisa ter ambientes de desenvolvimento e teste, além da produção. Então esta abordagem parece completa. Mas quanto custará?
Mas há uma situação em que as desvantagens são praticamente niveladas e apenas as vantagens permanecem. Estou falando sobre trabalho de design.
Projeto
Há dois anos participo de um projeto de construção de um data center para um grande provedor. Sou responsável pela F5 e Palo Alto neste projeto. Do ponto de vista da Cisco, trata-se de “equipamento de terceiros”.
Para mim, pessoalmente, existem duas fases distintas neste projeto.
O primeiro estágio
No primeiro ano estive muito ocupado, trabalhei à noite e nos fins de semana. Eu não conseguia levantar a cabeça. A pressão da administração e do cliente foi forte e contínua. Numa rotina constante, não consegui nem tentar otimizar o processo. Não se tratava apenas e nem tanto da configuração dos equipamentos, mas da preparação da documentação do projeto.
Os primeiros testes já começaram e eu ficaria surpreso com a quantidade de pequenos erros e imprecisões que foram cometidos. Claro que tudo funcionou, mas faltava uma letra no nome, faltava uma linha no comando... Os testes continuavam e eu já estava em uma luta constante e diária com erros, testes e documentação .
Isso durou um ano. O projeto, pelo que entendi, não foi fácil para todos, mas aos poucos o cliente foi ficando cada vez mais satisfeito, o que possibilitou a contratação de mais engenheiros que puderam assumir sozinhos parte da rotina.
Agora poderíamos olhar um pouco ao redor.
E este foi o início da segunda etapa.
Segunda etapa
Decidi automatizar o processo.
O que entendi da minha comunicação com os desenvolvedores naquela época (e devemos prestar homenagem, 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 de propriedades valiosas.
Assim, por exemplo, o formato de texto será útil se você quiser aproveitar ao máximo o GIT e todos os seus derivados. E eu queria.
Bem, parece que você pode simplesmente armazenar uma configuração ou uma lista de comandos, mas fazer alterações é bastante inconveniente. Além disso, há outra tarefa importante durante o design. Você deve ter documentação descrevendo seu projeto como um todo (Projeto de Baixo Nível) e implementação específica (Plano de Implementação de Rede). E neste caso, o uso de templates parece uma opção muito adequada.
Assim, ao usar YAML e Jinja2, um arquivo YAML com parâmetros de configuração como endereços IP, números BGP AS, ... cumpre perfeitamente o papel de NIP, enquanto os templates Jinja2 incluem sintaxe correspondente ao design, ou seja, é essencialmente um reflexo do LLD.
Demorou dois dias para aprender YAML e Jinja2. Alguns bons exemplos são suficientes para entender como isso funciona. Depois, demorou cerca de duas semanas para criar todos os modelos que combinassem com nosso design: uma semana para Palo Alto e outra semana para F5. Tudo isso foi postado no githab corporativo.
Agora o processo de mudança ficou assim:
- alterou o arquivo YAML
- criou um arquivo de configuração usando um modelo (Jinja2)
- salvo em um repositório remoto
- carregou a configuração criada para o equipamento
- Eu vi um erro
- alterou o arquivo YAML ou modelo Jinja2
- criou um arquivo de configuração usando um modelo (Jinja2)
- ...
É claro que no início muito tempo foi gasto em edições, mas depois de uma ou duas semanas isso se tornou uma raridade.
Um bom teste e oportunidade para depurar tudo foi o desejo do cliente de mudar a convenção de nomenclatura. Quem trabalhou com F5 entende o picante da situação. Mas para mim foi tudo muito simples. Alterei os nomes no arquivo YAML, apaguei toda a configuração do equipamento, gerei uma nova e carreguei. Tudo, inclusive a correção de bugs, levou 4 dias: dois dias para cada tecnologia. Depois disso, estava pronto para a próxima etapa, nomeadamente a criação de data centers DEV e Staging.
Desenvolvimento e preparação
Na verdade, o preparo replica completamente a produção. Dev é uma cópia bastante simplificada construída principalmente em hardware virtual. Uma situação ideal para uma nova abordagem. Se eu isolar o tempo que gastei do processo geral, acho que o trabalho não demorou mais do que duas semanas. O principal momento é esperar o outro lado e procurar juntos os problemas. A implementação de terceiros passou quase despercebida por outros. Teve até tempo para aprender alguma coisa e escrever alguns artigos sobre Habré :)
para resumir
Então, o que eu tenho no resultado final?
- Tudo o que preciso fazer para alterar a configuração é alterar um arquivo YAML simples e claramente estruturado com parâmetros de configuração. Eu nunca mudo o script python e muito raramente (somente se houver um erro) eu mudo o heatlate do Jinja2
- Do ponto de vista documental, esta é uma situação quase ideal. Você altera a documentação (arquivos YAML servem como NIP) e carrega essa configuração no equipamento. Assim sua documentação estará sempre atualizada
Tudo isso levou ao fato de que
- a taxa de erro caiu para quase 0
- 90 por cento da rotina desapareceu
- a velocidade de implementação aumentou significativamente
PAGAR, F5Y, ACY
Eu disse que alguns exemplos são suficientes para entender como funciona.
Aqui está uma versão curta (e, claro, modificada) do que foi criado durante meu trabalho.
= implantação Palo Aaté de Yaml = Palo Alto de Yaml
= implantação F5 da Yaml = F5 da Yaml (em breve)
= implantação ACeu de Yaml = F5 da Yaml
Acrescentarei algumas palavras sobre ACY (não confundir com ACI).
Quem já trabalhou com a ACI sabe que esse milagre (e no bom sentido também) definitivamente não foi criado por networkers :). Esqueça tudo o que você sabia sobre a rede - ela não será útil para você!
É um pouco exagerado, mas transmite aproximadamente a sensação que tenho experimentado constantemente, nos últimos 3 anos, trabalhando com a ACI.
E neste caso, o ACY não é apenas uma oportunidade para construir um processo de controle de mudanças (o que é especialmente importante no caso do ACI, porque é suposto ser a parte central e mais crítica do seu data center), mas também lhe dá uma interface amigável para criar configurações.
Os engenheiros deste projeto usam Excel para configurar ACI em vez de YAML exatamente para os mesmos fins. É claro que existem vantagens em usar o Excel:
- seu NIP em um arquivo
- lindas placas que agradam ao cliente olhar
- você pode usar algumas ferramentas do Excel
Mas há uma desvantagem e, na minha opinião, supera as vantagens. Controlar as mudanças e coordenar o trabalho em equipe torna-se muito mais difícil.
ACY é na verdade uma aplicação das mesmas abordagens que usei para terceiros configurarem ACI.
Fonte: habr.com