A próxima versão do Red Hat Ansible Engine 2.9 traz melhorias interessantes, algumas das quais são discutidas neste artigo. Como sempre, temos desenvolvido melhorias na Rede Ansible de forma aberta e com o apoio da comunidade. Junte-se a nós - dê uma olhada em e estudar o plano de desenvolvimento para na página wiki para .
Como anunciamos recentemente, agora inclui Ansible Tower, Ansible Engine e todo o conteúdo da Ansible Network. Hoje em dia, as plataformas de rede mais populares são implementadas através de módulos Ansible. Por exemplo:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Junípero Junos
- VyOS
Para obter uma lista completa de plataformas totalmente suportadas pela Red Hat por meio da assinatura do Ansible Automation, .
O que aprendemos
Nos últimos quatro anos, aprendemos muito sobre o desenvolvimento de uma plataforma de automação de rede. Também aprendemos que como os artefatos da plataforma são usados em manuais e funções do Ansible pelos usuários finais. E aqui está o que descobrimos:
- As organizações estão automatizando dispositivos não de apenas um, mas de vários fornecedores.
- A automação não é apenas um fenômeno técnico, mas também cultural.
- Automatizar redes em escala é mais difícil do que parece devido aos princípios arquitetônicos fundamentais do projeto de automação.
Quando discutimos nossos planos de crescimento de longo prazo há mais de um ano, nossos clientes corporativos solicitaram o seguinte:
- A coleta de fatos precisa ser melhor padronizada e alinhada com fluxos de trabalho de automação em todos os dispositivos.
- A atualização das configurações no dispositivo também precisa ser padronizada e consistente para que os módulos Ansible lidem com a segunda metade do ciclo após a coleta dos fatos.
- Precisamos de métodos rigorosos e suportados para converter a configuração do dispositivo em dados estruturados. Nesta base, a fonte da verdade pode ser movida do dispositivo de rede.
Melhorias nos fatos
A coleta de fatos de dispositivos de rede usando Ansible geralmente acontece de forma aleatória. As plataformas de rede têm vários graus de capacidade de coleta de fatos, mas têm pouca ou nenhuma funcionalidade para analisar e padronizar a representação de valores-chave dos dados. Ler Ken Celenza sobre como pode ser difícil e doloroso analisar e padronizar dados factuais.
Você deve ter notado que estamos trabalhando na função Ansible Network Engine. Naturalmente, após downloads de 24K, a função Network Engine rapidamente se tornou uma das funções mais populares do Ansible no Ansible Galaxy para cenários de automação de rede. Antes de migrarmos grande parte disso para o Ansible 2.8 para nos prepararmos para o que seria necessário no Ansible 2.9, essa função do Ansible forneceu o primeiro conjunto de ferramentas para ajudar a analisar comandos, gerenciar comandos e coletar dados para dispositivos de rede.
Se você sabe usar o Network Engine, esta é uma maneira muito eficiente de coletar, analisar e padronizar dados de fatos para uso no Ansible. A desvantagem dessa função é que você precisa criar vários analisadores para cada plataforma e para todas as atividades da rede. Para entender como é difícil criar, enviar e manter analisadores, dê uma olhada em dos caras da Cisco.
Resumindo, obter fatos dos dispositivos e normalizá-los em pares de valores-chave é essencial para a automação em escala, mas conseguir isso é difícil quando você tem muitos fornecedores e plataformas de rede.
Cada módulo de fatos de rede no Ansible 2.9 agora pode analisar a configuração de um dispositivo de rede e retornar dados estruturados – sem bibliotecas adicionais, funções Ansible ou analisadores personalizados.
Desde o Ansible 2.9, cada vez que um módulo de rede atualizado é lançado, o módulo de fatos é aprimorado para fornecer dados sobre esta seção da configuração. Ou seja, o desenvolvimento de fatos e módulos passa a ocorrer no mesmo ritmo, e eles sempre terão uma estrutura de dados comum.
A configuração dos recursos em um dispositivo de rede pode ser recuperada e convertida em dados estruturados de duas maneiras. Em ambas as formas, você pode coletar e transformar uma lista específica de recursos usando uma nova palavra-chave gather_network_resources. Os nomes dos recursos correspondem aos nomes dos módulos, o que é muito conveniente.
Ao coletar fatos:
Usando uma palavra-chave gather_facts você pode recuperar a configuração atual do dispositivo no início do manual e usá-la em todo o manual. Especifique os recursos individuais a serem recuperados do dispositivo.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueVocê deve ter notado algo novo nestes exemplos, a saber - gather_facts: true agora está disponível para coleta de fatos nativos para dispositivos de rede.
Usando o módulo de fatos de rede diretamente:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesO manual 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: Ethernet1Observe como o Ansible recupera a configuração nativa do dispositivo Arista e a transforma em dados estruturados para usar como pares de valores-chave padrão para tarefas e operações downstream.
Os fatos da interface podem ser adicionados às variáveis armazenadas do Ansible e usados imediatamente ou mais tarde como entrada para um módulo de recurso eos_interfaces sem processamento ou conversão adicional.
Módulos de Recursos
Assim, extraímos os fatos, normalizamos os dados, encaixamos-os em um diagrama de estrutura de dados interna padronizada e recebemos uma fonte de verdade pronta. Viva! Isso é ótimo, é claro, mas ainda precisamos converter de alguma forma os pares de valores-chave de volta para a configuração específica que a plataforma específica do dispositivo espera. Agora precisamos de módulos específicos de plataforma para atender a esses novos requisitos de coleta de fatos e normalização.
O que é um módulo de recursos? Você pode pensar nas seções de configuração de um dispositivo como recursos fornecidos por esse dispositivo. Os módulos de recursos de rede são intencionalmente limitados a um único recurso e podem ser empilhados como blocos de construção para configurar serviços de rede complexos. Como resultado, os requisitos e especificações para um módulo de recursos são naturalmente simplificados, uma vez que o módulo de recursos pode ler и configurar um serviço de rede específico em um dispositivo de rede.
Para explicar o que um módulo de recurso faz, vejamos um manual de exemplo que mostra uma operação idempoderante usando novos recursos de rede e fatos do módulo eos_l3_interface.
- name: example of facts being pushed right back to device.
hosts: arista
gather_facts: false
tasks:
- name: grab arista eos facts
eos_facts:
gather_subset: min
gather_network_resources: l3_interfaces
- name: ensure that the IP address information is accurate
eos_l3_interfaces:
config: "{{ ansible_network_resources['l3_interfaces'] }}"
register: result
- name: ensure config did not change
assert:
that: not result.changedComo você pode ver, os dados coletados do dispositivo são transferidos diretamente para o módulo de recurso correspondente sem conversão. Quando iniciado, o playbook recupera valores do dispositivo e os compara com os valores esperados. Neste exemplo, os valores retornados são os esperados (ou seja, verifica desvios de configuração) e informa se a configuração foi alterada.
A maneira ideal de detectar desvios de configuração é armazenar fatos em variáveis armazenadas do Ansible e usá-los periodicamente com o módulo de recursos no modo de inspeção. Este é um método simples para ver se alguém alterou manualmente os valores. Na maioria dos casos, as organizações permitem alterações e configurações manualmente, embora muitas operações sejam realizadas por meio do Ansible Automation.
Como os novos módulos de recursos diferem dos anteriores?
Para um engenheiro de automação de rede, existem três diferenças principais entre os módulos de recursos do Ansible 3 e das versões anteriores.
1) Para um determinado recurso de rede (que também pode ser considerado uma seção de configuração), módulos e fatos evoluirão simultaneamente em todos os sistemas operacionais de rede suportados. Acreditamos que se o Ansible oferece suporte à configuração de recursos em uma plataforma de rede, deveríamos apoiá-lo em todos os lugares. Isso simplifica o uso de módulos de recursos porque um engenheiro de automação de rede agora pode configurar um recurso (como LLDP) em todos os sistemas operacionais de rede com módulos nativos e suportados.
2) Os módulos de recursos agora incluem um valor de estado.
merged: a configuração é mesclada com a configuração fornecida (padrão);replaced: A configuração do recurso será substituída pela configuração fornecida;overridden: A configuração do recurso será substituída pela configuração fornecida; instâncias de recursos desnecessárias serão excluídas;deleted: a configuração do recurso será excluída/restaurada para o padrão.
3) Os módulos de recursos agora incluem valores de retorno estáveis. Quando o módulo de recursos de rede tiver feito (ou proposto) as alterações necessárias no dispositivo de rede, ele retornará os mesmos pares de valores-chave ao manual.
before: configuração no dispositivo em forma de dados estruturados antes da tarefa;after: se o dispositivo foi alterado (ou pode mudar se for utilizado o modo de teste), a configuração resultante será retornada como dados estruturados;commands: quaisquer comandos de configuração são executados no dispositivo para colocá-lo no estado desejado.
O que tudo isso significa? Por que isso é importante?
Esta postagem cobre muitos conceitos complexos, mas esperamos que no final você tenha uma melhor compreensão do que os clientes corporativos estão solicitando em termos de coleta de fatos, normalização de dados e configuração de loop para uma plataforma de automação. Mas por que eles precisam dessas melhorias? Muitas organizações estão agora buscando a transformação digital para tornar seus ambientes de TI mais ágeis e competitivos. Para o bem ou para o mal, muitos engenheiros de rede tornam-se desenvolvedores de rede por interesse próprio ou por ordem da administração.
As organizações estão percebendo que a automação de modelos de rede individuais não resolve o problema dos silos e apenas aumenta a eficiência até certo ponto. O Red Hat Ansible Automation Platform fornece modelos de dados de recursos rigorosos e normativos para gerenciar programaticamente os dados subjacentes em um dispositivo de rede. Ou seja, os usuários estão gradualmente abandonando métodos de configuração individuais em favor de métodos mais modernos com ênfase em tecnologias (por exemplo, endereços IP, VLANs, LLDP, etc.), em vez de na implementação específica de um fornecedor.
Isso significa que os dias de módulos de comando e configurações confiáveis e comprovados estão contados? Em nenhum caso. Os módulos de recursos de rede esperados não serão aplicáveis em todos os casos ou para todos os fornecedores, portanto, os módulos de comando e configuração ainda serão necessários aos engenheiros de rede para determinadas implementações. O objetivo dos módulos de recursos é simplificar grandes modelos Jinja e normalizar configurações de dispositivos não estruturados em um formato JSON estruturado. Com módulos de recursos, será mais fácil para as redes existentes transformarem sua configuração em pares estruturados de chave-valor que representem uma fonte de verdade de fácil leitura. Ao usar pares estruturados de chave-valor, você pode passar da execução de configurações em cada dispositivo para trabalhar com dados estruturados independentes e colocar as redes na vanguarda de uma abordagem de infraestrutura como código.
Quais módulos de recursos virão no Ansible Engine 2.9?
Antes de contarmos em detalhes o que acontecerá no Ansible 2.9, vamos lembrar como dividimos todo o escopo do trabalho.
Identificamos 7 categorias e atribuímos recursos de rede específicos a cada uma:
Nota: Os recursos em negrito foram planejados e implementados no Ansible 2.9.
Com base no feedback dos clientes corporativos e da comunidade, era lógico abordar primeiro os módulos 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 são 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 enquadra em nossa estratégia centrada na plataforma. Ou seja, incluímos no próprio Ansible as capacidades e funções necessárias para apoiar a padronização no desenvolvimento de módulos de rede, e também para simplificar o trabalho dos usuários no nível de funções e playbooks do Ansible. Para ampliar o desenvolvimento de módulos de recursos, a equipe Ansible lançou a ferramenta Module Builder.
Planos para Ansible 2.10 e além
Assim que o Ansible 2.9 for lançado, trabalharemos no próximo conjunto de módulos de recursos para o Ansible 2.10, que podem ser usados para configurar ainda mais a topologia e a política de rede, por exemplo. . O plano de desenvolvimento ainda pode ser ajustado, portanto, se você tiver comentários, informe-nos .
Recursos e primeiros passos
Fonte: habr.com