Use o juniper.device.config módulo Ansible para recuperar ou comparar configurações do Junos OS

Ao usar o juniper.device.config módulo para recuperar a configuração, você deve incluir o retrieve parâmetro na lista de argumentos do módulo. O retrieve parâmetro especifica o banco de dados de configuração do qual recuperar os dados. Você pode definir retrieve os seguintes valores para retornar dados de configuração do respectivo banco de dados:

• candidate— Recupere dados da configuração do candidato.

• committed— Recupere dados da configuração confirmada.

Banco de dados de configuração confirmada

O guia estratégico a seguir recupera a configuração confirmada completa em formato de texto para cada dispositivo no grupo de inventário:

Banco de dados de configuração de candidatos

O guia estratégico a seguir recupera a configuração completa do candidato em formato de texto para cada dispositivo no grupo de inventário.

Além de recuperar a configuração completa do Junos OS, você pode recuperar partes específicas da configuração usando o filter parâmetro. O filter valor do parâmetro é uma cadeia de caracteres que contém o filtro de subárvore que seleciona as instruções de configuração a serem retornadas. O filtro de subárvore retorna os dados de configuração que correspondem aos critérios de seleção. Se você solicitar várias hierarquias, o valor de filter deve representar todos os níveis da hierarquia de configuração, começando na raiz (representada pelo <configuration> elemento) até cada elemento a ser exibido.

O guia estratégico a seguir recupera e imprime a configuração nos [edit interfaces] níveis de hierarquia e [edit protocols] no banco de dados de configuração confirmado para cada dispositivo:

O guia estratégico a seguir recupera e imprime a configuração para a interface ge-1/0/1:

O guia estratégico a seguir recupera e imprime a configuração confirmada no nível da [edit system services] hierarquia:

Quando você usa o juniper.device.config módulo para recuperar a configuração, ele invoca a operação do protocolo <get-configuration> XML do Junos, que pode retornar dados de configuração em diferentes formatos. Por padrão, o módulo retorna dados de configuração como texto formatado. O formato de texto usa novas linhas, tabulações e outros espaços em branco, chaves e colchetes para indicar as relações hierárquicas entre as instruções.

Para especificar o formato no qual retornar os dados de configuração, defina o parâmetro do format módulo igual ao formato necessário. Os valores aceitáveis incluem:

• json—Notação de objeto JavaScript (JSON)

• set— Comandos do Junos OS set

• text— Texto formatado (padrão)

• xml—Elementos XML do Junos

Na saída do guia estratégico, as config chaves e config_lines contêm a configuração no formato solicitado. Se você solicitar o formato Junos XML ou JSON, a config_parsed chave conterá a configuração equivalente no formato JSON.

O guia estratégico a seguir recupera a configuração confirmada completa para cada dispositivo no grupo de inventário no formato XML:

Os dispositivos Junos retornam respostas RPC no formato XML. Mesmo quando você solicita dados em formato JSON, set ou texto, a resposta do servidor NETCONF envolve os dados em tags XML. Assim, os módulos do Ansible devem usar um analisador XML para lidar com a resposta RPC. Os analisadores XML geralmente impõem limites de segurança na profundidade do documento e no tamanho de nós de texto únicos. Esses limites são uma medida de segurança interna para evitar ataques mal-intencionados, esgotamento de memória e problemas gerais de desempenho.

Os dispositivos de rede podem ter configurações grandes e complexas e extensa saída de comando e RPC. Por padrão, o analisador XML impõe um limite de tamanho para nós de texto, que geralmente é de cerca de 10 MB. Quando um único nó de texto excede o limite de tamanho, o analisador gera um erro. Por exemplo:

Geralmente, se você solicitar dados de configuração, comando ou RPC no formato XML, o documento conterá muitos nós XML pequenos e o analisador não encontrará esse limite, exceto em casos raros. No entanto, se você solicitar os mesmos dados no formato JSON, set ou text, o dispositivo retornará os dados encapsulados em uma ou mais marcas XML. Por exemplo, além da <rpc-reply> tag, o dispositivo encapsula os dados de configuração do conjunto e do texto em uma <configuration-set> tag ou <configuration-text> uma tag, conforme apropriado. Da mesma forma, o dispositivo inclui a saída do comando em formato de texto em um <output> elemento. Para dados extensos, a resposta pode resultar em um único nó de texto XML que excede os limites padrão do analisador.

Quando você solicita configurações grandes ou comando extenso ou saída RPC em qualquer formato, o analisador XML lida com a resposta RPC. Assim, você pode encontrar o erro de limite de tamanho de nó para todos os formatos, embora seja mais raro para dados XML. Nesses casos, recomendamos retornar a resposta como XML.

