In today's fast-paced world of IT, where everything is interconnected and constantly changing, keeping networks running smoothly is more critical than ever. As organizations strive to keep pace with the dynamic nature of modern business, the role of automation in network operations has emerged as a game-changer. In this era of heightened connectivity and digital transformation, network automation has become a cornerstone in achieving agility, reliability, and security.
Ansible is a robust automation tool known for its emphasis on simplicity and user-friendly design. Operating with a declarative language approach, Ansible employs YAML for its configuration files. Its agentless nature eliminates the need for additional software installation on target machines, contributing to its straightforward deployment. Ansible truly shines in handling configuration management, seamlessly deploying applications, and automating tasks across various devices simultaneously. It's the go-to choice for environments that value simplicity and quick deployment, especially excelling in managing configurations in a stateful manner.
Let’s see an example of a very basic task to configure a one-line command. A configuration like this is useful to apply the same commands to multiple devices, for the examples we will see below we will use Juniper devices as an image. A use case could be configurations that we usually apply on all devices in our network such as SNMP, System Services, Firewall Filters, etc.
Ansible Playbook:
This Ansible playbook named 'Configure Services' is designed to configure system services on Juniper vMX devices. It targets hosts under the group 'vMX' and utilizes the Juniper.junos role for Junos-specific tasks. The playbook includes a task to configure system services, specifically enabling FTP, using the juniper_junos_config module. The provided credentials for the Junos device are the username 'lab' and the password 'lab123'. The configuration change is performed in 'candidate' mode, the load option is 'merge' and the result is registered as 'response1.' Additionally, there is a debug task that prints the registered variable 'response1,' allowing the user to inspect the outcome of the configuration task. The playbook is set to run locally ('connection: local') and skips gathering facts ('gather_facts: no').
Nevertheless, there are situations where the overall configuration remains uniform across multiple devices; however, in specific scenarios, the configuration details hinge on the individual characteristics of each device or interface. In such instances, an alternative tool comes into play, and that tool is known as Jinja2. Jinja2 proves invaluable by providing a powerful templating engine that facilitates dynamic and customized configuration file generation.
Here's an example showcasing the effectiveness of Jinja2. With this tool at our disposal, configuring multiple devices becomes a swift task, taking only a matter of minutes. After setting up the variables, the template and playbook take care of the entire configuration process.
Jinja : Interfaces.j2:
vMx1.yml
Ansible Playbook:
This Ansible playbook, combined with the Jinja template (Interfaces.j2) and the vMx1.yml file, orchestrates the configuration of network interfaces on Juniper vMX devices. The Jinja template dynamically generates interface configurations based on the variables provided in the vMx1.yml file. For each interface specified in the YAML file, it creates a corresponding configuration block with the interface name and IP address.
The Ansible playbook begins by including the variables from the vMx1.yml file. It then utilizes the Jinja template to render the interface configurations, saving the result in a temporary file (tmp/ConfigFinal.conf). Subsequently, the playbook employs the Juniper.junos role to load and replace the existing configurations on the vMX devices with the generated interface settings. The provided Junos device credentials ('lab' as the username and 'lab123' as the password) are used for authentication
The playbook captures the differences between the existing and new configurations (diff: yes) and registers the result as 'response1.' Finally, a debug task prints the registered variable, allowing users to review the outcome of the interface configuration.
Here we have a glimpse of the power of Ansible for network automation. The provided Ansible playbooks exemplifies its prowess, demonstrating how configurations can be effortlessly managed and applied across multiple devices and using Jinja2 the tool expands its applications. Although there are several other tools in the world of automation, such as Scripting in Python and its multiples libraries if you prioritize simplicity, rapid deployment and a declarative approach, Ansible may be the right choice. As we embrace the Network Automation Era, the collaboration between tools as Ansible and Jinja2 exemplifies a transformative approach to managing, adapting, and optimizing network configurations.
For more information about commands and features you can check https://docs.ansible.com https://jinja.palletsprojects.com/en/3.1.x.