JNCIS-DevOps: Automation and Configuration Management

What this domain covers

Automation and configuration management tests your ability to change Junos devices safely and repeatably: the Junos commit model, Junos PyEZ, and configuration management tools such as Ansible and Salt.

Core rules and concepts

• The Junos commit model is the safety net. Configuration is built in a candidate config, validated with commit check, and applied atomically. commit confirmed <minutes> auto-rolls back unless confirmed, and rollback n restores an earlier commit.
• Junos PyEZ is the Python library for Junos. Device opens a NETCONF session (TCP 830 by default). The Config utility handles lock(), load(), commit_check(), commit(), rollback() and unlock(); mode='exclusive' takes an exclusive lock.
• Tables and Views parse operational output into Python dictionaries, so you never regex show text.
• Ansible uses the juniper.device collection (junos_config, junos_command, junos_facts) over netconf or network_cli. Modules should be idempotent: a second run reports changed=false.
• Salt runs Junos as a proxy minion; NAPALM gives a multi-vendor getter/setter abstraction.

Worked example

Goal: ensure ge-0/0/1 has description UPLINK-A. Read first with dev.rpc.get_config(filter_xml=...) and compare the description; if it already matches, exit without loading. If not, enter Config(dev, mode='exclusive'), load() a small XML snippet with merge semantics, run commit_check(), then commit(comment='...'). Idempotent, locked and validated - the three things a mark scheme looks for.

Traps

• load merge vs load replace vs load override vs load set: merge adds, replace swaps a hierarchy, override discards everything else.
• Skipping commit check before commit.
• Forgetting that an exclusive lock blocks other users, and failing to unlock() or dev.close().
• Screen-scraping CLI output instead of using NETCONF/XML.