A viagem de um engenheiro para a automação não é algo novo, tendo vindo a ser gerido praticamente desde o surgimento das tecnologias de networking. Em alguns ambientes, chegou-se a ver a automação como uma ameaça para o engenheiro de rede, quando é o oposto, uma ajuda no seu dia-a-dia.
Nestes últimos tempos, o acrónimo SDN (Software Defined Networking) converteu-se na palavra mágica que inunda os portfólios de todos os fabricantes de equipamento de telecomunicações. Um dos motivos é automatizar as infraestruturas de comunicações. Passar de um paradigma, de um plano de controlo distribuído, a um plano de controlo centralizado que orquestre as infraestruturas de comunicações.
Uma das motivações da utilização deste tipo de tecnologias é automatizar as operações na rede: provisões na rede, obtenção de dados de uso, implementação de equipamento novo. Tanto é que, em alguns ambientes, se chega a identificar a automação com estas tecnologias quando, na realidade, a relação entre ambas não é objetiva: as tecnologias SDN utilizam a automação, mas, esta não tem de ir de mãos dadas da SADN.
A RAE define automatizar como “converter certos movimentos em movimentos automáticos ou inconscientes”. Dentro do ambiente das telecomunicações isto traduz-se na identificação de tarefas repetitivas e à aplicação de mecanismos e ferramentas que permitam uma execução mecânica das mesmas.
Embora existam e tenham existido ferramentas comerciais para a industrialização e automação de tarefas nas redes de comunicações, estas são adequadas para ambientes estáveis de produção ou com pouca variabilidade. Em projetos de engenharia nos quais prima a eficiência na execução das mudanças, seja a substituição de equipamento, desenho ou implementação de um novo equipamento, ou a verificação de se, na recepção do equipamento, este funcione corretamente, etc., a utilização das ferramentas tradicionais não é eficiente, nem efetiva.
É neste ponto em que se dá valor às habilidades do engenheiro de rede para conseguir minimizar o tempo necessário para executar as diferentes tarefas.
A aquisição das habilidades de automação nos engenheiros de rede não nasce, principalmente, como uma necessidade do mercado, mas sim como uma inquietude dos próprios engenheiros. Esta situação reflete-se neste clássico gráfico da internet:
Os engenheiros são motivados pela realização de tarefas diferentes que impliquem um desafio. Até se pode dizer que esse tipo de tarefas lhes diverte. Quando um engenheiro tem de realizar tarefas repetitivas, pensa na maneira de minimizar o tempo que necessita para as executar. E temos de reconhecer que a automação implica um desafio divertido: conseguir que uma tarefa aborrecida se possa realizar rapidamente e com um click.
Para tal, utilizará as ferramentas que estejam ao seu alcance. Aqui, o maior problema com o qual se depara o engenheiro de rede é o desconhecimento de que ferramentas existem. A crescente interrelação com departamentos de sistemas e de desenvolvimento, o paradigma DevOps, facilitou a descoberta deste tipo de ferramentas.
Exemplos concretos de automação
Se nos centrarmos em exemplos concretos, dentro do mundo das comunicações um caso típico é a criação de modelos para a implementação de equipamento. A forma pela qual se realiza esta tarefa foi variando com o tempo
- Inicialmente, criavam-se modelos com variáveis que era substituídas manualmente ou com o famoso “localizar e substituir”;
- Depois passa-se a utilizar a funcionalidade combinar correspondência do MS Word. Em ocasiões, esta aproximação provocava alguns problemas pela conversão automática de caracteres especiais;
- Em alguns casos, programava-se em alguma linguagem (VisualBasic, Perl, etc.) essa combinação de correspondência, que permitia dotar a tarefa de maior flexibilidade.
No entanto, esta aproximação só funciona bem quando todos ou quase todos os equipamentos e configurações são iguais ou praticamente iguais. No momento em que se introduz a variabilidade nesses modelos não há outra opção que a intervenção manual ou programar ad-hoc o script que faz os modelos.
Para solucionar este problema, as ferramentas de desenvolvimento web, tais como as linguagens de programação em modelos, ajudam o engenheiro de rede. Em particular, a linguagem Jinja2, desenhada para elaborar modelos em ambientes python.
Esta linguagem permite desenhar um modelo que se comporte de maneira diferente em função dos dados proporcionados. Inclui o conceito de modularidade aos modelos. Já não é necessário ter um modelo monolítico, mas sim pequenos modelos que se apliquem, ou não, em função dos dados com os quais queremos construir a nossa configuração.
A curva de aprendizagem desta linguagem de modelos para um engenheiro de rede é muito baixa. Podem-se elaborar modelos muito elaborados sem entrar em demasia nas complexidades de uma linguagem de programação. Embora Jinja2 seja uma linguagem muito potente e que permite fazer coisas muito detalhadas, o que um engenheiro de rede necessita realmente é muito menos: poder configurar um número variável de elementos, tais como interfaces de rede; poder aplicar, ou não, uma configuração em função de um ou vários parâmetros, como aplicar a configuração de BPG, ou não, a um equipamento, em função do seu perfil na rede, etc.
A utilização de Jinja2 representa uma melhoria em como se elaboram os modelos, dado que permite a sua industrialização e automação.
Outro artigo que poderá ser do seu interesse: Teleassistência Preventiva para Lutar contra o Coronavírus
No entanto, a utilização destes modelos, tal como os modelos tradicionais, mas em maior medida, levanta outro problema; a gestão das versões dos mesmos.
Agora, é fundamental levar um controlo destas versões: qual é a última versão, quais as modificações em relação à versão anterior, quem realizou as últimas modificações, qual o motivo por detrás delas, etc.
A forma tradicional é a utilização de um critério de nomeação manual dos ficheiros do modelo, mas, esta aproximação trouxe sempre más experiências: versões com nomes não consistentes, quem nunca viu modelos com nomes do tipo “definitiva”, “última” ou “final” dentro do mesmo diretório. Com frequência se substituiu um ficheiro por outro por erro, perdendo-se toda ou parte da informação. Já para não falar de conflitos quando duas pessoas modificaram, simultaneamente, o mesmo modelo.
Para ajudar o engenheiro de rede, volta outra vez o mundo do desenvolvimento. Neste ambiente, é fundamental o controlo de versões e utilizaram-se muitas ferramentas deste tipo. Desde há anos que a ferramenta predominante é Git, desenvolvida pelo famoso Linus Torvalds para gerir as versões do kernel de Linux.
Esta ferramenta solucionar-nos-á os dois principais problemas:
- Permite-nos ter um controlo de versões. Já não é necessário alterar o nome dos ficheiros; é a própria ferramenta que se encarrega de criar versões e de controlar as diferenças entre as mesmas.
- Trabalho em grupo: permite que, mais de uma pessoa, trabalhe ao mesmo tempo com uma cópia de um ficheiro e fusiona, automaticamente, todos as alterações. Só em caso de que duas pessoas tenham tocado as mesmas linhas de um ficheiro, se requererá uma intervenção manual para solucionar o conflito.
O seguinte passo na nossa viagem é como obter os dados necessários para alimentar o nosso modelo e gerar a nossa configuração.
Um tipo de projeto habitual nos ambientes de comunicação é a substituição ou migração de equipamento. Às vezes, este equipamento é do mesmo fabricante e, noutros, não; mas, em qualquer caso, é necessário obter os dados dos serviços nos equipamentos atuais para poder migrá-los aos novos.
Se, até ao momento, se havia conseguido evitar a utilização de linguagens de programação, neste momento, é difícil não ter de adquirir umas habilidades mínimas. A maior parte do equipamento atual já permite entregar dados em formatos estruturados (xml ou json, principalmente), mas, isto não é tão habitual em equipamento menos recente. Estes equipamentos entregam texto puro e duro, pelo que, em muitos casos, torna-se necessário ter de parsear a configuração: analisar a configuração para obter os dados necessários num formato com o qual possamos alimentar o nosso modelo de configuração.
Dentro das linguagens de programação que se podem utilizar, destaca-se o python. Os principais motivos são a sua simplicidade e a quantidade de recursos e exemplos que se podem encontrar online. Nestes momentos, é a linguagem utilizada na maioria das ferramentas de automação de rede. Até já se inclui um intérprete desta linguagem nos equipamentos dos principais fabricantes de rede, como Cisco, Juniper ou Nokia.
Com base em tudo o anterior, já seriamos capazes de analisar e processar a informação nos nossos PC´s de forma automática. Faltaria ver como obter essa informação de forma dinâmica e, também, ver como colocar a configuração em rede da mesma forma.
Temos aqui três grandes grupos de opções:
- Utilização de ferramentas englobadas em gestores de conexões, tai como secureCRT. O grande problema desta aproximação costuma ser duplo:
- Muitas vezes, estas ferramentas são proprietárias e têm um custo;
- Partilhar os scripts exige a utilização do mesmo gestor de conexões por parte de todo a equipa, algo que não costuma acontecer habitualmente.
- Utilização de ferramentas desenvolvidas pelos fabricantes: os principais atores do setor desenvolveram bibliotecas de python open source que podem ser utilizadas para realizar esta tarefa. Como exemplos seriam os pyATS de Cisco ou pyEZ de Juniper.
- Utilização de ferramentas agnósticas de fabricante e desenvolvidas pela comunidade. Aqui, teríamos duas principais vertentes:
- Ansible: ferramenta de automação generalista proveniente do mundo DevOps;
- Ferramentas orientadas à rede como napalm, nornir ou salt.
De entre estas destaca-se o Ansible pelos seguintes motivos:
- Não é necessário ter conhecimentos de programação para a poder utilizar. As demais ferramentas são bibliotecas de python que se podem utilizar nos nossos scripts;
- Dispõe de uma grande quantidade de módulos específicos para cada fabricante, desenvolvidos, na maioria dos casos, por esses mesmos fabricantes;
- É relativamente fácil criar novos módulos, programando. Mas, uma vez programado o módulo, qualquer um o pode utilizar sem possuir esses conhecimentos de programação.
Ansible permite uma grande flexibilidade na automação de tarefas. Permite, por exemplo:
- Conectar-se a um equipamento e averiguar em que equipamento estabelece sessões de transporte;
- Conectar-se a esses equipamento e averiguar o estado do serviço, segundo os parâmetros que determinemos;
- Colocar num disco a informação obtida com o formato que mais nos interesse.
Até agora, este tipo de tarefas era realizadas de forma relativamente manual, tanto na obtenção da informação, como na própria correlação.
A utilização de ansible como ferramenta de automação permite-nos poder replicar uma tarefa de forma simples em qualquer momento (por exemplo, antes e depois de realizar uma intervenção na rede) e também reduz os riscos de erros que se produzem entre a cadeira e no teclado do computador.
A forma em que se “programa” ansible é com os denominados playbooks: ficheiros em formato yaml, nos quais lhe indicamos que ações queremos que realize. Embebido em ansible, utiliza-se jinja2 como linguagem de modelos. Por isso, estes playbook também se podem (e devem) gerir mediante o uso de git.
Não se deve esquecer de destacar uma metaferramenta que transcende todas as anteriores: GNU Linux. Este sistema operativo permite, desde os seus inícios, grandes capacidades de automação, algumas que deram bons resultados, como expect, que permite realizar um diálogo com um dispositivo: eu envio-te uma informação e, antes de que me respondas, envio-te outra informação e assim sucessivamente. Algumas ferramentas como ansible também se podem executar sobre Windows, pelo que não há desculpas para aprender o básico deste sistema operativo.
Finalmente, é conveniente relembrar que a automação não é um fim, mas sim um meio. No nosso dia-a-dia, antes de começar a executar uma nova tarefa, devemos analisar se merece, ou não, a pena automatizá-la.
Figura 1 Fonte www.xkcd.com
Também temos de ter em conta que a curva ideal de quanto tempo poupamos com as automações nem sempre se ajusta ao gráfico anterior de “geeks and repetitive tasks”. Se perdemos de vista que a automação é um meio e não um fim, essa curva pode-se converter na seguinte dor de cabeça:
Figura 2: Fonte www.xkcd.com
Mas, a única maneira de um engenheiro de rede alcançar a eficiência na automação é começar a viagem… e começar a divertir-se.
Artigo publicado no outubro pelo meio “A NOSA REDE” del Colegio Oficial Enxeñeiros de Telecomunicación de Galicia .
Pode ver mais do que isso: Plataforma para Medir, Gerir e Monitorizar o Impacto da COVID-19