Using Ansible
In this lesson we’re going to be taking a look at how to really use Ansible. This lesson is going to be really lab heavy, so for the best experience I highly recommend you sign up and check out the lesson’s video at the bottom of the page. we’re going to spend a lot of time looking at the actual usage of Ansible and configuring a few live devices, and showing what the output looks like and some of the features available to us. We’ll see how to execute and retry and also review the ad hoc modules and playbooks.
ad hoc Modules

So let’s go ahead and see what we mean by ad-hoc. ad-hoc module execution means executing an individual module outside of a playbook. This is generally not recommended or really particularly useful for juniper devices due to the amount of manual and custom configuration that you need in order to make this work, then you would use a command like this.

We use the ansible command and specify the IP address or hostname of the device within your inventory file that you should execute the module against. It does need to be listed in the ansible inventory file. Additionally, for juniper devices the local connection type must be specified in your inventory file. Then specify the -m flag and the module name. You need to specify a user to connect to the device with using -u, and the -k is to prompt for a password.
Here is a little excerpt of what an inventory file might look like, and that on the line of the device that we want to specify we would have to say ansible_connection = local, and that would need to be on every line of every device that we run to specify the local connection type for.

So for any of our Juniper devices it’s a little bit of a pain to try and get this ad-hoc module execution working. I had to play with it for a while to get things moving correctly, because in addition to this we also needed to save and accept the host key for SSH, as it was denying by default. So you need to connect your device first, or pass an argument to your ansible command with custom SSH command arguments which will ignore the SSH host key and not bring up that warning or fail the module execution because of it. So I don’t really recommend ad-hoc module execution, however it is possible to do it so I did want to bring that up.

Now, executing modules in a playbook is really where we’re going to get into the meat of everything. Playbooks are executed using the ansible-playbook command. You can specify a custom inventory file as we had talked about our inventory files previously in the course here, and this can be passed using the -i flag. You can also use the –list-hosts argument to only show the list of devices that the playbook would execute against. This does not actually execute the playbook, it just lists the devices that it would execute against using the specified inventory and limits.
Now, you will specify your hosts within your actual playbook and you can even limit your hosts with a –limit or -l argument to your ansible-playbook command.

We see here in our example command we have our ansible-playbook, we are specifying the YAML file of our playbook which would be in the same directory as the one we are currently in. We are specifying a custom inventory file within our home directory, it is the my_hosts file and then we are also limiting this playbook to only be executed against the hostname LAB-1
For a full lab demonstration using the topology below, please watch the full video lesson!

Tag:ansible, automation, devops, jn0-222, jncia, jncia-devops, juniper