ansible-plugin
ansible-plugin copied to clipboard
rundeck-plugins
Working with virtual environments (Part 2)
Being able to set an arbitrary virtualenv path would be huge. I have seen several use cases where there are multiple development teams that are authoring Ansible playbooks, over time there is a big gap between the versions that each of the teams are using.
The development teams will often not have the bandwidth to refactor their playbooks to support a specific (backwards-INcompitable) version of Ansible. This leads to an organization being stuck on an ancient version of Ansible configured on the Rundeck server - therefore making the usage of this plugin impossible (jobs then have to be managed with wrapper scripts to set the environments).
I don't use Python and virtualenv, what would the plugin need to do before launching Ansible?
Hi @aes512 ,
My understanding is that you use multiple python virtualenv with different ansible versions in it ? and you would like to be able to specify the virtualenv name as part of the project configuration ? I think you can still do this manually by switching the environment in the server, right ?
@yassineazzouz yes. Multiple projects and jobs, each having separate Python virtual environments. All we have done thus far to compliment this environment is to wrap the ansible/ansible-playbook commands in a shell script, which (1) sources the virtualenv and (2) runs the ansible/ansible-playbook command(s).
The Rundeck server itself cannot be tied to a specific version of Ansible due to the fact that there are several different Ansible versions that need to be supported. I am not sure what you mean about switching the environment in the server?
Hi @aes512 , I see so the environment get passed to ansible through the shell parent process. Well what I meant is just sourcing the virtualenv in /etc/rundeck/profile, but that will require you to restart rundeckd each time you source a new file, which I guess is a bit painful. I can't think of a way of doing this, other than sourcing the virtualenv in the plugin itself. right ?
The ability to specify the path to the ansible executable should be enough, you could pick the script installed in the virtualenv.
Hi all,
I need the same feature :
- select the Python version,
- select the Ansible version,
- set the Python modules, Ansible plugins and roles, etc. before running my playbook. They are playbook-specific, then job-specific. I do this with pip (for python modules), and ansible-galaxy (for Ansible roles).
Each Ansible playbook and each rundeck job has his specific requirements, and I would like Ansible to run in his own isolated virtualenv.
A nice workflow would be :
- Run a workflow step that creates a fresh virtualenv. The step basically needs the Python version and the Ansible version. It could be implemented with a simple shell script (job argument?). Then export the location of the activation script for the virtualenv.
- Run a workflow step that setups the virtualenv with pip and ansible-galaxy, according to a requirements list. It could be implemented with a simple shell script (job argument?).
- Run the virtualenv activation script and ansible-playbook
- Delete the virtualenv
The point is that I don't know how to export the location of the virtualenv activation script from 1. to 3. :-(
@DazWorrall where would I do that exactly?
DazWorrall commented on Aug 8 The ability to specify the path to the ansible executable should be enough, you could pick the script installed in the virtualenv.
Your PR is most welcome for this request, but personally it isn't something I'd be implementing anytime soon. It's also potentially confusing. There's already a lot of options exposed to the end user, but providing the executable path to ansbile and ansible-playbook per job is getting a bit extreme.
Setting a virtualenv rather than simply path to executable is advantageous because any external plugins that ansible invokes (inventory, etc.) will not necessarily use the the same python environment as the ansible binary triggered.
This is because ansible doesn't assume plugins are python, and so essentially makes a shell call to run them. With virtualenv, the called plugins will naturally use that same environment.
@joshbenner I certainly understand the benefit of using virtualenv and there's no objection to it. You're most welcome to submit a PR for it (hope that doesn't sound rude).
What if we set the VIRTUALENV and PATH environment variables according to what the activate script do? Then we can pass the environment to the ansible command and voilà.
