Ansible on Cisco Redes

Cisco Meraki – Inicialização Ansible para primeiro playbook

Mon, 02 Dec 2019 00:00:00 +0000

Olá Pessoal,

Como todos sabem que muitas das vezes eu não consigo atualizar os conteúdos conforme eu desejaria, mas na medida do possível vou sempre atualizando nosso seguidores e comunidade sobre os tópicos que vou aprendendo e desenvolvendo para compartilhar com todos.

Enfim, depois de avançar bastante com tópicos de Meraki + Umbrella, hoje vamos continuar sobre nossos desenvolvimentos baseado em Ansible para controlar seu ambiente, bem como gerenciar as configurações de uma forma mais ágil.

Nos estavamos mencionando nos posts anteriores sobre as capturas que podemos fazer via as API através do Postman. Porém, como vamos iniciar trabalhando dentro do Ansible para chamar algumas solicitações para o Meraki, então nesse momento vou demonstrar algumas ações sendo feitas através de alguns modulos já existentes no Ansible e futuramente coloco algum caso utilizando alguma API dedicada diretamente via Ansible.

API Key para Ansible

Como todos sabemos para acesso ao Meraki precisamos utilizar nossa chave e por consequencia é necessario adicionar esses parametros para o Ansible, pois através dessa ” key ” é que teremos permissões para fazer solicitações ( GET, POST, DELETE, UPDATE ) ao ” Dashboard “.

Não devemos esquecer que o ” Control Node ” que está executando o Ansible deve ter acesso a Internet, já que o produto Meraki está hospedado em Cloud pública. Baseado nessa API Key você também precisa ficar atento que hospedar arquivo host em algum respositório ( Git ), pode expor sua chave de acesso dando permissão ” full ” a toda administração Meraki.

Usando Ansible-Vault

Como informado acima temos que usar algumas técnicas para podermos criptografar nosso arquivo que irá ter nossa ” API Key “ e consequentemente mais algumas informações, que podemos denominar como variáveis para utilização em nossa playbook.

Dentro desta estrutura temos um ítem simples e prático para executar essas ações que esta denominado como sendo função ” ansible-vault “. Como esse não é objetivo principal do post vou executar o mais simples, que é criptografar todo o meu conteúdo no arquivo ( group_vars/auth_key_mer.yml ). Caso queira visualizar mais opções visite a documentação do Ansible-Vault.

Para nosso caso estou criando um novo arquivo para preencher com as varíaveis e logo após estou populando as minhas variavéis que será usada posteriormente. Segue abaixo o exemplo:

Após criação dois ítens estou criando a encriptação do arquivo através de uma senha que estou determinado no momento que executo essa ação. Veja abaixo:

Para demonstrar estou abrindo o arquivo após a encriptação para consolidarmos que de fato esse arquivo foi codificado.

Logo após vocês poderiam perguntar. Como vou editar agora esse arquivo?

Se você observar acima eu posso editar ele normalmente utilizando minha senha, e posteriormente ele irá abrir como um arquivo texto normal, podendo ser editado e salvo da mesma forma que estavamos trabalhando anteriormente.

Vale ressaltar que se por algum motivo você esquecer essa senha, infelizmente você perdeu seu arquivo e terá que construi-ló novamente.

Lógica do Playbook

Como havia informado incialmente vamos utilizar os módulo já populados para Ansible e disponivéis para consumir, pois os proprios fabricantes já desenvolvem para ajudar nesses quesitos. Caso queira saber todos os modulos para o Meraki pode consultar nesse link.

Como feito em outras playbooks que venho utilizando no Ansible, eu criei algumas estruturas para segmentar minhas ” tasks “, e assim fazer as solicitações para ter um pouco mais controle e compreender em qual estado estou de minha playbook e interpretar em alguns momentos os erros que recebo. Segue a estrutura de pastas que criei para esse nosso primeiro exemplo:

Modulo Ansible

Para esse primeiro exemplo escolhi trabalhar com o módulo ” meraki_ssid “ para executar 3 ações que desejo fazer em meu equipamento ” MR “. Desta forma, vou criar um SSID novo, deletar esse SSID e posteriormente vou consultar ” query “ quais SSIDs estão configurados na minha organização.

Novamente, vale ressaltar que neste momento estou criando meu SSID com ítens básico, apenas para ser visualizado no portal, mas caso você queira adicionar mais configurações somente é necessário passar os paramêtros desejados.

Volte ao ínicio

Logo abaixo temos nosso código relacionado ao arquivo ( meraki_basics.yaml ) que será a playbook que irá solicitar todas as demandas baseadas nas opções que eu desejo executar na minha playbook.

---
- name: START CONFIGURATION
  hosts: localhost
  gather_facts: no

  vars_prompt:
  - name: "action_ssid"
    prompt: "Please with action would you like to do?
             ( 1 ) - Add
             ( 2 ) - Delete 
             ( 3 ) - Query"
    private: no

  - name: "ssid_name"
    prompt: "Which SSID name will be (add) or (delete) or query (all)?"
    private: no

  tasks:
  - name: DECRYPT KEYS
    include_vars: "./group_vars/auth_key_mer.yml"
    no_log: true

  - name: GET INFO OF ORG
    include_role:
      name: get_info_org
    no_log: true

  - name: GOING TO ADD SSID
    include_role:
      name: add_ssid
    when: action_ssid == '1'

  - name: GOING TO DELETE SSID
    include_role:
      name: delete_ssid
    when: action_ssid == '2'

  - name: GOING TO QUERY SSID
    include_role:
      name: query_ssid
    when: action_ssid == '3'

