Ansible Control and Ansible Roles: Now with More Windows

They said it couldn’t be done! They were wrong. As I continue my dive into Ansible and automation in general, I’ve been working on a real world project created by one of my colleagues at Juniper. I wanted to get my Windows OS to work as an Ansible control machine. Currently Ansible doesn’t support Windows as a control machine and apparently there are no plans to in the future. However, at least with the latest updates, it is possible to do this using the Windows Subsystem for Linux. Let’s take a walk through this…and I’ll also include some of my troubleshooting with the Juniper.junos Ansible role.

I’m not going to go through all the steps, but for reference (or if you just want to cut to the chase) go here. This blog is more of a “why” this installation works. This will work for you even if you’re not using Juniper, or if you’re trying to get another playbook running that does use the Juniper.junos role. I was actually using Vagrant to spin up everything and call the Ansible playbook as well, just to add another layer of complexity.

VirtualBox needs to be running in order to spin up virtual machines and devices. Pretty easy, just download and install it as you would any other Windows installation. Then you need the WSL (Windows Subsystem for Linux). This is basically like installing the Linux Bash Shell (Ubuntu) on your Windows machine. The problem is that it doesn’t communicate with anything on your Windows machine by default. Which is, of course where you have VirtualBox installed. We’ll get to that in a minute.

Now, you need to install python-pip. Why? Because when you install Ansible in your WSL using apt-get, it installs an older version. This wouldn’t be a problem, except that the specific role, Juniper.junos, requires at least Ansible 2.1. Apt-get install version (at least on mine).  Now you can install Ansible in the WSL using pip.

From a Mac, for some reason, likely because these elements may already be installed, you don’t have to install PyEZ in the WSL as well, for Juniper.junos to work. However, on a Windows machine, you do. It’s actually the juniper_junos_config module located in Juniper.junos that requires PyEZ.

There’s also a specific way you have to install Vagrant, because nothing’s easy. So by typing:

  • sudo dpkg -i vagrant_2.1.1_x86_64

It will install Vagrant correctly. Obviously this is version 2.1.1, which works just fine and is the current release as of this writing. Now you can enable your WSL to communicate with VirtualBox (installed on Windows) via Vagrant.

So you need to run the following commands from the WSL to allow the communication:

  • export PATH=”$PATH:/mnt/c/Program Files/Oracle/VirtualBox”

FYI: if you close your WSL, you may need to run these commands again to make it work, or you’ll get an error as shown in the featured image of this blog.

Ansible Roles, Specifically Juniper.junos

The term “role” in Ansible might be a little misleading. It’s not part of an Access role or RBAC, it’s actually a collection of tasks or functions really.  Vendors can use Ansible Galaxy to create roles that help folks configure their products specifically, like Juniper.junos. Juniper.junos contains several modules as shown in the link at the beginning of this sentence. The Ansible Playbook I was using specifically used the juniper_junos_config module to configure the vQFXs. I mentioned the juniper_junos_config module earlier. This actually contains several options, like load, commit, and src called from the Ansible Playbook. Hence also having the proper version of Ansible which is compatible with these modules.

I had several problems with the installation of this role. At first when I installed it as part of my original Ansible install (in which I used apt-get), Juniper.junos was installed in the typical place /etc/ansible/roles. There are probably many reasons I kept getting errors here. My ansible.cfg file wasn’t pointing to the right place, for one, to use this role. Even after changing that, though, it didn’t work, likely due to an incompatible version of Ansible.

When I used pip to install Ansible, finally, the Juniper.junos role just installed to my current working directory, because apparently when you use pip it doesn’t install the directory /etc/ansible since it’s really all just templates. However, my ansible.cfg still wasn’t pointing to the right place, so I kept getting juniper_junos_config errors. Finally after doing a clean install of literally everything (including the WSL) I ran the sudo ansible-galaxy install Juniper.junos command in the directory where I was also running vagrant up, the directory where my GitHub project was located. That worked!


I hope the guide in GitHub is helpful to you. Remember that it can be used for really any project where you’re trying to run Ansible from a Windows OS, whether you’re using Vagrant, VirtualBox, or even doing anything with Juniper or not.

Full project:

Windows install:

No egos here…if you have any constructive criticism or questions…feel free to @Malhoit me.