It seems like it would be relatively easy to do this:
Yes, please include this (pun intended)
-- Art Z.
So - with this in mind - are there other global playbook idioms to
setup.
I'm working on puppet-replacement playbooks now for setting up some
vmhosts and builder boxes and I'm noticing I'm setting up some generic
items that probably most people could use.
for example this is my global_vars.yml file:
I think it would be nice to see a best-practice documented for how to layout one’s repository. I like having the top-level directories of handlers/ and tasks/. Having a mess of files under files/ or templates/ would not work because of the potential for namespace collision. Two options that work are: files/etc/ssh/sshd_config and files/openssh/sshd_config. I tend to prefer the latter. It would be interesting to see other possible layouts.
In the long term, I think it would be best to see a recommended layout for repositories.
sf
Suggestion – Create one and invite comments. This is how all the BP guides get created originally.
– Michael
https://github.com/sfromm/ansible-playbooks
It is there, just not advertised. The readme should be fleshed out and the repo is a bit thin at the moment. Comments? 
sf
Looks good, my personal preferences are mostly cosmetic:
- always include whitespace between tasks
- always have a comment at the top of every file
- comment non-obvious tasks where relevant
- always name tasks (you do this)
- I'd probably have a common.yml in tasks for all hosts in a play if
there were any common tasks
I don't think I have any preferences on openssh vs /etc/ssh/ as a
prefix for files. It seems like a good idea to have them match the
playbook on one hand, but on the other,
if I had a full filesystem tree, that would be pretty awesome to
visualize and jump around in.
I currently have been using a seperate directory for files and
templates -- on one hand it's more explicit, on the other hand, it's
harder to visualize what you are putting where (similar
to the above)
We could also do stuff more similar to Puppet land:
openssh/tasks
openssh/files
Which makes sharing easier
What do people think?
How about the following (directories in blue). Optimized so that all files related to a specific task are in the same folder - less jumping around. Separate folders for shared resources are justified because these folders are likely to contain many more files than any specific task.
-
roles
-
webservers.yml
-
loadbalancer.yml- shared
-
files
-
sharedFile1.txt- templates
-
template1.conf- handlers
-
sharedHandler1.yml- tasks
-
openssh
-
openssh.yml
-
ssh_config- sysctl
-
sysctl.yml
-
sysctl.conf
thoughts?
Hi all,
Same with you, I'm also looking into 'howto' structure playbooks and
inputs.
Here's my sample also:
dev-server.yml (include nginx and mysql playbooks inside it)
nginx-ubuntu.yml
- nginx/
- templates/
- nginx.j2
- vars/
- tasks/
- files/
mysql-ubuntu.yml
- mysql/
- templates/
- vars/
- tasks/
- files/
( Note: directories ends with /)
Here's my repo for my testing:
https://github.com/cocoy/ansible-playbooks/tree/master/nginx
-Rodney
Hi all,
Same with you, I’m also looking into ‘howto’ structure playbooks and
inputs.
Here’s my sample also:dev-server.yml (include nginx and mysql playbooks inside it)
nginx-ubuntu.yml
- nginx/
- templates/
- nginx.j2
- vars/
- tasks/
- files/
mysql-ubuntu.yml- mysql/
- templates/
- vars/
- tasks/
- files/
Thinking about it, I tend to like the above structure of templates/, tasks/, and what-not located under topic-specific directories (eg. ssh, mysql, etc). That would help make playbooks easier to share. This would be similar to puppet’s modules, as Michael mentioned as one possibility:
We could also do stuff more similar to Puppet land:
openssh/tasks
openssh/filesWhich makes sharing easier
Regards,
sf
I’m rewriting the playbooks docs this weekend, so there is likely going to be a whole page on “Playbook Best Practices”. Good timing.
Taking what everyone has said so far into consideration, unless someone can tell me that this is terrible, I like this for maximum portability.
It’s easy to tar up, share on the internet, cp around, etc. It also has the VERY NICE property of not just restricting us to describing running state,
but also allows playbooks for what John Kleint did – having playbooks to start/stop/other things.
Thus the idea that “setup.yml” is probably a common thing in a playbook, but stop.yml might be too.
subdirectories for each meaningful thing
nginx/
templates/
nginx.j2
vars/
nginx.vars
tasks/
setup.yml
stop.yml
files/
x
y
handlers
main.yml
other/
yada yada yada
And plays are just lists of what gets done together, and should probably be named after what systems they target and what they do.
Rather than web servers, it’s “setup_webservers”, because we might also want something like “stop_webservers”, etc. TBD.
file: setup_webservers.yml
- hosts:
webservers.yml
tasks: - include: nginx/tasks/setup.yml
- include: other/tasks/setup.yml
handlers: - include: nginx/handlers/main.yml
Thoughts?
I like this modular setup a lot. One feature I've seen previously
discussed on the list is the ability of playbooks to include other
playbooks... is this something that's on the roadmap? Using the
example below, I can imagine wanting to:
* on a regular basis run all of my setup.yml tasks as part of standard
configuration management practice. This would be my configuration
management playbook.
* on a one-off basis, i'd like to be able to run the tasks associated
with nginx/tasks/setup.yml against my nginx servers because i've just
made a change... i don't want to run a whole configuration management
playbook because maybe it takes too long or whatever.
If I could include my one-off playbooks in my configuration management
playbook, i'd only have to write them once and only change them in one
place if i had to include another task or address a different group or
servers. I guess I'm wondering whether the basic building blocks of
"doing stuff" should be at the tasks/foo.yml level, or one level
higher up in the plays.
matt
It would need to wait until 0.5, but I don’t see why not.
For now the way to do that is just simulate a playbook by making a top level bash script that just calls all the plays you want to run on the ansible-playbook command line, or by calling ansible-playbook more than once.
Hi Michael,
I completely agree with the point about restricting us to describing running state and also optimizing for sharing.
For completeness, it would be nice to see a recommendation on where to put plays and hosts (setup_webservers.yml and webservers.yml in your example).
I think the templates/vars/tasks/files/handlers directories are a bit overkill for the run-of-the-mill task. I suspect the average task will only use 2 or 3 of these directories and only contain 1 or 2 files. The same visual separation can be achieved with file extensions that follow a convention (i.e. tasks get .yml, vars get .vars, etc.). I’m sure the organization freaks will disagree, but I’m trying to advocate for Ansible’s mantra of simplicity. =)
I think the templates/vars/tasks/files/handlers directories are a bit overkill for the run-of-the-mill task. I suspect the average task will only use 2 or 3 of these directories and only contain 1 or 2 files. The same visual separation can be achieved with file extensions that follow a convention (i.e. tasks get .yml, vars get .vars, etc.). I’m sure the organization freaks will disagree, but I’m trying to advocate for Ansible’s mantra of simplicity. =)
Strongly disagree about extensions, because it doesn’t allow for expansion later, and makes for two ways to do things where it will get inconsistent.
Not creating subdirectories that you don’t use is of course fine. I suspect most people will use tasks, handlers, and templates. Some people will use files. Not everyone will need vars.
I’m cribbing almost directly from Puppet module organization here, because I like how that works out.
–Michael
I don’t follow your point about “two ways to do things…”, and expansion is equivalent in both models (you either expand the convention or your expand the directories)
We can agree to disagree - it seems that Ansible doesn’t impose a structure, which is great. =)
How about shared files? For example, handlers or templates are re-used across nginx/other/other2/… Something to consider for the best practices doc?
I don’t follow your point about “two ways to do things…”, and expansion is equivalent in both models (you either expand the convention or your expand the directories)
We can agree to disagree - it seems that Ansible doesn’t impose a structure, which is great. =)
Eh, perhaps correct that it’s expandable, but I still think it’s a mess.
How about shared files? For example, handlers or templates are re-used across nginx/other/other2/… Something to consider for the best practices doc?
Not really, there’s nothing precluding this though.