Getting Started: Using the Virtual Environment

[sorangutan]

Welcome to another Getting Started blog post! Previously, we did a four-part series on Ansible and Windows automation.

In this post, we are going to talk about how you can modify and use the Python virtual environment that is built when Red Hat Ansible Tower is installed. Before we get started, if you would like a dive deeper into the virtual environment you can find our documentation on it here .

Is This a Virtual Reality Test?

No, it is not. But one can dream, right? Before we get into this, let’s talk about what is created when you install Ansible Tower in regards to virtual environments.

Ansible Tower 3.0 and later uses virtualenv. Virtualenv creates isolated Python environments to avoid problems caused by conflicting dependencies and differing versions.

Ansible Tower creates two virtualenvs during installation–one is used to run Ansible Tower, while the other is used to run Ansible. This allows Ansible Tower to run in a stable environment and allows you to make changes to your Ansible environment.

The next topic we are going to talk about is modifying the Ansible virtualenv. But first, a warning to the adventurous. Modifying the virtualenv used by Ansible Tower is unsupported and not recommended. Unless a support representative advises you to make a change to that environment, do not make a change to that virtualenv.

Before We Modify...

The Ansible virtualenv, the one we can actually manipulate, is very easy to manage. So before we do anything, you will need access to the machine where Ansible Tower is installed. It is also recommended that you configure permissions properly before making any changes to the virtualenv.

Note: If you are running Ansible Tower in a clustered environment, you will need to make this modification across all of the nodes in the cluster.

An example of the recommended permissions can be found below and in the docs here:

$ source /var/lib/awx/venv/ansible/bin/activate $ umask 0022 

Now We Modify

There are a couple of reasons as to why you might need to make some changes to your virtualenv for Ansible.

The first use case involves inventory imports. Ansible Tower has a couple of built-in inventory import scripts for some of the major cloud providers that help with dynamic inventory sources, like EC2 and Red Hat Satellite 6. In some scenarios, like having a single source of truth for all of your infrastructure, you may have to write your own inventory import script. If you need help writing that script, you can find more information in our documentation about inventory scripts here.

Depending on what packages and libraries you are using in your script, you might have to add those to the Ansible virtualenv. It is really simple to add them into the environment. As outlined above, you will need access to the machine. Once you are on the machine, change to the AWX user and then activate the virtualenv.

$ su awx $ . /var/lib/awx/venv/ansible/bin/activate 

Once the virtual environment is activated, you can install whatever you need via pip!

The second use case revolves around specific modules. Some modules within Ansible require certain packages to be present so that they can work properly. An example would be some of the Junos networking modules. A specific example of a module would be the junos_package module.

Not every module has specific requirements like the junos_package module does, but if it does, you can find out what it needs in the requirements section of the specific module you are looking at using.

So following along from our previous example, to get this required package, you would need to initialize the virtual environment and then install junos-eznc.

$ pip install --upgrade junos-eznc 

It’s All Virtual in the End

Manipulating the Ansible virtualenv is simple. Don’t be afraid to dive in and add things that you might need. If you have questions, never be afraid to consult the documentation on how you can interact with virtualenv.

Coming in the release of Ansible Tower 3.3, there will be added support of multiple virtualenvs. What this means is that the admin/root like user can create their own customer virtualenv under /var/lib/awx/venv. These vitrualenvs can be assigned to a particular Organization, Project or Job Template depending on the need.

However, as one last final reminder, modifying the virtualenv used by Ansible Tower is unsupported and not recommended. The correct virtualenv that you can interact with can be found /var/lib/awx/venv/ansible/.

Happy automating and we hope to see you at AnsibleFest in October!

https://www.ansible.com/blog/getting-started-using-the-virtual-environment