Na próxima versão do Red Hat Ansible Engine 2.9, você encontrará melhorias impressionantes, algumas das quais estão descritas neste artigo. Como de costume, desenvolvemos melhorias no Ansible Network de forma aberta, com o apoio da comunidade. Junte-se a nós — confira e explore o plano de desenvolvimento para na página wiki para .
Como anunciamos recentemente, agora inclui Ansible Tower, Ansible Engine e todo o conteúdo do Ansible Network. Atualmente, a maioria das plataformas de rede populares é implementada através de módulos Ansible. Por exemplo:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- VyOS
A lista completa de plataformas que são totalmente suportadas pela Red Hat através da assinatura do Ansible Automation .
O que aprendemos
Nos últimos quatro anos, aprendemos muito sobre o desenvolvimento de uma plataforma de automação de redes. Também aprendemos que como os artefatos da plataforma são utilizados em playbooks e roles do Ansible pelos usuários finais. E aqui está o que descobrimos:
- As organizações automatizam dispositivos de vários fornecedores, não apenas de um.
- A automação é um fenômeno não apenas técnico, mas também cultural.
- A automação em larga escala de redes é mais complexa do que parece, devido aos princípios arquiteturais fundamentais do design de automação.
Quando discutimos nossos planos de desenvolvimento de longo prazo há mais de um ano, nossos clientes corporativos pediram o seguinte:
- A coleta de informações precisa ser melhor padronizada e alinhada com o fluxo de trabalho de automação para qualquer dispositivo.
- A atualização de configurações em dispositivos também precisa ser padronizada e alinhada, de modo que os módulos Ansible tratem da segunda metade do ciclo após a coleta de informações.
- São necessárias metodologias rigorosas e suportadas para transformar a configuração do dispositivo em dados estruturados. Nessa base, a fonte da verdade poderá ser transferida do dispositivo de rede.
Melhorias na coleta de dados
A coleta de dados de dispositivos de rede com Ansible muitas vezes ocorre de maneira aleatória. As plataformas de rede têm capacidades de coleta de dados em graus variados, mas têm quase nenhuma — ou mesmo nenhuma — funcionalidade para fazer parsing e padronizar a apresentação dos dados em pares chave-valor. Leia Ken Celenza sobre como é difícil e doloroso analisar e padronizar os dados coletados.
Você pode ter notado como trabalhamos na função Ansible Network Engine. Naturalmente, após 24 mil downloads, a função Network Engine rapidamente se tornou uma das mais populares no Ansible Galaxy para scripts de automação de rede. Antes de migrar muito disso para o Ansible 2.8, para nos prepararmos para o que será necessário no Ansible 2.9, essa função Ansible forneceu o primeiro conjunto de ferramentas para ajudar na análise de comandos, gerenciamento de equipes e coleta de dados para dispositivos de rede.
Se você está familiarizado com o uso do Network Engine, é uma maneira muito eficiente de coletar, analisar e padronizar dados de fatos para uso no Ansible. A desvantagem dessa função é que é necessário criar uma série de analisadores para cada plataforma e para toda atividade de rede. Para entender o quão complicado é criar, entregar e manter analisadores, veja dos caras da Cisco.
Em resumo, para automação em larga escala, é crucial obter fatos dos dispositivos e normalizá-los em pares chave-valor, mas isso é difícil quando você tem muitos fornecedores e plataformas de rede.
Agora, cada módulo de fatos de rede no Ansible 2.9 pode analisar a configuração do dispositivo de rede e retornar dados estruturados — sem bibliotecas adicionais, funções Ansible ou analisadores personalizados.
A partir do Ansible 2.9, a cada lançamento de um módulo de rede atualizado, o módulo de fatos é melhorado para fornecer dados sobre esta seção da configuração. Ou seja, a evolução dos fatos e módulos agora ocorre em um ritmo comum, e eles sempre terão uma estrutura de dados compartilhada.
A configuração de recursos em um dispositivo de rede pode ser extraída e transformada em dados estruturados de duas maneiras. Ambas as maneiras podem reunir e transformar uma lista específica de recursos com a nova palavra-chave gather_network_resources. Os nomes dos recursos correspondem aos nomes dos módulos, e isso é muito conveniente.
Durante a coleta de fatos:
Com a palavra-chave gather_facts , é possível extrair a configuração atual do dispositivo no início do playbook, e depois usá-la ao longo de todo o playbook. Especifique os recursos individuais que precisam ser extraídos do dispositivo.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueVocê pode ter notado algo novo nesses exemplos, a saber — gather_facts: true agora disponível para coleta nativa de fatos para dispositivos de rede.
Uso do módulo de fatos de rede diretamente:
- name: coletar fatos de configuração da interface
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesO playbook retorna os seguintes fatos sobre a interface:
ansible_facts:
ansible_network_resources:
interfaces:
- enabled: true
name: Ethernet1
mtu: '1476'
- enabled: true
name: Loopback0
- enabled: true
name: Loopback1
- enabled: true
mtu: '1476'
name: Tunnel0
- enabled: true
name: Ethernet1
- enabled: true
name: Tunnel1
- enabled: true
name: Ethernet1Note como o Ansible extrai a configuração nativa do dispositivo Arista e a converte em dados estruturados para uso como pares chave-valor padrão para tarefas e operações subsequentes.
Os fatos da interface podem ser adicionados a variáveis persistentes do Ansible e usados imediatamente ou depois como entrada para o módulo de recurso eos_interfaces sem processamento ou transformação adicional.
Módulos de recursos
Portanto, extraímos os fatos, normalizamos os dados, os inserimos em um esquema interno de estrutura de dados padronizado e obtemos uma fonte de verdade pronta. Uhul! Isso é ótimo, mas ainda precisamos de alguma forma de converter os pares chave-valor de volta na configuração específica que a plataforma do dispositivo espera. Agora precisamos de módulos para plataformas específicas para atender a esses novos requisitos de coleta de fatos e normalização.
O que é um módulo de recurso? As seções de configuração do dispositivo podem ser vistas como recursos oferecidos por esse dispositivo. Os módulos de recursos de rede são intencionalmente limitados a um único recurso e podem ser combinados, como blocos de montar, para configurar serviços de rede complexos. Como resultado, os requisitos e a especificação para um módulo de recurso se tornam naturalmente mais simples, pois o módulo de recurso pode ler e configurar um serviço de rede específico em um dispositivo de rede.
Para explicar o que faz um módulo de recurso, vamos examinar um exemplo de playbook que demonstra uma operação idempotente usando os novos fatos de recurso de rede e o módulo eos_l3_interface.
- nome: exemplo de fatos sendo enviados de volta para o dispositivo.
hosts: arista
gather_facts: false
tasks:
- nome: capturar fatos eos da arista
eos_facts:
gather_subset: min
gather_network_resources: l3_interfaces
- nome: garantir que as informações do endereço IP estão corretas
eos_l3_interfaces:
config: "{{ ansible_network_resources['l3_interfaces'] }}"
register: result
- nome: garantir que a configuração não mudou
assert:
that: not result.changedComo você pode ver, os dados coletados do dispositivo são enviados diretamente para o módulo de recursos relevante sem transformação. Ao executar o playbook, ele extrai os valores do dispositivo e os compara com os esperados. Neste exemplo, os valores obtidos correspondem aos esperados (ou seja, a verificação de desvios de configuração é realizada) e uma mensagem é exibida, indicando se a configuração foi alterada.
A maneira ideal de detectar desvios de configuração é armazenar os fatos em variáveis persistentes do Ansible e usá-las periodicamente com o módulo de recursos em modo de verificação. Este é um método simples para ver se alguém alterou valores manualmente. Na maioria dos casos, as organizações permitem alterações e configurações manuais, embora muitas operações sejam realizadas por meio da Automação Ansible.
O que diferencia os novos módulos de recursos dos anteriores?
Para um engenheiro de automação de redes, existem 3 principais diferenças nos módulos de recursos no Ansible 2.9 em comparação com versões anteriores.
1) Para um determinado recurso de rede (que também pode ser visto como uma seção de configuração), os módulos e fatos se desenvolverão em todos os sistemas operacionais de rede suportados simultaneamente. Acreditamos que, se o Ansible suporta a configuração de um recurso em uma plataforma de rede, devemos suportá-la em todos os lugares. Isso facilita o uso dos módulos de recursos, pois o engenheiro de automação de redes agora pode configurar um recurso (como LLDP) em todos os sistemas operacionais de rede com módulos nativos e suportados.
2) Agora, os módulos de recursos incluem um valor de estado.
mesclado: configuração mesclada com a configuração fornecida (por padrão);substituído: a configuração do recurso será substituída pela configuração fornecida;substituído: a configuração do recurso será substituída pela configuração fornecida; instâncias extras de recursos serão removidas;deleted: a configuração do recurso será removida/restaurada por padrão.
3) Os módulos de recursos agora incluem valores de retorno estáveis. Quando o módulo de recursos de rede faz (ou sugere) as alterações necessárias no dispositivo de rede, ele retorna os mesmos pares chave-valor no playbook.
before: configuração no dispositivo na forma de dados estruturados até a tarefa;depois: se o dispositivo mudou (ou pode mudar, se o modo de verificação estiver em uso), a configuração resultante será retornada na forma de dados estruturados;comandos: quaisquer comandos de configuração executados no dispositivo para levá-lo ao estado desejado.
O que tudo isso significa? Por que é importante?
Este post descreve muitos conceitos complexos, mas esperamos que, no final, você entenda melhor o que os clientes corporativos pedem em termos de coleta de fatos, normalização de dados e configuração do ciclo para a plataforma de automação. Mas por que eles precisam dessas melhorias? Atualmente, muitas organizações estão passando por transformações digitais para tornar seus ambientes de TI mais ágeis e competitivos. Bom ou ruim, muitos engenheiros de rede estão se tornando desenvolvedores de rede — por interesse próprio ou a pedido de gerentes.
As organizações compreendem que a automação de templates de rede isolados não resolve o problema da fragmentação e aumenta a eficiência apenas até certo ponto. A plataforma Red Hat Ansible Automation Platform fornece modelos de dados de recursos rigorosos e normalizadores para gerenciar programaticamente os dados subjacentes em dispositivos de rede. Ou seja, os usuários estão gradualmente abandonando métodos individuais de configuração em favor de abordagens mais modernas focadas em tecnologia (como endereços IP, VLAN, LLDP, etc.), em vez de implementações específicas de fornecedores.
Isso significa que os dias de módulos de configuração e de comandos confiáveis e testados estão contados? De forma alguma. Os módulos de gerenciamento de rede previstos não serão aplicáveis em todos os casos e para cada fornecedor, portanto, os módulos de comandos e de configuração ainda serão necessários para os engenheiros de rede em certas implementações. O objetivo dos módulos de recursos é simplificar grandes modelos Jinja e normalizar configurações não estruturadas de dispositivos em um formato JSON estruturado. Com os módulos de recursos, redes existentes encontrarão mais fácil transformar suas configurações em pares de chave-valor estruturados que servirão como uma fonte de verdade legível. Usando pares de chave-valor estruturados, é possível passar de executar configurações em cada dispositivo para trabalhar com dados estruturados independentes e colocar a rede em destaque na abordagem de 'infraestrutura como código'.
Quais módulos de recursos aparecerão no Ansible Engine 2.9?
Antes de detalharmos o que estará no Ansible 2.9, vamos relembrar como dividimos todo o escopo de trabalho.
Identificamos 7 categorias e atribuímos determinados recursos de rede a cada uma:
Nota: recursos destacados em negrito foram planejados e implementados no Ansible 2.9.
Com base no feedback de clientes corporativos e da comunidade, fez sentido abordar inicialmente aqueles módulos que estão relacionados aos protocolos de topologia de rede, virtualização e interfaces.
Os seguintes módulos de recursos foram desenvolvidos pela equipe Ansible Network e correspondem às plataformas suportadas pela Red Hat:
Os seguintes módulos foram desenvolvidos pela comunidade Ansible:
exos_lldp_global— da Extreme Networks.nxos_bfd_interfaces— da Cisconxos_telemetry— da Cisco
Como você pode ver, o conceito de módulos de recursos se encaixa em nossa estratégia de orientação para plataformas. Ou seja, estamos incorporando as capacidades e funcionalidades necessárias diretamente no Ansible para apoiar a padronização no desenvolvimento de módulos de rede, além de simplificar o trabalho dos usuários em termos de funções e playbooks do Ansible. Para expandir o desenvolvimento de módulos de recursos, a equipe do Ansible lançou a ferramenta Module Builder.
Planos para o Ansible 2.10 e além
Após o lançamento do Ansible 2.9, focaremos no próximo conjunto de módulos de recursos para o Ansible 2.10, que poderão ser usados para configuração adicional de topologia e política de rede, como O plano de desenvolvimento ainda pode ser ajustado, então, se você tiver comentários, informe-os na .
Recursos e início do trabalho
Fonte: habr.com
