DevOps on Cisco Redes

Ansible – Gerenciando erros na playbook

Wed, 04 Jul 2018 00:00:00 +0000

Olá Pessoal,

Hoje venho aqui para trazer mais um ítem para que possamos agregar em nossas implementações de Ansible, e como vocês vêem observando nós temos algumas alternativas para identificar quando houve um erro com o device, ou de alguma forma que executamos algum erro no módulo que estamos escrevendo por falta de um parâmetro, erro na digitação, caminho da pasta apresentada erronêamente, etc.

Pois bem, nós temos algumas formas de contornar esses alarmes, ou demostrar quais equipamentos estão sendo ignorados, para que possamos continuar com a execução do restante de nossa playbook. Para que possamos iniciar, gostaria primeiramente de apresentar a primeira opção que com certeza vai acontecer, é o fato de termos algum problema no preenchimento da planilha ( .csv ), que por sua vez está atrelado a falta de algum valor em alguma coluna desse arquivo.

Desta forma, para testarmos eu acabei excluindo apenas um valor relacionado à coluna do router R1 e R4, com isso podemos apresentar as metodologias para fazer essa tratativa de erros através de termos que são agregados a sua playbook. A forma que podemos trabalhar é de fato trazendo a função ” ignore_errors “, “ fail ” e ” any_errors_fatal “. Se desejar, recomendo também consultar a documentação do Ansible sobre ” Error handling “.

Abaixo vocês vão observar alteração que fiz no arquivo que popula todas as minhas variáveis do ( .csv ) e abaixo a menção sobre o “ ignore_errors ” classificado como “ yes “.

---
- name: GET VARIABLES FROM CSVFILE
  set_fact:
    vars_dict:
        DHCP: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=1 delimiter=,') }}"
        dhcp_exclude1_start: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=2 delimiter=,') }}"
        dhcp_exclude1_end: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=3 delimiter=,') }}"
        dhcp_network: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=4 delimiter=,') }}"
        dhcp_netmask: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=5 delimiter=,') }}"
        dhcp_gateway: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=6 delimiter=,') }}"
        new_hostname: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=7 delimiter=,') }}"
        id_loopback: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=8 delimiter=,') }}"
        ip_loopback: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=9 delimiter=,') }}"
        mask_loopback: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=10 delimiter=,') }}"
        ip_loopback_x: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=11 delimiter=,') }}"
        mask_loopback_x: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=12 delimiter=,') }}"
        ip_loopback_y: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=13 delimiter=,') }}"
        mask_loopback_y: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=14 delimiter=,') }}"
  with_items: "{{ inventory_hostname }}"
  ignore_errors: yes
  tags:
    - always

Após a inserção desse recurso o que iremos fazer é executar nossa playbook e observar o comportamento na execução do código. Como esperado verifico que o status para os dois roteadores está mostrando como ” ignoring “, ou seja, ele acaba excluindo meu erro e continua execução dos meu outros roteadores, ou melhor dizendo, dos meus hosts já populados em nosso arquivo.\

Se obervamos, vamos analisar os erros posteriores da minha playbook, porque é devido as variavéis que deveriam ter sido capturadas anteriormente, porém sem o recurso de ” ignore_errors ” não vemos a mensagem de “ ignoring “, que por consequência vamos observar na finalização que temos nosso contador demostrando como “ failed=1 ” capturados nessa task ( TEMPLATE 881 ).

Então, para que também seja executado nessa task é necessario adicionar ” ignore_errors ” e agora vamos observar novamente a mensagem e automaticamente temos nosso contador “ failed ” zerado.

Caso você tenha necessidade pode-se usar o recurso de ” any_errors_fatal ” como sendo ” True “, que por sua vez, vai demonstrar o erro e popular em nosso contador.

Talvez vocês estejam pensando em que momento poderia utilizar esses métodos, ou seja, um ítem para pensarmos rápido seria em situações que nossos equipamentos populados no inventário estejam ” unreachable ” que por sua vez vai parar toda execução de sua playbook.

Outro ponto interessante, para que possamos armazenar os logs das execuções de nossa playbook, seria habilitar dentro do arquivo ” ansible.cfg ” um caminho para nossos logs, pois em algumas circunstâncias não vamos estar sempre presentes para analisar naquele momento o erro que ocorreu, ou seja, você vai observar os futuros problemas através desse arquivo.

Para isso devemos editar nosso arquivo e adicionar o caminho através do “ log_path ” conforme pode observar abaixo:

Após isso podemos consultar nosso arquivo populado em nosso diretorio e todas as informações salvas baseado em um timestamp.

Obs.: Nesse parâmetro precisamos ficar esperto com o tamanho desse arquivo se for uma task muito longa e com muitos hosts, bem como para ter um significado maior teríamos que popular “ verbose ” no comando ad-hoc do Ansible.

Bom pessoal, espero que tenham gostado dessas dicas e espero alguns comentários e idéias para compartilharmos.

Abs,
Rodrigo

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

Mon, 02 Jul 2018 00:00:00 +0000

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 “.

---
- name: JINJA AND CSVFILE
  hosts: all
  gather_facts: no
  connection: local

  tasks:
  - name: OBTAIN LOGIN CREDENTIALS
    include_vars: secret.yaml
    tags:
      - always

  - name: LOOKUP IN CSV FILE
    include_role:
      name: lookup_csv_info
    when: ./excel/test.csv is defined
    tags:
      - always

  - name: EXECUTE JINJA2
    include_role:
      name: script_jinja2
    tags:
      - 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 “.

---
- name: GET VARIABLES FROM CSVFILE
  set_fact:
    vars_dict:
        DHCP: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=1 delimiter=,') }}"
        dhcp_exclude1_start: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=2 delimiter=,') }}"
        dhcp_exclude1_end: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=3 delimiter=,') }}"
        dhcp_network: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=4 delimiter=,') }}"
        dhcp_netmask: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=5 delimiter=,') }}"
        dhcp_gateway: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=6 delimiter=,') }}"
        new_hostname: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=7 delimiter=,') }}"
        id_loopback: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=8 delimiter=,') }}"
        ip_loopback: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=9 delimiter=,') }}"
        mask_loopback: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=10 delimiter=,') }}"
        ip_loopback_x: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=11 delimiter=,') }}"
        mask_loopback_x: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=12 delimiter=,') }}"
        ip_loopback_y: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=13 delimiter=,') }}"
        mask_loopback_y: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=14 delimiter=,') }}"
  with_items: "{{ inventory_hostname }}"
  tags:
    - 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.

---
- name: TEMPLATE 881
  template:
    src: ./template/script.j2
    dest: ./template/configuration/script_{{ inventory_hostname }}.conf
  with_items: "{{ inventory_hostname }}"
  tags:
    - router881

- name: TEMPLATE 1941
  template:
    src: ./template/script_1941.j2
    dest: ./template/configuration/script_{{ inventory_hostname }}.conf
  with_items: "{{ inventory_hostname }}"
  tags:
    - router1941

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

Ansible – Script Configuração usando Jinja2 – Parte 2

Tue, 13 Mar 2018 00:00:00 +0000

Olá Pessoal,

Vamos continuar nossas explicações sobre as configurações ( scripts ) que podemos fazer através de uma base externa ( csv ) que iniciamos em nosso post anterior.

Muitas pessoas mencionaram que de fato isso poderia ser feito através de um arquivo ( yaml ) ou propriamente sendo populado através de outra metodologia via ( group_vars ). Concordo, mas lembre-se, que eu havia mencionado que baseado em nossa estrutura de pastas vocês vão entender até nosso ultimo post as opções que teremos para trabalhar dessa forma.

Como proposto vou trazer nossa variável ” vars_dict ” para nossa pasta ( group_vars/all.yml ) adicionando ela dentro de outra variável ( vars_from_csv ), para que de fato possamos utiliza-lá fazendo referências dentro de nosso script de configuração.

---
vars_from_csv: "{{ vars_dict }}"

Como demostrado nesse momento já temos todos os nossos valores ( variáveis ) populadas, portanto, precisamos executar agora nosso template que irá capturar essas variáveis para inserir em nosso arquivo de configuração.

Dentro desse conceito “ DEVOPS “, bem como para utilização com Ansible, umas das linguagens mais utilizadas para essas demandas é chamada de JINJA2. Se vocês observarem a documentação ela também é utilizada como template para Python, portanto, desta forma você pode entender o porque da utilização nesse mundo de automação.

Sua documentação é bem extensa, mas gostaria de deixar documentado em nosso BLOG os principais ítens, que nesse primeiro momento seria para criar nosso arquivo de configuração. Eles estão relacionados aos loops e variáveis que temos que criar para utilizar em nossos equipamentos.

{% … %} for Statements

{{ … }} for Expressions to print to the template output