Feito isso, eu resolvi criar uma ” task “ dedicada para eu obter todas as informações necessárias do dashboard para que posteriormente eu possa usar qualquer varíavel dentro de outras ” task “. Com isso eu tendo a variável registrada eu consigo obter qualquer variavel pois a estrutura de saída do comando já e formatado em JSON. Segue o codigo relacionado ao arquivo ( get_info_org/tasks/main.yaml ).

---
- name: Query information about Organizations associated to the user
  meraki_organization:
   auth_key: "{{ auth_key_api }}"
   state: query
  delegate_to: localhost
  register: meraki_name
  no_log: true

- name: List all networks associated to the Organization
  meraki_network:
   auth_key: "{{ auth_key_api }}"
   state: query
   org_name: "{{ meraki_name.data[0].name }}"
  delegate_to: localhost
  register: meraki_all_net
  no_log: true

Talvez você me pergunte, porque você está usando ” no_log: true”? Isso deve-se justamente relacionados as informações que podem ser populadas através de uma funcionalidade de ” verbose “ que poderiamos usar para visualizar as informações, mas abaixo você pode detectar que nada é mostrado:

Agora se você observar a saída do comando o qual ele pode trazer, e desta forma podemos filtrar especificamente o valor desejado para sua playbook a partir do momento que estou executando a playbook com ” verbose “ e na minha task foi removido ” no_log: true “

Dando sequencia a nossa playbook iremos consolidar sobre inserção de um novo SSID. Como vocês podem observar estou fazendo a execução desta task, baseado no que o usuario responde a partir do questionamento feito no inicio da playbook, ou seja, essa ação será executada se for preenchida com o ” 1 “. Para que eu possa inserir esse SSID estou colocando o estado como ” present “, assim ele irá escrever e colocar como ” enable “ esse SSID no portal.

---
- name: Adding SSID
  meraki_ssid:
    auth_key: "{{ auth_key_api }}"
    state: present
    org_name: "{{ meraki_name.data[0].name }}"
    net_name: "{{ meraki_all_net.data[0].name }}"
    name: "{{ ssid_name }}"
    enabled: true
  delegate_to: localhost

Logo na sequencia temos o ” delete “ que é a mesma função anterior, porém preciso colocar o estado como ” absent “ e no modo ” enable “ em falso.

---
- name: Delete-Disable SSID
  meraki_ssid:
    auth_key: "{{ auth_key_api }}"
    state: absent
    org_name: "{{ meraki_name.data[0].name }}"
    net_name: "{{ meraki_all_net.data[0].name }}"
    name: "{{ ssid_name }}"
    enabled: false
  delegate_to: localhost

E para finalizar irei colocar uma demanda para fazer ” query “ e fazer ele consultar todos os meus SSIDs configurados, criando assim um loop para ele varrer as variaveis e trazer se de fato o SSID esta habilitado ou desabilitado.

Volte ao ínicio

---
- name: Executing Query
  meraki_ssid:
    auth_key: "{{ auth_key_api }}"
    state: query
    org_name: "{{ meraki_name.data[0].name }}"
    net_name: "{{ meraki_all_net.data[0].name }}"
  with_items: data
  register: status
  delegate_to: localhost

- debug: 
   msg="We found the SSID {{ status.results[0].data[item].name }} in your Meraki Dashboard and enable status is {{ status.results[0].data[item].enabled }} "
  loop: 
    - 0
    - 1
    - 2
    - 3
    - 4

Teste da Playbook

Após vocês entenderem a logica de programação, chegou a hora de verificar se fato está funcionando nossa ideia dentro do portal Meraki.

Neste primeiro teste estou executando como ” ansible-playbook –ask-vault-pass meraki_basics.yaml “, onde a demanda do ” Vault “ é justamente para eu digitar minha senha e poder conseguir obter a variavel desejada que necessito para minhas próximas ações.

Logo abaixo pode observar que estou opção ” 1 “ que irá adicionar um SSID denominado como ” Ansible “.

Agora vou consultar meu portal e consolidar se de fato ele populou meu novo SSID. Confira abaixo:

BINGO!!!

Próximo passo seria deletar esse mesmo SSID e consolidar o que vemos no portal.

Podemos observar que ele já foi removido do portal e por padrão sempre quando não temos o SSID configurado ele irá aparecer como ” Unconfigured SSID x “

Para finalizar vamos consolidar todos os nossos SSIDs configurado e habilitados em nosso Dashboard, utilizando nossa função de ” Query “

Como observamos acima, imprimi todos as saídas para identificar o que temos em operação.

Depois de um longo post, chegamos ao final de mais uma ideia ou iniciativa para começar a manipular seus dados no portal Meraki via Ansible. O que vocês acharam? Vale a pena fazer um video para compartilhar os testes ou ficou bem compreendido?

O que vocês acham que poderiamos mudar nesse código ou o que vocês gostariam que eu demonstrasse para vocês?

Deixe seus comentários, pois esse BLOG é construído para todos.

Abs,
Rodrigo

Ansible – Palestras no VMworld 2018

Mon, 15 Oct 2018 00:00:00 +0000

Olá Pessoal,

Eu estava devendo para vocês sobre minha palestra executada no VMware{code}, a qual estava disponível apenas na pagina do Facebook.

