Hi,
Apologies for not being clearer. The third example I posted as an example
of a potentially nicer way of structuring playbooks/roles if Ansible had
the ability to function in that way, i.e: by 'roles:' supporting lists or
with_items.
> You also can't stick an "include" and "vars" together in the same item.
My mistake.
Thanks,
Rob
On Monday, 11 August 2014 10:02:22 UTC+1, Rob Zissou wrote:
>
> Hi All,
>
> I've been trying to work out the best layout for our playbooks and roles.
> I've been attempting to conform to DRY principles but trying to leave
> things as loosely coupled as possible.
>
> Our infrastructure involves many similar apps that have minor differences
> which is why I've been looking specifically at how it might be possible to
> parameterise playbooks/roles to avoid many very similar files.
>
> Initially I had something like this:
>
> ## apps described in 'meta roles' (roles with only meta/main.yml that
> include other roles)
>
> # app1.yml
> roles:
> - app1
>
> # app2.yml
> roles:
> - app2
>
> # roles/app1/meta/main.yml
> dependencies:
> - { role: pre_deploy_common_stuff }
>
> - { role: deploy_app_1 }
>
> - { role: deploy_other_stuff }
>
> - { role: post_deploy_common_stuff }
>
> # roles/app2/meta/main.yml
> dependencies:
> - { role: pre_deploy_common_stuff }
>
> - { role: deploy_app_2 }
>
> - { role: post_deploy_common_stuff }
>
> ## ---
>
> Then I tried moving the contents of 'meta/main.yml' for each app into
> playbooks like this:
>
> ## apps described in playbooks
>
> # app1.yml
> - roles:
> - { role: pre_deploy_common_stuff }
>
> - { role: deploy_app_1 }
>
> - { role: deploy_other_stuff }
>
> - { role: post_deploy_common_stuff }
>
>
> # app2.yml
> - roles:
> - { role: pre_deploy_common_stuff }
>
> - { role: deploy_app_2 }
>
> - { role: post_deploy_common_stuff }
>
> ## ---
>
> Then thinking in DRY terms, I tried this:
>
> ## templated playbook with parameterization
>
> # app1.yml
> - vars:
> my_roles:
> - { role: deploy_app_1 }
> - { role: deploy_other_stuff }
>
> include: foo.yml my_roles="{{ my_roles }}"
>
> # app2.yml
> - vars:
> my_roles:
> - { role: deploy_app_2 }
>
> include: foo.yml my_roles="{{ my_roles }}"
>
> # foo.yml
> - roles:
> - { role: pre_deploy_common_stuff }
>
> # this won't work because 'roles' expects a list but gets string 'my_roles'
> - roles: "{{ my_roles }}"
>
> # neither will this because with_items doesn't work in playbooks
> - roles: "{{ item }}"
> with_items: my_roles # or "{{ my_roles }}"
>
> # 'role' is equivalent to including various main.yml files manually.
> # we still can't use with_items or pass a list as a single argument to
> include so
> # using include: in place of role: wouldn't work either
>
> - roles:
> - { role: post_deploy_common_stuff }
>
> # a possibility would be to test with_items in a meta/main.yml file but
> # at that point we're moving back towards 'meta role' territory..!
>
> ## --
>
> The last example doesn't work for reasons described in the comments. I had
> a quick and nasty go at getting ansible 'roles:' to allow lists or
> with_items but to no avail.
>
> I think the last pattern may work in a 'meta' style role (rather than
> playbook) but I'm hesitant to introduce this concept of meta-roles when it
> seems like that information should be stored in playbooks.
>
> I'd be interested to hear how other people approach this type of
> configuration or whether I've made any mistakes in my understanding of how
> to write playbooks/roles.
>
> Thanks!
>
> Rob
>
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/b3f8ac1b-80e9-41f6-b34e-ca30c47bc3d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
