As the topic describe itself, we are going to deploy Multiple Ansible version on Same control node, so that even if we have to contact the managed hosts with old python version or for some deprecated feature or any latest one, we are not bounded to deploy a separate control node.
Also it provide leverage to test newer Ansible release for compatibility, without need to upgrade the actual Ansible setup. For ease of setup, we have prepared a video at the end, do view that as well.
With advent on Ansible Tower3.0, ansible incorporated use of virtual environment, that create isolated python environments in single control node. One can be used to run Tower and other for regular Ansible CLI.
Depending on which version of Python one want to install, it can be used to Deploy isolated Python Environments, to install and configure different versions of ansible.
Not an official term, one can understand this as Python or Ansible Polymorphism.
What is virtualenv or venv ?
These are python tools/modules used for creating lightweight “virtual environments”. Each virtual environment has its own Python binary (which matches the version of the binary that was used to create this environment) and can have its own independent set of installed Python packages in its site directories.
Deployment
For reference we have both versions of Python deployed on my RHEL8 host. You can start with any versions of your choice to deploy various versions of Ansible. Choice is yours, read the official documentation and choose one that best fits your release.
# dnf -y install python3-pip python3-virtualenv python2-pip
By virtualenv
This tool is pretty good as it allows to create isolated environment using both Python3 & Python (which is going to be deprecated soon).
Let’s use it to create environment skeleton for ansible 2.8 & 2.4 to display use of different python versions:
# mkdir /opt/python/ansible ; cd /opt/python/ansible
# virtualenv -p python2 /opt/python/ansible/2.4.0
# virtualenv -p python3 /opt/python/ansible/2.8.0
Now activate the environments and install required versions of ansible using pip command. “source” command can be use to activate the environment for use (created from skeleton by previous commands).
Note: “deactivate” command need to be used to come out of particular python environment.
Ansible 2.8 Deployment
# source /opt/ansible/ansible/2.8.0/bin/activate
# pip install --upgrade pip
# pip install ansible==2.8.0
# ansible --version
# deactivate
Ansible 2.4 Deployment
# source /opt/ansible/ansible/2.4.0/bin/activate
# pip install --upgrade pip
# pip install ansible==2.4.0
# ansible --version
# deactivate
By venv:
This is a module shipped by Python3 to create virtual environment, it creates and used python3 to build the environment skeleton.
Let’s deploy some other versions of ansible by venv
# yum -y install epel-release
# yum -y install python36 python36-pip
# python3.6 --version
# cd /opt/python/ansible
Now creating environment structure by venv and installing Ansible 2.5 by it
Ansible 2.5 deployment
# python3.6 -m venv /opt/python/ansible/2.5.0
# source /opt/python/ansible/2.5.0/bin/activate
# pip install --upgrade pip setuptools
# pip install ansible==2.5.0
# python -V
# ansible --version
Repeating same commands to deploy ansible 2.9 version
Ansible 2.9 deployment
# python3.6 -m venv /opt/python/ansible/2.9.0
# source /opt/python/ansible/2.9.0/bin/activate
# pip install --upgrade pip setuptools
# pip install ansible==2.9.0
# python -V
# ansible --version
Alias Creation
Since switching to every environment everytime can be a painful activity, so we can create and use the alias to switch to particular environment
# alias ansible-activate='f(){ source /opt/python/ansible/"$@"/bin/activate; unset -f f; }; f'
Usage:
# ansible-activate <EnvironentName>
Using environment
Now let’s try to use our ansible to use and connect to the hosts using specific environment.
Note: We are skipping doing the ansible pre-requisites, like placing some ansible config and inventory file. For more details, refer our previous blogs.
Now the big question is are the files created/deployed local to environment or available on system for all. Let’s check this by switching to some other environment and validate.
So we can use the files created in different environments as well.
Now to propagate our validation in more granular manner let’s create a simple playbook to test some features available in Ansible recent releases. For example, before Ansible 2.5 loop was not used, instead with_<lookup> was used. let’s test to see this.
So now first switching to ansible 2.4.x environment and create a playbook to use loop feature:
[root@control dockerInstall]# ansible-activate 2.4.0
(2.4.0) [root@control dockerInstall]# cd /opt/python/ansible/
(2.4.0) [root@control ansible]# mkdir playbooks
(2.4.0) [root@control ansible]# vi playbooks/additional_packages.yml
(2.4.0) [root@control ansible]# ansible-playbook playbooks/additional_packages.yml
Testing the playbook execution and see if it goes fine with ansible 2.4
So it failed as expected as the feature was not introduced in that release, now try to run same playbook with latest ansible version
(2.4.0) [root@control ansible]# deactivate
[root@control ansible]# ansible-activate 2.9.0
(2.9.0) [root@control ansible]# ansible-playbook playbooks/additional_packages.yml
So this time ansible 2.9 able to identify the loop keyword and able to resolve the packages requested by it.
Conclusion
Virtual environments are pretty beneficial if we want to test several Ansible versions, without any need of additional control nodes. Well the scope is not limited to Ansible only, they can be used to test other python modules. We left it to you how you want to use it, and will love to hear back your experience and success story.
Thank You … Keep Learning.
Your technical Mate 