Enfim, as palestras agora foram disponibilizadas no Youtube ( segue o canal ), para qual fica um pouco mais facil para que possamos compartilhar. Apenas como lembrete, essa palestra foi de 30 minutos, onde no final acabo demostrando um video que havia gravado para apresentar, pois não tive recursos para usar a estrutura planejada para executar a demo. Segue nossa video, espero que vocês gostem.

Para concluir e deixar populado apenas em um post, segue abaixo nossa palestra executada no vBrownBag que eu já havia compartilhando aqui, porém para ficar mais unificado vou adicionar abaixo. Vale lembrar, que essa sessão foi de 15 minutos, apenas para introduzir sobre o assunto.

Abs,
Rodrigo

Cisco – Divulgação de Código para Comunidade

Wed, 19 Sep 2018 00:00:00 +0000

Olá Pessoal,

Acredito que todos já devem estar acompanhando os esforços da Cisco em cada vez mais publicar e facilitar essa transição que estamos vivendo de nossa famosa função ” Network Engineer ” para uma cultura um pouco mais abragente de que não devemos apenas ser um ” Native CLI “, e sim ter algumas mãos espalhadas em outras áreas como a de ” Developer “.

Talvez muita gente pode se perguntar ou em vários momentos já entraram em discussões com amigos, professores, chefe, vizinho, etc se nós profissionais da área de Redes devem aprender programação. O que vocês acham? 💡

Vou dar minha opinião ( vocês podem concordar ou discordar ) daquilo que estou vivenciando, bem como o que vocês estão acompanhando no BLOG do que venho apresentando/estudando. De fato, a função de ” Network Engineer ” não vai sumir do mercado e lógico que a função como qualquer outra do mercado de tecnologia ela precisa ir adapatando-se aquilo que estamos trabalhando, ou seja, de fato precisamos acrescentar maiores “ skills ” em nossa função, o qual hoje ela deseja que tenhamos esse conhecimento de programação, mas não se desespere você não precisa ser um ” Expert ” em programação, e sim ter um raciocionio lógico para saber utilizar as facilidades que a programação oferece hoje dentro do mercado e a facilidade que os equipamentos estão oferecendo para que você execute desta forma.

Eu imagino que você possa ter outra percepção, da qual pode imaginar que seu conhecimento adquirido ao longo dessa carreira ou de estudo estão perdendo-se. Novamente volto ao ponto da função de ” Network Engineer ” que ela não vai sumir do mercado, e sim estamos nos adaptando ao mercado, pois o que adianta você saber programar mas não entender como um protocolo de roteamento funcione, ou vice-versa.

Com isso gostaria divulgar um ítem na qual a Cisco esta agrupando alguns códigos que são desenvolvidos em varias plataformas ( especial Github ) e trazendo isso para dentro do programa que ela denominou como ” Code Exchange “. Isso caracteriza que diversos desenvolvedores e colaboradores podem aplicar seu código para dentro dessa plataforma, na qual ele é validado e algumas características são equalizadas para ele possa ser demonstrado nesta plataforma. Como já venho trabalhando em uma situação que acho bem interessante e que pode ajudar algumas pessoas no dia a dia, eu apliquei meu código ( já disponibilizado no github ) e de fato ele foi aprovado e já pode ser visualizado na página. Se quiser visualizar página acesse aqui.

Bom, o quero demonstrar aqui é que você que esta desenvolvendo códigos para melhorar seu dia a dia e queira publicar ( se for permitido ) pode utilizar essa plataforma, bem como também poderemos ter mais pessoas que podem colaborar para seu projeto tendo mais idéias e ajudando a crescer cada vez mais essa facilidade que temos hoje em dia.

Espero que vocês tenham gostado e deixe seus comentário abaixo do que você pensa sobre esse tópico. Nós proximos vou trazer mais idéias sobre esse movimento. 😆

Abs,

Rodrigo

VMworld 2018 – Day 3 – Quarta Feira

Mon, 03 Sep 2018 00:00:00 +0000

Olá Pessoal,

Estamos praticamente na metade de nosso evento e sinceramente hoje foi o dia onde as empresas finalizaram suas notificações sobre as novidades que eles planejam lançar dentro do VMworld. Inclusive hoje já temos a festa de encerramento do VMworld patrocinada pela VMware.

O que eu consegui capturar hoje de novidade está relacionado a Veeam, para qual a sessão foi focada em novidades da integração do Veeam com a Cloud que virão no Update 4. Uma delas será a possibilidade de fazer restore diretamente para a AWS com uma estimativa de custo diretamente no console do Veeam. Para quem não conhece a empresa recomendo entrar no website informado acima, porém é uma empressa que está crescendo bastante e o foco principal deles é trabalhar com o gerenciamento de seus dados ( backup, recovery, otimização da replicação, backup em nuvem , etc ).

Em minha próxima sessão fui assistir ” To Infrastructure and Beyond: Infrastructure as Code with VMware “, na qual minha intenção é entender sobre a denominação de ” DevOps “. Pelo meu entendimento a ideia é que você tenha um portal ( ferramenta VMware ) hospedada em nuvem, para que você possa executar suas tarefas através de um dashboard onde ele já traz algumas facilidades para fazer seu gerenciamento e criação de tarefas diárias muito mais rápida e simples. Nesse caso demonstraram a criação de uma pagina WordPress para subir isso rapidamente dentro de sua infraestrutura. Segue alguns slides capturados.

