Use o juniper.device.config módulo Ansible para gerenciar a configuração do Junos OS
Você pode usar o juniper.device.config módulo Ansible para gerenciar a configuração em dispositivos que executam o Junos OS e dispositivos que executam o Junos OS Evolved.
A Juniper Networks oferece módulos Ansible que permitem configurar dispositivos Junos. A Tabela 1 descreve os módulos disponíveis. Se você já estiver usando um determinado conjunto de módulos da juniper.device coleção, use o módulo para esse conjunto.
|
Coleção de Emoji |
Conjunto de módulos |
Nome do módulo |
|---|---|---|
|
|
||
|
|
juniper.device.junos_config |
As seções a seguir discutem como usar o juniper.device.config módulo para modificar e confirmar a configuração em dispositivos Junos. Para obter informações sobre o juniper.device.junos_config módulo, consulte Usar o módulo juniper.device.junos_config Ansible para configurar dispositivos Junos.
Visão geral do módulo
O juniper.device.config módulo permite realizar as seguintes operações em dispositivos Junos:
-
Carregar dados de configuração
-
Confirmar a configuração
-
Reverta a configuração
-
Carregar a configuração de resgate
O processo básico para fazer alterações de configuração é bloquear a configuração, carregar as alterações de configuração, confirmar a configuração para torná-la ativa e, em seguida, desbloquear a configuração. A conta de 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. Para modificar a configuração, a lista de argumentos do módulo deve incluir um dos seguintes parâmetros:
-
load— Carregue novos dados de configuração. -
rollback— Reverta para a configuração de resgate ou uma configuração confirmada anteriormente.
Por padrão, o juniper.device.config módulo faz 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 especificar um modo de configuração diferente. Por exemplo, você pode fazer alterações em uma cópia privada da configuração candidata ou no banco de dados de configuração efêmera. Para obter mais informações sobre como especificar o modo de configuração, consulte 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 carregamento e a origem e o formato das alterações.
-
Operação de carregamento — A operação de carregamento determina como os dados de configuração são carregados no banco de dados de configuração selecionado. Você pode selecionar entre muitas das mesmas operações de carga que estão disponíveis na CLI do Junos OS. Para obter mais informações, consulte Como especificar a ação de carregamento.
-
Formato — Você pode configurar dispositivos Junos usando um dos formatos padrão suportados. Você pode fornecer dados de configuração ou modelos Jinja2 como texto, elementos XML do Junos, comandos do Junos OS
setou JSON. Para obter informações sobre como especificar o formato dos dados de configuração, consulte 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, de um arquivo no nó de controle local do Ansible, de um modelo Jinja2 ou de uma URL acessível a partir do dispositivo cliente. Para obter mais informações sobre como especificar a origem dos dados de configuração, consulte as seguintes seções:
O juniper.device.config módulo também permite carregar e confirmar a configuração de resgate ou reverter a configuração para uma configuração confirmada anteriormente. Para carregar a configuração de resgate ou uma configuração confirmada anteriormente, você deve incluir o rollback argumento module. Para obter mais informações, consulte as seguintes seções:
Depois de modificar a configuração, você deve confirmar a configuração para torná-la a configuração ativa no dispositivo. Por padrão, o módulo confirma juniper.device.config as alterações na configuração. Para alterar esse comportamento ou fornecer opções de confirmação adicionais, consulte Como confirmar a configuração.
Por padrão, quando o juniper.device.config módulo inclui os load argumentos or rollback , a resposta do módulo retorna automaticamente as alterações de configuração no formato diff ou patch. O módulo retorna as diferenças nos diff campos e diff_lines . Para impedir que o módulo calcule e retorne as diferenças, defina o argumento do diff módulo como false.
Como especificar o modo de configuração
Você pode especificar o modo de configuração a ser usado ao modificar a configuração do dispositivo. Para especificar o modo de configuração em sua tarefa, inclua o parâmetro do config_mode módulo. Os modos de configuração suportados incluem:
-
batch -
dynamic -
ephemeral -
exclusive -
private
Por padrão, o juniper.device.config módulo faz alterações no banco de dados de configuração do candidato usando configure exclusive o modo. O modo exclusivo de configuração bloqueia a configuração global candidata (também conhecida como banco de dados de configuração compartilhada) pelo tempo que o módulo exigir para fazer as alterações de configuração solicitadas. Bloquear o banco de dados impede que outros usuários modifiquem ou confirmem alterações no banco de dados ao mesmo tempo.
Os exemplos a seguir mostram como configurar uma cópia privada da configuração do candidato e como configurar o banco de dados efêmero.
Exemplo: config_mode: "private"
O guia estratégico a seguir usa private o modo de configuração para modificar uma cópia privada da configuração do candidato:
---
- 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
ansible.builtin.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
Configurar o banco de dados efêmero
Você pode usar o juniper.device.config módulo para atualizar o banco de dados de configuração efêmera em dispositivos que dão suporte a esse banco de dados. O banco de dados efêmero é um banco de dados de configuração alternativo que fornece uma interface programática rápida para realizar atualizações de configuração em dispositivos Junos.
Para abrir e configurar a instância padrão do banco de dados de configuração efêmera, inclua o config_mode: ephemeral argumento. Por exemplo:
---
- name: Configure ephemeral database
hosts: dc1a
connection: local
gather_facts: no
tasks:
- name: Configure the default ephemeral database
juniper.device.config:
config_mode: ephemeral
load: set
lines:
- "set protocols mpls label-switched-path to-hastings to 192.0.2.1"
Para abrir e configurar uma instância definida pelo usuário existente do banco de dados de configuração efêmera, inclua o config_mode: ephemeral argumento e defina o ephemeral_instance argumento como o nome da instância.
tasks:
- name: Configure a user-defined ephemeral instance
juniper.device.config:
config_mode: ephemeral
ephemeral_instance: eph1
load: set
lines:
- "set protocols mpls label-switched-path to-hastings to 192.0.2.2"
Como especificar a ação de carregamento
O juniper.device.config módulo oferece suporte ao carregamento de mudanças de configuração usando muitas das mesmas operações de carregamento suportadas na CLI do Junos OS. Você especifica a operação de carregamento definindo o argumento do load módulo como o valor da operação de carregamento correspondente. A Tabela 2 resume os valores dos argumentos para as diferentes operações de carga.
|
Operação de carga |
|
Descrição |
|---|---|---|
|
|
|
Mescle a configuração carregada com a configuração existente. |
|
|
|
Substitua toda a configuração pela configuração carregada. Todos os processos do sistema analisam a configuração. |
|
|
|
Carregue dados de configuração de um arquivo de patch. |
|
|
|
Mescle a configuração carregada com a configuração existente, mas substitua as instruções na configuração existente por instruções na configuração carregada que especificam a |
|
|
|
Carregue os dados de configuração que estão no |
|
|
|
Carregue uma configuração completa e compare-a com a configuração existente. Substitua apenas as partes da configuração candidata que foram alteradas. Durante a operação de confirmação, apenas os processos afetados do sistema analisam a nova configuração. |
Como especificar o formato dos dados de configuração a serem carregados
O juniper.device.config módulo permite configurar dispositivos Junos usando um dos formatos padrão 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 em uma string, arquivo ou modelo Jinja2, os formatos suportados para os dados incluem texto, elementos XML do Junos, comandos do Junos OS set e JSON.
O juniper.device.config módulo tenta detectar automaticamente o formato dos dados de configuração que você fornece como strings dentro do lines argumento. No entanto, você pode especificar explicitamente o formato das cadeias de caracteres incluindo o format argumento. Ao fornecer dados de configuração em um arquivo ou modelo Jinja2, você deve especificar o formato dos dados. Adicione a extensão apropriada ao arquivo ou inclua 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 o parâmetro do arquivo. Se você incluir o format argumento, ele substituirá o formato de detecção automática de cadeias de caracteres e o formato indicado por uma extensão de arquivo.
|
Formato dos dados de configuração |
Extensão de arquivo |
|
|---|---|---|
|
Declarações de configuração da CLI (texto) |
.conf |
|
|
Notação de objeto JavaScript (JSON) |
.json |
|
|
|
.set |
|
|
Elementos XML do Junos |
.xml |
|
Quando você define o argumento do load módulo como override ou update, não é possível usar o formato de comando do Junos OS set .
Como carregar dados de configuração como strings
O juniper.device.config módulo permite carregar 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 usa uma lista de strings contendo os dados de configuração a serem carregados.
O módulo tenta 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, consulte Como especificar o formato dos dados de configuração a serem carregados. Se você incluir o format argumento, ele substituirá o formato detectado automaticamente.
O guia estratégico a seguir configura e confirma dois scripts operacionais. Nesse caso, o load argumento tem o valor 'set' porque os dados de configuração usam lines o formato de instruçã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
ansible.builtin.debug:
var: response
O guia estratégico a seguir configura as mesmas instruções usando lines com dados de configuração em formato de texto. Nesse caso, o exemplo usa load: "merge".
---
- 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"
ansible.builtin.debug:
var: response
Como carregar dados de configuração de um arquivo local ou remoto
O juniper.device.config módulo permite carregar dados de configuração de um arquivo. O arquivo pode residir em um dos seguintes locais:
-
Nó de controle do Ansible
-
Dispositivo cliente
-
URL FTP ou HTTP acessível a partir do dispositivo cliente
Ao carregar dados de configuração de um arquivo, você deve indicar o local do arquivo e o formato dos dados de configuração no arquivo. Os formatos de dados de configuração suportados incluem texto, elementos XML do Junos, comandos do Junos OS set e JSON. Para obter informações sobre como carregar arquivos que contêm modelos Jinja2, consulte Como carregar dados de configuração usando um modelo Jinja2.
Para especificar o formato, inclua o parâmetro do módulo ou adicione a extensão apropriada ao arquivo de format dados de configuração. Se você especificar o format parâmetro, ele substituirá o formato indicado pela extensão do arquivo. Para obter informações sobre como especificar o formato, consulte Como especificar o formato dos dados de configuração a serem carregados. Quando os dados de configuração usam o formato XML do Junos, você deve colocar os dados na tag de nível <configuration> superior.
Você não precisa incluir dados de configuração formatados como texto, comandos do Junos OS set ou JSON em <configuration-text>, <configuration-set>, ou <configuration-json> tags conforme necessário ao configurar o dispositivo diretamente em uma sessão NETCONF.
A Tabela 4 descreve os parâmetros do módulo que você pode incluir para especificar o local do arquivo.
|
Parâmetro do módulo |
Descrição |
|---|---|
|
|
|
|
|
|
Para carregar dados de configuração de um arquivo local no nó de controle do Ansible, defina o src argumento como 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
ansible.builtin.debug:
var: response
Para carregar dados de configuração de um arquivo no dispositivo Junos ou de um URL FTP ou HTTP, use o url parâmetro. Especifique o caminho ou a URL do arquivo a ser carregado. 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
ansible.builtin.debug:
var: response
O valor de url pode ser um caminho de arquivo local absoluto ou relativo, um local de FTP ou uma URL HTTP.
-
O caminho de um arquivo local no dispositivo de destino tem uma das seguintes formas:
-
/path/filename— Arquivo em um sistema de arquivos montado, no disco flash local ou no disco rígido.
-
uma:filename ou um: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).
-
-
O caminho de um arquivo em um servidor FTP tem o seguinte formato:
ftp://username:password@hostname/path/filename -
O caminho de um arquivo em um servidor HTTP tem o seguinte formato:
http://username:password@hostname/path/filename
Em cada caso, o valor padrão da path variável é o diretório inicial do 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
O juniper.device.config módulo permite renderizar dados de configuração de um arquivo de modelo Jinja2 no nó de controle do Ansible e carregar e confirmar a configuração em um dispositivo Junos. Jinja é um mecanismo de modelo para Python que permite gerar documentos a partir de modelos predefinidos. Os modelos, que são arquivos de texto no idioma desejado, fornecem 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 XML do Junos, comandos do Junos OS set e JSON. O módulo Ansible usa o modelo Jinja2 e um dicionário de variáveis fornecido para renderizar os dados de configuração.
Para carregar e confirmar dados de configuração usando um modelo Jinja2, inclua os template parâmetros e vars na lista de argumentos do módulo.
-
template— Caminho do arquivo de modelo Jinja2 -
vars— Dicionário de chaves e valores necessários para renderizar o modelo Jinja2
Você também deve incluir o format parâmetro quando a extensão do arquivo do modelo não indicar o formato dos dados. Para obter informações sobre como especificar o formato, consulte 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 juniper.device.config módulo para carregar o modelo Jinja2, defina o template argumento como o caminho do arquivo de modelo. Defina as variáveis exigidas pelo modelo no vars dicionário.
O guia estratégico a seguir usa o modelo Jinja2 e o vars dicionário para renderizar os dados de configuração. O format parâmetro indica o formato dos dados de configuração no arquivo de modelo. O guia estratégico carrega e confirma a configuração no host de destino.
---
- 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
ansible.builtin.debug:
var: response
O módulo gera os seguintes dados de configuração. O módulo carrega os dados na configuração candidata no dispositivo e os confirma.
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 precisar reverter para uma configuração conhecida ou como último recurso se a configuração do dispositivo e os arquivos de configuração de backup forem danificados além do reparo. Quando você cria uma configuração de resgate, o dispositivo salva a configuração confirmada mais recentemente como a configuração de resgate.
O juniper.device.config módulo permite que você reverta para uma configuração de resgate existente em dispositivos Junos. Para carregar e confirmar 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
ansible.builtin.debug:
var: response
Como reverter a configuração
Os dispositivos Junos armazenam uma cópia da configuração confirmada mais recentemente e até 49 configurações anteriores, dependendo da plataforma. Você pode reverter para qualquer uma das configurações armazenadas. Esse recurso é útil quando as alterações 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. No entanto, em vez de carregar dados de configuração, você executa uma reversão, que substitui toda a configuração do candidato por uma configuração confirmada anteriormente.
O juniper.device.config módulo permite que você reverta para uma configuração anteriormente confirmada em dispositivos Junos. Para reverter a configuração e confirmá-la, inclua o argumento do rollback módulo e especifique a ID da configuração de reversão. Os valores de ID válidos são 0 (zero, para a configuração confirmada mais recentemente) até um a menos que o número de configurações anteriores armazenadas (o máximo é 49).
O guia estratégico a seguir solicita primeiro a ID de reversão da configuração a ser restaurada. A primeira tarefa reverte a configuração para a versão solicitada e a confirma. A segunda tarefa imprime as diferenç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
ansible.builtin.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 confirmar a configuração
Por padrão, quando você usa o juniper.device.config módulo para modificar a configuração, o módulo executa automaticamente uma verificação de confirmação e confirma as alterações. Para impedir que o módulo execute uma verificação de confirmação ou confirme as alterações, defina o check argumento ou commit como false, respectivamente.
Você também pode personalizar a operação de confirmação com muitas das mesmas opções que estão disponíveis na CLI do Junos OS. 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 |
|---|---|---|
|
|
Execute 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 a configuração mesmo que a configuração candidata não tenha alterações. |
|
|
|
Sincronize e confirme a configuração em todos os mecanismos de roteamento, mesmo que o outro Mecanismo de Roteamento tenha sessões de configuração abertas ou alterações de configuração não confirmadas. |
|
|
|
Sincronize e comprometa a configuração em todos os mecanismos de roteamento. |
|
|
|
Exigir que uma operação de confirmação seja confirmada dentro de um período de tempo especificado após a confirmação inicial. Se você não confirmar a confirmação no tempo especificado, reverta para a configuração confirmada anteriormente. Confirme a confirmação usando a |
– |
|
|
Aguarde a conclusão da operação usando o valor especificado como o tempo limite. |
30 segundos |
Comentário do commit
Ao confirmar a configuração, você pode incluir um breve comentário para descrever a finalidade das mudanças confirmadas. Para registrar um comentário descrevendo as alterações, inclua o comment: "comment string" argumento com a cadeia de caracteres da mensagem.
Verificação de confirmação
Por padrão, o juniper.device.config módulo executa uma verificação de confirmação e uma operação de confirmação. O check_commit_wait argumento define o número de segundos a aguardar entre a verificação de confirmação e as operações de confirmação. Inclua esse argumento quando precisar fornecer tempo suficiente para que o dispositivo conclua a operação de verificação de confirmação e libere o bloqueio de configuração antes de iniciar a operação de confirmação. Se o dispositivo iniciar a operação de confirmação antes que a operação de verificação de confirmação libere seu bloqueio na configuração, a operação de confirmação falhará e o módulo emitirá um CommitError.
Confirmar alterações vazias
Por padrão, se a configuração candidata e a configuração confirmada não tiverem diferenças, o módulo não confirmará as alterações. Para forçar uma operação de confirmação mesmo quando nenhuma diferença estiver presente, inclua o commit_empty_changes: true argumento.
Sincronização de confirmação
Se o dispositivo tiver mecanismos de roteamento duplos, você poderá sincronizar e confirmar a configuração em ambos os mecanismos de roteamento incluindo o commit_sync: true argumento. Para forçar a commit synchronize operação a ser bem-sucedida, mesmo que o outro Mecanismo de Roteamento tenha sessões de configuração abertas ou alterações de configuração não confirmadas, use o commit_force_sync: true argumento. Quando você inclui a commit_force_sync: true opção, o dispositivo encerra todas as sessões de configuração no outro Mecanismo de Roteamento antes de sincronizar e confirmar a configuração.
Confirmar confirmação
Para exigir que uma operação de confirmação seja confirmada dentro de um período de tempo especificado após a confirmação inicial, inclua o confirmed: minutes argumento. Se você não confirmar a confirmação dentro do limite de tempo determinado, a configuração será revertida automaticamente para a configuração confirmada anteriormente. O intervalo permitido é de 1 a 65.535 minutos. A operação de confirmação confirmada é útil para verificar se uma alteração de configuração funciona corretamente e não impede o acesso de gerenciamento ao dispositivo. Se a alteração impedir o acesso ou causar outros erros, a reversão automática para a configuração anterior habilitará o acesso ao dispositivo após o término do prazo de reversão. Para confirmar a operação de confirmação, invoque o juniper.device.config módulo com o check: true argumento or commit: true .
No guia estratégico a seguir, a primeira tarefa modifica a configuração, aguarda 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 em 5 minutos. Ele também registra um comentário para o commit. A segunda tarefa emite uma commit check operação para confirmar a confirmação. Em um cenário do mundo real, você pode executar tarefas de validação após a confirmação inicial e executar a confirmação de confirmação apenas 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
ansible.builtin.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
ansible.builtin.debug:
var: response
Como ignorar avisos ao configurar dispositivos
O juniper.device.config módulo permite modificar e confirmar a configuração em dispositivos Junos. Em alguns casos, a resposta RPC pode conter <rpc-error> elementos com um nível de gravidade de aviso ou superior que fazem com que o módulo gere uma RpcError exceção. Uma RpcError exceção pode fazer com que a operação de carregamento ou confirmação falhe.
Em determinados casos, pode ser necessário ou desejável suprimir as RpcError exceções geradas em resposta a avisos para operações de carregamento e confirmação. Você pode instruir o juniper.device.config módulo a suprimir RpcError exceções geradas para avisos, incluindo o ignore_warning parâmetro na lista de argumentos do módulo. O ignore_warning argumento usa um booleano, uma cadeia de caracteres ou uma lista de cadeias de caracteres.
Para instruir o módulo a ignorar todos os avisos para operações de carregamento e confirmação executadas pelo módulo, inclua o ignore_warning: true argumento. O exemplo a seguir ignora todos os avisos para operações de carregamento 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
ansible.builtin.debug:
var: response
Se você incluir ignore_warning: true e todos os <rpc-error> elementos tiverem um nível de gravidade de aviso, o aplicativo ignorará todos os avisos e não gerará uma RpcError exceção. No entanto, todos os <rpc-error> elementos com níveis de gravidade mais altos ainda gerarão exceções.
Para instruir o módulo a ignorar avisos específicos, defina o ignore_warning argumento como uma cadeia de caracteres ou uma lista de cadeias de caracteres que contém os avisos a serem ignorados. 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
ansible.builtin.debug:
var: response
O módulo suprimirá RpcError exceções se todos os <rpc-error> elementos tiverem um nível de gravidade de aviso e cada aviso na resposta corresponder a uma ou mais das cadeias de caracteres especificadas.
Exemplo: usar o Ansible para configurar dispositivos Junos
O juniper.device.config módulo permite que você gerencie a configuração em dispositivos Junos. Este exemplo usa o config módulo para fazer mudanças de configuração em um dispositivo Junos por meio de NETCONF sobre SSH.
- Requerimentos
- Visão geral
- Configuração
- Execute o manual
- Verificação
- Solucionar problemas de erros do guia estratégico
Requerimentos
Este exemplo usa os seguintes componentes de hardware e software:
-
Servidor de gerenciamento de configuração executando o Ansible 2.17 ou posterior com a
juniper.devicecoleção instalada -
Dispositivo Junos com NETCONF habilitado e uma conta de usuário configurada com as permissões apropriadas
-
Par de chaves pública/privada SSH configurado para o usuário apropriado no controlador Ansible e no dispositivo Junos
-
Arquivo de inventário existente do Ansible com hosts necessários definidos
Visão geral
Este exemplo apresenta um playbook do Ansible que usa o juniper.device.config módulo para habilitar um novo script de op na configuração dos dispositivos Junos de destino. O arquivo de dados de configuração, junos-config.conf, contém os dados de configuração relevantes formatados como texto.
O playbook inclui a Check NETCONF connectivity tarefa, que utiliza o ansible.builtin.wait_for módulo Ansible para tentar estabelecer uma sessão NETCONF com o dispositivo de destino usando a porta padrão NETCONF (830). Se o nó de controle não conseguir estabelecer uma sessão NETCONF com um dispositivo de destino durante a execução do playbook, ele ignorará as tarefas restantes na reprodução para esse dispositivo.
O playbook usa o juniper.device.file_copy módulo para copiar o novo script de op do nó de controle do Ansible para o dispositivo Junos. Os argumentos do módulo especificam o diretório e o nome do arquivo do script no dispositivo local e o diretório de destino no dispositivo remoto.
A tarefa de configurar o dispositivo executa o juniper.device.config módulo, desde que a verificação NETCONF tenha sido bem-sucedida. O load: "merge" argumento carrega os novos dados de configuração na configuração candidata usando uma load merge operação. Por padrão, o módulo confirma config dados de configuração em um dispositivo para load e 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 no 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 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 é 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; } } }
Criar o manual do Ansible
Procedimento passo a passo
Para criar um playbook que usa o config módulo para fazer mudanças de configuração em um dispositivo Junos:
-
Inclua o boilerplate do manual, 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: Check NETCONF connectivity ansible.builtin.wait_for: host: "{{ inventory_hostname }}" port: 830 timeout: 5 -
Crie uma tarefa para copiar o novo script de operação para o dispositivo.
- name: Copy the op script to the device juniper.device.file_copy: action: put file: bgp.slax local_dir: scripts remote_dir: /var/db/scripts/op -
Crie a tarefa para carregar a configuração no dispositivo e confirmá-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 imprimir a resposta, que inclui as alterações de configuração no formato diff .
- name: Print the response ansible.builtin.debug: var: response
Resultados
No nó de controle do Ansible, examine o manual concluído. Se o guia estratégico 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: Check NETCONF connectivity
ansible.builtin.wait_for:
host: "{{ inventory_hostname }}"
port: 830
timeout: 5
- name: Copy the op script to the device
juniper.device.file_copy:
action: put
file: bgp.slax
local_dir: scripts
remote_dir: /var/db/scripts/op
- 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
ansible.builtin.debug:
var: response
Execute o manual
Para executar o manual:
-
Emita o
ansible-playbookcomando no nó de controle e forneça o caminho do guia estratégico e as 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 [Check NETCONF connectivity] ***************************************** ok: [dc1a.example.net] TASK [Copy the op script to the device] *********************************** changed: [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=4 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Verificação
Verifique a configuração
Finalidade
Verifique se a configuração foi atualizada corretamente no dispositivo Junos.
Ação
Revise a saída do guia estratégico do 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, o histórico de commits e os arquivos de log para verificar a configuração e o commit, 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
Solucionar problemas de erros do guia estratégico
- Solucionar problemas de erros de tempo limite
- Solucionar problemas de erros de bloqueio de configuração
- Solucionar problemas de erros de alteração de configuração
Solucionar problemas de erros de tempo limite
Problema
O guia estratégico gera uma mensagem de TimeoutExpiredError erro e falha ao atualizar a configuração do dispositivo.
ncclient.operations.errors.TimeoutExpiredError: ncclient timed out while waiting for an rpc reply
O tempo padrão para um RPC NETCONF atingir o tempo limite é de 30 segundos. Grandes alterações de configuração podem exceder esse valor, fazendo com que a operação atinja o tempo limite antes que a configuração possa ser carregada e confirmada.
Solução
Para acomodar alterações de configuração que podem exigir um tempo de confirmação maior que o intervalo de tempo limite RPC padrão, defina o argumento do timeout módulo como um valor apropriado e execute novamente o playbook.
Solucionar problemas de erros de bloqueio de configuração
Problema
O guia estratégico gera uma mensagem de LockError 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 confirmou as alterações.
-
O usuário que executa o módulo Ansible não tem permissões para configurar o dispositivo.
Solução
A LockError cadeia de caracteres da mensagem 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 o bloqueio seja liberado ou as alterações sejam confirmadas e execute o guia estratégico novamente. Se a causa do problema for que o usuário não tem permissões para configurar o dispositivo, execute o 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.
Solucionar problemas de erros de alteração de configuração
Problema
O guia estratégico gera uma mensagem de ConfigLoadError erro indicando que a configuração não pode ser modificada, pois a permissão foi 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 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.