Este artigo é o sexto de uma série de artigos intitulados "Como colocar a infraestrutura de rede sob seu controle". O conteúdo de todos os artigos da série e os links podem ser encontrados aqui .
Deixando alguns tópicos para trás, decidi 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 uma forma ou de outra, pode ser útil para muitos. É um conto sobre como a automação pode mudar a vida de um engenheiro. Será sobre o uso de modelos. No final, há uma lista dos meus projetos, onde você pode ver como tudo descrito aqui funciona.
DevOps para a Web
Criando uma configuração com um script, usando o GIT para controlar alterações na infraestrutura de TI, "preenchimento" remoto - essas idéias surgem primeiro quando você pensa sobre a implementação técnica da abordagem do DevOps. As vantagens são óbvias. Mas, infelizmente, também existem desvantagens.
Quando, há mais de cinco anos, nossos desenvolvedores vieram até nós, para redes de contatos, com essas ofertas, não estávamos entusiasmados.
Devo dizer que herdamos uma rede bastante heterogênea que consiste no equipamento de cerca de 10 fornecedores diferentes. Algo era conveniente de configurar através do nosso CLI favorito, mas em algum lugar preferimos usar a GUI. Além disso, longo trabalho em equipamentos "ao vivo" foi ensinado ao controle em tempo real. Por exemplo, ao fazer alterações, me sinto muito mais confortável trabalhando diretamente através do CLI. Então eu posso ver rapidamente que algo deu errado e "reverter" as alterações. Tudo isso estava em contradição com as idéias deles.
Outras questões surgem, por exemplo, de versão para versão de software, a interface pode variar um pouco. No final, isso fará com que o seu script crie a "configuração" errada. Eu não gostaria de usar a produção para uma invasão.
Ou como entender que 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 dizendo "A", provavelmente é aconselhável dizer "B", e se você quiser usar os mesmos processos para controle de alterações que no desenvolvimento, precisará ter ambientes de desenvolvimento e preparação além da produção. Então essa abordagem parece completa. Mas quanto vai custar?
Mas há uma situação em que os contras estão quase nivelados e apenas os profissionais permanecem. Eu estou falando sobre o trabalho de design.
Projeto
Nos últimos dois anos, participei de um projeto para construir um data center para um grande fornecedor. Sou responsável pela F5 e Palo Alto neste projeto. Do ponto de vista da Cisco, é o "equipamento de terceiros".
Para mim, pessoalmente, existem duas etapas distintas neste projeto.
Primeira etapa
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. Em uma rotina constante, eu não conseguia nem otimizar o processo. Não era apenas e não tanto a configuração do equipamento como a preparação da documentação do projeto.
Então, os primeiros testes começaram e eu ficaria surpreso com quantos erros e imprecisões menores foram cometidos. É claro que tudo funcionou, mas a letra do nome estava faltando, a linha da equipe estava faltando aqui ... Os testes continuaram e continuaram, e eu já estava em uma luta constante e diária com erros, testes e documentação.
Isso durou um ano. O projeto, como eu o entendo, não foi fácil para todos, mas gradualmente o cliente ficou cada vez mais satisfeito, e isso possibilitou a contratação de engenheiros adicionais que pudessem participar da rotina.
Agora era possível olhar um pouco ao redor.
E esse foi o começo da segunda etapa.
Segunda etapa
Eu decidi automatizar o processo.
O que eu entendi da comunicação com os desenvolvedores da época (e devemos prestar homenagem, tínhamos uma equipe forte) é que o formato de texto, embora pareça à primeira vista algo do mundo do sistema operacional DOS, possui várias propriedades valiosas .
Por exemplo, um formato de texto será útil se você quiser tirar o máximo proveito do GIT e de todos os seus derivados. 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, ao projetar, há outra tarefa importante. Você deve ter documentação descrevendo seu design geral (Design de baixo nível) e implementação específica (Plano de implementação de rede). E, neste caso, o uso de modelos parece ser uma opção muito adequada.
Portanto, ao usar o YAML e o Jinja2, um arquivo YAML com parâmetros de configuração, como endereços IP, números BGP AS, ... cumpre perfeitamente o papel do NIP, enquanto os modelos do Jinja2 incluem uma sintaxe apropriada ao design, ou seja, é um reflexo do LLD.
Demorou dois dias para aprender os idiomas YAML e Jinja2. Alguns bons exemplos são suficientes para entender como isso funciona. Demorou cerca de duas semanas para criar todos os modelos adequados ao nosso design: uma semana para Palo Alto e outra semana para a F5. Tudo isso foi publicado no githab corporativo.
Agora, o processo de mudança foi o seguinte:
- arquivo yaml alterado
- criou um arquivo de configuração usando um modelo (Jinja2)
- salvo em um repositório remoto
- carregou a configuração criada para o equipamento
- vi um erro
- arquivo YAML ou modelo Jinja2 alterado
- criou um arquivo de configuração usando um modelo (Jinja2)
- ...
É claro que, no início, muito tempo foi gasto em edição, mas depois de uma semana ou duas já era mais provável uma raridade.
Um bom teste e a capacidade de depurar tudo foi o desejo do cliente de mudar a convenção de nomenclatura. Quem trabalhou com a F5 entende a importância da situação. Mas para mim foi bem simples. Mudei os nomes no arquivo YAML, excluí toda a configuração do equipamento, gerei uma nova e carreguei. Tudo, levando em consideração as correções, levou quatro dias: dois dias para cada tecnologia. Depois disso, eu estava pronto para a próxima etapa, a saber, a criação de data centers DEV e Staging.
Dev and Staging
O estadiamento repete a produção completamente. O Dev é uma cópia altamente simplificada, construída principalmente em hardware virtual. Situação ideal para uma nova abordagem. Se eu isolar o tempo gasto no processo geral, acho que o trabalho não levou mais de duas semanas. O tempo principal é o tempo de espera do outro lado e uma busca conjunta por problemas. A implementação do terceiro foi quase invisível para os outros. Houve até tempo para ensinar alguma coisa e escrever alguns artigos sobre Habré :)
Resumir
Então, o que eu tenho na linha de fundo?
- tudo o que é necessário para alterar a configuração é modificar um arquivo YAML simples e claramente estruturado com parâmetros de configuração. Eu nunca mudo o script python e muito raramente (apenas se houver um erro) eu mudo o Jinja2
- do ponto de vista da documentação, é obtida uma situação quase ideal. Você altera a documentação (os arquivos YAML atuam como NIP) e carrega essa configuração no equipamento. Assim, sua documentação está sempre atualizada.
Tudo isso levou ao fato de que
- a porcentagem de erros diminuiu para quase 0
- foram necessários 90% da rotina
- a velocidade de implementação aumentou significativamente
PAGAR, F5Y, ACY
Eu disse que alguns exemplos são suficientes para entender como isso funciona.
Aqui está uma versão curta (e, é claro, modificada) do que foi criado no processo do meu trabalho.
PAY = implantação
P alo
A lto de
Y aml = Palo Alto de Yaml
F5Y = implantação
F5 de
Y aml =
F5 de
Y aml (em breve)
ACY = implantação
AC i de
Y aml =
F5 de
Y aml
Acrescentarei algumas palavras sobre o ACY (para não confundir com o ACI).
Quem trabalhou com a ACI sabe que esse milagre (e de uma boa maneira também) não foi criado por redes :). Esqueça tudo o que sabia sobre a rede - isso não será útil para você!
É um pouco exagerado, mas transmite aproximadamente a sensação que eu constantemente experimento há 3 anos, trabalhando com a ACI.
E, nesse caso, o ACY não é apenas uma oportunidade para criar um processo de controle de alterações (o que é especialmente importante no caso da ACI, porque é assumido que essa é a parte central e mais crítica do seu data center), mas também oferece uma interface amigável para a criação de uma configuração.
Os engenheiros deste projeto usam o Excel para usar ACI em vez de YAML exatamente para o mesmo objetivo. Existem algumas vantagens em usar o Excel, é claro:
- seu beliscão em um arquivo
- belos sinais de que o cliente tem o prazer de olhar
- você pode usar algumas ferramentas do excel
Mas há uma desvantagem e, na minha opinião, supera os profissionais. Controlar as mudanças e coordenar o trabalho em equipe se torna muito mais difícil.
O ACY está realmente aplicando as mesmas abordagens que eu usei para configurar o ACI de terceiros.