Ansible for Juniper Junos Configuration Automation - 夜莺博客

Ansible for Juniper Junos Configuration Automation

Junos was designed for programmatic management - structured configuration, native NETCONF support since day one, and a commit model that makes failed changes self-reverting. That makes it the easiest major network OS to automate with Ansible, provided you use NETCONF rather than screen-scraping the CLI and you understand that each junos_config task commits by default. This guide covers a working inventory, the playbook patterns worth keeping, and the rollback options that make change windows survivable.

Install and Prepare

ansible-galaxy collection install junipernetworks.junos
ansible-galaxy collection install ansible.netcommon
pip install junos-eznc ncclient jxmlease xmltodict

Juniper also publishes a juniper.device collection that is the forward-looking option; the junipernetworks.junos collection is widely deployed but has been marked for eventual removal from the community distribution, so pin your versions in a requirements file whichever you choose.

Enable NETCONF and Build the Inventory

set system services netconf ssh
set system services netconf rfc-compliant
commit
# inventory/junos.ini
[junos_routers]
mx-edge-01 ansible_host=10.0.0.1
mx-edge-02 ansible_host=10.0.0.2

[junos_switches]
ex-access-01 ansible_host=10.0.1.1

[junos:children]
junos_routers
junos_switches

[junos:vars]
ansible_network_os=junipernetworks.junos.junos
ansible_connection=ansible.netcommon.netconf
ansible_user=automation
ansible_port=830

NETCONF gives structured XML, proper error codes and transactional commits. Use ansible.netcommon.network_cli only for devices where NETCONF is unavailable.

Applying Configuration with set Commands

Junos set commands are idempotent, which aligns perfectly with Ansible's declarative model. Put all related statements in a single task so they land in one atomic commit.

- name: Configure Junos baseline
  hosts: junos_routers
  gather_facts: no
  tasks:
    - name: System settings
      junipernetworks.junos.junos_config:
        lines:
          - set system host-name {{ inventory_hostname }}
          - set system domain-name corp.local
          - set system name-server 10.0.0.53
          - set system ntp server 10.0.0.50
          - set system time-zone Asia/Shanghai
        comment: "baseline via ansible"

Structured configuration also works - push a text or XML file with src and src_format, and choose the load operation with update (merge, replace or override).

    - name: Push structured config
      junipernetworks.junos.junos_config:
        src: templates/router-base.conf.j2
        src_format: text
        update: merge

Backup Before Every Change

The module can archive the running configuration as part of the same task, which gives you a per-run history without any extra tooling.

    - name: Backup and configure
      junipernetworks.junos.junos_config:
        backup: true
        backup_options:
          dir_path: ./backups
        lines:
          - set interfaces xe-0/0/0 description "Uplink to core-01"

Commit-Confirm for Risky Changes

A commit-confirm change reverts itself if nobody confirms it within the window - the single most useful safety mechanism for remote automation.

    - name: Apply with auto-rollback
      junipernetworks.junos.junos_config:
        lines:
          - set interfaces xe-0/0/2 description "New customer link"
          - set interfaces xe-0/0/2 unit 0 family inet address 172.16.0.1/30
        confirm: 5
        comment: "confirm within 5 minutes"
      register: cfg

    - name: Confirm if the change is good
      junipernetworks.junos.junos_config:
        confirm_commit: true
      when: cfg.changed

If the confirm task never runs - because the network broke - the device rolls back on its own. That property is why commit-confirm beats a manual rollback plan.

Rollback and Factory Reset

    - name: Roll back to previous commit
      junipernetworks.junos.junos_config:
        rollback: 1
        comment: "revert last change"

The zeroize: true argument runs request system zeroize, wiping configuration, keys and user files - reserve it for decommissioning and always pair it with a console connection, because after zeroize you must log in at the console as root.

Verification and Idempotency

- name: Check operational state
  hosts: junos_routers
  gather_facts: no
  tasks:
    - name: Collect interface summary
      junipernetworks.junos.junos_command:
        commands:
          - show interfaces terse
          - show system rollback compare 0 1
      register: out

    - ansible.builtin.debug:
        var: out.stdout_lines

Run every playbook twice. The second run should report changed: false; if it still reports changes, your lines are not idempotent. For Python-native alternatives see PyEZ Python automation and NETCONF, and for the vendor-neutral module set, Ansible network automation command modules across vendors.

原文链接:https://www.juniper.net/documentation/us/en/software/junos-ansible/ansible/topics/topic-map/junos-ansible-configuration-junos-config-module.html