Actually I did already and it doesn’t work for me : tasks are copied from lamp_simple to lamp_haproxy rather than reused. For example, the apache install file exists in both directories.
Imagine the two playbooks (haproxy and simple) are used by two different people/teams, they will both try to figure out what is the best way to install and configure apache instead of working together on it.
What i’m trying to achieve is a set of conventions that allows for a centralized repository of ansible plays and playbooks.
Consider lamp_haproxy as your main/only repository and if a team wants to delpoy a simple lamp stack, he/she can copy the site.yml and remove the include for haproxy, which give them lamp_simple.
If another team team wants lamp_haproxy just use site.yml.
and say if a new team wants lamp+ nginx … they would have to just create a new roles folder and put the plays in that directory
roles/nginx/tasks/main.yml
and in the top level directory create the playbook for configuring lamp + nginx.
It might look like:
include playbook/db.yml
include playbooks/web.yml
include playbook/nginx.yml
In short roles directory would become your core repository for reusable playbooks. and playbooks folder would have your team specific playbooks.
Thanks.
When building my own playbooks i started doing just that : having a general playbook that includes more specific ones. The limitation is that hosts are kind of “hard coded”.
In other words, i think a central repository should provide reusable task lists, not reusable playbooks. Playbooks are specific to an infrastructure, a set of VMs, etc ; they contain passwords, and specific settings.
Task lists, handlers, etc on the other hand are totally reusable : i can have separate sets of debian VMs, each one configured differently, but they way I install and maintain mysql ou postgresql will be the same.
Hence the setup i propose in https://github.com/gaspaio/ansible-repository
Looks good to me, but i would definitely let others also comment.
but still i would love to see those mysql/hg etc… grouped together into directory roles and a top level directly playbooks with those example_mysql etc… .
Can be the issue of hardcoded hosts be resolved using separate inventory file’s or groups or using --limit feature. But again your current design might be best suited for your use case.
Just an observation, for your variables for webservers,mysql if etc… you can have it in
group_vars/webservers variables for webservers
group_vars/all for all hosts etc…
Roles or the group_vars are properties of the playbooks, not of what i call “Parts”, tasks+templates+handlers. I’ll probably add a separate directory with subdirectories by roles and dedicated playbooks, variables, etc ; those playbooks will then reference the main Parts repository.
I’ll have proof of concept on that soon (i hope).
Thanks for your remarks.
And I agree with you, it would be great if other people told us what they think !
but still i would love to see those mysql/hg etc… grouped together into directory roles and a top level directly playbooks with those example_mysql etc… .