Similar to Terraform, Ansible is a common, open-source automation tool often used in Continuous Integration/Continuous Deployment DevOps methodologies.
Although overlaps exist in the capabilities of Terraform and Ansible, they are very complementary.
While Terraform is better at the initial deployment and ensuring ongoing consistency of the underlying infrastructure, Ansible is better at the initial configuration and ongoing management of the things that live in that infrastructure, such as systems, network devices, and so on.
Here's where the Ansible CML Collection comes in.
Similar to the CML Terraform integration covered in a previous blog, the Ansible CML Collection can automate the deployment of topologies in CML for testing.
The Ansible CML Collection has modules to create, start, and stop a topology and the hosts within it, but more importantly, it has a dynamic inventory plugin for getting information about the topology.
If your topology uses dynamic host configuration protocol and/or CML's PATty functionality, the information for how Ansible communicates with the nodes needs to be communicated to the playbook.
Let's go over some of the features of the Ansible CML Collection's dynamic inventory plugin.
These two tags tell the Ansible playbook to connect to port 2020 of the CML server to automate the specified host in the topology.
You can use the playbooks provided in the collection to load and start a topology in your CML server.
Build -e wait='yes' -e cml lab file=topology.
If -e startup='host' is specified, the playbook will start each host individually as opposed to starting them all at once.
When cml config file is defined in the host's inventory, it is parsed as a Jinja file and fed into that host as config at startup.
First, WAN-rtr1 is assigned the DHCP address it received for its ansible host value, and ansible port is 22.
If the host running the playbook has IP connectivity, it will be able to reach that host.
The second scenario shows an example of the PATty functionality with the host nso1 in which the dynamic inventory plugin reads those tags to determine that the host is available through the CML server's interface.
It knows that ansible port should be set to the port specified in the tags.
After these values are set, the ansible playbook can reach the host in the topology using the PATty functionality in CML. The last example, site1-host1, shows the scenario in which the CML dynamic inventory script can either find a DHCP allocated address or tags to specify to what ansible host should be set, so it uses the node name.
These built-in playbooks show examples of how to use the functionality in the CML Ansible Collection to build your own playbooks, but you can also use them directly as part of your pipeline.
If you want to learn more about the CML Ansible Collection, you can find it in Ansible Galaxy as well as on Github.
This Cyber News was published on feedpress.me. Publication date: Wed, 17 Jan 2024 20:13:04 +0000