>
> Yes, most people would set up different playbooks in that case.
>


That's what I do, I have a playbook for each 'action' I want to execute 
(create, delete, update), and those playbooks include tasks for each part 
of the infrastructure I want to configure :

Example :

playbook "create":
- name: create apache vhost
  action : foo

- name: create php vhost
  action : foo

- name: create haproxy vhost
  action : foo


playbook "delete":
- name: delete apache vhost
  action : foo

- name: delete php vhost
  action : foo

- name: delete haproxy vhost
  action : foo

The mapping "server => roles" is stored in database.


Le mercredi 25 décembre 2013 18:00:14 UTC+1, Michael DeHaan a écrit :
>
> Yes, most people would set up different playbooks in that case.
>
> You definitely want a source controlled record of what groups are mapped 
> to what roles and if you just pass in everything with "-e" you'll not have 
> that.
>
>
> On Wed, Dec 25, 2013 at 4:28 AM, Nicolas Rodriguez 
> <[email protected]<javascript:>
> > wrote:
>
>> Actually, I use Ansible to create, delete or update vhosts (apache, 
>> nginx, haproxy, php) on the infrastructure and sometimes I only want to 
>> talk with servers of a certain role, to update Apache config for example. 
>> This avoids executing unneeded tasks.
>>
>>
>> Le mercredi 25 décembre 2013 00:13:56 UTC+1, Michael DeHaan a écrit :
>>>
>>> So in that case, you still just have a play that says "for machines in 
>>> this group, these roles apply".
>>>
>>> This doesn't imply you would need to template the role names at all.
>>>
>>> - hosts: all_my_base
>>>   roles:
>>>      - are_belong_to_me
>>>      - common
>>>      - stuff
>>>
>>> etc
>>>
>>>
>>>  
>>>
>>> On Tue, Dec 24, 2013 at 5:34 PM, Aaron Hunter <[email protected]>wrote:
>>>
>>>> In general I agree that this isn't a great idea. However, I can see a 
>>>> case where one's infrastructure is more elastic, and shrinks and grows 
>>>> dynamically. VMs have made this case more likely. What do you think about 
>>>> passing a URL for the inventory and main playbook (site.yml) files? If you 
>>>> could pass say, http://repo.site.com/production.hosts to the Anisble 
>>>> command line then the files could be generated dynamically by the web 
>>>> server. With that approach you could keep your inventory and roles in an 
>>>> RDBMS and generate the inventory on the fly. 
>>>>
>>>> Just an idea...
>>>>
>>>>
>>>> On Friday, December 20, 2013 6:32:56 PM UTC-5, Michael DeHaan wrote:
>>>>
>>>>> Right now I'm guessing role names aren't being templated against extra 
>>>>> vars
>>>>>
>>>>> I agree the final one should work with your JSON example, and the 
>>>>> first one should work if JMODULES was the name of a single role.
>>>>>
>>>>> I would file a bug in github to track this.... though this is the 
>>>>> first time I've got the request.
>>>>>
>>>>> I would generally recommend structuring playbooks to record the 
>>>>> desired system configuration, so passing things in and not having them in 
>>>>> source control (what hosts get what roles) seems like a bit of an 
>>>>> anti-pattern, hence why this is not implemented... but yes, I agree this 
>>>>> in 
>>>>> principle would be something you might expect to work (however unusual 
>>>>> and 
>>>>> unexpected).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Dec 20, 2013 at 9:30 AM, Nicolas Rodriguez <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> I try to do dynamic role calling in playbook like that :
>>>>>>
>>>>>> ---
>>>>>> - hosts: "{{ HOST }}"
>>>>>>   user: root
>>>>>>
>>>>>>   roles:
>>>>>>     - "{{ JMODULES }}"
>>>>>>
>>>>>>
>>>>>> command : ansible-playbook test.yml --extra-vars 
>>>>>> '{"JMODULES":["apache","haproxy"]}'
>>>>>>
>>>>>> I get an error : AttributeError: 'list' object has no attribute 
>>>>>> 'startswith'
>>>>>>
>>>>>>
>>>>>> If I change to 
>>>>>>
>>>>>> ---
>>>>>> - hosts: "{{ HOST }}"
>>>>>>   user: root
>>>>>>
>>>>>>   roles: "{{ JMODULES }}"
>>>>>>
>>>>>> I get : ERROR: value of 'roles:' must be a list
>>>>>>
>>>>>>
>>>>>> Any help?
>>>>>> Thank you!
>>>>>>
>>>>>>  -- 
>>>>>> 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].
>>>>>>
>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Michael DeHaan <[email protected]>
>>>>>
>>>>> CTO, AnsibleWorks, Inc.
>>>>> http://www.ansibleworks.com/
>>>>>
>>>>>   -- 
>>>> 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].
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>
>>>
>>>
>>> -- 
>>> Michael DeHaan <[email protected]>
>>> CTO, AnsibleWorks, Inc.
>>> http://www.ansibleworks.com/
>>>
>>>   -- 
>> 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] <javascript:>.
>> To post to this group, send email to [email protected]<javascript:>
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> -- 
> Michael DeHaan <[email protected] <javascript:>>
> CTO, AnsibleWorks, Inc.
> http://www.ansibleworks.com/
>
> 

-- 
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].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to