{"id":34742,"date":"2019-10-31T22:00:10","date_gmt":"2019-10-31T19:00:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty\/"},"modified":"2019-10-31T22:00:10","modified_gmt":"2019-10-31T19:00:10","slug":"kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty","title":{"rendered":"Como controlar a infraestrutura de rede. Cap\u00edtulo quatro. Automa\u00e7\u00e3o. Templates.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Este artigo \u00e9 o sexto da s\u00e9rie de artigos \"Como controlar a infraestrutura de rede\". O conte\u00fado de todos os artigos dessa s\u00e9rie e os links podem ser encontrados aqui<\/a><\/noindex><\/i>.<\/p>\n

Deixando alguns t\u00f3picos para tr\u00e1s, decidi, no entanto, come\u00e7ar um novo cap\u00edtulo.<\/p>\n

Voltarei \u00e0 seguran\u00e7a um pouco mais tarde. Aqui, quero discutir uma abordagem simples, mas eficaz, que, tenho certeza, de alguma forma pode ser \u00fatil para muitos. \u00c9 mais uma breve hist\u00f3ria sobre como a automa\u00e7\u00e3o pode mudar a vida de um engenheiro. Estarei falando sobre o uso de templates. No final, apresento uma lista dos meus projetos, onde voc\u00ea pode ver como tudo o que foi descrito aqui funciona.<\/p>\n

DevOps para redes<\/h2>\n

\nA cria\u00e7\u00e3o de configura\u00e7\u00f5es via script, o uso do GIT para controle de mudan\u00e7as na infraestrutura de TI, o \"upload\" remoto \u2014 essas ideias v\u00eam \u00e0 mente primeiro quando se pensa na implementa\u00e7\u00e3o t\u00e9cnica da abordagem DevOps. As vantagens s\u00e3o \u00f3bvias. Mas, infelizmente, existem tamb\u00e9m desvantagens.<\/p>\n

Quando nossos desenvolvedores vieram at\u00e9 n\u00f3s, os especialistas em redes, com essas propostas h\u00e1 mais de 5 anos, n\u00e3o est\u00e1vamos exatamente empolgados.
\n<\/a><\/noindex>
\nDevo dizer que herdamos uma rede bem diversa, composta por equipamentos de cerca de 10 diferentes fornecedores. Algumas coisas eram convenientes para configurar atrav\u00e9s de nosso querido cli, mas em alguns casos prefer\u00edamos usar a GUI. Al\u00e9m disso, o longo trabalho em equipamentos \"vivos\" nos acostumou ao controle em tempo real. Eu, por exemplo, me sinto muito mais confort\u00e1vel fazendo mudan\u00e7as diretamente pelo cli. Assim, posso rapidamente ver se algo deu errado e \"reverter\" as altera\u00e7\u00f5es. Tudo isso estava em certo conflito com suas ideias.<\/p>\n

Outras quest\u00f5es surgem, como o fato de que a interface pode mudar de vers\u00e3o para vers\u00e3o do software. Isso, afinal, levar\u00e1 ao seu script gerar uma \"configura\u00e7\u00e3o\" incorreta. N\u00e3o gostaria de usar o ambiente de produ\u00e7\u00e3o para \"testes\". <\/p>\n

Ou ent\u00e3o, como saber se os comandos de configura\u00e7\u00e3o foram aplicados corretamente e o que fazer em caso de erro?<\/p>\n

N\u00e3o quero dizer que todas essas quest\u00f5es sejam insol\u00faveis. Apenas, ao dizer \"A\", talvez seja razo\u00e1vel dizer tamb\u00e9m \"B\" e, se voc\u00ea quiser usar os mesmos processos para controle de mudan\u00e7as que na desenvolvimento, deve ter, al\u00e9m do ambiente de produ\u00e7\u00e3o, tamb\u00e9m ambientes de dev e staging. Assim, essa abordagem parece completa. Mas quanto isso custar\u00e1?<\/p>\n

Mas h\u00e1 uma situa\u00e7\u00e3o em que as desvantagens praticamente se anulam, e s\u00f3 permanecem as vantagens. Estou falando sobre trabalhos de projeto.<\/p>\n

Projeto<\/h2>\n

\nNos \u00faltimos dois anos, participei de um projeto para construir um data center para um grande provedor. Eu sou respons\u00e1vel neste projeto pela F5 e Palo Alto. Do ponto de vista da Cisco, isso \u00e9 \"equipamento de terceiros\".<\/p>\n

Para mim, h\u00e1 duas fases bem definidas nesse projeto. <\/p>\n

Primeira fase<\/h3>\n

\nNo primeiro ano, estive infinitamente ocupado, trabalhei \u00e0 noite e nos fins de semana. Eu n\u00e3o conseguia levantar a cabe\u00e7a. A press\u00e3o da ger\u00eancia e do cliente era forte e cont\u00ednua. Na rotina constante, n\u00e3o consegui nem tentar otimizar o processo. N\u00e3o se tratava apenas de configurar o equipamento, mas tamb\u00e9m de elaborar a documenta\u00e7\u00e3o do projeto. <\/p>\n

Ent\u00e3o come\u00e7aram os primeiros testes, e fiquei surpreso com quantos pequenos erros e imprecis\u00f5es 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\u00e1ria com os erros, os testes e a documenta\u00e7\u00e3o. <\/p>\n

Isso continuou por um ano. O projeto, pelo que entendi, n\u00e3o era f\u00e1cil para ningu\u00e9m, mas gradualmente o cliente se tornava cada vez mais satisfeito, e isso nos permitiu contratar engenheiros adicionais que poderiam assumir parte da rotina.<\/p>\n

Agora era poss\u00edvel olhar ao redor.
\nE isso foi o in\u00edcio da segunda fase. <\/p>\n

Segunda fase<\/h3>\n

\nDecidi automatizar o processo.<\/p>\n

O que percebi da comunica\u00e7\u00e3o com os desenvolvedores na \u00e9poca (e devo reconhecer, t\u00ednhamos uma equipe forte) \u00e9 que o formato de texto, embora \u00e0 primeira vista pare\u00e7a algo do mundo do sistema operacional DOS, possui uma s\u00e9rie de propriedades valiosas.
\nPor exemplo, o formato de texto ser\u00e1 \u00fatil se voc\u00ea quiser aproveitar ao m\u00e1ximo as vantagens do GIT e suas ramifica\u00e7\u00f5es. E eu queria. <\/p>\n

Bem, \u00e0 primeira vista, poderia parecer que era simples armazenar a configura\u00e7\u00e3o ou a lista de comandos, mas fazer mudan\u00e7as enquanto isso \u00e9 bastante inconveniente. Al\u00e9m disso, ao projetar, h\u00e1 mais uma tarefa importante. Voc\u00ea deve ter uma documenta\u00e7\u00e3o que descreva seu design como um todo (Low Level Design) e a implementa\u00e7\u00e3o espec\u00edfica (Network Implementation Plan). E neste caso, o uso de templates parece ser uma op\u00e7\u00e3o muito adequada.<\/p>\n

Assim, ao usar YAML e Jinja2, o arquivo YAML com par\u00e2metros de configura\u00e7\u00e3o, como endere\u00e7os IP, n\u00fameros BGP AS,\u2026 desempenha perfeitamente o papel de NIP, enquanto os templates Jinja2 incluem a sintaxe correspondente ao design, ou seja, s\u00e3o essencialmente um reflexo do LLD. <\/p>\n

O estudo das linguagens YAML e Jinja2 levou dois dias. Para entender como funciona, s\u00e3o necess\u00e1rios 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.<\/p>\n

Agora, o processo de mudan\u00e7as parecia o seguinte:<\/p>\n