{# … #} for Comments not included in the template output

… ## for Line Statements

Para execução de nosso template iremos adicionar em nossa playbook inicial uma ” role ” relacionado as tarefas que iremos executar para obter o jinja ( .j2 ).

---
- name: JINJA AND CSVFILE
  hosts: all
  gather_facts: no
  connection: local

  tasks:
  - name: OBTAIN LOGIN CREDENTIALS
    include_vars: secret.yaml

  - name: LOOKUP IN CSV FILE
    include_role:
      name: lookup_csv_info
    when: ./excel/test.csv is defined

  - name: EXECUTE JINJA2
    include_role:
      name: script_jinja2

Após esse processo vamos construir nossa task via ” template “, onde nosso arquivo de origem será ( .j2 ) transformando ele um arquivo destino ( .conf ) que será posteriormente arquivo para executar em nossos equipamentos da infra-estrutura. Segue task do template:

---
- name: TEMPLATE
  template:
    src: ./template/script.j2
    dest: ./template/configuration/script_{{ inventory_hostname }}.conf
  with_items: "{{ inventory_hostname }}"

Como observado precisamos agora ter nosso ” script.j2 ” construido, onde será ele o criador da configuração utilizando nossas variáveis capturadas anteriormente.

!
hostname {{ vars_from_csv.new_hostname }}
!
{% if vars_from_csv.DHCP == 'true' %}
no ip dhcp conflict logging
ip dhcp excluded-address {{vars_from_csv.dhcp_exclude1_start}} {{vars_from_csv.dhcp_exclude1_end}}
!
ip dhcp pool POOL1
   network {{vars_from_csv.dhcp_network}} {{vars_from_csv.dhcp_netmask}}
   default-router {{vars_from_csv.dhcp_gateway}}
   dns-server 8.8.8.8 8.8.4.4
{% endif %}
!
interface loopback {{ vars_from_csv.id_loopback }}
 description + Management +
 ip address {{ vars_from_csv.ip_loopback }} {{ vars_from_csv.mask_loopback }}
 no shutdown
!

De fato o que podemos entender com essa metodologia é que podemos fazer ” loops ” e a utilização de condicionais “ if ” para que se tivermos um valor ( ” true/false ” ou ” 1/0 “ ) eu posso tomar algumas decisões nessa configuração. Observem que estou colocando como exemplo a variável “ DHCP ” sendo verdadeira ( ” true ” ), que por consequência eu preciso implementar o DHCP, caso contrário eu não desejo implementar esse recurso em meus roteadores.

Com isso conseguimos observar que as alterações foram executadas utilizando nosso script.

Para garantirmos que foi executado correto vamos observar nossos arquivos de configuração, criados para cada roteador.


Configuração do Roteador 1	Configuração do Roteador 2
! hostname R1_floor1 ! no ip dhcp conflict logging ip dhcp excluded-address 1.1.1.9 1.1.1.10 ! ip dhcp pool POOL1 network 1.1.1.8 255.255.255.248 default-router 1.1.1.1 dns-server 8.8.8.8 8.8.4.4 ! interface loopback 10 description + Management + ip address 10.10.10.1 255.255.255.255 no shutdown !	! hostname R2_floor1 ! ! interface loopback 10 description + Management + ip address 10.10.10.1 255.255.255.255 no shutdown !

Vale lembrar, que não estou fazendo o acesso aos equipamento para descarregar as informações ( scripts ), pois não tenho todo esse inventário emulado nesse momento para inserir todos os roteadores. Caso tenha necessidade pode observar em nossos posts anteriores, mas a forma para implementar nos equipamentos seria adicionar essa task em nossa playbook ( ./script_jinja2/tasks/main.yaml ).

- name: Execute Script
  ios_config:
    provider: "{{ creds }}"
    src: ./template/configuration/script_{{ inventory_hostname }}.conf
  with_items: "{{ inventory_hostname }}"

Talvez vocês devem estar se perguntando onde está o ” loop ” da configuração. Exato, ele vai ser adicionado em nosso próximo post. 💡

Espero que vocês tenha gostado e deixem seus comentários.

Abs,
Rodrigo

Ansible – Configuração via CSV File – Parte 1

Thu, 08 Mar 2018 00:00:00 +0000

Olá Pessoal,

Dando sequência as nossas publicações sobre Ansible, e como já comentei com vocês que estou pegando alguns exemplos que de fato são situações que nós Engenheiros de Rede acaba vivenciado para executar esse tipo de trabalho em nosso dia a dia, ou seja, venho com a pergunta. Vocês já receberam aquele Excel ( .csv ), para de fato fazer algumas alterações em seus equipamentos?

Se sim, acredito que você está no caminho correto, pois hoje, venho com mais um exemplo que vamos fazer as preparações para tratar nossos dados e posteriormente criar nossos arquivos de configuração que serão aplicados em nossos equipamentos Cisco ( IOS ).

Vale lembrar, para que seja efetivo nossa Automação precisamos ter um inventário consolidado, onde as informações relacionadas ao nossos equipamentos devem ser coerentes para futuro crescimento de nossa infra-estrutura. Se você ainda não acompanhou os posts anteriores, recomenda-se ler esses tópicos sobre Ansible.

Como vocês podem observar vamos tratar nossos dados via um arquivo ( .csv ), que de alguma forma são valores/informações populadas através de outras fontes ( ferramentas, pessoas, etc ). Em nosso exemplo, estou colocando diversas informações que a principio vocês possam não entender, mas no decorrer de nossos posts isso fará sentido para o entendimento correto e as opções que podemos criar em nossa automação.

inventory_hostname,DHCP,dhcp_exclude1_start,dhcp_exclude1_end,dhcp_network,dhcp_netmask,dhcp_gateway,new_hostname,id_loopback,ip_loopback,mask_loopback
R1,true,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R1_floor1,10,10.10.10.1,255.255.255.255
R2,false,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R2_floor1,10,10.10.10.1,255.255.255.255
R3,false,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R3_floor1,10,10.10.10.1,255.255.255.255
R4,false,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R4_floor1,10,10.10.10.1,255.255.255.255
R31,true,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R31_floor1,10,10.10.10.1,255.255.255.255
R32,true,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R32_floor1,10,10.10.10.1,255.255.255.255
R5,false,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R5_floor1,10,10.10.10.1,255.255.255.255
R6,true,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R6_floor1,10,10.10.10.1,255.255.255.255

Como vocês podem observar isso são exemplos e vocês podem adaptar conforme sua necessidade e as solicitações que são exigidas pelas diferentes áreas de sua empresa. Todo o desenvolvimento de nossa automação também é muito co-relacionada com a estrutura de pastas e arquivos que vamos utilizar dentro do Ansible, portanto segue a estrutura que estou utilizando para esse exemplo.

Uma outra informação diferente dos exemplos citados em nossos posts sobre Ansible, é que estou criando como fictício todos esses roteadores em nosso arquivo de inventário ( ./hosts ), para que nosso exemplo seja mais robusto e obviamente no final de nosso exemplo irei demonstrar como aplicar as configurações. Segue meu inventário criado para esse exemplo:

[routers-client]
R1 ansible_host=192.168.0.22
R2 ansible_host=192.168.0.23
R31 ansible_host=192.168.0.24
R5 ansible_host=192.168.0.25
R6 ansible_host=192.168.0.26

Tendo como base essas informações vamos trabalhar com um módulo que Ansible oferece que é de executar um “ lookup ” dentro de um arquivo ( .csv ). Para que nosso código seja mais estruturado minha playbook principal irá chamar minha “ role ” definida como ( ./lookup_csv_info.yaml ).

---
- name: JINJA AND CSVFILE
  hosts: all
  gather_facts: no
  connection: local

  tasks:
  - name: OBTAIN LOGIN CREDENTIALS
    include_vars: secret.yaml

  - name: LOOKUP IN CSV FILE
    include_role:
      name: lookup_csv_info
    when: ./excel/test.csv is defined

Talvez vocês devem estar se perguntando o porque utilizar “ roles ” dentro desse código? De fato a funcionalidade role é muito utilizada no sentido de trazer mais dinamismo, funcionalidade e flexibilidade para seu código, pois eles podem se tornar difíceis de gerenciar e difíceis de manter com um único arquivo. As roles permitem que você crie playbooks mínimas que, em seguida, busque uma estrutura de diretório para determinar as etapas de configurações reais que precisam executar, bem como proceder para as próximas roles se anterior foi executada/validada da forma correta.

Seguindo essa linha de raciocínio, demostro agora a playbook específica que irá pesquisar todas as informações dentro de nosso arquivo ( .csv ). Ressalto, que em nosso arquivo temos mais informações do que de fato existem ( hostnames ) nosso arquivo de ( ./hosts ), ou seja, estamos pesquisando em nossa planilha se existem elementos que coincidem com nosso inventário.

---
- name: GET VARIABLES FROM CSVFILE
  set_fact:
    vars_dict:
        DHCP: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=1 delimiter=,') }}"
        dhcp_exclude1_start: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=2 delimiter=,') }}"
        dhcp_exclude1_end: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=3 delimiter=,') }}"
        dhcp_network: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=4 delimiter=,') }}"
        dhcp_netmask: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=5 delimiter=,') }}"
        dhcp_gateway: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=6 delimiter=,') }}"
        new_hostname: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=7 delimiter=,') }}"
        id_loopback: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=8 delimiter=,') }}"
        ip_loopback: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=9 delimiter=,') }}"
        mask_loopback: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=10 delimiter=,') }}"
  with_items: "{{ inventory_hostname }}"

Para que possamos ver que as informações estão sendo capturadas vamos colocar uma task contendo debug de uma variável para observar o comportamento. Essa variável em nosso caso é ” var_dict ” onde se tem todo o ” dicionário ” com os valores populados de cada elemento. Para adicionar essa validação foi inserido o comando:

  - debug: var={{'vars_dict'}}

Desta forma temos esse output e a confirmação que os dados estão sendo populados corretamente.

Acredito que vocês observaram que temos todos os elementos que foram lidos/capturados baseado em cada coluna de nosso arquivo ( .csv ) comparado ao nosso inventário em uma única “ task “. Porquê?

Isso está relacionado justamente com ” loops ” que podemos criar dentro de nossas “ tasks “, fazendo com que ele faça a mesma tarefa diversas vezes baseado no requisito que estamos utilizando. Para nosso exemplo estou usando a variável “ {{ inventory_hostname }} “, justamente para que ela pesquise no arquivo todos os roteadores expostos no arquivo ( ./hosts ). Essa função pode ser observada através do ” with_items: “.

Espero que vocês tenham gostado e no próximo post vou detalhar como trabalhar com esse dados.

Abs,
Rodrigo

Ansible – Instalar SSH usando processo de automação

Thu, 21 Dec 2017 00:00:00 +0000

Olá Pessoal,

Já faz um bom tempo que não escrevo aqui no BLOG, mas tudo isso é devido outras tarefas que estão tomando também um certo tempo ( recertificação CCIE, estudos DevOps, projetos particulares, aulas, treinamentos, etc ). Enfim, hoje venho aqui trazer uma situação real que acredito que diversos leitores de nosso canal podem vivenciar em sua infra-estrutura e de alguma forma já fizeram esse questionamento quando começei aqui explicar sobre Ansible 💡 . Você pode conferir nossos posts sobre Ansible aqui.

De fato, vocês observaram que a todo momento o que implementamos usando essa ferramenta foi utilizando o processo de acesso remoto a nossos equipamentos, é claro, executando as operações necessarias via CLI. Mas qual é esse acesso remoto? **SSH.

Pois bem, se observarmos todos os módulos para Networking os acessos aos equipamentos é feito pela biblioteca ” Paramiko “, e antes da versão 2.4 do Ansible não tinhamos nenhum módulo para utilizarmos os acessos via Telnet. Devido a isso, foi criado na versão 2.4.0 um módulo para que pudessemos avaliar os equipamentos ou executar algum comando ( CLI ) pelo acesso via Telnet. Esse módulo você pode conferir através desse link ( Telnet no Ansible ).

Baseado nesses fatos, a ideia é acessar os equipamento via telnet, implementar script para habilitar o SSH, e após essa configuração toda a nossa infra-estrutura já estaria apta para utilizar-se de uma metodologia de maior segurança para acesso remoto aos equipamentos e pronto para trabalharmos com qualquer outro módulo disponível dentro da estrutura do Ansible. O que posso dizer é, mais ou menos!!!

Como estamos pensando em automação vamos pontuar os ítens para que isso seja efetivo:

Acessar o equipamento via telnet.
Verificar se o equipamento tem o ssh habilitado.
Qual a versão implementada do SSH.
Caso negativo, devemos instalar o script para acesso via SSH e importar a chave SSH para o host remoto da gerência para evitarmos as perguntas se queremos aceitar a chave em nosso primeiro acesso.
Caso positivo, devemos importar a chave SSH para o host remoto da gerência para evitarmos as perguntas se queremos aceitar a chave em nosso primeiro acesso.

As dificuldades encontradas com o módulo telnet do Ansible é de fato capturar alguns logs ( utilizar pipe ) e fazer as tratativas dos outputs para obter somente o necessário, então o desafio foi encontrar biblioteca para usarmos nesta demanda. Depois de avaliar diferentes caminhos/testes e pedir ajuda à grupo discussão no SLACK Networktocode ( onde indico para todos com intuito adquirir experiências com essas pessoas, e claro, de uma comunidade que de fato ajuda muito nas dúvidas e idéias para desenvolvermos nossas soluções ), verifiquei poderíamos trabalhar com a biblioteca ” ntc-ansible “, pois ela já oferece o acesso via telnet e temos diversos outputs ” show commands ” formatados JSON ” JavaScript Object Notation “, onde a comunidade executou via TextFSM, trazendo assim esse ” array ” para ficar de fato mais pratico a consulta de nossos outputs. Mas, nossa vida não é fácil, pois esse comando que é necessario em minha playbook não tinhamos pronto, porém não foi impactante devido a conseguir executar os filtros e capturar o output essencial do comando.

Para nossa estrutura de arquivos e pastas eu desenvolvi desta forma.

Vocês podem observar que temos uma estrutura de ” roles “, ” templates ” e ” output ” onde a principal pasta para corresponder a nossa playbook estaria dentro de roles, desta forma podemos fazer nossas validações ” conditionals ” na playbook e trabalhar baseado nos outputs/status para as execuções das tarefas posteriores. Nosso arquivo raiz para iniciar implementação estaria em ” ssh_config.yaml “.

---
- name: INSTALL SSH IN CISCO DEVICES
  hosts: routers-client
  gather_facts: no
  connection: local
  vars:
    template_dir: /home/rodrigo/Documents/ansible/ntc-ansible/ntc-templates/templates/

  tasks:
  - name: OBTAIN LOGIN CREDENTIALS
    include_vars: secret.yaml

  - name: INCLUDE SSH ENABLE ROLE
    include_role:
      name: ensure_ssh_enabled

  - name: INCLUDE SSH KEY ON THE PATH .ssh/known_hosts
    include_role:
      name: get_ssh_key

Como podem observar a primeira validação é garantir se temos implementado o SSH, e caso negativo, iremos fazer a implementação de nosso script. Dentro da estrutura de roles podemos ter diversos arquivos denominados com o mesmo nome, porém ele sempre irá buscar o arquivo main.yaml que é a base de nossa role.

---
- name: ACCESS BY TELNET
  ntc_show_command:
      connection: telnet
      platform: cisco_ios
      template_dir: "{{ template_dir }}"
      command: "{{ item }}"
      host: "{{ inventory_hostname }}"
      username: "{{ creds['username'] }}"
      password: "{{ creds['password'] }}"
      secret: "{{ creds['auth_pass'] }}"
  with_items:
      - show ip ssh | include SSH Enabled - version 2
  register: ssh_telnet

- name: ENABLE SSH IF REQUIRED
  include_tasks: enable_ssh.yaml
  when: "ssh_telnet.results.0.response.0 != 'SSH Enabled - version 2.0'"

Para ficar mais claro vocês podem observar no debug ( via ah-hoc command ” -vvv ” ) output sendo demostrado com valor essencial para validar via condição ( when ) de qualquer coisa que seja diferente de versão 2 , então ele irá chamar nossa próxima task para implementar nosso script.

PS.: Nessa execução o valor é o mesmo comparado portando ele esta executando o ” skipping “

Em nossa próxima task temos novamente o acesso sendo executado via telnet e a implementação dos comandos necessário para subirmos o protocolo SSH, liberando assim esse equipamento para seus devidos fins.

---
- name: INSTALL SSH TEMPLATE
  ntc_config_command:
      connection: telnet
      platform: cisco_ios
      host: "{{ inventory_hostname }}"
      username: "{{ creds['username'] }}"
      password: "{{ creds['password'] }}"
      secret: "{{ creds['auth_pass'] }}"
      commands_file: "/home/rodrigo/Documents/ansible/IWAN Project/ssh_installation_by_telnet/template/ssh_configuration.txt"

Após toda essa validação e configuração ( se necessario ) nós precisamos fazer com que nosso host tenha essa chave inserida em seu arquivo de controle ( ~/.ssh/known_hosts ) para que ele não faça essa pergunta chata quando for acessar pela primeira vez seu equipamento.

Para isso, iremos ter nossa próxima role para trazer essas validações e inserções dentro do arquivo necessário. Após chamar role ” get_ssh_key ” iremos novamente ter nosso arquivo main.yaml sendo executado e nele iremos tratar as informações.

---
- name: ACCESS BY TELNET
  ntc_show_command:
      connection: telnet
      platform: cisco_ios
      template_dir: "{{ template_dir }}"
      command: "{{ item }}"
      host: "{{ inventory_hostname }}"
      username: "{{ creds['username'] }}"
      password: "{{ creds['password'] }}"
      secret: "{{ creds['auth_pass'] }}"
  with_items:
      - show ip ssh | begin ^ssh-rsa
  register: ssh_key

- name: Save output in variable related inline command
  set_fact: myvar="{{ ssh_key.results.0.response.0 }}"
  when: ssh_key is defined

- name: Replace space inside myvar
  set_fact:
    clean: "{{ myvar.replace('\n','') }}"
  when: ssh_key is defined

- name: ADD KEY INSIDE LOCALHOST OF SSH CONNECTION
  lineinfile:
    path: ~/.ssh/fake_hosts
    state: present
    line: "{{ inventory_hostname }} {{ clean }}"
    insertafter: EOF
  when: ssh_key is defined

Um dos problemas enfrentados nesse tópico foi justamente a comparação da chave existente com o fato de possívelmente eu já ter essa chave inserida em seu arquivo de hosts, portanto dependendo de sua infra-estrutura essas informações poderiam ficar duplicadas e também a cada execução ele salvar a mesma chave em seu arquivo. Para validação no arquivo temos um módulo muito interessante chamado ” lineinfile ” que de fato ele pesquisa no arquivo se temos essa informação, caso negativo, ele insere o que foi solicitado. Como dito o problema sobre a inserção toda vez que executava a playbook ficava atrelado algum espaço ( \n ) que ele tinha do output ficando interpretável para o modulo lineinfile, com isso precisou ser feito um ” replace ” desses espaços para que pudesse comparar minha variável com o arquivo.

PS.: Vocês vão observar que criei um arquivo ” fake_hosts ” justamente para que você não fique testando dentro de seu arquivo de produção e de alguma forma possa impactar aquilo que esta funcionado, portanto criei o arquivo para você validar os seus passos e analisar se esta sendo executado da maneira correta, pois no momento de rodar talvez em cima de 100, 300 devices o rollback pode ficar complicado. ( rsrs )

Vamos partir do principio que não temos nada instalado em nosso equipamento e a configuração que será implementado é conforme abaixo.

!
username ssh privilege 15 password 0 sshansible
!
ip domain-name cisco.com
!
crypto key generate rsa modulus 2048
!
ip ssh version 2
ip ssh source-interface g3
ip ssh time-out 5
!
line vty 0 4
 login local
 transport input all
!

Abaixo você pode conferir que removi toda a configuração de ssh e deletei no meu arquivo de teste para garantir que não temos nada populado.

Com isso, em nosso próximo output você poderá observar que de fato não consigo fazer nenhum acesso SSH, e após execução de nossa playbook ( capturando duas changes ) temos de fato implementado nosso script e chave inserida. O erro mencionado abaixo em meu detalhamento refere-se ao fato de eu não ter salvo nossa chave SSH no arquivo correto, devido ao que foi comentando logo acima.

Para garantir podemos acessar nosso equipamento e consolidar as informações relacionados ao script implementado, bem como, adicionei um novo usuario.

Validando nosso arquivo ” fake_hosts ” para garantir que temos a mesma chave inserida no arquivo e comparado ao nosso equipamento.\

Vale lembrar que, o foi adicionado em nosso arquivo de ” known_hosts ” é o hostname, portanto se você acessa seus equipamentos pelo nome ele terá essa menção adicionado no arquivo, porém se o DNS não resolver esse nome você terá que acessar pelo endereço IP e que nesse caso não é a mesma informação que populamos em nosso arquivo de “ known_hosts “, sendo assim ele irá questionar para adicionar sua chave.

Logo abaixo, coloco alguns exemplo para garantir o correto funcionamento, colocando hipóteses de alguns itens que podemos obter durante a implementação que diversos hosts.

Nesse caso foi removido apenas ” no ip ssh version 2 ” para que possamos implementar o script, mas não inserir chaves duplicadas em nosso arquivo.

Declaro que esse post ficou bem grande, porém quis demonstrar todas as possibilidades colocando os outputs e anuências que foram vivenciadas até o desenvolvimento dessa automação.

Espero que vocês tenham gostado e de fato ajude de alguma forma a solucionar problemas vivenciados em seu dia a dia. Fique a vontade de compartilhar esse artigo e de colocar mais sugestões ou melhorias para essa estrutura.

Esses códigos estão disponivéis também no meu Github. 😛

Abs,
Rodrigo

Ansible – Módulo Networking

Fri, 24 Nov 2017 00:00:00 +0000

Olá Pessoal,

Acredito que vocês vêem acompanhando sobre os posts que estou descrevendo sobre essa nova tecnologia de ” DevOps ” para qual estou me atualizando baseado em Ansible.

Devido a isso gostaria de divulgar algumas informações adicionais para vocês que também estão se interessando nesse tópico, trazendo assim um histórico para nosso BLOG sobre essa comunidade que está crescendo e principalmente os módulos de networking está tendo uma visbilidade muito importante não somente da RedHat, mas em relação também as vendors de oferecerem essas facilidades para comunidade.

Com isso, gostaria de agregar aquilo que já comentei em nosso 3 post sobre o módulo de networking, bem como agora podemos acompanhar evolução ( roadmap ) das novas versão que estão para chegar. Aqui são slides que capturei para apresentar para vocês, porém se desejam ver na integra temos o Ansible Webinar Networking.

Abs,
Rodrigo

Ansible – Validação de Configuração – Parte 3

Mon, 30 Oct 2017 00:00:00 +0000

Olá Pessoal,

Seguindo em nossos posts, continuamos trabalhando para fazer nossas comparações entre as configurações que estão aplicadas em nosso ambiente. Hoje vamos tratar sobre a validação do módulo ” startup-config “.

Como vocês observaram anteriormente, sempre estavamos validando situações onde iríamos comparar arquivos ( scripts ) que poderiam ser aplicados em nossos equipamentos ou validados no sentido de possíveis alterações que de fato não se equipara com nossa base ( backup ).

Logo abaixo, iremos fazer uma validação simples entre “ startup-config ” com a ” running-config “, com isso temos outro motivo para possíveis troubleshooting identificar rapidamente se algo foi alterado, e se de fato essa alteração foi feita da maneira correta, sempre lembrando-se que, essas alterações podem aparecer desde que ainda não foram salvas na NVRAM. Abaixo temos o script:

---
- hosts: all
  connection: local
  gather_facts: no

  tasks:
  - name: OBTAIN LOGIN CREDENTIALS
    include_vars: secret.yaml

  - name: Fill vars
    set_fact:
      provider:
        host: "{{ ansible_host }}"
        username: "{{ creds['username'] }}"
        password: "{{ creds['password'] }}"
        auth_pass: "{{ creds['auth_pass'] }}"

  - name: Compare startup-config with running-config
    ios_config:
      diff_against: startup
      provider: "{{ provider }}"
    register: test_diff

  - name: Take startup-config and sets it to a variable called *before*
    set_fact: before="{{ test_diff['diff']['before'].split('\n')}}"
    when: test_diff['diff'] is defined

  - name: This takes the running_config and sets it to a variable called *after*
    set_fact: after="{{ test_diff['diff']['after'].split('\n')}}"
    when: test_diff['diff'] is defined

  - name: Create a line-to-line diff of running-config to startup_config
    set_fact: difference="{{ after | difference(before) }}"
    when: test_diff['diff'] is defined

  - name: sanitized output "Lines added to running-config that are not present in startup_config"
    debug:
      var: difference
    when: test_diff['diff'] is defined

Vale ressaltar que utilizamos a mesma técnica já explicada anteriormente, onde temos que “ sanitizar ” as diferenças para que de fato tenhamos a saída mais ” clean ” possível, e claro de fácil visualização. No primeiro momento, como vocês vão perceber apenas executei nossa playbook para demonstrar que de fato meu equipamento foi ligado e permanece com a mesma configuração.

A mensangem ” skipping ” é justamente para mencionar que nossa variável esta ” zerada ” e que essa tarefa está sendo pulada para as tarefas seguintes. Segue abaixo:

Agora, como já temos tudo garantido, vamos novamente fazer uma alteração em nosso roteador relacionado a um novo usuário, e claro, não vamos salvar em nossa NVRAM.

Feito isso, agora esperamos que após execução da playbook iremos visualizar que nosso novo usuário foi inserido na ” running-config “. Segue abaixo o output trazendo assim a linha adicional:

Com isso, finalizamos nossas 3 opções de validação de configuração, para qual pode atender diversas opções dentro de nosso ambiente de produção ou mesmo de futuros laboratórios. Pensando assim, vendo nossas demonstrações você avalia que isso de fato pode automatizar algum processo que hoje você precisa executar manualmente ou não consiga gerenciar suas configurações de equipamentos? O que seria mais interessante?

PS.: Vale lembrar novamente que estamos executando somente em um roteador, porém isso, pode ser escalável a muitos equipamentos, apenas alterando nosso arquivo de hosts.

Deixe seus comentários.

Abs,
Rodrigo

Ansible – Validação de Configurações

Mon, 23 Oct 2017 00:00:00 +0000

Olá Pessoal,

Enfim, depois de um longo periodo voltamos para trazer mais tópicos sobre nossa estrutura de DevOps utilizando Ansible. Acredito que algumas pessoas devem ter visto que a RedHat fez anúncio sobre atualização do Ansible para a versão 2.4, e se observarem o módulo de networking foi o que teve a maior quantidade de release, portanto podemos observar que o projeto e a comunidade esta empenhanda em trazer mais beneficios para nossa área. Segue a menção explicada pelo engenheiro do modulo de networking da RedHat

Para critério de equiparação eu já fiz atualização para a nova versão, pois nossos exemplos e laboratórios já estão com os novos módulos. Segue a versão que estamos trabalhando nesse momento.

root@ubuntu:/home/rodrigo# ansible –version ansible 2.4.0.0 config file = /etc/ansible/ansible.cfg configured module search path = [u’/root/.ansible/plugins/modules’, u’/usr/share/ansible/plugins/modules’] ansible python module location = /usr/lib/python2.7/dist-packages/ansible executable location = /usr/bin/ansible python version = 2.7.12 (default, Nov 19 2016, 06:48:10) [GCC 5.4.0 20160609]

Como estamos trabalhando em exemplos sobre backups de configuração, historico de configuração, neste post vou trazer algumas funcionalidades que temos agora para comparar nossas configurações e obter outputs que podem trazer beneficios em nosso dia a dia. O módulo voltado para Cisco, onde iremos trabalhar seria “ ios_config “, que por sua vez, teve algumas alterações nessa nova edição. Para contextualizar, existem algumas possibilidades que dependendo do seu ambiente podem-se enquadrar de uma forma diferente, portanto, para nosso caso eu irei criar um arquivo ( .conf ) que iremos apenas adicionar usuários para que possamos comparar nossas configurações. Segue exemplo de meu arquivo:

!
username R1 privilege 15 password 0 rodrigo3
username teste2 privilege 15 password 0 rodrigo3
username teste12 privilege 15 password 0 teste
!
!

PS.: Não é obrigatório a criação do arquivo como sendo ( .conf ), ele pode ser como texto e utilizar a estrutura que você tem em seu ambiente.

Após a criação de nosso arquivo base, iremos construir nosso playbook para que possamos fazer as comparações das configurações. Neste primeiro exemplo, iremos fazer a comparação da ” running-config ” com o arquivo base, e assim output que irá trazer em nossa variavél será a diferença entre os dois arquivos.

---
- hosts: all
  connection: local
  gather_facts: no

  tasks:
  - name: OBTAIN LOGIN CREDENTIALS
    include_vars: secret.yaml

  - name: Fill vars
    set_fact:
      provider:
        host: "{{ ansible_host }}"
        username: "{{ creds['username'] }}"
        password: "{{ creds['password'] }}"
        auth_pass: "{{ creds['auth_pass'] }}"

  - name: Compare running-config with base file
    ios_config:
      diff_against: running
      provider: "{{ provider }}"
      src: /home/rodrigo/Documents/ansible/input/{{ inventory_hostname }}.conf
    register: test_diff

  - debug: var=test_diff.updates

Com isso, podemos agora fazer nossa validação através de nosso playbook utilizando comando ad-hoc ( –check ). Vale lembrar que o “check” não irá popular nenhuma configuração em seu equipamento.

Assim podemos comparar com nossa configuração apresentada em nosso roteador que os usuários não estão presentes em nossa configuração ( running-config ), entretanto vocês podem observar que temos um usuario ( rodrigo ) que o mesmo não foi demostrado em nosso output. Porque?

Isso ocorre porque a validação que é feita é somente a comparação do R1.conf com a running-config, trazendo assim somentes as diferenças ( check ) do que temos na configuração base com o que está no roteador ( running-config ), e não o inverso. Teremos outras funções para que essa diferença também seja apresentada.

Devido a este ponto, para os próximos posts irei trazer mais validações usando essa nova funcionalidade ( diff_against ).

Abs,
Rodrigo

Ansible – Notificação BOT Telegram

Mon, 04 Sep 2017 00:00:00 +0000

Olá Pessoal,

Seguindo nossa sequência sobre Ansible, hoje gostaria de trazer um adendo que estaria envolvido simplesmente em criar uma notificação que poderá ser exibida no Telegram, através de nossos famosos e tão comentado BOTs.

Para que todo esse processo funcione, você terá a necessidade de criar um BOT simples pelo Telegram, para isso você pode interagir com nosso amigo @BotFather. Se necessitar de mais informações sobre os procedimentos para criação desse BOT, recomendo que pesquise nesse link, na pagina do Telegram.

Em nossos testes eu criei meu BOT e vou utiliza-lo para fazer as notificações para uma sala de teste, no intuito de inserir meu BOT para visualizar as notificações.

Seguindo com nossas configurações, irei utilizar o mesmo exemplo que já estamos trabalhando, porém vou agregar mais um arquivo no projeto, denominado como telegram.yaml

---
  - name: Send test message
    telegram:
        token: bot000:xxxx
        chat_id: -yyyy
        msg: Ansible playbook executed

Como podem observar eu omiti algumas informações de nosso exemplo devido a ser referenciado ao meu token e ID de BOT, portanto a partir de seu BOT essas informações vocês devem alterar olhando especificamente em seu BOT.

Um dos motivos mais difíceis para conseguir funcionar essa notificação através do BOT, foi conseguir adquirir esse chat_id, que com exclusividade vou detalhar um pouco de que forma facilitar sua vida.

Como exemplo o nome do BOT seria rodrigo_bot

Você deve inserir seu BOT em um grupo
Você precisa enviar uma mensagem em seu grupo para seu BOT
1. Neste caso você deve fazer /my_id @rodrigo_bot ( Eu tentei diversas mensagens, mas a única que trouxe a informação foi utilizando /my_id )
Em seu browser você deve colocarhttps://api.telegram.org/botXXX:YYYY/getUpdates ( lembre-se de trocar as variáveis citadas pelo token de seu BOT )
Após a resposta você deve procurar pelo campo ,“chat”:{“id”:-xxxxxx
BINGO!!!! 😆

Enfim, agora você pode utilizar as informações para preencher em seu arquivo do Ansible ( telegram.yaml ). Se quiser fazer um teste antes para validar sobre o chat-id o telegram aceita notificação via CURL. Esse comando é aceito no Linux ( curl -X POST “https://api.telegram.org/botxxx:yyyyy/sendMessage” -d “chat_id=-wwwww&text=my sample text” ), lembrando-se que para funcionar você precisa anexar suas informações de token e chat_id.

Para que possamos finalizar eu chamei através de nosso arquivo principal ( backup_router.yaml ) nossa notificação na sala de bate papo.

---
- name: Configuration Backup in Cisco Devices
  hosts: routers
  gather_facts: no
  connection: local

  tasks:
  - name: OBTAIN LOGIN CREDENTIALS
    include_vars: secret.yaml

  - name: Define access
    set_fact:
      provider:
        host: "{{ ansible_host }}"
        username: "{{ creds['username'] }}"
        password: "{{ creds['password'] }}"
        auth_pass: "{{ creds['auth_pass'] }}"

  - name: Obtain commands
    include: commands_variance.yaml

  - name: Obtain Telegram
    include: telegram.yaml

Segue a execução de nossa playbook. Nesse caso chamei duas mensagens para popular mais opções para você.

Após a execução podemos consultar em nossa sala de bate papo nossa mensagem populada.

Espero que tenham gostado e nossa próxima integração será através de outra ferramenta de messaging. Aguardem!!!

Abs,
Rodrigo

Ansible – Rodar um Grupo de seu Inventário

Mon, 21 Aug 2017 00:00:00 +0000

Olá Pessoal,

Detalhando um pouco mais sobre nossa estrutura do Ansible, gostaria de trazer hoje algumas facilidades que podemos executar através de um recurso chamado ” Ad-Hoc commands “, onde caracteriza que podemos passar variáveis, limitar host, executar module, etc, através de nossa própria execução do playbook.

Neste exemplo, o que vou trazer de dica é que, a partir do momento que temos um lista grande hosts ( inventário ) em algum determinado momento acredito que, não queremos obter as informações de todos que estão presentes nesta lista, por isso podemos trazer limitações de quais hosts iremos executar nossas task. Como podem observar abaixo, fiz alteração em nosso arquivo de ( hosts ) adicionando mais equipamentos e trazendo grupos distintos de equipamentos ( routers e switches ). Para maiores detalhes dos comandos ad-hoc veja no site da documentação.

Vale lembrar que, em nossa simulação até o momento não temos esses equipamentos adicionais, foi mais pela questão demonstrar sobre quais os grupos, equipamentos estamos trazendo nesse post.

[routers]
R1 ansible_host=192.168.0.19
R33 ansible_host=192.168.0.21

[switches]
SW1 ansible_host=192.168.0.20

Devido a termos as segmentações de equipamentos fiz alteração em nosso arquivo abaixo, chamando na função ” hosts ” ambos os grupos, mas isso não é um ítem obrigatório, pois iremos chamar nossas funções via parâmetro na execução de nossa playbook.

---
- name: Acesso remoto aos equipamentos
  hosts: routers, switches
  gather_facts: no
  connection: local

  tasks:
  - name: OBTAIN LOGIN CREDENTIALS
    include_vars: secret.yaml

  - name: Define access
    set_fact:
      provider:
        host: "{{ ansible_host }}"
        username: "{{ creds['username'] }}"
        password: "{{ creds['password'] }}"
        auth_pass: "{{ creds['auth_pass'] }}"

  - name: Obtain commands
    include: commands_variance.yaml

Após essa alteração vamos executar nosso playbook, porém iremos adicionar um comando adicional ( –limit “routers” ), que por sua vez irá executar nossas tarefas em todos os routers definidos anteriormente. Segue em detalhe em nosso quadro azul.

Após essa menção detalho que estamos agora chamando nosso próximo grupo.

Logo abaixo faço uma pequena alteração, chamando agora especificamente um hosts que está dentro de um grupo de equipamentos, fazendo com que eu possa executar as tasks sem executar as tarefas em qualquer outro equipamentos que esteja em nossa lista de inventário.

Espero que vocês tenham gostado.

Abs,
Rodrigo

Ansible – Agregar TimeStamp ao Arquivo

Wed, 16 Aug 2017 00:00:00 +0000

Olá Pessoal,

Como vocês estão observando, segue mais uma evolução desenvolvimento para nosso script em Ansible. Acredito que vocês haviam se perguntado: Não vejo nenhum objetivo se eu ficar armazenando/sobrescrever o mesmo arquivo sem ter nenhum histórico ou obter um database de alteração desse arquivo? Pois é, eu também pensei dessa forma, mas devido à isso trago agora uma alteração pequena, porém importante para você rastrear seu histório de alteração ou de logs.

Em nosso playbook podemos utilizar-se da função “ lookup ” atrelado a data+time de nosso sistema operacional que está executando a playbook. Vale ressaltar que essa data não tem nenhuma amarração com o time de seu equipamento ( router, switch, etc ), e sim a máquina host que esta executando nossa biblioteca do ansible, que por consequência devemos garantir para que ela esteja sincronizada com algum serviço de NTP.

Para essa visualização eu fiz alteração apenas em nosso arquivo ” commands_variance.yaml “, adicionando nossa função ” lookup “, e por consequencia adicionei minha varável ao nome do arquivo que estou salvando em ” .txt “

---
  - name: Timestamp
    set_fact: mydate="{{lookup('pipe','date +%Y%m%d_%H%M%S')}}"

  - name: show running-config
    ios_command:
     provider: "{{ provider }}"
     commands:
        - show running-config
    register: config

  - name: save output Running
    copy:
      content: "{{ config.stdout[0] }}"
      dest: "/home/rodrigo/Documents/ansible/{{ inventory_hostname }}_running_{{mydate}}.txt"

  - name: show version
    ios_command:
      provider: "{{ provider }}"
      commands:
        - show version
    register: config

  - name: save output Version
    copy:
      content: "{{ config.stdout[0] }}"
      dest: "/home/rodrigo/Documents/ansible/{{ inventory_hostname }}_version.txt"

Após execução de nossa playbook segue o detalhamento da criação de meu arquivo.

Aguardo comentário e se alguém tiver mais alguma ideia para que possamos manipular esses comandos/arquivos fique a vontade de mencionar ou compartilhar. 😉

Abs,
Rodrigo

Ansible – Variações no Playbook – ” Include “

Mon, 14 Aug 2017 00:00:00 +0000

Olá Pessoal,

Baseando-se em nosso ultimo post, acredito que vocês tenham pensado em algumas alternativas para capturar comandos dos equipamentos ou de alguma forma ser mais flexível para armazenar arquivos. Pensando em algumas alternativas segue aquelas que acho interessante compartilhar com vocês para que isso possa de alguma forma ser uma implementação dentro de seu ambiente.

Como vocês observaram nosso arquivo de texto estava sendo salvo com o IP do equipamento, talvez isso não seja interessante e você gostaria de salvar esse documento através do hostname do equipamento, tendo isso como principio vamos fazer algumas alterações para que isso possa acontecer. Nosso primeiro passo é editar o arquivo de hosts ( inventário ) colocando nele a denominação do hostname e nossa variável ” ansible_host ” obviamente atrelado ao nosso IP de gerenciamento.

[routers]
R1 ansible_host=192.168.0.19

Desta forma precisamos fazer uma pequena alteração em nosso playbook adicionando a variável ” inventory_hostname ” no momento de salvar nosso arquivo ( .txt ). Para ficar melhor documentado, vocês podem observar que podemos adicionar algo após nossa variável, e assim a documentação do nome desse arquivo fica personalizada. 🙂

Segue abaixo nosso novo arquivo:

---
- name: Acesso remoto aos equipamentos
  hosts: routers
  gather_facts: no
  connection: local

  tasks:
  - name: OBTAIN LOGIN CREDENTIALS
    include_vars: secret.yaml

  - name: Define access
    set_fact:
      provider:
        host: "{{ ansible_host }}"
        username: "{{ creds['username'] }}"
        password: "{{ creds['password'] }}"
        auth_pass: "{{ creds['auth_pass'] }}"

  - name: show running-config
    ios_command:
     provider: "{{ provider }}"
     commands:
        - show running-config
    register: config

  - name: save output Running
    copy:
      content: "{{ config.stdout[0] }}"
      dest: "/home/rodrigo/Documents/ansible/{{ inventory_hostname }}_running.txt"

Com isso, podemos executar nosso playbook como explicado anteriormente, e logo vocês podem observar a diferença de ” output “, para qual temos o hostname populado ” R1 “, bem como o arquivo de texto que foi gerado como ” R1_running.txt “

Depois de fazermos essas alterações vocês talvez queiram incluir mais comandos em nossa playbook, para que de alguma forma seja documentado, ou seja, vocês podem ir adicionando mais comandos conforme exemplo anterior e salvar em um novo arquivo. Segue exemplo para adicionarmos mais comandos:

- name: show version
    ios_command:
      provider: "{{ provider }}"
      commands:
        - show version
    register: config

  - name: save output Version
    copy:
      content: "{{ config.stdout[0] }}"
      dest: "/home/rodrigo/Documents/ansible/{{ inventory_hostname }}_version.txt"

Após compilar novamente nossa playbook vocês podem observar que foram executados os dois comandos e consequentemente gerados dois arquivos.

Agora vêm o ponto, pensando em comandos e sobre a escalabilidade desse formato, onde teremos uma playbook gigantesca para executar várias tarefas. 💡 O que podemos fazer?

Acredito que seja mais interessante criarmos um arquivo ( yaml ), onde colocaremos todos nossos comandos, e desta forma, podemos chamar esse arquivo através de nossa playbook principal, assim ela não fica poluída com varias ações para ser executada. Para isso devemos usar nosso modulo “ include “, conforme segue abaixo em nosso script.

---
- name: Acesso remoto aos equipamentos
  hosts: routers
  gather_facts: no
  connection: local

  tasks:
  - name: OBTAIN LOGIN CREDENTIALS
    include_vars: secret.yaml

  - name: Define access
    set_fact:
      provider:
        host: "{{ ansible_host }}"
        username: "{{ creds['username'] }}"
        password: "{{ creds['password'] }}"
        auth_pass: "{{ creds['auth_pass'] }}"

  - name: Obtain commands
    include: commands_variance.yaml

Após essa inserção eu criei um novo documento ( yaml ), onde foi inserido todos os comandos que desejo fazer para meu equipamento, e assim fica mais claro as execuções de tarefas dentro de nossa playbook.

---
  - name: show running-config
    ios_command:
     provider: "{{ provider }}"
     commands:
        - show running-config
    register: config

  - name: save output Running
    copy:
      content: "{{ config.stdout[0] }}"
      dest: "/home/rodrigo/Documents/ansible/{{ inventory_hostname }}_running.txt"

  - name: show version
    ios_command:
      provider: "{{ provider }}"
      commands:
        - show version
    register: config

  - name: save output Version
    copy:
      content: "{{ config.stdout[0] }}"
      dest: "/home/rodrigo/Documents/ansible/{{ inventory_hostname }}_version.txt"

Após a execução o mesmo output é observado, porém temos uma estruturação muito mais adequada para execução e mapeamento de seu script. O que acharam? Deixem seus comentários.

Abs,
Rodrigo

Ansible – Criação do Playbook

Wed, 09 Aug 2017 00:00:00 +0000

Olá Pessoal,

Conforme mencionado em nosso último post, hoje gostaria de trazer para você as configurações executadas em nosso playbook, para que possamos acessar nosso equipamento Cisco ( CSR1000V ) para capturar sua configuração ( running-config ) e salvar essa configuração em uma pasta específica. Para que isso possa acontecer é necessário fazer algumas validações, e assim garantir acesso ao nosso equipamento. Primeiramente um teste rápido que devemos executar via Ubuntu é fazermos o teste de ping, conforme abaixo:

Após esse processo devemos garantir que nosso roteador é acessível via protocolo SSH ( Secure Shell ), isso é necessário porque o Ansible utiliza-se somente desse protocolo para acesso aos equipamentos ( Roteadores, Switches, Servidores, etc ) e quando pensarmos nessa utilização precisamos garantir que o protocolo SSH esteja habilitado em nosso equipamento e da mesma forma acessível. Conforme abaixo, eu estou executando o acesso ao meu equipamento, e como esperado ele me questiona para confirmação de acesso usando uma nova chave de SSH para o equipamento. Após esse processo digito a senha e tenho acesso completo ao equipamento. Se tiver interesse em habilitar o SSH Server no Ubuntu siga esse procedimento, mas nesse momento você não precisa se preocupar em habilitar esse serviço nesse sistema operacional.

Após esse acesso podemos validar em nosso roteador qual sessão foi estabelecida com o equipamento, bem como verificar o tipo de criptografia, status e username logado. Conforme mostrado na figura com a representação numero ( 1 ).

Logo abaixo, temos maiores detalhes sobre a conexão e a chave criptográfica utilizada pelo protocolo. Após essa validação, eu saio do modo de acesso via SSH ao roteador e podemos observar na figura com a representação numero ( 2 ) que não temos mais nenhuma sessão estabelecida com o equipamento. Se quiser monitorar acesso ao seu roteador habilite o ” debug ip ssh detail “.

Para que vocês possam fazer a configuração de SSH ao nosso roteador segue os comandos básicos abaixo, vale lembra que aqui nesse ambiente de teste estou utilizando um usuário local criado no equipamento com acesso privilegiado, entretanto devemos lembrar que ambientes mais robustos seria interessante que esse usuario fosse autenticado através de outras plataformas como Radius, TACACS+.

!
username rodrigo privilege 15 password 0 rodrigo
!
ip domain name cisco.com
!
ip ssh time-out 60
ip ssh source-interface GigabitEthernet3
ip ssh version 2
!
line vty 0 15
login local
transport input ssh

Enfim, depois de garantir total acesso ao equipamento, segue abaixo a configuração de nosso playbook para que possamos capturar o ” show running-config “.

---
- hosts: routers
  gather_facts: no
  connection: local

  tasks:
  - name: OBTAIN LOGIN CREDENTIALS
    include_vars: secret.yaml

  - name: Define access
    set_fact:
      provider:
        host: "{{ ansible_host }}"
        username: "{{ creds['username'] }}"
        password: "{{ creds['password'] }}"
        auth_pass: "{{ creds['auth_pass'] }}"

  - name: show running-config
    ios_command:
     provider: "{{ provider }}"
     commands:
        - show run
    register: config

  - name: save output to /home/rodrigo/Documents/ansible
    copy:
      content: "{{ config.stdout[0] }}"
      dest: "/home/rodrigo/Documents/ansible/{{ ansible_host }}.txt"

Podemos observar abaixo que temos nossos arquivos criados, conforme em nossos posts anteriores e devidamente validado, pois no presente momento não temos nenhum backup de configuração ( .txt )

Após todo esse processo devemos executar nosso playbook através do comando ” ansible-playbook -i hosts backup_cisco_router.yaml “. Na sequencia podemos observar todos os passos de nosso playbook sendo visualizado através das confirmações de nossas “ tasks “, e na última ação ” PLAY RECAP ” ele sempre irá trazer para nós o resumo se foi feito com sucesso e se tivemos alguma alteração baseado na ultima solicitação.

Com isso podemos visualizar nosso arquivo ” .txt ” com toda a configuração atual de nosso equipamento.

Espero que vocês tenham gostado e no proximo post vou demostrar algumas variações que podemos executar dentro dessa lógica de script.

Aguardo comentários. 🙂

Abs,
Rodrigo

Ansible – Execução da Playbook

Tue, 18 Jul 2017 00:00:00 +0000

Olá Pessoal,

Como já venho tratando sobre esse tópico em nossos posts anteriores, hoje venho aqui para explicar um pouco sobre o processo de execução de nosso playbook criado para rodar dentro da plataforma do Ansible.

Como já fizemos as tratativas dos arquivos de ” hosts “, também conhecido como inventário, e também uma forma prática de criar um arquivo de senhas para acesso aos nossos equipamentos, a ideia seria irmos para a criação de nosso ” playbook “, porém achei mais interessante trazer antes de que forma é composto o playbook para que possamos acessar as bibliotecas, e assim obter as configurações e execução de nosso python por trás de toda a estrutura.

Segue abaixo os componentes que podemos considerar para que toda a estrutura implementada no ansible possa executar.

Dentro desse propósito explico os ítens atrelado a essa estrutura:

Inventory = Arquivo que hospeda todas as definições dos seus equipamentos atrelados aos seus IPs de gerenciamento de sua infraestrutura, ou até mesmo através de um resolução de DNS.
Modules = Nesse caso podemos definir como sendo o modulo que roda todas as classes dentro do Ansible. Podemos mencionar aqui toda a estrutura do ansible galaxy, instalação / atualização para o Ubuntu, modulos de networking, monitoração, etc
Ansible Config = Essa configuração já é definida na própria instalação do software, porém é nesta base que temos visualizar e obviamente torna-se um item importante para fazer a conexão ao nosso ambiente de script que está acoplado ao Python. Em nossos testes posteriores não iremos fazer nenhuma tratativa nesse arquivo, pois não iremos cobrir alterações dentro dessa estrutura.
Python = Essa biblioteca já vem instalada com o software e são dessas bibliotecas que acessamos para os parametros relacionados aos equipamentos, em nosso caso estamos usando especificamente para questões dos modulos para Cisco.
Playbook = Nele podemos ter diferentes “ plays “, ou seja, pode existir chamadas arquivos remotos, como eu expliquei anteriormente sobre utilização do arquivo ” secret.yaml ” para fazer as tratativas dos usuário/senhas. Basicamente é um conjunto de tarefas usando os módulos, executados em um conjunto definido de hosts, tendo assim a execução em sequencia aos seus passos criados dentro do ” playbook “. Veja abaixo o exemplo:

Desta forma temos a estruturação de nosso ” playbook “, para que assim possamos pensar nas etapas de consulta ou configuração de nossos equipamentos. Em nosso próximo post irei trazer as configurações executadas para que possamos fazer a captura do arquivo de configuração dos equipamentos via ansible e assim salvar em um diretorio especifico.

Abs,
Rodrigo

Ansible – Criar arquivo host

Wed, 14 Jun 2017 00:00:00 +0000

Olá Pessoal,

Conforme venho comentando com vocês hoje gostaria de trazer a primeira iniciativa para que possamos criar nosso arquivo denominado como host. O que seria este arquivo?

Devido ao seu próprio nome, ele é um arquivo que podemos fazer analogia baseando-se no inventário de sua rede, portanto neste arquivo você deve popular todos os seus equipamentos que serão visívies à partir da instalação que você executou de seu Linux ( Ubuntu – veja nosso post anterior ). Em nossa pequena topologia para testes, eu apenas adicionei meu router CSR1000V dentro dos parâmetros desse arquivo conforme abaixo:

[router]
192.168.0.13

Com isso poderíamos pensar em fazer segmentações nesse arquivo separando roteadores, switches, firewalls conforme exemplo abaixo:

[routers]
192.168.0.13
192.168.0.20

[switches]
192.168.0.21
192.168.0.22

[firewalls]
192.168.0.23
192.168.0.24

Dependendo da escalabilidade de crescimento de seu ambiente esse arquivo pode tomar outras formas, definindo assim, uma melhor forma de criar seu inventário. Uma das possibilidades que você pode executar nesse arquivo seria a criação de uma ” variável “, fazendo com que você implemente uma inserção de informação para esse grupo.

[routers]
192.168.0.13
192.168.0.20

[routers:vars]
ntp_server=200.160.7.186

Seguindo um pouco mais adiante podemos fazer inserção de grupos dentro de grupos e ainda utilizar variavéis para colocar aquela determinada informação.

[routers]
192.168.0.13
192.168.0.20

[switches]
192.168.0.21
192.168.0.22

[dcsaopaulo:children]
routers
switches

[dcsaopaulo:vars]
ntp_server=200.160.7.186

[brasil:children]
dcsaopaulo
dcriodejaneiro
dcbrasilia
dcrecife

Podemos também utilizar um range de endereços IPs que irão seguir uma sequência, facilitando assim a definição dos endereços dentro do arquivo, economizando uma lista maior com somente os endereços IPs

[routers]
192.168.0.[1:255]
192.168.1.[1:128]

Para finalizarmos podemos também fazer associação desses endereços IPs por nome de hosts, mas vale lembrar, para que isso funcione você precisar ter o DNS funcionando corretamente, para que esse nome seja resolvido antes dele consultar seu device na sua infraestrutura. Segue um exemplo:

[routers]
R1_andar_1
R2_andar_1

[switches]
SW1_sala_10
SW2_sala_10

Com isso você já consegue manipular seus equipamentos através de seu arquivo de ” host “, fazendo com essa maquina possa alcançar a sua infraestrutura e manipular seus equipamentos. Para maiores detalhes, exemplos recomendo fazer a consulta através da documentação do Inventory Ansible.

Abs,
Rodrigo

Validação Sintaxe – Ansible

Mon, 15 May 2017 00:00:00 +0000

Olá Pessoal,

Conforme nossas notificações anteriores, hoje gostaria de trazer algumas facilidades que podem ajudar vocês em relação a validação de ” Syntax “. O que seria isso?

Toda linguagem de programação, bem como nossa ” costumeira ” CLI tem sua syntax correta, para que nossos comandos sejam aplicados de forma correta em nossos equipamentos, bem como nesse caso, a lógica seria executar algumas validações em meu script ” Ansible “, para que ele já possa mostrar onde podem estar contidos os erros.

Com isso, vocês podem perceber que o Atom pode trazer diferentes temas e pacotes para customização de seu editor, onde para nosso caso vou trazer 3 pacotes que irá ajudar em suas validações de script. Vale lembrar que esses pacotes que encontrei, foram os que mais me agradam, portanto se alguém que já trabalha com esse editor para desenvolvimento de scripts e tiver mais algumas dica interessante, posta em nossos comentários para que possamos desenvolver juntos as facilidades. 😛

Para procurar os pacotes e fazer a instalação, você deve ir em Edit -> Preferences -> + Install. Logo, você deve visualizar algo conforme nossa figura abaixo:

Após, isso eu recomendo esses três pacotes para que você procure na aba de packages e faça a instalação dos mesmos:

language-ansible
linter-ansible-syntax
linter-js-yaml

Após instalação alguns recursos precisam ser configurados, para que de fato eles possam trabalhar a seu favor. Em dois casos a recomendação é que você faça edição de um arquivo do Atom chamado ( config.cson ), para isso segue os links dos 3 pacotes recomendados acima para que você leia e execute conforme recomendação.

Com isso após estes passos, podemos observar alguns ítens que são inseridos logo abaixo de nossa aplicação dando dicas de possíveis erros em nosso script:

Em nossos dois retângulos azuis, podemos visualizar os alertas que nossos pacotes inserem como notificação e o retângulo laranja a descrição da falha, bem como em que linha ela esta ocorrendo. Desta forma, já conseguimos ter alguma visualização de possíveis erros de digitação, estruturação de variáveis, variáveis sem contéudo, etc.

Como uma última dica e que pode ajudar de alguma forma a visualização da sua indentação, onde pode trazer para você vários problemas, como um espaço adicionado ou até um ” TAB ” executado por engano ( achando que estava na CLI do Cisco…rsrsrs 🙂 ). Para isso devemos novamente ir em Edit -> Preferences -> Editor ( Scroll on ) e você irá visualizar Show Indent Guide. Como em nossa figura:

Você pode visualizar em nosso retângulo azul à esquerda as linhas nas verticais representando o nível de cada argumento que você esta inserindo em seu código.

Espero que vocês tenham gostado dessas dicas e se alguém tiver mais alguma dica fique a vontade em compartilhar. Em nosso próximo post vou iniciar com algumas configurações para captura em nosso CSRV1000V.

Abs,
Rodrigo

Instalação Ansible – Ubuntu

Thu, 11 May 2017 00:00:00 +0000

Olá Pessoal,

Conforme explicado em nosso post anterior, gostaria de trazer algumas dicas para facilitar o seus estudos e que você não ” apanhe ” como aconteceu comigo, perdendo algum tempo para ajustar seu laboratório.

Primeiramente, todo esse ambiente que instalei para praticar meu laboratório estão virtualizados no meu Vmware WorkStation 12, desta forma foi feita instalação do Ubuntu 16.04 LTS ( pode ser feito donwload free do Ubuntu ) através da imagem ” iso ” e iniciado o processo de instalação onde todos os ítens basico do sistema operacional foram instalados. Após finalização do processo de instalação do sistema operacional, você precisa fazer instalação da biblioteca Ansible em seu SO e obviamente capturar a versão mais nova do Ansible + Python. Segue abaixo os comandos em Ubuntu para instalação:

$ sudo apt-get install software-properties-common
$ sudo apt-add-repository ppa:ansible/ansible
$ sudo apt-get update
$ sudo apt-get install ansible

Após essa instalação vocês devem observar que foram instalados todos os pacotes do Ansible, mais as bibliotecas do Python que o proprio Ansible utiliza-se para execução de suas tarefas. Para garantir integridade de instalação você pode conferir através do comando abaixo:

root@ubuntu:/home/rodrigo# ansible –version

( Status de instalação na minha máquina ):

root@ubuntu:/home/rodrigo# ansible –version
ansible 2.3.0.0
config file = /etc/ansible/ansible.cfg
configured module search path = Default w/o overrides
python version = 2.7.12 (default, Nov 19 2016, 06:48:10) [GCC 5.4.0 20160609]

Como padrão do SO ele vai instalar toda essa demanda na pasta ( /etc/ansible ) e como dica eu recomendo que você copiei o conteúdo dessa pasta e grave esses arquivos em uma outra pasta ( /documents ) para que você possa trabalhar tranquilamente com esses arquivos, sem impactar na sua instalação, já que estamos apenas praticando nossos conceitos e erros de fato podem acontecer.

Agora temos nossa biblioteca/app instalado e podemos começar a trabalhar em nossos scripts. Mas, aqui dou mais uma dica para facilitar para você que irá começar a escrever seus scripts, e que não sofrá com a ” syntax ” da linguagem de programação, que por usa vez, podem trazer diversos erros que são muitas vezes indecifravéis, para nos que estamos iniciando nessa área.

Claro, que as pessoas que já estão acostumados a trabalhar com essas ferramentas podem continuar da mesma forma, mas aqui vou partir do principio que nem todos fazem isso em seu dia a dia, então para que você não fique ” stressado 👿 ” com as teclas de atalho que o ” vi ” traz para você e obviamente ele não traz uma ” syntax ” amigável, eu recomendaria a instalação do Atom.io que irá facilitar muito nossa vida tanto em programação de Python como em Ansible. Existem diversas ferramentas para esse tipo de trabalho, portanto fiquem a vontade de utilizar a que mais adequa-se a você. Para instalação do Atom você pode executar conforme abaixo:

sudo add-apt-repository ppa:webupd8team/atom -y

sudo apt-get update

sudo apt-get install atom -y

Após instalação do Atom eu recomendo que você inicie o aplicativo de edição sempre em modo ” root “, para que desta forma você já posso compilar, validar e grava através de seu editor de texto, diminuindo assim algumas tarefas para execução de seu playbook ansible. Para isso basta iniciar a aplicação como abaixo:

sudo atom

Após inicialização você irá visualizar sua tela de edição conforme figura abaixo:

Em nosso próximo post vou trazer mais alguns caminhos para que você possa instalar em seu ” editor de scripts ” para que possamos ter algumas validações de syntax para o Ansible.

Abs,
Rodrigo

Automação – Ansible – DevOps

Mon, 08 May 2017 00:00:00 +0000

Olá Pessoal,

Acredito que baseando-se no título, vocês devem estar se perguntando esse BLOG não é de redes? Sim, ele é de redes, porém, como já venho trazendo em alguns posts anteriores e sempre menciono que nossa área de redes está passando por uma transformação é devido a esses ítens que venho hoje falar um pouco mais para vocês.

Devido a essa novo tema, venho aqui, compartilhar um pouco do que estou estudando para que eu possa melhorar em alguns aspectos, e claro gostaria de mostrar para vocês sobre alguns ítens que possam ajudar nossos engenheiros em nossas tarefas diárias.

Hoje, nosso segmento de redes está trazendo muitos conceitos sobre os processos de automações que devemos implementar, para que nossas tarefas diarias sejam mais efetivas e que nossos scripts não sejam somente atrelados a nossa CLI ( command line interface ) e sim, que nossos scripts possam agregar mais valor as tarefas cotidianas de implementações e que demandam muito esforço repetitivo. Baseando-se nesses tópicos estamos falando-se de duas frentes de trabalho que estão caminhando muito forte dentro do mundo de Redes ( Cisco ) que são Python e Ansible.

Talvez, algumas pessoas podem estar pensando, porque ele já vai falar de Ansible se os temas de Python ainda não forão discutidos ou exemplificados em nosso BLOG. Isso eu vou explicar mais no final de nossa serie de posts sobre Ansible.

Como mencionado anteriormente, nos estamos falando muito em automação dos processos para que seja executado de forma rapida e automatica diversas configurações ou validações em nossos ambientes de redes. Devido a isso, a Cisco está trabalhando fortemente nas disponibilizações de API ( para que não viu, verifique em nosso post de Rest API / API ) e também em formas de trabalhar em conjunto para que essas metodologias de DevOps, seja cada vez mais vivenciado nesse mundo Cisco. Com isso, o que trago para vocês é um detalhamento sobre a linguagem Ansible.

Basicamente, essa linguagem é desenvolvida pela Red Hat, onde eles estão investindo pesado para divulgação dessa linguagem e disponibilizações de soluções para diferentes vendors. Com isso, gostaria de mostrar a documentação do Ansible, para que vocês possam consultar e com certeza através dela muitos ítens podem ser validados, para que você pense em seu primeiro script. Como uma primeira dica, gostaria de deixar um ítem extremamente voltado para nossa área de Redes, especificamente para as demandas que podemos utilizar para equipamentos Cisco, mas também podem observar que temos para diversos fabricantes.

Para efetuar nossos testes eu vou trabalhar com o sistema operacional Linux ( escolhido foi o Ubuntu ) e para maior praticidade, vou utilizar um router virtualizado Cisco CSR1000V. Segue uma topologia bem simples para que vocês entendam o cenario de teste, porém lembrando que esse ambiente pode ser escalado a níveis muito maiores.

Em nosso próximo post, vou explicar um pouco mais sobre a instalação da biblioteca Ansible no Ubuntu e de alguns recursos que vocês podem utilizar para melhorar seu aprendizado. 🙂

Abs,
Rodrigo