Se quiser executar testes a recomendação passada foi para que você criei um acesso através do site ( https://console.cloud.vmware.com ), e verifique as possibilidades em fazer suas tarefas. Alguns laboratório do HOL também acabam dando referência e até executando algumas configurações dentro deste ambiente. Vale a pena conferir.

Após isso fui diretamente no ” Solution Exchange ” no estande da Red Hat, para conversar com os especialista e obviamente fui capturar maiores informações sobre Ansible. De fato o que eles trouxeram para o evento foi a demonstração do Ansible Tower, e as demandas para configuração como demo do VSphere. Novidades ainda não temos muitas em relação ao desenvolvimento, mas como já venho acompanhando eles mencionaram que a parceira com as empresas está crescendo bastante e a idéia que os modulos possam aumentar em cada nova atualização tanto do Tower como do Ansible ( engine de orquestração ). Um ítem citado e também para reforçar que em Outubro ( 2 à 3 ) teremos o AnsibleFest, onde é a conferência de encontro dos profissionais, bem como também eles prometem lançar mais alguma novidade. Para quem não puder ir, ele também será transmitido online.

Em linhas gerais para mim não teve muitas novidades falando-se de Ansible, pois está sendo um assunto que estou acompanhando bem de perto, porém foi interessante conversar com as especialistas e trocar algumas experiências.

Para completar meu dia consegui encontrar no evento, nada mais que Neil Moore ( 8xCCIE, CCDE ), uma lenda dentro do modelo de certificações Cisco, onde fui encontrar ele no LABS do HOL, o qual ele estava trabalhando e suportando casos do evento. Foi um bate papo muito interessante onde ele contou um pouco sobre sua carreira, demandas e apresentações que ele estava executando no VMworld, onde espero futuramente escrever um pouco sobre esse bate papo. Segue a selfie como comprovação. 😀

Continue seguindo nosso BLOG, que maiores informações serão publicadas.

Abs,
Rodrigo

VMworld 2018 – Day 4 – Quinta feira

Mon, 03 Sep 2018 00:00:00 +0000

Olá Pessoal,

Hoje venho aqui para dizer que é meu último dia no evento da VMware ( VMworld ), e posso declarar que eu aproveitei bastante essa energia, com certeza fiz muitos amigos e também aprendi muita coisa. Mas tudo precisa ter um fim para que possamos ter outro recomeço, então para quem pensa em planejamento no ano de 2019 esse evento será na cidade de ” San Francisco “.

No ultimo dia, área onde ficavam os expositores já ficam fechadas, pois as 14hs de fato o evento encerra, então neste dia temos área onde ficam os telões, área relaxamento, área de bloggers e ainda algumas sessões acontecem no VMTN Village e também na área de ” Education Services ” que está atrelada ao segmento de certificações VMware, porém neste espaço aconteceram diferentes palestras.

Hoje é um dia mais tranquilo, mas também foi um dia importante e ansioso, pois eu apresentei minha palestra sobre “ Starting Engineering inside Ansible ” no VMware{code}. No inicio do dia acabei ficando mais no vBrownBag, assistindo as sessões e vários assuntos foram abordados falando-se bastante de vSphere.

Por volta das 12:45PM ( USA Time ) e no Brasil 16:45PM eu apresentei minha palestra. De fato foi uma experiência muito boa e satisfatória, pois consegui repassar para o pessoal um conteúdo interessante e dando uma visibilidade de como nós Engenheiros, podemos iniciar aprendendo um pouco desse mundo de ” Automation ” no universo de Networking. O feedback depois da sessão foi positivo, pois tivemos varias pessoas perguntando após a palestra, com isso acredito que fiz meu papel de despertar o interesse em alguns para iniciar no mundo ” NetDevOps “. Essa palestra foi apresentada no ” Facebook Live ” e até esse momento ela não foi publicada no YouTube. Assim que eu receber a notificação volto a divulgar para vocês que não conseguiram acompanhar no dia.

Mas para não deixar a todos ansiosos sobre o conteúdo, vou carregar em nossa área de ” Arquivos ” os slides que apresentei para o pessoal no dia.

Para finalizar um resumo que recebemos relacionado a esses 4 dias de evento. O que acham?

300+ customers certified
10,000+ hands-on labs completed
800 sessions (with more than 160 at maximum capacity)
61,000+ social media posts with the hashtag #vmworld (so far!)
7,200+ attendees at the VMworld Fest
5 Elvis impersonators spotted
3,000 VMware 20th birthday cupcakes consumed

Fiquem ligados em nosso BLOG!!! Juntos somos melhores. 🙂

Abs,
Rodrigo

Introdução Ansible – VBrownBag Brasil

Fri, 20 Jul 2018 00:00:00 +0000

Olá Pessoal,

Não sei se todos acompanharam os dois episódios que executamos no vBrownBag Brasil falando um pouco sobre Ansible.

Se você não conseguiu acompanhar, eles estão populados no proprio canal do YouTube ( vBrownBag Brasil ) e a ideia desses dois capítulos foi inicialmente focar um pouco na introdução do Ansible e obviamente trazer os conceitos que estão sendo abordados para área de Networking. Segue abaixo os dois episódios:

Parte 1

Parte 2

Espero que gostem e deixem seus comentários. 🙂

Abs,
Rodrigo

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 – Loop com Validação de Variáveis – Parte 4

Thu, 26 Apr 2018 00:00:00 +0000

Olá Pessoal,

Esse post acabou surgindo depois de discussões em nosso foruns, mais especificamente no Telegram, onde eu já havia feito essa alteração mas acabei não detalhando em nosso BLOG, sobre essa possível alteração e de que forma poderia ser feito dentro de nossa estrutura de playbook para o Ansible.

Como já mencionado em nossos posts, inúmeras ideias podem surgir baseado na necessidade de seu ambiente e lógicas para cada tipo de configuração, portanto explorar as ideias são sempre bem vindas. Enfim, o que gostaria de agregar aqui nesse post seria sobre uma hipótese de precisarmos fazer uma validação de algum ID de loopback para que possamos amarrar a nossa base externa.

Pensando nesse item e respondendo ao questionamento, é possivel. Com isso iremos fazer atualização em nosso arquivo de teste ( .csv ) definindo variáveis ( x e y ) para popular em nosso exemplo de amarração com loopback ID ( 12 e 13 ).

inventory_hostname,DHCP,dhcp_exclude1_start,dhcp_exclude1_end,dhcp_network,dhcp_netmask,dhcp_gateway,new_hostname,id_loopback,ip_loopback,mask_loopback,ip_loopback_x,mask_loopback_x,ip_loopback_y,mask_loopback_y
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,2.2.2.2,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,3.3.3.3,255.255.255.255,5,5
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,1,2,5.5.5.5,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,1,2,5,5
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,1,2,5,5
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,1,2,5,5
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,1,2,5,5
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,1,1,5.5.5.5,255.255.255.255

Obs.: Vocês podem achar que estou louco

, mas na verdade estou somente jogando valores ficticios nas variaveis definidas como IP Address de loopback, para que possamos de fato validar automação, então não se espante com esses IPs.

Para comparar os IDs ( 12 e 13 ) adicionei eles em nosso arquivo ( /group_vars/all.yml ).

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

cisco_881_l2_interfaces:
  - FastEthernet0
  - FastEthernet1
  - FastEthernet2
  - FastEthernet3

loopback_id:
  - 5
  - 6
  - 7
  - 10
  - 11
  - 12
  - 13

Com isso agora já preparei minha base ( .csv ) e minha variáveis para que agora eu possa montar minha condição obviamente dentro de meu arquivo Jinja2, usando as condições de ” if, elif e else “. Segue alteração de nosso jinja template.

!
{% for loopback in loopback_id %}
{% if loopback == 12 %}
interface loopback {{loopback}}
  ip address {{ vars_from_csv.ip_loopback_x }} {{ vars_from_csv.mask_loopback_x }}
  no shutdown
!
{% elif loopback == 13 %}
interface loopback {{loopback}}
  ip address {{ vars_from_csv.ip_loopback_y }} {{ vars_from_csv.mask_loopback_y }}
  no shutdown
!
{% else %}
interface loopback {{loopback}}
  ip address {{ vars_from_csv.ip_loopback }} {{ vars_from_csv.mask_loopback }}
  no shutdown
!
{% endif %}
{% endfor %}
!

Vocês podem observar que estou criando condições de se coincidir com o ID escrevo isso, caso contrario coincidir com o IDy escrevo aquilo e por fim execute isso.

Dentro desse contexto estou comparando meu ID com o valor quero propagar em meu script e obviamente exportar para meu futuro device. 😉

Agora como desafio e ideias que vocês podem adicionar em nossos comentários, vocês já imaginaram de que forma também eu poderia agregar se eu consolidar o script comparando familias de equipamentos ( 881, 1941, etc ) para após isso montar meu template? E se em meu arquivo de base externa ( .csv ) eu não tiver com uma variável preenchida o que irá acontecer? Posso remediar?

Aguardo os comentários e claro depois de nossas discussões coloco meus exemplos/ideias para esses problemas.

Abs,
Rodrigo

Ansible – Nova Versão Disponível – 2.5

Tue, 03 Apr 2018 00:00:00 +0000

Olá Pessoal,

Conforme eu havia mencionado em nosso post sobre a nova versão que estaria disponível em março conforme o ” roadmap ” informado, e de fato podemos observar que o release foi liberado na data prevista.

Nesse link você pode observar que temos uma documentação definida como ” devel “, bem como pode observar os ítens prometidos e executados pelo time para ser disponibilizado nesse versão.

Entretanto já tinhamos um post escrito pelo time em Fevereiro já detalhando sobre as alterações mais importantes para nossa área de Networking. Isso pode ser consultado através desse link.

Porém, para trazer um resumo e um dos fatores mais importantes que podemos detalhar aqui é a maneira que podemos tratar agora para acessar os equipamentos de rede, trazendo uma flexibilidade muito maior e dinamismo. Vocês podem observar em nossos posts que sempre estavamos utilizando ” connection: local “, porém agora teremos mais duas funções ” network_cli e netconf “. Esse desenho mostra essas alterações bem como os exemplos já explicados no link informado acima.

Com isso observamos como o código é executado dentro de nosso ” control node “, fora que novos modulos foram adicionados como do fabricante Infoblox, para qual já existe facilidades para trabalhar com essa ferramenta.

Enfim, vale a pena ler a documentação para entender as mudanças nessa versão e obviamente já fiz minha atualização para fazer agora alguns testes baseando-se em ” netconf “. Aguardem!!!

Abs,
Rodrigo

Ansible – Loop de Variáveis usando Jinja2 – Parte 3

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

Olá Pessoal,

Baseado em nossos posts anteriores explicando sobre implementação de arquivos de configuração utilizando loops e dados capturados via uma base externa, hoje venho aqui para que possamos finalizar nosso conteúdo trazendo de fato nosso loop com as variavéis sendo inseridas em nosso arquivo de ” vars “.

Como vocês observaram nos posts anteriores nosso arquivo incluido no “ group_vars/all.yml ” será alterado para que possamos agora inserir mais duas variáveis que iremos trabalhar para gerar nosso loop. Esses exemplos de fato são para que eu possa demonstrar, mas podemos pensar em varias situações onde seria interessante trabalhar criando essas interfaces ou definindo posteriormente VLANs. Segue o arquivo completo:

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

cisco_881_l2_interfaces:
  - FastEthernet0
  - FastEthernet1
  - FastEthernet2
  - FastEthernet3

loopback_id:
  - 5
  - 6
  - 7
  - 10
  - 11

Com isso populado em nosso arquivo, agora teremos que alterar nosso template ( jinja2 ) para inserir nosso loop com o intuito de varrer essas variáveis e criar nosso template de configuração. Nossa alteração será executada no “ template/script.j2 “.

!
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
!
{% for interface in cisco_881_l2_interfaces %}
interface {{interface}}
 switchport access vlan 10
 spanning-tree portfast
!
{% endfor %}
{% for loopback in loopback_id %}
interface loopback {{loopback}}
  ip address {{ vars_from_csv.ip_loopback }} {{ vars_from_csv.mask_loopback }}
  no shutdown
!
{% endfor %}
!

Como vocês podem observar estou trabalhando com a função “ for ” que é o argumento para gerarmos o loop até que exista essa variável populada em nosso arquivo, ou seja, essa função somente sairá do loop ” endfor ” se todos os ítens forem verificados, como consequência ele irá seguir para o próximo loop para executar a função das loopbacks, tendo como lógica a mesma explicada acima.

Após essas alterações podemos executar nossa playbook para que possamos avaliar se irá executar da forma que planejamos. Gostaria de lembrar que estamos criando esse template via uma base externa ( csv ) e também geramos ítens adicionais que de fato podem ser exemplificados como melhorias de algum template que precise criar que de alguma forma ele não foi demonstrado ou manipulado pelo arquivo csv.

Segue aqui a menção que obtivemos com alteração ( change ) em todos os elementos do inventário.

Para consolidarmos nossas alterações vamos observar nossos arquivos, não esquecendo que ainda continuamos fazendo as alterações ( true e false ) da configuração do DHCP normalmente, bem como trabalhando com os valores deles mesmo dentro de nosso loop, ou seja, depois de estruturado nossos dados podemos utiliza-lo diferentes formas.


Template Router 1	Template Router 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 ! interface FastEthernet0 switchport access vlan 10 spanning-tree portfast ! interface FastEthernet1 switchport access vlan 10 spanning-tree portfast ! interface FastEthernet2 switchport access vlan 10 spanning-tree portfast ! interface FastEthernet3 switchport access vlan 10 spanning-tree portfast ! interface loopback 5 ip address 10.10.10.1 255.255.255.255 no shutdown ! interface loopback 6 ip address 10.10.10.1 255.255.255.255 no shutdown ! interface loopback 7 ip address 10.10.10.1 255.255.255.255 no shutdown ! interface loopback 10 ip address 10.10.10.1 255.255.255.255 no shutdown ! interface loopback 11 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 ! interface FastEthernet0 switchport access vlan 10 spanning-tree portfast ! interface FastEthernet1 switchport access vlan 10 spanning-tree portfast ! interface FastEthernet2 switchport access vlan 10 spanning-tree portfast ! interface FastEthernet3 switchport access vlan 10 spanning-tree portfast ! interface loopback 5 ip address 10.10.10.1 255.255.255.255 no shutdown ! interface loopback 6 ip address 10.10.10.1 255.255.255.255 no shutdown ! interface loopback 7 ip address 10.10.10.1 255.255.255.255 no shutdown ! interface loopback 10 ip address 10.10.10.1 255.255.255.255 no shutdown ! interface loopback 11 ip address 10.10.10.1 255.255.255.255 no shutdown ! !

Template Router 1

Template Router 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 ! interface FastEthernet0 switchport access vlan 10 spanning-tree portfast ! interface FastEthernet1 switchport access vlan 10 spanning-tree portfast ! interface FastEthernet2 switchport access vlan 10 spanning-tree portfast ! interface FastEthernet3 switchport access vlan 10 spanning-tree portfast ! interface loopback 5 ip address 10.10.10.1 255.255.255.255 no shutdown ! interface loopback 6 ip address 10.10.10.1 255.255.255.255 no shutdown ! interface loopback 7 ip address 10.10.10.1 255.255.255.255 no shutdown ! interface loopback 10 ip address 10.10.10.1 255.255.255.255 no shutdown ! interface loopback 11 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 ! interface FastEthernet0 switchport access vlan 10 spanning-tree portfast ! interface FastEthernet1 switchport access vlan 10 spanning-tree portfast ! interface FastEthernet2 switchport access vlan 10 spanning-tree portfast ! interface FastEthernet3 switchport access vlan 10 spanning-tree portfast ! interface loopback 5 ip address 10.10.10.1 255.255.255.255 no shutdown ! interface loopback 6 ip address 10.10.10.1 255.255.255.255 no shutdown ! interface loopback 7 ip address 10.10.10.1 255.255.255.255 no shutdown ! interface loopback 10 ip address 10.10.10.1 255.255.255.255 no shutdown ! interface loopback 11 ip address 10.10.10.1 255.255.255.255 no shutdown ! !

Vocês podem observar que todas as loopbacks estão com o mesmo endereço IP, porém estou apenas demonstrando as possibilidades de trabalhar com esses valores e se for utilizar em seu ambiente de produção você terá que adequar suas variáveis/valores.

Pessoal espero que vocês tenham gostado dessa série, porque eu gostei muito de trabalhar com essas possibilidades e ao mesmo tempo empolgado pois podemos observar o potencial que temos em nossas mãos para começar a trabalhar com automações e dinamismo em nossas estruturas.

Se você acha que podemos evoluir nesse projeto acompanhe no meu GitHub e dê suas sugestões e se também acredita que gostaria de trazer mais exemplos aqui deixe seu comentário.

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ção – Parte 2

Thu, 26 Oct 2017 00:00:00 +0000

Olá Pessoal,

Conforme em nosso post anterior, hoje iremos tratar de um outro parâmetro, com o intuito de fazer validação das configurações em nossos equipamentos Cisco.

Baseando-se em nossas menções a configuração que iremos “confrontar” será a diferença que temos na “running-config” com nosso arquivo base ( intended ), ou seja, nesse post iremos agora mostrar o que temos de comandos adicionais na configuração que não esta presente em nosso arquivo padrão.

Vale lembrar que essa comparação será linha à linha, ou seja, para que isso faça mais sentido o ideal que você já tenha um template padrão de sua infra-estrutura aplicado para seus equipamentos, bem como, já tenha um histórico de armazenamento de configurações para começar a “confrontar” as configuração. É claro, que se você não tem, o importante é iniciar seu processo para backup de configuração ou criar políticas para que esse processo entre em produção, assim posteriomente, você pode revalidar suas configurações com o desejo de encontrar algo que foi alterado e que não deveria. 😉

Enfim, vamos ao nosso playbook onde iremos criar a validação. Devido ao teste eu acabei criando um processo anterior nesse script, baseando-se em configurações já apresentadas em posts anteriores sobre criação do “running-config“, devido a isso, eu apenas importei esse script para nosso playbook com a intenção de conseguir criar o arquivo inicial, e após isso, criar duas situações para comparar o antes e depois da mudança em nossa configuração do roteadore CSR1000V.

Segue abaixo nossa playbook

---
- 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: Capture running-config
    ios_command:
     provider: "{{ provider }}"
     commands:
        - show running-config
    register: running
    
  - name: Check that file exist
    stat:
      path: /home/rodrigo/Documents/ansible/IWAN Project/backup/{{ inventory_hostname }}_running.txt
    register: result_file

  - name: Save output running-config
    copy:
      content: "{{ running.stdout[0] }}"
      dest: "/home/rodrigo/Documents/ansible/IWAN Project/backup/{{ inventory_hostname }}_running.txt"
    when: result_file.stat.exists == False

  - name: Compare running-config with intended file
    ios_config:
      diff_against: intended
      provider: "{{ provider }}"
      intended_config: "{{ lookup('file', '/home/rodrigo/Documents/ansible/IWAN Project/backup/{{ inventory_hostname }}_running.txt') }}"
    register: test_diff

  - name: Take running-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 intended_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 intended_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 intended_config"
    debug:
      var: difference
    when: test_diff['diff'] is defined

No primeiro momento vocês podem observar que minha pasta não contém o arquivo, pois é a primeira vez que irei executar minha playbook. Após executar, vocês podem observar que tenho a mensagem de “ change ” em nosso “ log ” e consequentemente vamos observar que foi populado um novo arquivo em nosso servidor local ( ansible server ). \

Após criação de nosso arquivo, nesse momento é efetuado alteração em meu roteador ( running-config ) criando um usuário adicional, para que assim possamos validar as diferenças de configurações que existem entre nossas bases. Segue abaixo:

Com isso vocês agora podem observar que foi criado uma lógica de validação em relação ao meu arquivo de configuração ( running-config ), para que após a execução pela primeira vez da running-config ele não fique sobrescrevendo meu arquivo, para que desta forma, ela seja, minha configuração base ( intended ) que vou comparar posteriormente com o running-config. Abaixo você pode observar que existe uma ação ( skipping ) que é o momento de validação do arquivo existente, sendo que minha váriavel agora é ” True ” devido a isso minha tarefa em nossa playbook, não sera de fato executada ( gravar um novo arquivo ).

Podemos também observar outras ações que estão ocorrendo que é justamente as menções de diferenças entre os arquivos, que é demonstrador através do ” before ” e “ after “. Para que vocês possam entender o que representa output em azul trazendo numeros é simbolo é recomendado que visualize esse link.

Após todo essa validação o ideal que você faça as comparações do antes e depois de forma mais prática para seu output, pois, você pode obter linhas que de fato são adicionais em seu output, mas que de fato não foram alteradas. Devido a isso, foi necessário criar uma revalidação e ” sanitizar ” output utilizando as variáveis “ before ” e ” after ” para que possamos no final visualizar somente a linha que eu adicionei no running-config. Com esse output podemos concluir que de fato agora tenho uma alteração em meu equipamento que não deveria estar contido nele.

Espero que esse playbook possa dar um dinamismo maior para sua infra, na qual você precisa validar se algo foi alterado ( change ) em seu equipamento e que de fato posso ter impactado algum incidente reportado posteriomente sua change. Vale lembra que aqui estamos fazendo os testes em apenas 1 equipamento para qual a ideia é que isso possa ser escalonado dentro de seu ambiente. 😀

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 via Cisco Spark

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

Olá Pessoal,

Conforme venho trazendo em nosso BLOG as diretrizes do Ansible e as metodologias que ele traz para entrarmos de cabeça no DevOps, ou seja, hoje vou trazer uma outra ferramenta na intenção de criarmos interação entre elas, e assim, se obter de benefícios que possa trazer para nosso dia a dia, ou de idéias que possa oferecer para você trabalhar em seu dia a dia.

Você conhece o Spark? Se não conhece, eu gostaria de mencionar que ele é uma ferramenta de messaging e outros ítens adicionais como video calling, desenhos interativos, reunião on-line, white boarding etc. Como o próprio nome diz, ele é uma ferramenta da Cisco, que por sua vez, também pode trabalhar diversas formas, assim como outros messaging e interagindo através de BOT. Se quiser saber mais sobre a ferramenta visite o site do Cisco Spark.

Talvez você venha-se perguntar, deve custar uma fortuna ( rsrsrs ), mas nesse caso o Cisco Spark é uma ferramenta free, que inclusive você pode se registrar através do link informado acima. Claro que, se necessitar dos recursos adicionais para fazer video bridge terá licenças adicionais, mas para nosso propósito relacionado a notificação via Ansible o cadastro pode ser feito gratuitamente.

Depois dessa abordagem, para falar um pouco sobre essa ferramenta, gostaria de mencionar sobre outro parâmetro que terá muita importância na criação de nossa notificação via ansible em uma sala de bate papo do Spark. Para que esse processo aconteça, você necessita fazer acesso ao site do Developer do Cisco Spark, para que a partir desse acesso você consiga obter seu querido é amado token. ( rsrs ). Para acessar vá ao site developer do Cisco Spark e após logado em sua conta, clique em sua foto e guarde o seu token para que possamos utilizar posteriormente em nosso playbook. Veja abaixo:

Após esse processo voltamos ao nosso mundo de Ansible, onde podemos consultar através da documentação sobre a configuração de nossa integração com o Spark. Verifique o documento para obter os dados sobre o Ansible usando Spark.

Seguindo nosso projeto Ansible eu criei um arquivo chamado Spark.yaml que será utilizado para executar a notificação após a execução de nosso playbook. Fiquem a vontade de adicionar essas linhas onde melhor se encaixar em seu projeto.

---
- name: Cisco Spark - Text Message to a Room
  cisco_spark:
     recipient_type: roomId
     recipient_id: "{{ spark['roomId'] }}"
     message_type: markdown
     personal_token: "{{ spark['spark_token'] }}"
     message: "### {{ inventory_hostname }} - Show ip interfaces \n\n {{ interfaces.stdout }} \n\n"

Vale lembrar que o campos mencionados como ” roomId ” e ” spark_token ” são variáveis que devem ser adquiridas através do Spark e também no meu caso eu deixei esse valores com essas variáveis inseridas em nosso arquivo de ” secret.yaml “.

Para enviar sua notificação lembre-se de criar uma sala de bate papo no Spark, no meu caso eu criei como ” Playbook Notification “. Para que você descubra qual é seu ” roomId ” e necessario via developer webpage pesquisar pela API qual é o codigo da sala. Acesse API Reference -> Rooms -> Get Room Details

Após essa validação é necessario executar o ” RUN ” para que você capture seu ID, conforme abaixo:

Com essas informações você pode trabalhar da melhor maneira para publicar essa notificação, entretanto segue mensagem recebida depois de finalização de nosso playbook e consequentemente a informação desejada:

Com isso você podem perceber o poder que temos nas mãos após mostrar essas duas notificações. Lógico que não somente trabalhar com as notificações seja o mais interessante, mas aqui vocês podem observar que temos muita “ bala na agulha 😉 ” para desenvolver nossos BOTs e assim interagir com eles para execução de outras tarefas um pouco mais complexas.

Espero que vocês tenham gostado e novos posts serão publicados.

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 – Arquivo Usuário e Senhas

Wed, 12 Jul 2017 00:00:00 +0000

Olá Pessoal,

Como venho detalhando aos poucos nossa solução sobre Ansible, hoje venho aqui mencionar sobre uma dica para sua estrutura autenticação de usuário/senha para seus equipamentos, ou seja, desta forma fica mais prático no sentido de colocar seus usuarios unificados ou posteriormente vou detalhar sobre a criação de ” roles ” para acesso ao seus equipamentos.

Vocês podem ter observado a extensão que é utilizada pelo Ansible é definido como ” .yaml ” ou podemos verifcar em alguns casos arquivos salvos como ” .yml “. Definitivamente essa discussão pode ir longe, porém as duas extensões são praticamente a mesma coisa, porém hoje devido a estar mais consistente sempre iremos definir nossos arquivos como ” .yaml “. Vale ressaltar que a linguagem YAML não é de marcação.

Desta forma vamos criar nosso arquivo de senha, para que depois em nossos próximos posts, vou referenciar “ chamar ” esse arquivo para execução dele, fazendo assim o acesso aos meus equipamentos. Em nosso caso vou definir esse arquivo como sendo secret.yaml.

---
creds:
  username: rodrigo
  password: rodrigo
  auth_pass: rodrigo

Como podem observar todo arquivo que vamos criar a extensão “ .yaml ” sempre iniciará com ” — “, devido a este ponto na incialização do arquivo, a linguagem interpreta que é uma execução, e com isso conseguimos referenciar pelo nome em nosso arquivo que será construido chamando de playbook.

Vale lembrar para você que não viu nosso posts anteriores, recomendo para que você possa montar seus testes. 😉

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