Play includes

[Michael DeHaan]

It seems like it would be relatively easy to do this:

----

- include: plays/webserver.yml

- include: plays/dbserver.yml

Etc, as a pre-processing step.

So, just like you can do with tasks & handlers, you could have a top level playbook where each play was defined in a smaller file.   I'm thinking this might make it easier to trade plays on the internets

without doing any copy/paste.

You would still want to edit each play to refine what groups or patterns it addresses.

--Michael

[Art Zemon]

Yes, please include this (pun intended)

-- Art Z.


--
http://CheerfulCurmudgeon.com/

"Be kind, for everyone you meet is fighting a hard battle." Plato

[seth vidal]

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:

---
pathbase: /home/fedora/skvidal/ansible
pub: $pathbase/files/public
priv: $pathbase/files/private
playbooks: $pathbase/playbooks


which I include at the top of any playbook file in vars_files

I guess I'm trying to figure out how to setup a complete infrastructure
tree for many systems and playbooks.

-sv

[Stephen Fromm]

On Tue, May 1, 2012 at 1:12 PM, seth vidal <skv...@fedoraproject.org> wrote:

I guess I'm trying to figure out how to setup a complete infrastructure
tree for many systems and playbooks.

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

[Michael DeHaan]

Suggestion -- Create one and invite comments.  This is how all the BP guides get created originally.

-- Michael

[Stephen Fromm]

On Wed, May 2, 2012 at 4:36 PM, Michael DeHaan <michael...@gmail.com> wrote:

Suggestion -- Create one and invite comments.  This is how all the BP guides get created originally.

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

[Michael DeHaan]

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?

[Suraj Gupta]

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?

[Rodney Quillo]

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

On May 9, 10:14 am, Suraj Gupta <sur...@gmail.com> wrote:
> 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?
>
>
>
>
>
>
>
> On Wednesday, May 2, 2012 8:41:42 PM UTC-4, Michael DeHaan wrote:
>
> > 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?
>
> > On Wed, May 2, 2012 at 8:00 PM, Stephen Fromm <sfr...@gmail.com> wrote:

> > > On Wed, May 2, 2012 at 4:36 PM, Michael DeHaan <michael.deh...@gmail.com>

[Stephen Fromm]

On Tue, May 8, 2012 at 7:46 PM, Rodney Quillo <imc...@gmail.com> wrote:

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/files
>
> > Which makes sharing easier

Regards,

sf

[Michael DeHaan]

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?

[Matt Coddington]

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

[Michael DeHaan]

On Wednesday, May 9, 2012 at 11:30 AM, Matt Coddington wrote:

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:

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.

[Suraj Gupta]

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. =)

[Michael DeHaan]

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

 

[Suraj Gupta]

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?

[Michael DeHaan]

On Wednesday, May 9, 2012 at 1:46 PM, Suraj Gupta wrote:

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.