A próxima versão do Red Hat Ansible Engine 2.9 está esperando por você com melhorias impressionantes, algumas das quais são descritas neste artigo. Como sempre, desenvolvemos melhorias na rede Ansible abertamente, com o apoio da comunidade. Participe - Dê uma olhada no quadro de tarefas no GitHub e estude o plano de desenvolvimento para o lançamento do Red Hat Ansible Engine 2.9 na página wiki da Ansible Network .
Como anunciamos recentemente, a Plataforma de Automação Ansible da Red Hat agora inclui Ansible Tower, Ansible Engine e todo o conteúdo da Ansible Network. Agora, as plataformas de rede mais populares são implementadas através dos módulos Ansible. Por exemplo:
- Arista eos
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- Vyos
Uma lista completa de plataformas totalmente suportadas pela Red Hat através da Ansible Automation está disponível aqui .
O que aprendemos
Nos últimos quatro anos, aprendemos muito sobre o desenvolvimento de uma plataforma para automação de rede. Também aprendemos como os usuários finais jogam artefatos de plataforma em playbooks e papéis Ansible. E aqui está o que descobrimos:
- As organizações automatizam os dispositivos não apenas um, mas muitos fornecedores.
- A automação não é apenas um fenômeno técnico, mas também cultural.
- A automação de redes em larga escala é mais complicada do que parece, devido aos princípios arquiteturais fundamentais do projeto de automação.
Quando discutimos nossos planos de desenvolvimento 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 o fluxo de trabalho de automação para qualquer dispositivo.
- A atualização das configurações no dispositivo também precisa ser padronizada e harmonizada para que os módulos Ansible processem a segunda metade do ciclo após coletar os 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 de um dispositivo de rede.
Aprimoramentos de fatos
A coleta de fatos de dispositivos de rede usando o Ansible geralmente é aleatória. As plataformas de rede estão equipadas em graus variados com a capacidade de coletar fatos, mas elas têm quase nenhuma - ou mesmo nenhuma - funções para analisar e padronizar a apresentação de dados em pares de valores-chave. Leia o post de Ken Celenza sobre o quão difícil e doloroso é analisar e padronizar dados factuais.
Você deve ter notado como trabalhamos na função Ansible Network Engine. Naturalmente, 24.000 downloads depois, a função Network Engine rapidamente se tornou uma das funções mais populares da Ansible no Ansible Galaxy para cenários de automação de rede. Antes de migrarmos muito disso para o Ansible 2.8 para preparar o que o Ansible 2.9 precisava, essa função do Ansible forneceu o primeiro conjunto de ferramentas para auxiliar na análise de comandos, gerenciamento de comandos e coleta de dados para dispositivos de rede.
Se você é bom em usar o Network Engine, é uma maneira muito eficiente de coletar, analisar e padronizar dados de fatos para uso com o Ansible. A desvantagem dessa função é que você precisa criar um monte de analisadores para cada plataforma e para todas as atividades da rede. Para entender como é difícil criar, enviar e manter analisadores, observe os mais de 1200 analisadores da equipe da Cisco.
Em poucas palavras, para automação em larga escala, é muito importante receber fatos dos dispositivos e normalizá-los em pares de valores-chave, mas isso é difícil de obter quando você tem muitos fornecedores e plataformas de rede.
Agora, cada módulo de fato de rede no Ansible 2.9 pode analisar a configuração de um dispositivo de rede e retornar dados estruturados - sem bibliotecas adicionais, funções Ansible ou analisadores personalizados.
Começando com o Ansible 2.9, com cada versão do módulo de rede atualizado, o módulo de fatos é aprimorado para fornecer informações sobre esta seção de configuração. Ou seja, o desenvolvimento de fatos e módulos agora está acontecendo no mesmo ritmo e eles sempre terão uma estrutura de dados comum.
A configuração de recursos em um dispositivo de rede pode ser extraída e convertida em dados estruturados de duas maneiras. Nos dois sentidos, você pode compilar e transformar uma lista específica de recursos usando a nova gather_network_resources . Os nomes dos recursos correspondem aos nomes dos módulos, e isso é muito conveniente.
No momento da coleta dos fatos:
Usando a gather_facts você pode extrair 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: True
Você pode notar algo novo nesses exemplos, a saber gather_facts: true agora gather_facts: true disponível para pesquisa de fatos nativa para dispositivos de rede.
Usando o módulo de fatos da rede diretamente:
- name: collect interface configuration facts eos_facts: gather_subset: min gather_network_resources: - interfaces
O 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: Ethernet1
Observe como o Ansible recupera a configuração nativa do dispositivo Arista e a converte em dados estruturados para usar como pares de valores-chave padrão para tarefas e operações subseqüentes.
Os fatos da interface podem ser incluídos nas variáveis armazenadas Ansible e usados imediatamente ou mais tarde como entrada no eos_interfaces recursos eos_interfaces sem processamento ou conversão adicional.
Módulos de recursos
Assim, extraímos os fatos, normalizamos os dados, os inserimos em um esquema interno padronizado da estrutura de dados e obtivemos uma fonte pronta da verdade. Viva! Isso, é claro, é ótimo, mas ainda precisamos converter os pares de valores-chave de volta à configuração específica esperada por uma plataforma de dispositivo específica. Agora precisamos de módulos para plataformas específicas para satisfazer esses novos requisitos de coleta e normalização de fatos.
O que é um módulo de recursos? As seções de configuração do dispositivo podem ser consideradas os recursos fornecidos por este dispositivo. Os módulos de recursos de rede são intencionalmente limitados a um recurso e podem ser empilhados como tijolos para configurar serviços de rede complexos. Como resultado, os requisitos e especificações para o módulo de recursos são naturalmente simplificados, porque o módulo de recursos pode ler e configurar um serviço de rede específico em um dispositivo de rede.
Para explicar o que o módulo de recursos faz, vejamos um exemplo de um manual que mostra uma operação idempoent usando novos fatos de um recurso de rede e o 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.changed
Como você pode ver, os dados coletados do dispositivo são transferidos diretamente para o módulo de recurso correspondente sem conversão. Na inicialização, o manual recupera os valores do dispositivo e os compara com os esperados. Neste exemplo, os valores obtidos correspondem aos esperados (ou seja, os desvios de configuração são verificados) e uma mensagem é exibida se a configuração foi alterada.
Uma maneira ideal de detectar desvios de configuração é armazenar os fatos nas variáveis armazenadas Ansible e usá-los periodicamente com o módulo de recursos no modo de verificação. Este é um método simples para verificar se alguém alterou os 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 Ansible Automation.
Como os novos módulos de recursos são diferentes dos anteriores?
Para um engenheiro de automação de rede, há três diferenças principais entre os módulos de recursos no Ansible 2.9 das versões anteriores.
1) Para um recurso de rede específico (que também pode ser considerado uma seção de configuração), os módulos e os fatos serão desenvolvidos em todos os sistemas operacionais de rede suportados simultaneamente. Pensamos que, se o Ansible suportar a configuração de recursos em uma única plataforma de rede, devemos apoiá-la em qualquer lugar. Isso simplifica o uso de módulos de recursos, porque agora um engenheiro de automação de rede pode configurar um recurso (por exemplo, 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 em excesso serão excluídas;deleted : a configuração do recurso será excluída / 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 de valores-chave para o manual.
before : configuração no dispositivo na forma de dados estruturados antes da tarefa;after : se o dispositivo foi alterado (ou pode ser alterado se o modo de verificação for usado), a configuração resultante será retornada na forma de dados estruturados;commands : qualquer comando de configuração em execução no dispositivo para trazê-lo ao estado desejado.
O que tudo isso significa? Por que isso é importante?
Esta publicação descreve muitos conceitos complexos, mas esperamos que, no final, você entenda melhor que os clientes corporativos estão solicitando fatos, normalização de dados e configuração de loop para a plataforma de automação. Mas por que eles precisam dessas melhorias? Agora, muitas organizações estão envolvidas na transformação digital para tornar seus ambientes de TI mais flexíveis e competitivos. Para o bem ou para o mal, muitos engenheiros de rede se tornam desenvolvedores de rede, por seu próprio interesse ou por ordem dos gerentes.
As organizações entendem que a automação de modelos de rede individuais não resolve o problema de fragmentação e apenas aumenta a eficiência até um determinado limite. A Plataforma de Automação Ansible da Red Hat 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 abandonando gradualmente os métodos de configuração individual em favor de métodos mais modernos, com ênfase nas tecnologias (por exemplo, endereços IP, VLAN, LLDP, etc.), e não em uma implementação específica do fornecedor.
Isso significa que os dias de módulos e configurações de comando confiáveis e comprovados são numerados? De jeito nenhum. Os módulos de recursos de rede esperados não serão aplicáveis em todos os casos e não para cada fornecedor; portanto, os engenheiros de rede ainda precisarão de módulos de comando e configuração para determinadas implementações. O objetivo dos módulos de recursos é simplificar modelos Jinja grandes e normalizar configurações de dispositivos não estruturados em um formato JSON estruturado. Com os módulos de recursos, será mais fácil para as redes existentes transformar sua configuração em pares estruturados de valor-chave, que serão uma fonte de verdade fácil de ler. Se você usar pares estruturados de valor-chave, poderá alternar das configurações em execução em cada dispositivo para trabalhar com dados estruturados independentes e colocar as redes em primeiro plano com a abordagem "infraestrutura como código".
Quais módulos de recursos aparecerão no Ansible Engine 2.9?
Antes de contar em detalhes o que acontecerá no Ansible 2.9, vamos lembrar como dividimos toda a quantidade de trabalho.
Identificamos 7 categorias e cada um atribuiu recursos de rede específicos:
Nota: recursos em negrito foram planejados e implementados na Ansible 2.9.
Com base nos comentários dos clientes corporativos e da comunidade, era lógico lidar primeiro com os módulos relacionados aos protocolos de topologia de rede, virtualização e interfaces.
Os seguintes módulos de recursos são desenvolvidos pela equipe da 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 encaixa em nossa estratégia de orientação de plataforma. Ou seja, incluímos os recursos e funções necessários no próprio Ansible, para oferecer suporte à padronização no desenvolvimento de módulos de rede, além de simplificar o trabalho dos usuários no nível dos papéis e manuais 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 em diante
Após o lançamento do Ansible 2.9, trataremos do seguinte conjunto de módulos de recursos do Ansible 2.10, que podem ser usados para configurar ainda mais a topologia e a política de rede, por exemplo, ACL, OSPF e BGP . O plano de desenvolvimento ainda pode ser ajustado. Portanto, se você tiver comentários, relate-o à comunidade Ansible Network .
Recursos e introdução
Comunicado de imprensa da plataforma Ansible Automation
Blog da Plataforma de Automação Ansible
O futuro da entrega de conteúdo na Ansible
Reflexões sobre a mudança da estrutura do projeto Ansible