Se você precisar de um dos outros formatos, poderá substituir os limites do analisador incluindo o argumento module huge_tree: true . Quando você usa huge_tree: trueo , ele ativa a XML_PARSE_HUGE opção, que ignora os limites do tamanho máximo do nó de texto, do tamanho máximo do atributo e da profundidade máxima. Como resultado, o analisador pode processar documentos XML grandes, árvores XML profundas e nós de texto grandes.

O guia estratégico a seguir recupera a configuração confirmada no set formato para os dispositivos no grupo de inventário. Os juniper.device.config argumentos do módulo incluem huge_tree: true. Com essa opção, a tarefa é bem-sucedida mesmo que uma resposta específica exceda o limite de tamanho de nó padrão do analisador.

Você pode carregar módulos YANG padronizados ou personalizados em dispositivos Junos para adicionar modelos de dados que não são suportados nativamente pelo Junos OS, mas podem ser suportados por tradução. Você configura modelos de dados não nativos na configuração do candidato usando a sintaxe definida para esses modelos. Quando você confirma a configuração, os scripts de tradução do modelo de dados traduzem esses dados e confirmam a configuração correspondente do Junos OS como uma alteração transitória na configuração de checkout.

As configurações candidata e ativa contêm os dados de configuração para modelos de dados YANG não nativos na sintaxe definida por esses modelos. Você pode usar o juniper.device.config módulo para recuperar dados de configuração para modelos de dados padrão (IETF, OpenConfig) e YANG personalizados, além de recuperar a configuração nativa do Junos OS. Por padrão, a resposta do módulo não inclui dados de configuração para modelos de dados YANG de terceiros.

Para recuperar dados de configuração definidos por um modelo de dados YANG não nativo, além de recuperar a configuração do Junos OS, execute o módulo com o model parâmetro e inclua o namespace parâmetro quando apropriado. O model argumento recebe um dos seguintes valores:

• custom— Recupere dados de configuração definidos por modelos de dados YANG personalizados. Você deve incluir o namespace argumento ao recuperar dados para modelos de dados YANG personalizados.

• ietf— Recupere dados de configuração definidos por modelos de dados IETF YANG.

• openconfig— Recupere dados de configuração definidos por modelos de dados OpenConfig YANG.

• True— Recupere todos os dados de configuração, incluindo a configuração completa do Junos OS e os dados de qualquer modelo de dados YANG.

Se o model argumento especificar ietf ou openconfig, o módulo usará automaticamente o namespace apropriado. Se você especificar model: custom a recuperação de dados para um modelo de dados YANG personalizado, também deverá incluir o namespace argumento com o namespace correspondente.

Se você incluir o model argumento com o valor custom, ietfou openconfig e também incluir o filter argumento para retornar uma subárvore XML específica, o Junos OS retornará apenas a hierarquia correspondente do modelo de dados não nativo. Se a configuração do Junos OS contiver uma hierarquia com o mesmo nome, por exemplo, "interfaces", ela não será incluída na resposta. A filter opção não é suportada ao usar model: True.

Ao usar o juniper.device.config módulo para recuperar dados de configuração não nativos, você só poderá especificar o formato dos dados retornados se também incluir o filter parâmetro. Se você omitir o filter parâmetro, deverá especificar format: xml.

O guia estratégico a seguir recupera a hierarquia de configuração do OpenConfig interfaces da configuração confirmada. Se você omitir o filter argumento, o RPC retornará as configurações completas do Junos OS e do OpenConfig.

A tarefa a seguir recupera a l2vpn hierarquia de configuração da configuração confirmada para um modelo de dados YANG personalizado com o namespace fornecido:

A tarefa a seguir recupera a configuração completa comprometida do Junos OS, bem como os dados de configuração para outros modelos de dados YANG que foram adicionados ao dispositivo:

Quando você usa o juniper.device.config módulo para recuperar a configuração, ele invoca a operação do protocolo <get-configuration> XML do Junos. O módulo dá suporte a argumentos explícitos para muitos dos <get-configuration> atributos, por exemplo, o format atributo. O módulo também dá suporte options ao argumento, que permite incluir quaisquer atributos adicionais <get-configuration> que não tenham um argumento de módulo equivalente. O options argumento usa um dicionário de pares chave/valor de todos os atributos suportados pela <get-configuration> operação.

Para obter a lista completa de atributos compatíveis com a operação do protocolo <get-configuration> XML Junos, consulte <get-configuration>.

