Hi all,
Perhaps I’m approaching this the wrong way; I would appreciate some feedback.
We have various playbooks that have been developed over a period of time. Due to the (sometimes) lack of backwards compatibility of ansible, some playbooks might require a specific version. I don’t want to run this on different ansible runtime/orchestration servers; I’d like to be able to handle this on the one server.
In previous versions (prior to the core/extras submodule being split out), we could typically download some tar.gz releases and unzip/extract them into different directories. Then prior to running a playbook we could source hacking/env-setup for the specific version that we needed and could run the playbook.
For example:
`
source ansible-1.7.2/hacking/env-setup
run my ansible-playbook that requires version 1.7.2
source ansible-1.6.3/hacking/env-setup
#run my ansible-playbook that requires version 1.6.3
`
The above does not work since the core and extras modules became git submodules as outlined below.
Now I have a couple of options:
-
Take a release (such as http://releases.ansible.com/ansible/ansible-2.0.0.2.tar.gz). This doesn’t have the hacking directory so how do I configure my environment? I don’t want to run setup since doing this for different versions will override each other, and running jobs in parallel would certainly get issues if I did this. Hence I don’t have an easy mechanism of catering for different versions.
-
Take a source tar.gz (such as https://github.com/ansible/ansible/archive/v2.0.0.2-1.tar.gz). Whilst this gives me the hacking directory the lib/ansible/modules/core and lib/ansible/modules/extras (which correspond to the git submodules) are empty, so I would need to obtain those as well. How do I get those?
What I think would solve my issue is a tarball that includes all the source (including the git submodules) as well as the hacking directory.
Or am I going about this the wrong way?
Thanks for any help, advice or pointers.
Phil
Hi,
You can basically do what the env-setup script is doing with that in bash for example:
ANSIBLE=path-to-my-ansible-version
export PATH=$PATH:$ANSIBLE/bin
export PYTHONPATH=$ANSIBLE/lib
export ANSIBLE_LIBRARY=$ANSIBLE/library
You just need to manipulate those variables, so that should not be too bad to script.
Ghislain
I would propose you to use python’s virtualenvs:
virtualenv ansible17
source ansible17/bin/activate
pip install ansible==1.7
work with it
deactivate
next time
source ansible17/bin/activate
It is the same approach as you are using, but as virtualenv encapsulates the whole environment, so you don’t need to bother about the dependencies
I would propose you to use python’s virtualenvs:
virtualenv ansible17
source ansible17/bin/activate
pip install ansible==1.7
work with it
deactivate
next time
source ansible17/bin/activate
It is the same approach as you are using, but as virtualenv encapsulates the whole environment, so you don’t need to bother about the dependencies
Hi Philip,
I am facing the same situation. Is there a way to run ansible like an excutable like sourcing in old environments. I have a setup where ansible 1.5 is present and on the same machine i need to execute the ansible scripts of 2.0.0.2 version
Thanks
Regards
Subramanian
IMO, the best option in this case is to make use of Python virtual
environments, and install Ansible via pip
<http://docs.ansible.com/ansible/intro_installation.html#latest-releases-via-pip>\.
You can have several virtual environments, each with different Ansible
versions, and then activate the one you need prior to running your
playbooks.
HTH,
Carlos.
I would also suggest python virtual environments.
Although, I have also used Docker images for running Ansible. I create a Docker image with ‘ansible’ as the ENTRYPOINT, then create a shell script to execute ‘docker run -it --rm <image_name> <playbook_name> []’. This will execute ansible inside the docker and use the playbooks that you put inside the image when you created it.