Juniper Automation Tooling (Junos PyEZ, Ansible, Salt)
Know the three main Junos automation paths and when each is appropriate. Junos PyEZ is a Python library (jnpr.junos) that talks to devices via NETCONF. Core objects: Device (connection), Config (load/commit/rollback), Table/View (operational data as structured Python objects), and Rpc. Typical flow: connect (Device(host=..., user=..., password=...)), enter config mode, load() a template or file, commit_check(), commit(), or rollback(). Expect questions on commit_check() (syntax check without applying), diff() (show pending changes), and using Template/jinja2 for parameterized config.
Ansible is agentless and push-based. Know inventory, host_vars/group_vars, playbooks, tasks, modules, handlers, and idempotent modules. For Junos, the key modules are juniper.device.config (load/commit config, supports check_commit, commit, rollback), juniper.device.command (operational commands), juniper.device.facts, and juniper.device.table/junos_* for structured data. Understand connection: local/network_cli/netconf and that network modules often run on the control node. Traps: assuming a changed task re-runs every time (idempotency), and forgetting check_mode/check_commit for dry runs.
Salt uses a master/minion model (or proxy minions for network devices). Know states (declarative SLS files), execution modules, grains (static facts), and pillars (targeted data). Junos proxy minions let the master manage devices without an agent on the device itself.
Rule of thumb: PyEZ for custom Python workflows and precise NETCONF control; Ansible for agentless, idempotent, playbook-driven multi-device changes; Salt for large-scale event-driven/state-driven fleets.