Geekly articles weekly

Novos Recursos de Automação de Rede no Red Hat Ansible

À luz de melhorias significativas implementadas no Ansible Engine 2.6, além de levar em consideração o lançamento do Ansible Tower 3.3 e o lançamento recente do Ansible Engine 2.7, vamos examinar mais de perto as perspectivas de automação de rede.



Neste post:

  • Plug-in de conexão Httpapi.
    • Suporte para Arista eAPI e Cisco NX-API.
  • Novos módulos de automação de rede.
    • net_get e net_put.
    • netconf_get, netconf_rpc e netconf_config.
    • cli_command e cli_config.
  • Interface da web do Ansible Tower aprimorada.
  • Gerencie credenciais no Ansible Tower ao trabalhar com dispositivos de rede.
  • Usando versões diferentes do Ansible no Tower ao mesmo tempo

Não esqueça que o lançamento de cada nova versão do Ansible é acompanhado por uma atualização do guia de portabilidade , o que facilitará bastante a transição para a nova versão.

Plug-in de Conexão HTTPAPI


São os plug-ins de conexão que permitem ao Ansible conectar-se aos hosts de destino e, em seguida, executar tarefas neles. Começando com o Ansible 2.5, um novo plugin desse tipo chamado network_cli apareceu. Ele elimina a necessidade de usar o parâmetro provider e padroniza a ordem de execução dos módulos de rede, como resultado dos playbooks para dispositivos de rede agora que são executados, executados e funcionam da mesma maneira que playbooks para hosts Linux. Por sua vez, para o Ansible Tower, a diferença entre dispositivos de rede e hosts desaparece e não é mais necessário distinguir entre nomes de usuário e senhas para dispositivos de rede e máquinas. Isso foi discutido com mais detalhes aqui , mas, em suma, as senhas de login do servidor Linux e do switch Arista EOS ou roteador Cisco agora podem ser usadas e armazenadas de maneira semelhante.

No Ansible 2.5, a conexão através dos métodos eAPI e NX-API só era possível usando o antigo método de provedor. O Ansible 2.6 não possui mais essa limitação e você pode usar livremente o método de conexão httpapi de alto nível. Vamos ver como isso é feito.

Você deve primeiro ativar a eAPI ou NX-API no dispositivo de rede para poder usar o método httpapi. Isso é feito facilmente pela equipe Ansible apropriada, por exemplo, veja como habilitar a eAPI em um switch Arista EOS.

[user@rhel7]$ ansible -m eos_eapi -c network_cli leaf01 leaf01 | SUCCESS => { "ansible_facts": { "eos_eapi_urls": { "Ethernet1": [ "https://192.168.0.14:443" ], "Management1": [ "https://10.0.2.15:443" ] } }, "changed": false, "commands": [] }

Quando conectado a um switch Arista EOS real, o comando show management api http-command mostrará que a API está ativada:

 leaf01# show management api http-commands Enabled: Yes HTTPS server: running, set to use port 443 <<<rest of output removed for brevity>>>

O script Ansible Playbook abaixo simplesmente executa o comando show version e, em seguida, na seção de depuração, retorna apenas a versão da saída JSON da tarefa.

 --- - hosts: leaf01 connection: httpapi gather_facts: false tasks: - name: type a simple arista command eos_command: commands: - show version | json register: command_output - name: print command output to terminal window debug: var: command_output.stdout[0]["version"]

A execução desse script resultará no seguinte resultado:

 [user@rhel7]$ ansible-playbook playbook.yml PLAY [leaf01]******************************************************** TASK [type a simple arista command] ********************************* ok: [leaf01] TASK [print command output to terminal window] ********************** ok: [leaf01] => { "command_output.stdout[0][\"version\"]": "4.20.1F" } PLAY RECAP*********************************************************** leaf01 : ok=2 changed=0 unreachable=0 failed=0

NOTA: O Arista eAPI não oferece suporte a versões abreviadas de comandos (como “show ver” em vez de “show version2), portanto, é necessário escrever todos eles. Para obter mais informações sobre o plugin de conexão httpapi, consulte a documentação.

