This is the third demo in Part 1, I have logged into a virtual lab environment. Here is the libraries installed with PIP ahead of time. You can do this in order to keep different versions of tools and libraries in your virtual environment. It makes for a great practiced machine. Currently, I have an Ansible demo directory already built. Remember Ansible uses an inventory file and a playbook file. Let's start by looking at the devices.YML inventory file. That means it's going to be set up in YAML. YAML is sensitive to indentations, so take care not to make mistakes with your indentations. Otherwise you might return a syntax error when you try and run it, highlighted is the all, this is going to be the system group that represents all hosts and the inventory. Then under children, I have the group switches. Group switches will include hosts. In this case, there are just two of them. Core 1 and access 1. You can see the Ansible hosts for core 1 and the Ansible host address for access 1. That is the entire inventory for the demo. In production, you would likely have a production inventory, lab inventory, maybe other inventory files adding a little more complication. In the same directory that I have, the devices YAML inventory file, I can create a system folder like a group bars, and switches as a YAML file to define variables for that specific group. In our case, we have two CX switches where one is hardware based and one is virtualized. But we can open the group _var/switches.yml file to examine it. Now makes sure the file name matches the actual group name. Here's what we find, the Ansible username is admin, and we've applied a very secure password. We've also specified the Ansible network operating system to use Aruba networks AOS-CX. We've set the HTTP API to use SSL as true, but we've set certificate validation to false in order to allow our labs self-signed certificates to work without issue, we can check any Ansible roles that match a search criteria. For example, searching for Aruba that are going to be available to Ansible from Aruba. You can do this by entering Ansible-Galaxy search and Aruba. To install an Aruba role in to Ansible type the command Ansible-Galaxy install, and then the name of the desired role. Here we'll find a result that shows I've already done the install at this point. What then are Aruba roles? What exactly will they do and what benefit do they provide? Well, you can check all of this under the Ansible Directory, type home directory then Ansible roles and then Aruba networks.arubaaoscx_role. Although there are other roles we can look into. If you open this directory, there is going to be a library folder. Open this folder, and there are Aruba modules that we can use in our Ansible playbooks. Let's look at the Aruba, CXB lens. We can enter the file aoscx_vlan.py. If you open this with a text editor to explore it, then what we'll find is first the documentation at the top explaining what options we can use in Ansible. These include VLAN ID, name, description, admin states, and others. Then below this, towards the bottom are examples as well as even Python code that we can edit if we want. Returning back, we just examined what is the AOS-CX model. If we open the playbook file, playbook.yml, then we can see our simple YAML playbook. This starts with hosts, which is just the switch name. Under roles, we are using the arubanetworks.aoscx role from the previous module. Under variables or vars, we would like to use the ansible_connection in order to demonstrate network CLI instead of just doing a rest API calls, then we define tasks. The name is just a description, but the aoscx_commands is from the AOS-CX role. The commands allow us to build a list of commands we want to try. Here I've added simple show commands in order to test. The register and capture the output is used to capture output to the command output variable. The win option is a condition to run this task only when the variable ansible_connection is equal to the network_cli. The next task will run and show the output for these two commands and uses the same conditions. In the first place above, we used Ansible connection set to network CLI. But in this next task or this play, we're using HTTP API. To find out which module permits which connection type, check the model document I showed under libraries previously. Now we see the aoscx_vlan, which uses these given options to create VLAN set and the variable loop shown below. Then we finish off with a final WIN condition to use the rest API. Before I run the playbook, let's double-check the inventory file. We could do this using the command Ansible-i and then the name of the inventory file devices dot YML and the flag list-hosts all. This displays are two hosts. If I want to check if they're reachable, I can adjust my previous commands to do a -mping on switches, but this is going to end up failing. The reason that the commands failed wasn't a typo, but rather that they required a secure login. Adding the option asked -vaul-password will prompt for a password and now we can successfully access our switches. Now we're ready to start the Ansible playbook using the command ansible-playbook, we can indicate our inventory file and run the playbook itself. Don't forget to add the password. The playbook is started with three plays. First we run the CLI commands, then it runs a debug to display the comments to screen. This is going to show a list of VLANs on both switches. The third task loops through the tasks of creating VLANs 30 and 31 of those switches, where we get successful responses for both devices. If we try to run the playbook again, it runs successfully, outputting the same debug command. However, nothing has changed given the idempotent nature of Ansible, meaning that after we added the values for VLANs the first time, nothing needs to be updated. In this example, we ran the playbook to display output using the CLI commands with the Aruba supplied models for Ansible, you could use rest APIs instead to gather this same information. This will conclude using Ansible with inventory files, playbooks, models, and even secure credentials.
