One step further with Ansible to automate Junos devices
Aug 1, 2016
Ansible is a very popular automation framework to manage and deploy all components of an IT infrastructure. Since 2014, Juniper has been providing Ansible modules for Junos to allow our customers to manage Junos devices with Ansible. These modules for Junos are available in Ansible Galaxy and will be referenced as “Galaxy Modules”.
In its latest release, Ansible is now officially supporting a group of modules for various network devices, including Junos. Juniper is very excited by this new partnership and we’ve been working closely with Ansible to make sure that these new modules will follow both Ansible and Juniper best practices. These modules for Junos will be referenced as “Core Modules”
As the Galaxy Modules have been available for some time, it was a great opportunity to redesign the Junos modules and add new capabilities to make Ansible even more compelling to manage Juniper devices. The “Core Modules“ are bringing some exciting new capabilities that will enable our customers to automate even more operations. (See the list of improvements below).
All modules, in Galaxy and in Core, are working over our management API, Netconf and are compatible with all devices running Junos 11.4+. For better maintainability, all modules are using the library PyEZ that intent to simplify the usage of the netconf API in Python. PyEZ is an open source library used by hundreds of our customers, Juniper actively develops and supports PyEZ.
What is available in Ansible 2.1
Starting Ansible 2.1, 6 Core Modules for Junos are available, these new modules are organized by topics, unlike the Galaxy Modules that are organized by action (1 action = 1 module). As a result, a smaller number of modules can cover even more use cases.
For our existing users of the Galaxy modules, the migration will be seamless as both Galaxy and Core modules can coexist on the same system.
Improvements available in the new Core Modules
As mentioned, there are several enhancements available in the new Core modules for Junos
Idempotency is an important capability in automation. An idempotent task will first check the state of the device and will make a change only if the current state does not match the required end state. Not all actions can’t be idempotent by nature, only modules that introduce a change are eligible.
The Core modules junos_config and junos_package are mostly idempotent, check the documentation for more details
Of course junos_command is NOT idempotent
2/ Convert XML to JSON
Junos Core modules are able to natively convert XML to JSON to pass returned information to Ansible. This new capability allows for a wide range of new use cases where information coming from Junos can be used to execute some tests or to dynamically generate other requests.
With this new capability, it’s possible to get the list of interfaces configured with OSPF from the configuration and check if there is a peering associated with each of them.
The conversion from XML to JSON is preferred over native JSON output because it works with more version of Junos
junos_fact can collect configuration in XML and convert to JSON
junos_command can convert XML responses and convert to JSON
The Core module junos_command integrates an option to validate the response received and retry it, if the response is not valid.
This capability opens the door to new use-cases like:
Wait for an action to complete > interface turn up
Verify element state > BGP state
Check command integrity
This method is preferred over Ansible native wait_for because it will maintain the session open with the device, while wait_for will force a new session
Starting in release 2.1, Ansible integrates a shared library to communicate with Junos devices. This library centralized the management of the netconf session, XML conversion to JSON etc ..
All Core modules are using this library.
Main benefits for the end user are:
Modules are easier to maintain, there is less duplicate of code
All Modules have homogeneous parameters and options name
New transport can be added more easily (console)
5/ Better integration with Ansible
The Core Modules have a better integration with Ansible, especially the options “—check” and “—diff” in cli that make it easier to understand the potential effect of a playbook without affecting your devices. These options are very useful in production and are very popular among Ansible users.
6/ Ansible tower
Core modules are officially supported in Ansible tower. Ansible tower is a Front End Graphical interface from Ansible and also provide REST API and RBAC.
The Ansible Tower dashboard provides a heads-up NOC-style display for everything going on in your Ansible environment.
Ansible tower is a product commercialized by Ansible
Both Core and Galaxy modules have a place
Moving forward, both Core and Galaxy modules will continue to evolve. Ansible and Juniper will support the Core modules and modules that are not generic enough to be incorporated into Ansible Core will remain in Galaxy.
For Juniper and Ansible customers, this evolution should be transparent and this model will guarantee the right balance between long term support and innovation.
Juniper keeps investing in Galaxy modules, recently new Galaxy modules oriented around operational management and system testing have been developed ... more information will be available soon on these.
Get started with Ansible
It’s very easy to get started with Ansible to automate your Junos devices.