Novos módulos de automação de rede


O Ansible 2.6 e a versão 2.7 lançada em outubro oferecem sete novos módulos para automação de rede.

  • net_get - Copia um arquivo de um dispositivo de rede para o Ansible Controller.
  • net_put - Copia um arquivo do Ansible Controller para um dispositivo de rede.
  • netconf_get - Recupera dados de configuração / status de um dispositivo de rede com o NETCONF ativado.
  • netconf_rpc - Executa operações em um dispositivo de rede com o NETCONF ativado.
  • netconf_config - configuração do dispositivo netconf , o módulo permite ao usuário enviar um arquivo XML para os dispositivos netconf e verificar se a configuração foi alterada.
  • cli_command - executa o comando cli em dispositivos de rede que possuem uma interface de comando (cli).
  • cli_config - envia (push) a configuração de texto para os dispositivos de rede via network_cli.

net_get e net_put


  • net_get - Copia um arquivo de um dispositivo de rede para o Ansible Controller.
  • net_put - Copia um arquivo do Ansible Controller para um dispositivo de rede.

Os módulos net_get e net_put não estão vinculados ao equipamento de nenhum fabricante em particular e simplesmente copiam arquivos do dispositivo de rede para dispositivos usando os protocolos de transferência SCP ou SFTP padrão (especificados pelo parâmetro de protocolo). Ambos os módulos requerem o uso do método de conexão network_cli e também funcionam apenas se scp (pip install scp) estiver instalado no controlador e SCP ou SFTP estiver ativado no dispositivo de rede.

Assumimos que, no exemplo do nosso manual, já executamos o seguinte comando no dispositivo Leaf01:

 leaf01#copy running-config flash:running_cfg_eos1.txt Copy completed successfully.

Aqui está a aparência de um manual com duas tarefas (a primeira copia o arquivo do dispositivo Leaf01 e a segunda copia o arquivo para o dispositivo Leaf01):

 --- - hosts: leaf01 connection: network_cli gather_facts: false tasks: - name: COPY FILE FROM THE NETWORK DEVICE TO ANSIBLE CONTROLLER net_get: src: running_cfg_eos1.txt - name: COPY FILE FROM THE ANSIBLE CONTROLLER TO THE NETWORK DEVICE net_put: src: temp.txt

netconf_get, netconf_rpc e netconf_config



  • netconf_get - Recupera dados de configuração / status de um dispositivo de rede com o NETCONF ativado.
  • netconf_rpc - Executa operações em um dispositivo de rede com o NETCONF ativado.
  • netconf_config - configuração do dispositivo netconf , o módulo permite ao usuário enviar um arquivo XML para os dispositivos netconf e verificar se a configuração foi alterada.

Protocolo de Gerenciamento de Rede O NETCONF (Protocolo de Configuração de Rede) é desenvolvido e padronizado pela IETF. De acordo com a RFC 6241, o NETCONF pode ser usado para instalar, manipular e excluir configurações de dispositivos de rede. NETCONF é uma alternativa à linha de comando SSH (network_cli) e APIs como Cisco NX-API ou Arista eAPI (httpapi).

Para demonstrar os novos módulos netconf, primeiro habilitamos o netconf nos roteadores Juniper usando o módulo junos_netconf . O Netconf não é suportado em todos os modelos de equipamentos de rede; portanto, verifique sua documentação antes de usá-lo.

 [user@rhel7 ~]$ ansible -m junos_netconf juniper -c network_cli rtr4 | CHANGED => { "changed": true, "commands": [ "set system services netconf ssh port 830" ] } rtr3 | CHANGED => { "changed": true, "commands": [ "set system services netconf ssh port 830" ] }

A Juniper Networks oferece o Junos XML API Explorer para tags operacionais e para tags de configuração . Considere o exemplo da solicitação operacional que a Juniper Networks usa em sua documentação para ilustrar a solicitação RPC para uma interface específica.

 <rpc> <get-interface-information> <interface-name>ge-2/3/0</interface-name> <detail/> </get-interface-information> </rpc> ]]>]]>

