Ansible – Script baseado na família do equipamento – parte 5

Olá Pessoal,

   Já faz um tempo que não adiciono nada em relação a este tema, então vamos trazer mais opções para que vocês possam observar essas idéias e possam adaptar ou criar dentro de seus ambientes que trabalham no dia a dia.

   Neste detalhamento vou atrelar aos códigos que já estavamos desenvolvendo nos posts anteriores que trazia o conceito de trabalhar com ( .csv ) e scripts Jinja2, bem como respondendo o que eu havia perguntando no post anterior de nossa série.

   Pois bem, nesse primeiro momento vamos fazer a nossa tratativa para selecionar o equipamento através de uma funcionalidade básica, que por sua vez vai depender de alguns parâmetros ” ad-hoc ” no momento de execução de nossa playbook. Eu quis dizer básico, pois vamos adicionar ” tags ” que de alguma forma será identificada manualmente pela inserção do desenvolvedor do código.

   Dentro do ambiente Ansible essas ” tags ” são tratadas inerente ao comando ou ação que você esta executando em sua “ task “, ou seja, essas marcações vão ser interpretadas a partir do momento que ela é definida na execução de sua ” playbook “. Portanto, se a ” tag ” estiver identificada aquela task será executada e obviamente se você estiver incluindo “ sub tasks “, “ roles ” as mesmas ações de suas “ tags ” precisam ser identificadas no ambiente. Essa é uma maneira mais rápida e prática identificar as ações que devem ser executadas em sua playbook, porém dependendo de sua demanda outros caminhos e soluções precisam ser analisadas. Para maiores detalhes recomendo observar documentação tags em Ansible.

   Na versão 2.4 e 2.5 já temos algumas nomenclaturas adicionadas para que você consiga anexar em sua lógica de execução, e assim facilitar em algumas metodologias. Nesses parâmetros podemos definir ” always “, ” tagged “, “ untagged ” e ” never “. Outro ponto que podemos declarar em algumas situações é através do ” –skip-tags “, na qual eu reforço aqui, que devemos usar através de comandos ” ad-hoc “, como já explicado nesse post sobre esse recurso.

   Com isso mapeado, nesse caso vou trazer um exemplo para que possamos gerar scripts distintos para uma plataforma Cisco 881 e outra plataforma Cisco 1941. Venho ressaltar que no script do 1941 estou apenas anexando o nome do router para validação e declarando para identificar que de fato rodamos o template correto via automação. PS.: Esse script não tem muito sentido olhando na visão de router, mas vou testar a lógica.

   Primeiramente analisando meu código eu tenho tasks que precisam ser executadas independentemente da plataforma, ou seja, estou utilizando a tag ” always “.

   Como mencionando preciso adicionar nas minhas “ roles ” que também precisam identicar em que situação iremos rodas essas tarefas. Neste meu caso popular as varíaveis são essenciais, portanto vamos também adicionar a tag ” always “.

   Enfim, chegamos no ponto onde vou definir minhas variaveis distintas e obviamente meu template ” script ” distinto. Nesse caso eu criei um arquivo adicional chamado de ” script_1941.j2 ” para emular minha plataforma e avaliar se estou populando corretamente via “ tags “. Após esse detalhamento adicionei mais uma tarefa para separar essas demandas.

   Agora podemos executar e analisar quais templates estão sendo gerados utilizando via comando ” ad-hoc “. Para isso vamos seguir desta forma chamando como  –tags “router1941” .

   Agora vamos observar a criação dos templates com suas caracteristicas dessa seleção de “ tag “.


   Quando usado por exemplo um –skip-tags “router1941” você pode observar que rodamos outra “ tag “, portanto excluindo toda tarefa relacionada a essa demanda. Se pensarmos, podemos também utilizar a tag ” router881 ” que terá a mesma execução.

   Enfim, mais uma vez podemos verificar a diversidade que podemos atender baseando em sua demanda. Em nosso próximo post essa escolha será automatica na qual irei validar no router real que plataforma estamos trabalhando e após isso farei a entrega do template correto ao equipamento. Reforçando que esse códigos estão todos disponivéis no meu Github.

   Espero que vocês tenham gostado e falta apenas provar para vocês a questão levantada no post anterior sobre as validações de erros.  😉 

Abs,
Rodrigo

0
0

Link permanente para este artigo: https://ciscoredes.com.br/2018/07/02/ansible-script-baseado-na-familia-do-equipamento-parte-5/

Deixe uma resposta

Seu e-mail não será publicado.

This site uses Akismet to reduce spam. Learn how your comment data is processed.