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 “.
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.
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.
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.
--- - 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
Comentários Recentes