É facilmente traduzido para o Ansible Playbook. get-interface-information é uma chamada RPC e parâmetros adicionais são especificados como pares de valor-chave. Neste exemplo, existe apenas um parâmetro - interface-name - e, em nosso dispositivo de rede, queremos apenas examinar o em1.0. Usamos o parâmetro de registro que foi definido para a tarefa, apenas para salvar os resultados, portanto, usamos o módulo de depuração e exibimos os resultados na tela do terminal. O módulo netconf_rpc também permite converter a saída XML diretamente para JSON.

 --- - name: RUN A NETCONF COMMAND hosts: juniper gather_facts: no connection: netconf tasks: - name: GET INTERFACE INFO netconf_rpc: display: json rpc: get-interface-information content: interface-name: "em1.0" register: netconf_info - name: PRINT OUTPUT TO TERMINAL WINDOW debug: var: netconf_info

Depois de iniciar o manual, obtemos o seguinte:

 ok: [rtr4] => { "netconf_info": { "changed": false, "failed": false, "output": { "rpc-reply": { "interface-information": { "logical-interface": { "address-family": [ { "address-family-flags": { "ifff-is-primary": "" }, "address-family-name": "inet", "interface-address": [ { "ifa-broadcast": "10.255.255.255", "ifa-destination": "10/8", "ifa-flags": { "ifaf-current-preferred": "" }, "ifa-local": "10.0.0.4" }, <<<rest of output removed for brevity>>>

Para obter mais informações, consulte o Juniper Platform Guide e a documentação NETCONF .

cli_command e cli_config


  • cli_command - executa um comando em dispositivos de rede usando sua interface de linha de comando (se houver).
  • cli_config - envia (push) a configuração de texto para os dispositivos de rede via network_cli.

Os módulos cli_command e cli_config que apareceram no Ansible Engine 2.7 também não estão vinculados ao equipamento de um fabricante específico e podem ser usados ​​para automatizar várias plataformas de rede. Eles são baseados no valor da variável ansible_network_os (configurada no arquivo de inventário ou na pasta group_vars) para usar o plug-in cliconf desejado. Uma lista de todos os valores da variável ansible_network_os é fornecida na documentação . Nesta versão do Ansible, você ainda pode usar os módulos antigos para plataformas específicas; portanto, reserve um tempo para reescrever os playbooks existentes. Para mais informações, consulte os guias oficiais de portabilidade .



Vamos ver como esses módulos são usados ​​no Ansible Playbook. Este manual será executado em dois sistemas Cisco Cloud Services Routers (CSR) executando o IOS-XE. A variável ansible_network_os no arquivo de inventário está configurada para ios.

 <config snippet from inventory> [cisco] rtr1 ansible_host=34.203.197.120 rtr2 ansible_host=34.224.60.230 [cisco:vars] ansible_ssh_user=ec2-user ansible_network_os=ios

Aqui está como cli_config e cli_command são usados:

 --- - name: AGNOSTIC PLAYBOOK hosts: cisco gather_facts: no connection: network_cli tasks: - name: CONFIGURE DNS cli_config: config: ip name-server 8.8.8.8 - name: CHECK CONFIGURATION cli_command: command: show run | i ip name-server register: cisco_output - name: PRINT OUTPUT TO SCREEN debug: var: cisco_output.stdout

E aqui está a saída deste manual:

 [user@rhel7 ~]$ ansible-playbook cli.yml PLAY [AGNOSTIC PLAYBOOK] ********************************************* TASK [CONFIGURE DNS] ************************************************* ok: [rtr1] ok: [rtr2] TASK [CHECK CONFIGURATION] ******************************************* ok: [rtr1] ok: [rtr2] TASK [PRINT OUTPUT TO SCREEN] **************************************** ok: [rtr1] => { "cisco_output.stdout": "ip name-server 8.8.8.8" } ok: [rtr2] => { "cisco_output.stdout": "ip name-server 8.8.8.8" } PLAY RECAP ********************************************************** rtr1 : ok=3 changed=0 unreachable=0 failed=0 rtr2 : ok=3 changed=0 unreachable=0 failed=0

Observe que esses módulos são idempotentes desde que você use a sintaxe apropriada para os dispositivos de rede correspondentes.

Interface de torre Ansible aprimorada


A interface da Web no Red Hat Ansible Tower 3.3 tornou-se mais conveniente e funcional, permitindo menos cliques ao executar várias tarefas.



Gerenciamento de credenciais, agendador de tarefas, scripts de inventário, controle de acesso baseado em funções, notificações e muito mais agora são coletados no menu principal no lado esquerdo da tela e estão disponíveis em um clique. A tela de visualização de tarefas exibe imediatamente informações adicionais importantes: quem iniciou a tarefa e quando; que inventário foi desenvolvido durante sua implementação; de que projeto foi retirado o manual.



Gerenciar credenciais para dispositivos de rede no Ansible Tower


O Red Hat Ansible Tower 3.3 facilita muito o gerenciamento de senhas de login para dispositivos de rede. Na nova interface da web, o comando Credenciais está localizado imediatamente no menu principal, no grupo Recursos.



O Ansible Tower 3.3 deixou uma credencial chamada "rede" especial (Rede), que define as variáveis ​​de ambiente ANSIBLE_NET_USERNAME e ANSIBLE_NET_PASSWORD usadas no método antigo do provedor. Tudo isso ainda funciona, conforme escrito na documentação , para que você possa usar os scripts existentes do Ansible Playbooks.No entanto, para os novos métodos de alto nível de conexão de httpapi e network_cli, o tipo de credencial de rede não é mais necessário, pois agora o Ansible trabalha igualmente com os logins de senha, como em conexão a dispositivos de rede e, portanto, ao conectar-se a hosts Linxu. Portanto, para dispositivos de rede, agora você precisa selecionar o tipo de credencial da máquina - basta selecioná-lo e inserir sua senha de login ou fornecer uma chave SSH.



NOTA: O Ansible Tower criptografa a senha imediatamente após salvar as credenciais.



Graças à criptografia, as credenciais podem ser delegadas com segurança a outros usuários e grupos - eles simplesmente não verão ou reconhecerão a senha. Para obter mais informações sobre como as credenciais funcionam, qual criptografia é usada e que outros tipos de credenciais (como Amazon AWS, Microsoft Azure e Google GCE) podem ser encontrados na documentação da Ansible Tower .

Uma descrição mais detalhada do Red Hat Ansible Tower 3.3 pode ser encontrada aqui .

Usando versões diferentes do Ansible no Tower ao mesmo tempo


Suponha que queremos que alguns manuais sejam executados no Ansible Engine 2.4.2 e outros no Ansible Engine 2.6.4. O Tower possui uma ferramenta virtualenv especial para criar caixas de proteção Python para evitar conflitos com dependências conflitantes e versões diferentes. O Ansible Tower 3.3 permite definir o virtualenv em diferentes níveis - Organização, Projeto ou Modelo de Trabalho. É assim que o Modelo de trabalho que criamos na Ansible Tower para fazer backup de nossa rede é semelhante.



Quando você possui pelo menos dois ambientes virtuais, o menu suspenso Ansible Environment aparece no menu principal do Ansible Tower, onde é possível especificar facilmente qual versão do Ansible deve ser usada ao executar a tarefa.



Portanto, se você tiver uma combinação de playbooks para automatizar a rede, alguns dos quais usam o método antigo do provedor (Ansible 2.4 e versões anteriores) e alguns usam novos plugins httpapi ou network_cli (Ansible 2.5 e superior), é possível atribuir facilmente cada tarefa Versão Ansible. Além disso, esse recurso será útil se os desenvolvedores e a produção usarem versões diferentes do Ansible. Em outras palavras, você pode atualizar o Tower com segurança, sem se preocupar com o fato de que depois disso você precisará mudar para qualquer versão do Ansible Engine, o que aumenta bastante a flexibilidade na automação de vários tipos de equipamentos e ambientes de rede, além de cenários de uso.

Para obter mais informações sobre o uso do virtualenv, consulte a documentação .

Source: https://habr.com/ru/post/pt436318/

More articles:


All Articles