I´m trying to create a modular structure to run playbooks as neccesary.
The this is I have a folder call “custom_playbooks” to create a custom tasks procedure. The thing is I want to keep the structure as modular as possible to avoid hardcoding. So I have external playbooks for this. Example I created a playbook to install python depending of the version you want to use in the custom recipe.
name: Main Process Playbook
hosts: localhost
gather_facts: no
tasks:
name: Call Python Installation
include_playbook: install_python.yml
vars:
python_ver: “3.6.8”
python_path: “C:\Python3.6”
other vars…
Other tasks…
Secondary playbook:
/Ansible/Playbooks/custom_playbooks/install.yml
name: Install Python
all the tasks to install python with some required {{ vars }}
The thing is how can I send these vars to the secondary scripts? I have problems using import_playbook:
ERROR! this task ´include_playbook´ has extra params, which is only allowed in the following modules: meta, import tasks, group_by, etc
Any suggestions of how to handle vars, out the correct process?
Besides “Don’t do this!” you mean? Well, yeah, you can write out the vars to a yaml vars file that the other playbooks could read in.
But “Don’t do this!” is a better answer. Task files are fine for trivial sets of tasks, and they can be called from multiple “sibling” playbooks. Roles work great if you need easily overridden default variables or have more complicated sets of tasks, handlers, plugins, etc. All of your playbooks are already in the same directory, so take all the tasks currently in your playbooks and move them into task files or roles which any of your playbooks can use. Your playbooks’ tasks eventually all turn into a series of include_roles. Populate your host_vars/ and group_vars/ directories at the same level and your variable sharing problem evaporates. In short, your playbooks-calling-playbooks scheme is a solution to a problem you don’t have which creates a problem you can’t solve without a whole lot of coupling between playbooks which is what you were initially trying to avoid!
Having said all that, AWX does provide “workflows” — networks of “jobs” (pre-defined playbook invocations) which, depending on conditions you set, call subsequent jobs in the network. And they do pass variables “downstream”. It’s really cool what you can do with workflows. But it isn’t a solution to the desire to overgeneralize basic playbooks, and that’s where it sounds like you are it this point.
You should get a second opinion of course. And I happen to have one. You don’t have separate playbooks. I know it looks like you do because they have the playbook syntax and you run them with ansible-playbook etc., but you actually have separate roles masquerading as playbooks. You can tell, because they do things, and playbooks don’t do things. Roles do things. Playbooks determine what hosts or host groups those things get done to. If you’re ever unsure about whether something should be in a playbook vs a role, there’s your guiding question: is this about what to do, or is it about which assets to do something to?
Restructure your stuff along those lines, and your need to call playbooks from other playbooks goes away.
You don’t have separate playbooks. I know it looks like you do because they have the playbook syntax and you run them with