Use o Ansible para configurar dispositivos Junos
RESUMO Use os módulos Ansible da Juniper Networks para gerenciar a configuração em dispositivos Junos.
A Juniper Networks oferece módulos Ansible que permitem configurar dispositivos Junos. A Tabela 1 descreve os módulos disponíveis. A conta do usuário usada para fazer alterações de configuração deve ter permissões para alterar as partes relevantes da configuração em cada dispositivo.
| Conjunto de conteúdo |
Nome do módulo |
|---|---|
|
|
|
|
|
Juniper.junos A partir do lançamento 2.0.0, o juniper_junos_config módulo combina e substitui a funcionalidade dojunos_commit, junos_get_configjunos_install_confige junos_rollback módulos.
As seções a seguir discutem como usar os módulos para modificar e comprometer a configuração em dispositivos Junos.
Visão geral do módulo
Os módulos e juniper_junos_config os config módulos permitem que você realize as seguintes operações em dispositivos Junos:
-
Dados de configuração de carga
-
Confirmar a configuração
-
Reverta a configuração
-
Carregue a configuração de resgate
Para modificar a configuração, a lista de argumentos do módulo deve incluir o load parâmetro para carregar novos dados de configuração ou o rollback parâmetro para reverter para a configuração de resgate ou uma configuração previamente comprometida. O processo básico para fazer mudanças na configuração é bloquear a configuração, carregar as mudanças de configuração, comprometer a configuração para torná-la ativa e, em seguida, desbloquear a configuração.
Por padrão, os módulos e juniper_junos_config os config módulos fazem alterações no banco de dados de configuração do candidato usando configure exclusive o modo, que bloqueia e desbloqueia automaticamente a configuração global do candidato. Você também pode fazer alterações em uma cópia privada da configuração do candidato. Para obter mais informações sobre como especificar o modo de configuração, veja Como especificar o modo de configuração.
Ao carregar novos dados de configuração, além de especificar o modo de configuração, você também pode especificar a operação de carga e a fonte e o formato das mudanças.
-
Operação de carga — a operação de carga determina como os dados de configuração são carregados na configuração do candidato. As funções oferecem suporte a muitas das mesmas operações de carga disponíveis no Junos OS CLI. Para obter mais informações, veja Como especificar a ação de carga.
-
Formato — você pode configurar dispositivos Junos usando um dos formatos padrão e suportados. Você pode fornecer dados de configuração ou modelos Jinja2 como texto, elementos Junos XML, comandos Junos OS
setou JSON. Para obter informações sobre como especificar o formato dos dados de configuração, veja Como especificar o formato dos dados de configuração a serem carregados. -
Fonte de dados de configuração — você pode carregar dados de configuração de uma lista de strings, um arquivo no nó de controle ansible local, um modelo Jinja2 ou um URL acessível do dispositivo cliente, incluindo o
lines,src,templateouurlparâmetro, respectivamente. Para obter mais informações sobre como especificar a fonte dos dados de configuração, veja as seguintes seções:
Os config módulos e os módulos juniper_junos_config também permitem que você carregue e comprometa a configuração de resgate ou reverta a configuração para uma configuração previamente comprometida. Para carregar a configuração de resgate ou uma configuração previamente comprometida, você deve incluir o argumento do rollback módulo. Para obter mais informações, veja as seguintes seções:
Depois de modificar a configuração, você deve comprometer a configuração para torná-la a configuração ativa no dispositivo. Por padrão, os módulos e juniper_junos_config os config módulos confirmam as alterações na configuração. Para alterar esse comportamento ou fornecer opções adicionais de confirmação, veja Como comprometer a configuração.
Por padrão, quando o config módulo ou juniper_junos_config módulo inclui os load argumentos rollback para alterar a configuração, o módulo retorna automaticamente as mudanças de configuração no formato diff ou patch na resposta do módulo. As diferenças são devolvidas nas variáveis e diff_lines nas diff variáveis. Para evitar que o módulo calcule e devolva as diferenças, defina o argumento do diff módulo para false.
Como especificar o modo de configuração
Você pode especificar o modo de configuração a ser usado ao modificar o banco de dados de configuração do candidato. Por padrão, os módulos e juniper_junos_config os config módulos fazem alterações no banco de dados de configuração do candidato usando configure exclusive o modo. Configure o modo exclusivo que bloqueia a configuração global do candidato (também conhecida como banco de dados de configuração compartilhada) pelo tempo necessário para que o módulo faça as alterações solicitadas na configuração. Bloquear o banco de dados impede que outros usuários modifiquem ou cometam alterações no banco de dados até que a fechadura seja liberada.
Para especificar o modo, inclua o config_mode parâmetro na lista de argumentos do módulo. Os modos suportados incluem exclusive e private. Ambos os modos descartam quaisquer alterações não comprometidas na saída.
O manual a seguir usa configure private o modo para modificar a configuração:
---
- name: "Configure Device"
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: "Configure op script"
juniper.device.config:
config_mode: "private"
load: "set"
lines:
- "set system scripts op file bgp.slax"
register: response
- name: "Print the config changes"
debug:
var: response.diff_lines
user@ansible-cn:~/ansible$ ansible-playbook configure-script.yaml
PLAY [Configure Device] *******************************************************
TASK [Configure op script] ****************************************************
changed: [dc1a.example.net]
TASK [Print the config changes] ***********************************************
ok: [dc1a.example.net] => {
"response.diff_lines": [
"",
"[edit system scripts op]",
"+ file bgp.slax;"
]
}
PLAY RECAP ********************************************************************
dc1a.example.net : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Como especificar a ação de carga
O e juniper_junos_config os config módulos oferecem suporte a mudanças na configuração de carregamento usando muitas das mesmas operações de carga suportadas no Junos OS CLI. Você especifica a operação de carga incluindo o load parâmetro na lista de argumentos do módulo e configurando-o no valor da operação de carga correspondente. A Tabela 2 resume as configurações de parâmetros necessárias para cada tipo de operação de carga.
| Operação de carga |
Argumento de carga |
Descrição |
|---|---|---|
|
|
|
Mescle a configuração carregada com a configuração existente. |
|
|
|
Substitua toda a configuração pela configuração carregada. |
|
|
|
Mescle a configuração carregada com a configuração existente, mas substitua as declarações na configuração existente por aquelas que especificam a |
|
|
|
Carregue dados de configuração de um arquivo de patch. |
|
|
|
Carregue dados de configuração que estão em |
|
|
|
Compare a configuração completa carregada com a configuração existente. Cada elemento de configuração que é diferente na configuração carregada substitui seu elemento correspondente na configuração existente. Durante a operação de confirmação, apenas processos de sistema que são afetados por elementos de configuração alterados analisam a nova configuração. |
Como especificar o formato dos dados de configuração a serem carregados
Os config módulos e juniper_junos_config os módulos permitem que você configure dispositivos Junos usando um dos formatos padrão e suportados. Você pode fornecer dados de configuração como strings ou arquivos. Os arquivos podem conter dados de configuração ou modelos Jinja2. Ao fornecer dados de configuração dentro de um modelo de string, arquivo ou Jinja2, os formatos suportados para os dados incluem texto, elementos Junos XML, comandos Junos OS set e JSON.
A partir do Junos OS Release 16.1R1, os dispositivos Junos suportam o carregamento de dados de configuração no formato JSON.
Os módulos e juniper_junos_config os config módulos tentam detectar automaticamente o formato dos dados de configuração fornecidos como strings usando o lines argumento. No entanto, você pode especificar explicitamente o formato para strings, incluindo o format argumento. Quando você fornece dados de configuração em um arquivo ou modelo Jinja2, você deve especificar o formato dos dados, seja adicionando a extensão apropriada ao arquivo ou incluindo o format argumento.
A Tabela 3 resume os formatos suportados para os dados de configuração e o valor correspondente para a extensão e format parâmetro do arquivo. Se você incluir o format argumento, ele substitui tanto o formato de detecção automática para strings quanto o formato indicado por uma extensão de arquivo.
| Formato de dados de configuração |
Extensão |
parâmetro do formato |
|---|---|---|
| Declarações de configuração de CLI (texto) |
.Conf |
" |
| Notação de objetos JavaScript (JSON) |
.json |
" |
| Comandos do Junos OS |
.pôr |
" |
| Elementos do Junos XML |
.XML |
" |
Quando você define o argumento do load módulo ou 'update'não pode usar o formato de comando do Junos OSset.'override'
Como carregar dados de configuração como strings
Os config módulos e juniper_junos_config os módulos permitem que você carregue dados de configuração de uma lista de strings. Para carregar dados de configuração como strings, inclua o argumento apropriado load e o lines argumento. O lines argumento leva uma lista de strings que contêm os dados de configuração para carregar.
Os módulos tentam detectar automaticamente o formato dos dados de lines configuração. No entanto, você pode especificar explicitamente o formato incluindo o format argumento. Para obter informações sobre como especificar o formato, veja como especificar o formato dos dados de configuração a serem carregados. Se você incluir o format parâmetro na lista de argumentos do módulo, ele substitui o formato de detecção automática.
O manual a seguir configura e confirma dois scripts de operação. Neste caso, o load argumento tem o valor 'set', porque os dados de configuração em lines uso do formato de declaração do Junos OS set .
---
- name: "Load and commit configuration"
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: "Load configuration data using strings and commit"
juniper.device.config:
load: "set"
lines:
- "set system scripts op file bgp.slax"
- "set system scripts op file bgp-neighbor.slax"
register: response
- name: "Print the response"
debug:
var: response
O manual a seguir configura as mesmas declarações usando lines com dados de configuração em formato de texto. Neste caso, load: "merge" é usado.
---
- name: "Load and commit configuration"
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: "Load configuration data using strings and commit"
juniper.device.config:
load: "merge"
lines:
- |
system {
scripts {
op {
file bgp.slax;
file bgp-neighbor.slax;
}
}
}
register: response
- name: "Print the response"
debug:
var: response
Como carregar dados de configuração de um arquivo local ou remoto
Os módulos e juniper_junos_config os config módulos permitem que você carregue dados de configuração de um arquivo. O arquivo pode residir em um dos seguintes locais:
-
Nó de controle ansível
-
Dispositivo cliente
-
URL que é acessível a partir do dispositivo cliente
Ao carregar dados de configuração de um arquivo, você deve indicar o formato dos dados de configuração no arquivo e a localização do arquivo. Os formatos de dados de configuração suportados incluem texto, elementos Junos XML, comandos Junos OS set e JSON. Para obter informações sobre o carregamento de arquivos que contêm modelos Jinja2, veja Como carregar dados de configuração usando um modelo Jinja2.
Você pode especificar o formato dos dados de configuração incluindo explicitamente o format parâmetro na lista de argumentos do módulo ou adicionando a extensão apropriada ao arquivo de dados de configuração. Se você especificar o format parâmetro, ele substitui o formato indicado pela extensão do arquivo. Para obter informações sobre como especificar o formato, veja como especificar o formato dos dados de configuração a serem carregados. Quando os dados de configuração usam o formato Junos XML, você deve utilizar os dados na tag de alto nível <configuration> .
Você não precisa incluir dados de configuração que sejam formatados como texto ASCII, comandos Junos OS set ou JSON, <configuration-text><configuration-set>ou <configuration-json> tags conforme necessário ao configurar o dispositivo diretamente dentro de uma sessão netconf.
A Tabela 4 descreve os parâmetros do módulo que você pode incluir para especificar a localização do arquivo.
| Parâmetro do módulo |
Descrição |
|---|---|
|
|
Caminho absoluto ou relativo a um arquivo no nó de controle Ansible. O diretório padrão é o playbook directory. |
|
|
Caminho absoluto ou relativo a um arquivo no dispositivo cliente, ou uma localização FTP, ou uma URL de protocolo de transferência de hipertexto (HTTP). O diretório padrão no dispositivo cliente é o diretório de trabalho atual, que fica inadimplente com o diretório doméstico do usuário. |
Para carregar dados de configuração de um arquivo local no nó de controle Ansible, configure o src argumento para o caminho absoluto ou relativo do arquivo que contém os dados de configuração. Por exemplo:
---
- name: "Load and commit configuration"
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: "Load configuration from a local file and commit"
juniper.device.config:
load: "merge"
src: "build_conf/{{ inventory_hostname }}/junos.conf"
register: response
- name: "Print the response"
debug:
var: response
Para carregar dados de configuração de um arquivo no dispositivo Junos gerenciado, ou de um FTP ou URL HTTP, use o url parâmetro e especifique o caminho do arquivo que contém os dados de configuração a serem carregados. Por exemplo:
---
- name: "Load and commit configuration"
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: "Load configuration from a remote file and commit"
juniper.device.config:
load: "merge"
url: "/var/tmp/junos.conf"
register: response
- name: "Print the response"
debug:
var: response
O valor url pode ser um caminho de arquivo local absoluto ou relativo, uma localização FTP ou uma URL de protocolo de transferência de hipertexto (HTTP).
-
Um nome de arquivo local pode ter um dos seguintes formulários:
-
/path/filename— Arquivo em um sistema de arquivos montado, seja no disco flash local ou em disco rígido.
-
um:filename ou a:path/filename— Arquivo na unidade local. O caminho padrão é / (o diretório de nível raiz). A mídia removível pode estar no formato MS-DOS ou UNIX (UFS).
-
-
Um nome de arquivo para um arquivo em um servidor FTP tem o seguinte formulário:
ftp://username:password@hostname/path/filename -
Um nome de arquivo para um arquivo em um servidor HTTP tem o seguinte formulário:
http://username:password@hostname/path/filename
Em cada caso, o valor padrão da path variável é o home directory para o usuário. Para especificar um caminho absoluto, o aplicativo inicia o caminho com os caracteres %2F; por exemplo, ftp://username:password@hostname/%2Fpath/filename.
Como carregar dados de configuração usando um modelo Jinja2
Os módulos e juniper_junos_config os config módulos permitem que você renderize dados de configuração de um arquivo modelo Jinja2 no nó de controle e carga Ansible e comprometa a configuração em um dispositivo Junos. Jinja é um mecanismo de modelo para Python que permite que você gere documentos a partir de modelos predefinidos. Os templates, que são arquivos de texto na linguagem desejada, oferecem flexibilidade por meio do uso de expressões e variáveis. Você pode criar dados de configuração do Junos OS usando modelos Jinja2 em um dos formatos de configuração suportados, que inclui texto ASCII, elementos Junos XML, comandos Junos OS set e JSON. Os módulos Ansible usam o modelo Jinja2 e um template fornecido de variáveis para renderizar os dados de configuração.
Para carregar e comprometer dados de configuração usando um modelo Jinja2, inclua os parâmetros e vars a template lista de argumentos do módulo.
-
template— Caminho do arquivo modelo Jinja2 -
vars— O cookies de chaves e valores necessários para tornar o modelo Jinja2
Você também deve incluir o format parâmetro quando a extensão de arquivo dos modelos não indicar o formato dos dados. Para obter informações sobre como especificar o formato, veja como especificar o formato dos dados de configuração a serem carregados.
Por exemplo, o arquivo interfaces-mpls.j2 contém o seguinte modelo Jinja2:
interfaces {
{% for item in interfaces %}
{{ item }} {
description "{{ description }}";
unit 0 {
family {{ family }};
}
} {% endfor %}
}
protocols {
mpls {
{% for item in interfaces %}
interface {{ item }};
{% endfor %}
}
rsvp {
{% for item in interfaces %}
interface {{ item }};
{% endfor %}
}
}
Para usar o config ou juniper_junos_config módulo para carregar o modelo Jinja2, definir o template argumento para o caminho do arquivo template e definir as variáveis exigidas pelo modelo no vars níquete. O manual a seguir usa o modelo Jinja2 e as variáveis definidas vars para renderizar os dados de configuração e carregá-los no host alvo. O format parâmetro indica o formato dos dados de configuração no arquivo modelo.
---
- name: "Load and commit configuration"
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: "Load a configuration from a Jinja2 template and commit"
juniper.device.config:
load: "merge"
template: "build_conf/templates/interfaces-mpls.j2"
format: "text"
vars:
interfaces: ["ge-1/0/1", "ge-1/0/2", "ge-1/0/3"]
description: "MPLS interface"
family: "mpls"
register: response
- name: "Print the response"
debug:
var: response
O módulo gera os seguintes dados de configuração, que são carregados na configuração do candidato no dispositivo e comprometidos:
interfaces {
ge-1/0/1 {
description "MPLS interface";
unit 0 {
family mpls;
}
}
ge-1/0/2 {
description "MPLS interface";
unit 0 {
family mpls;
}
}
ge-1/0/3 {
description "MPLS interface";
unit 0 {
family mpls;
}
}
}
protocols {
mpls {
interface ge-1/0/1;
interface ge-1/0/2;
interface ge-1/0/3;
}
rsvp {
interface ge-1/0/1;
interface ge-1/0/2;
interface ge-1/0/3;
}
}
Como carregar a configuração de resgate
Uma configuração de resgate permite que você defina uma configuração de trabalho conhecida ou uma configuração com um estado conhecido que você pode restaurar a qualquer momento. Você usa a configuração de resgate quando precisa reverter para uma configuração conhecida ou como último recurso se a configuração do dispositivo e os arquivos de configuração de backup ficarem danificados sem reparo. Quando você cria uma configuração de resgate, o dispositivo salva a configuração mais recentemente comprometida como a configuração de resgate.
Os config módulos e juniper_junos_config os módulos permitem que você reverta para uma configuração de resgate existente em dispositivos Junos. Para carregar e comprometer a configuração de resgate em um dispositivo, inclua o argumento do rollback: "rescue" módulo. Por exemplo:
---
- name: "Revert to rescue configuration"
hosts: dc1a
connection: local
gather_facts: no
tasks:
- name: "Load and commit rescue configuration"
juniper.device.config:
rollback: "rescue"
register: response
- name: "Print response"
debug:
var: response
Como reverter a configuração
Os dispositivos Junos armazenam uma cópia da configuração mais recentemente comprometida e até 49 configurações anteriores, dependendo da plataforma. Você pode reverter para qualquer uma das configurações armazenadas. Isso é útil quando as mudanças de configuração causam resultados indesejáveis, e você deseja reverter para uma configuração de trabalho conhecida. A reversão da configuração é semelhante ao processo de fazer alterações de configuração no dispositivo, mas em vez de carregar dados de configuração, você realiza uma reversão, que substitui toda a configuração do candidato por uma configuração previamente comprometida.
Os módulos e juniper_junos_config os config módulos permitem que você reverta para uma configuração previamente comprometida em dispositivos Junos. Para reverter a configuração e confirmar, inclua o argumento do rollback módulo e especifique o ID da configuração de reversão. Os valores de ID válidos são 0 (zero, para a configuração mais recentemente comprometida) por meio de um a menos do que o número de configurações anteriores armazenadas (o máximo é 49).
O manual a seguir solicita que a ID de reversão da configuração seja restaurada, reverta a configuração e a comprometa e, em seguida, imprime as mudanças de configuração na saída padrão.
---
- name: "Roll back the configuration"
hosts: dc1a
connection: local
gather_facts: no
vars_prompt:
- name: "ROLLBACK"
prompt: "Rollback ID of the configuration to restore"
private: no
tasks:
- name: "Roll back the configuration and commit"
juniper.device.config:
rollback: "{{ ROLLBACK }}"
register: response
- name: "Print the configuration changes"
debug:
var: response.diff_lines
user@ansible-cn:~/ansible$ ansible-playbook configuration-rollback.yaml
Rollback ID of the configuration to restore: 1
PLAY [Roll back the configuration] ********************************************
TASK [Roll back the configuration and commit] *********************************
changed: [dc1a.example.net]
TASK [Print the configuration changes] ***************************************
ok: [dc1a.example.net] => {
"response.diff_lines": [
"",
"[edit interfaces]",
"- ge-0/0/0 {",
"- unit 0 {",
"- family mpls;",
"- }",
"- }"
]
}
PLAY RECAP ********************************************************************
dc1a.example.net : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Como comprometer a configuração
Por padrão, quando você usa o config módulo ou juniper_junos_config modifica a configuração usando o load argumento ou o rollback argumento, o módulo realiza automaticamente uma verificação de confirmação e confirma as alterações. Para evitar que o módulo realize uma verificação de confirmação ou cometa as alterações, definir o ou commit o check argumento parafalse, respectivamente.
Você também pode personalizar a operação de confirmação com muitas das mesmas opções disponíveis no Junos OS CLI. A Tabela 5 descreve os argumentos do módulo que você pode usar para especificar diferentes opções de confirmação.
| Argumento do módulo |
Descrição |
Valor padrão para |
|---|---|---|
|
|
Realize uma verificação de confirmação ou confirme uma operação de confirmação confirmada anteriormente. |
|
|
|
Aguarde o número especificado de segundos entre a verificação de confirmação e a operação de confirmação. |
– |
|
|
Registre um comentário para essa operação de confirmação no arquivo de log do sistema e no histórico de confirmação do dispositivo. |
– |
|
|
Confirme as alterações de configuração ou confirme uma operação de confirmação confirmada anteriormente. |
|
|
|
Confirme as mudanças de configuração mesmo que não haja diferenças entre a configuração do candidato e a configuração comprometida. |
|
|
|
Exija que uma operação de confirmação seja confirmada em um período especificado de tempo após o compromisso inicial. Caso contrário, reverta para a configuração previamente comprometida. A opção |
– |
Ao confirmar a configuração, você pode incluir um breve comentário para descrever a finalidade das mudanças comprometidas. Para registrar um comentário descrevendo as mudanças, inclua o comment: "comment string" argumento com a corda da mensagem.
Por padrão, os módulos e juniper_junos_config os config módulos executam uma verificação de confirmação e uma operação de confirmação. O check_commit_wait argumento define o número de segundos para esperar entre a verificação de confirmação e as operações de confirmação. Inclua esse argumento quando precisar fornecer tempo suficiente para o dispositivo concluir a operação de verificação de confirmação e liberar o bloqueio de configuração antes de iniciar a operação de confirmação. Se você omitir esse argumento, pode haver certas circunstâncias em que um dispositivo inicia a operação de confirmação antes que a operação de verificação de confirmação libere seu bloqueio na configuração, resultando em uma CommitError operação de confirmação e falha.
Por padrão, se não houver diferenças entre a configuração do candidato e a configuração comprometida, o módulo não confirmará as alterações. Para forçar uma operação de confirmação mesmo quando não há diferenças, inclua o commit_empty_changes: true argumento.
Para exigir que uma operação de confirmação seja confirmada em um período especificado de tempo após o compromisso inicial, inclua o confirmed: minutes argumento. Se o commit não for confirmado dentro do prazo determinado, a configuração volta automaticamente para a configuração previamente comprometida. O intervalo permitido é de 1 a 65.535 minutos. A operação de confirmação confirmada é útil para verificar se uma mudança de configuração funciona corretamente e não impede o acesso do gerenciamento ao dispositivo. Se a mudança impedir o acesso ou causar outros erros, a reversão automática da configuração anterior permite o acesso ao dispositivo após o prazo de reversão passar. Para confirmar a operação de confirmação, invoque o config módulo ou juniper_junos_config commit: true o check: true argumento.
No manual a seguir, a primeira tarefa modifica a configuração, espera 10 segundos entre a verificação de confirmação e a operação de confirmação e exige que a operação de confirmação seja confirmada dentro de 5 minutos. Ele também registra um comentário para o commit. A segunda tarefa emite uma commit check operação para confirmar o compromisso. Em um cenário real, você pode realizar tarefas de validação após o compromisso inicial e apenas executar a confirmação de confirmação de confirmação se as tarefas passarem por determinados critérios de validação.
---
- name: "Load configuration and confirm within 5 minutes"
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: "Load configuration. Wait 10 seconds between check and commit. Confirm within 5 min."
juniper.device.config:
load: "merge"
format: "text"
src: "build_conf/{{ inventory_hostname }}/junos.conf"
check_commit_wait: 10
confirmed: 5
comment: "updated using Ansible"
register: response
- name: "Print the response"
debug:
var: response
- name: "Confirm the commit with a commit check"
juniper.device.config:
check: true
diff: false
commit: false
register: response
- name: "Print the response"
debug:
var: response
Como ignorar avisos ao configurar dispositivos
Os módulos e os config módulos juniper_junos_config permitem que você modifique e comprometa a configuração em dispositivos Junos. Em alguns casos, a resposta de RPC pode conter <rpc-error> elementos com um nível de aviso de gravidade ou superior que fazem com que o módulo aumente uma exceção RpcError , fazendo com que a operação de carga ou confirmação falhe.
Em certos casos, pode ser necessário ou desejável suprimir as RpcError exceções levantadas em resposta a avisos para operações de carga e comprometimento. Você pode instruir os config módulos e juniper_junos_config os módulos a suprimir RpcError exceções levantadas para avisos, incluindo o ignore_warning parâmetro na lista de argumentos do módulo. O ignore_warning argumento requer um Boolean, uma corda, ou uma lista de cordas.
Para instruir o módulo a ignorar todos os avisos para operações de carga e comprometimento realizadas pelo módulo, inclua o ignore_warning: true argumento. O exemplo a seguir ignora todos os avisos para operações de carga e confirmação.
---
- name: Configure Device
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Configure op script
juniper.device.config:
config_mode: "private"
load: "set"
lines:
- "set system scripts op file bgp.slax"
ignore_warning: true
register: response
- name: Print the response
debug:
var: response
Se você incluir ignore_warning: true e todos os <rpc-error> elementos tiverem um nível de alerta de gravidade, o aplicativo ignora todos os avisos e não levanta uma exceção RpcError . No entanto, quaisquer <rpc-error> elementos com níveis de gravidade mais altos ainda levantarão exceções.
Para instruir o módulo a ignorar avisos específicos, defina o ignore_warning argumento para uma string ou uma lista de strings contendo os avisos a ignorar. O exemplo a seguir ignora dois avisos específicos:
---
- name: Configure Device
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Configure Junos device and ignore warnings
juniper.device.config:
config_mode: "private"
load: "merge"
src: "build_conf/{{ inventory_hostname }}/junos.conf"
ignore_warning:
- "Advertisement-interval is less than four times"
- "Chassis configuration for network services has been changed."
register: response
- name: Print the response
debug:
var: response
O módulo suprime RpcError exceções se todos os <rpc-error> elementos tiverem um nível de aviso de gravidade e cada aviso na resposta corresponde a uma ou mais das strings especificadas.
Exemplo: Use Ansible para configurar dispositivos Junos
O config módulo permite que você gerencie a configuração em dispositivos Junos. Este exemplo usa o config módulo para fazer alterações de configuração em um dispositivo Junos por meio do NETCONF sobre SSH.
- Requisitos
- Visão geral
- Configuração
- Execute o playbook
- Verificação
- Resolução de problemas de erros de playbook
Requisitos
Este exemplo usa os seguintes componentes de hardware e software:
Servidor de gerenciamento de configuração executando Ansible 2.10 ou posterior com a
juniper.devicecoleção instaladaDispositivo Junos com NETCONF habilitado e uma conta de usuário configurada com permissões apropriadas
Par de chave SSH público/privado configurado para o usuário apropriado no controlador Ansible e no dispositivo Junos
Arquivo de inventário Ansible existente com hosts necessários definidos
Visão geral
Este exemplo apresenta um manual ansible que usa o config módulo para habilitar um novo script de operação na configuração dos dispositivos Junos alvo. O arquivo de dados de configuração, junos-config.conf, contém os dados de configuração relevantes formatados como texto.
O manual inclui a Checking NETCONF connectivity tarefa, que utiliza o wait_for módulo Ansible para tentar estabelecer uma sessão NETCONF com o dispositivo alvo usando a porta padrão NETCONF (830). Se o nó de controle não estabelecer uma sessão NETCONF com um dispositivo-alvo durante a execução da cartilha, ele pulará as tarefas restantes em jogo para esse dispositivo.
A tarefa de configurar o dispositivo executa o config módulo desde que a verificação da NETCONF tenha sido bem sucedida. O argumento do load: "merge" módulo carrega os novos dados de configuração na configuração do candidato usando uma load merge operação. Por padrão, o config módulo compromete dados de configuração em um dispositivo e load rollback operações. Os argumentos do módulo incluem o comment argumento, que registra um comentário de confirmação no arquivo de log do sistema do dispositivo e histórico de confirmação.
Configuração
Criar o arquivo de dados de configuração
Procedimento passo a passo
Para criar o arquivo de dados de configuração que é usado pelo módulo:
Crie um novo arquivo com a extensão apropriada com base no formato dos dados de configuração, que neste exemplo é o texto.
Inclua as alterações de configuração desejadas no arquivo.
user@ansible-cn:~/ansible$ cat build_conf/dc1a.example.net/junos-config.conf system { scripts { op { file bgp.slax; } } }
Crie o Ansible Playbook
Procedimento passo a passo
Para criar um manual que usa o config módulo para fazer alterações de configuração em um dispositivo Junos:
Inclua a caldeira playbook, que executa os módulos localmente.
--- - name: Load and commit configuration data on a Junos device hosts: dc1 connection: local gather_facts: no
(Opcional) Crie uma tarefa para verificar a conectividade NETCONF.
tasks: - name: Checking NETCONF connectivity wait_for: host: "{{ inventory_hostname }}" port: 830 timeout: 5Crie a tarefa para carregar a configuração no dispositivo e comprometê-la.
- name: Merge configuration data from a file and commit juniper.device.config: load: "merge" src: "build_conf/{{ inventory_hostname }}/junos-config.conf" comment: "Configuring op script with Ansible" register: response(Opcional) Crie uma tarefa para publicar a resposta, que inclui as mudanças de configuração no formato diff .
- name: Print the response debug: var: response
Resultados
No nó de controle Ansible, revise o manual completo. Se o manual não exibir o código pretendido, repita as instruções neste exemplo para corrigir o manual.
---
- name: Load and commit configuration data on a Junos device
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Checking NETCONF connectivity
wait_for:
host: "{{ inventory_hostname }}"
port: 830
timeout: 5
- name: Merge configuration data from a file and commit
juniper.device.config:
load: "merge"
src: "build_conf/{{ inventory_hostname }}/junos-config.conf"
comment: "Configuring op script with Ansible"
register: response
- name: Print the response
debug:
var: response
Execute o playbook
Para executar o manual:
-
Emita o
ansible-playbookcomando no nó de controle e forneça o caminho de manual e quaisquer opções desejadas.user@ansible-cn:~/ansible$ ansible-playbook ansible-pb-junos-config.yaml PLAY [Load and commit configuration data on a Junos device] **** TASK [Checking NETCONF connectivity] ************************************** ok: [dc1a.example.net] TASK [Merge configuration data from a file and commit] ******************** changed: [dc1a.example.net] TASK [Print the response] ************************************************* ok: [dc1a.example.net] => { "response": { "changed": true, "diff": { "prepared": "\n[edit system scripts op]\n+ file bgp.slax;\n" }, "diff_lines": [ "", "[edit system scripts op]", "+ file bgp.slax;" ], "failed": false, "file": "build_conf/dc1a.example.net/junos-config.conf", "msg": "Configuration has been: opened, loaded, checked, diffed, committed, closed." } } PLAY RECAP **************************************************************** dc1a.example.net : ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Verificação
Verifique a configuração
Propósito
Verifique se a configuração foi atualizada corretamente no dispositivo Junos.
Ação
Analise a saída de manual ansible para ver se a tarefa de configuração foi bem sucedida ou falhou. Você também pode fazer login no dispositivo Junos e visualizar a configuração, histórico de confirmação e arquivos de log para verificar a configuração e confirmar, por exemplo:
user@dc1a> show configuration system scripts
op {
file bgp.slax;
}
user@dc1a> show system commit
0 2020-12-17 15:33:50 PST by user via netconf
Configuring op script with Ansible
user@dc1a> show log messages Dec 17 15:33:39 dc1a mgd[33444]: UI_COMMIT: User 'user' requested 'commit' operation (comment: Configuring op script with Ansible) Dec 17 15:33:57 dc1a mgd[33444]: UI_COMMIT_COMPLETED: commit complete
Resolução de problemas de erros de playbook
- Resolução de problemas de erros de tempo limite
- Solucionar problemas de bloqueio de configuração
- Resolução de problemas de erros de mudança de configuração
Resolução de problemas de erros de tempo limite
Problema
O manual gera uma TimeoutExpiredError mensagem de erro e não atualiza a configuração do dispositivo.
ncclient.operations.errors.TimeoutExpiredError: ncclient timed out while waiting for an rpc reply
O tempo padrão de um RPC NETCONF para o tempo de saída é de 30 segundos. Grandes mudanças de configuração podem exceder esse valor, fazendo com que a operação fique sem tempo antes que a configuração possa ser carregada e comprometida.
Solução
Para acomodar mudanças de configuração que possam exigir um tempo de confirmação mais longo do que o intervalo de tempo limite de RPC padrão, defina o argumento do timeout módulo para um valor apropriado e execute novamente a cartilha.
Solucionar problemas de bloqueio de configuração
Problema
O manual gera uma LockError mensagem de erro indicando que a configuração não pode ser bloqueada. Por exemplo:
FAILED! => {"changed": false, "msg": "Unable to open the configuration in exclusive mode: LockError(severity: error, bad_element: None, message: configuration database modified)"}
ou
FAILED! => {"changed": false, "msg": "Unable to open the configuration in exclusive mode: LockError(severity: error, bad_element: lock-configuration, message: permission denied)"}
Um erro de bloqueio de configuração pode ocorrer pelos seguintes motivos:
Outro usuário tem um bloqueio exclusivo na configuração.
Outro usuário fez alterações no banco de dados de configuração, mas ainda não cometeu as mudanças.
O usuário que executa o módulo Ansible não tem permissões para configurar o dispositivo.
Solução
A LockError sequência de mensagens geralmente indica a causa raiz do problema. Se outro usuário tiver um bloqueio exclusivo na configuração ou tiver modificado a configuração, aguarde até que a fechadura seja liberada ou as alterações sejam comprometidas e execute a cartilha novamente. Se a causa do problema for que o usuário não tenha permissões para configurar o dispositivo, execute a playbook com um usuário que tenha as permissões necessárias ou, se apropriado, configure o dispositivo Junos para dar ao usuário atual as permissões necessárias para fazer as alterações.
Resolução de problemas de erros de mudança de configuração
Problema
O manual gera uma ConfigLoadError mensagem de erro indicando que a configuração não pode ser modificada, porque a permissão é negada.
FAILED! => {"changed": false, "msg": "Failure loading the configuraton: ConfigLoadError(severity: error, bad_element: scripts, message: error: permission denied)"}
Essa mensagem de erro é gerada quando o usuário que executa o módulo Ansible tem permissão para alterar a configuração, mas não tem permissão para alterar a seção solicitada da configuração.
Solução
Execute o manual com um usuário que tenha as permissões necessárias ou, se apropriado, configure o dispositivo Junos para dar ao usuário atual as permissões necessárias para fazer as alterações.
Tabela de histórico de mudanças
O suporte de recursos é determinado pela plataforma e versão que você está usando. Use o Feature Explorer para determinar se um recurso é suportado em sua plataforma.
Juniper.junos A partir do lançamento 2.0.0, o
juniper_junos_config módulo combina e substitui a funcionalidade do
junos_commit,
junos_get_config
junos_install_confige
junos_rollback módulos.