If I have a separate host file for production and testing, can I do something like:
[all:vars]
dbpassword=blah
Right now we set an environment variable with our env (prod/testing), then import a var file with vars_file based on that variable.
you can just have a group_vars/all
that has global variables
sorry, hit enter too early.
you can just have a group_vars/all
that has global variables, and have a inventory file per enviornment so:
-i /etc/ansible/prod/inventory (with /etc/ansible/prod/group_vars/all)
vs
-i /etc/ansible/staging/inventory (with /etc/ansible/staging/group_vars/all)
So in this case, will /etc/ansible/group_vars/all still be loaded for both prod and staging?
What about roles, can I keep my roles directory in /etc/ansible, or I have to have a different one prod and staging?
no, if you specify different inventory paths you won't also get the
'default' inventory.
Another option is to have a unified inventory /etc/ansible/hosts and
group_vars/all for common variables, group_vars/production for produciton
globals, group_vars/staging ... etc.
Ansible is very flexible and doesn't really force you to 1 way of setting
up your environment, but this can sometimes be "too much choice",
I just started using roles and I keep them in my playbook repo, not sure
how they would work from /etc/ansible.
You can fully path almost everything if you want to instead of assuming the relative roles paths.
“/etc/roles/foo” as a roles path, though I didn’t plan for it, will work.
Thanks this was helpful. I had never really realised the total separation between inventory and playbooks. We keep both in the same area and under revision control.
I worked out a way to have a set of common variables for all environments by adding a "common" role with just a vars/main.yml, while I keep my environment specific variables under the inventory subdirs (prod/group_vars/all, test/group_vars/all, etc...).
By the way, it took me a while to get my head around roles vs. host groups, but I found a scheme that works now, and makes for very clean playbooks.Thanks!
One question: would a patch for accepting both main.yml and main.yaml acceptable (we've got all .yaml files, and have the .yml ones in there, which leads to typos)?
“One question: would a patch for accepting both main.yml and main.yaml acceptable (we’ve got all .yaml files, and have the .yml ones in there, which leads to typos)?”
Yes, there were some earlier attempts at this that we didn’t take because they duplicated some code, I dont’ think we ever got that back into something we merged in.
Perfectly fine and would be welcome, thanks!