Por exemplo, o juniper.device.config módulo recupera dados da configuração de pré-herança, na qual as <groups>tags , <apply-groups>, <apply-groups-except>e <interface-range> são elementos separados na saída da configuração. Para recuperar dados da configuração pós-herança, você pode incluir o options argumento com inherit: inherit. A configuração pós-herança exibe instruções herdadas de grupos e intervalos definidos pelo usuário como filhos das instruções herdadas,

O guia estratégico a seguir recupera os dados de configuração no [edit system services] nível da hierarquia da configuração confirmada pós-herança. Na configuração pós-herança, as instruções configuradas em níveis de hierarquia de grupo, como [edit groups global system services] são herdadas [edit system services] e retornadas nos dados de configuração recuperados.

Ao usar o juniper.device.config módulo para recuperar a configuração, você pode salvar os dados de configuração retornados em um arquivo no nó de controle local do Ansible. Para salvar os dados em um arquivo, inclua o módulo ou dest parâmetro.dest_dir A dest_dir opção especifica um caminho de diretório. A dest opção pode especificar um caminho e um nome de arquivo. Se um arquivo de saída já existir com o nome de destino, o módulo substituirá o arquivo.

Para especificar o diretório no qual salvar as configurações recuperadas, defina o dest_dir argumento como o caminho do diretório de destino. A configuração de cada dispositivo é armazenada em um arquivo separado chamado hostname.config.

O guia estratégico a seguir recupera a configuração confirmada de todos os dispositivos no grupo de inventário. O playbook salva cada configuração de dispositivo em um arquivo separado no diretório configs no diretório do playbook no nó de controle do Ansible.

Para especificar o caminho e o nome do arquivo para os arquivos de saída, defina o dest argumento como o caminho absoluto ou relativo do arquivo. Se você incluir o dest argumento, mas omitir o diretório, os arquivos serão salvos no diretório do playbook. Se você recuperar a configuração para vários dispositivos, o dest argumento deverá incluir uma variável para {{ inventory_hostname }} diferenciar o nome do arquivo para cada dispositivo. Se você não diferenciar os nomes dos arquivos, o arquivo de configuração de cada dispositivo substituirá o arquivo de configuração dos outros dispositivos.

O guia estratégico a seguir recupera a [edit system services] hierarquia do banco de dados de configuração comprometido em todos os dispositivos no grupo de inventário. O playbook salva cada configuração de dispositivo em um arquivo separado no diretório do playbook no nó de controle do Ansible. Cada arquivo é identificado exclusivamente por seu nome de host.

Se você estiver salvando os dados de configuração em arquivos e não quiser duplicar os dados de configuração na resposta do módulo, poderá incluir return_output: false opcionalmente na lista de argumentos do módulo. Definir return_output como false faz com que o módulo omita as configteclas , config_linese em config_parsed sua resposta. Isso pode ser necessário se o dispositivo retornar uma quantidade significativa de dados de configuração.

O juniper.device.config módulo permite comparar a configuração ativa com uma configuração confirmada anteriormente ou configuração de reversão. Para comparar a configuração ativa com uma configuração anterior, inclua os seguintes argumentos de módulo:

Por padrão, quando você inclui o rollback: id argumento, o módulo reverte a configuração, executa uma verificação de confirmação e confirma as alterações. Você deve incluir o commit: false argumento para comparar apenas as configurações e impedir que o módulo carregue e confirme a configuração de reversão. Incluir o check: false argumento impede a operação de verificação de confirmação desnecessária.

O módulo retorna as diff chaves e diff_lines . As chaves contêm as diferenças de configuração entre a configuração ativa e a anterior no formato diff ou patch.

• diff— Dicionário que contém uma única chave chamada prepared e seu valor, que é uma única string de várias linhas contendo as diferenças.

• diff_lines— Lista de strings de linha única contendo as diferenças.

Para salvar as diferenças em um arquivo no nó de controle local do Ansible, inclua o diffs_file argumento e defina o caminho absoluto ou relativo do arquivo de saída. Se você incluir o diffs_file argumento, mas omitir o diretório, os arquivos serão salvos no diretório do playbook. Se você comparar as configurações em vários dispositivos, o diffs_file argumento deverá incluir uma variável para {{ inventory_hostname }} diferenciar o nome do arquivo para cada dispositivo. Se você não diferenciar os nomes de arquivo, o arquivo de saída de cada dispositivo substituirá o arquivo de saída dos outros dispositivos.

O guia estratégico a seguir solicita a ID de reversão de uma configuração confirmada anteriormente. Em seguida, o guia estratégico compara a configuração confirmada com a configuração de reversão especificada, salva a comparação em um arquivo com nome exclusivo e imprime a resposta na saída padrão.