Using YAML as the base configuration format allows me to define structured defaults that are easy to read, maintain, and version-control. Environment variables then handle dynamic values for environment-specific customisations, with custom logic to support default values for additional flexibility.
It’s vital to test new technology before rolling it out into your production environment. I like to use Python virtual environments provided by the venv module for developing and testing Ansible playbooks and features. Instead of using the default Python and Ansible commands installed on your system, you can easily set up multiple Python environments and test different versions of Ansible and its component libraries.
Virtual environments are like a virtual machine or Linux chroot, but they create an isolated structure of lightweight directories separated from actual Python system directories. That means you can have different sets of Python environments, each with different versions of modules, files, or configurations.
Ansible is based on Python and leverages many Python modules and plugins. When you test something new, it could require you to update a module that your Ansible installation depends on. Upgrading a component that your production environment depends on defeats the purpose of testing. Still, you can have different versions of Ansible and other important Python modules in a dedicated test directory with a virtual environment.
Ansible Tower 3.0 and later uses virtualenv. Virtualenv creates isolated Python environments to avoid problems caused by conflicting dependencies and differing versions. Virtualenv works by simply creating a folder which contains all of the necessary executables and dependencies for a specific version of Python. Ansible Tower creates two virtualenvs during installation–one is used to run Tower, while the other is used to run Ansible. This allows Tower to run in a stable environment, while allowing you to add or update modules to your Ansible Python environment as necessary to run your playbooks. For more information on virtualenv, see the Python Guide to Virtual Environments and the Python virtualenv project itself.
By default, the virtualenv is located at /var/lib/awx/venv/ansible on the file system but starting with Ansible Tower 3.5, you can create your own custom directories and use them in inventory imports. This allows you to choose how you run your inventory imports, as inventory sources use custom virtual environments.
Tower also pre-installs a variety of third-party library/SDK support into this virtualenv for its integration points with a variety of cloud providers (such as EC2, OpenStack, Azure, etc.) Periodically, you may want to add additional SDK support into this virtualenv, which is described in further detail below.