For several years now, Ansible AWX has been on my ToDo list. I have always postponed dealing with it due to its complexity, but today I find myself having to tackle it.
Network automation arises as a necessity to reduce and enhance operability, standardize working methods, and operate on multiple devices in significantly reduced times. The number of individuals interested in this approach is steadily expanding: starting from network engineer teams, automation is now attracting GRC (Governance Risk and Compliance) teams.
Developing automations that interact with network devices requires having a development environment to test, learn, and experiment with frameworks, integrations, and automations. Virtualization over the years has allowed anyone to have realistic copies of network devices at their disposal.
This article serves as an example to explore different strategies for configuring a feature on network devices using Ansible. Specifically, we will focus on configuring NTP on Cisco IOS devices, although the discussions here can be generalized.
This article explores how to optimize the provisioning of a hundred Cisco XR devices so that they are configured with minimal human intervention. Depending on the context, the devices might be shipped directly from the factory and configured automatically on-site, or more likely, they could be automatically configured in a lab environment, verified, and then shipped for installation.
Ansible Navigator is a container-based textual interface designed to manage various components of Ansible. In essence, it serves as a wrapper, providing a unified interface to the Ansible ecosystem. Initially, the use of Ansible Navigator does not require container usage; thus, we will use the --ee=false parameter.
When working with Ansible, one of the “recipes” that I always keep handy is related to debugging variables. I find it particularly useful to have a comprehensive view of the variables associated with a host, defined at the “facts”, environment, group, and host levels.
In this article, we’ll explore the two methods for defining an inventory usable by Ansible. The inventory serves as the source of truth containing the information that Ansible will use to connect to devices.
In the realm of automation, each laboratory we will create requires a feature as basic as it is essential: the IP addresses of the devices must be accessible from the automation system.
In my opinion, one of the less understandable constructs in Ansible concerns loop management. If we then talk about nested loops, the situation becomes even more complex. In this short post, we’ll see the recipes for: