I'd do this without delegation, but with roles. I'd have one role that's parameterized with "instance name" , and have it applied 3 times to one host in testing and once (parameterized with host vars) per host in production.
Or even better, parameterize the role with list of mongo instances - then you'd be able to use the same play for tests and production.
Mike Trienis <
mike.t...@orcsol.com> napisał:
>Hi Michael, thank you for taking the time to respond!
>
>It's a bit of an unusual use case, so I am trying to understand if
>there is
>a better way to solve the problem.
>
>I am setting up mongo replication on two types of environments
>
> 1. Single-instance with replication for testing purposes
> 2. Multi-instance with replication for production purposes
>
>In the single-instance case there are three init scripts on one machine
>
> - /etc/init.d/mongod-mongo1
> - /etc/init.d/mongod-mongo2
> - /etc/init.d/mongod-mongo3
>
>Starting all three services on instance A is a simple task for the
>single
>instance topology
>
>- name: start all three mongodb service
> shell: creates=/var/lock/subsys/mongod-{{
item.name }}
>/etc/init.d/mongod-{{
item.name }} start
> with_items:
> - { name: mongo1, host:
mongo1.example.com }
> - { name: mongo2, host:
mongo2.example.com }
> - { name: mongo3, host:
mongo3.example.com }
This would be just:
- service: name={{
item.name }} state=started
with_items: mongo_instances
With something like:
mongo_instances:
- name: mongo1
- name: mongo2
- name: mongo3
In the test host's variables
>However, if we're dealing with a multi-instance topology, I would want
>to
>start */etc/init.d/mongo1* on instance A, and */etc/init.d/mongo2* on
>instance B, and */etc/init.d/mongo3* on instance C. Here is a a crappy
>solution to help illustrate the problem.
>
>- name: start all three mongodb service
> shell: ssh root@"{{ item.host}}"; creates=/var/lock/subsys/mongod-{{
>
item.name }} /etc/init.d/mongod-{{
item.name }} start
> with_items:
> - { name: mongo1, host:
mongo1.example.com }
> - { name: mongo2, host:
mongo2.example.com }
> - { name: mongo3, host:
mongo3.example.com }
For this you'd have to set the right instances in the right host's variables - the playbook could stay the same
>
>Thanks, Mike.
>
>
>On Tuesday, 19 August 2014 11:38:21 UTC-7, Michael DeHaan wrote:
>>
>> " am running a playbook that connects to* remote host A*, and would
>like
>> to know if it is possible to run a *delegate_to:* command on the
>*remote
>> host* *A."*
>>
>> The delegate_to keyword is there to supply a different host to run on
>than
>> one being traversed by Ansible's host loop. If you are looping over
>the
>> playbook on A, and want to run the command on A, you would leave off
>the
>> delegate_to entirely.
>>
>> I'm perhaps not understanding the question though.
>>
>>
>>
>>
>> On Tue, Aug 19, 2014 at 12:38 AM, Mike Trienis <
mike.t...@orcsol.com
>> <javascript:>> wrote:
>>
>>> Hi All,
>>>
>>> I am running a playbook that connects to* remote host A*, and would
>like
>>> to know if it is possible to run a *delegate_to:* command on the
>*remote
>>> host* *A. *The use case is that I have two different types of
>>> environments, one that relies on /etc/hosts to resolve the domain,
>and
>>> another type of environment that uses DNS to resolve the domain. So
>if I
>>> run delegate_to: "
my.host.com", it will either resolve to 127.0.0.1
>in
>>> the case of a single instance, or it will resolve the public IP
>address in
>>> the case for a remote machine.
>>>
>>> - name: start all three mongodb services
>>> delegate_to: "{{ item.host }}"
>>> shell: creates=/var/lock/subsys/mongod-{{
item.name }}
>>> /etc/init.d/mongod-{{
item.name }} start
>>> with_flattened:
>>> - replication_servers
>>>
>>> Any help would be appreciated
>>>
>>> --
>>> 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
ansible-proje...@googlegroups.com <javascript:>.
>>> <javascript:>.
><
https://groups.google.com/d/msgid/ansible-project/c196e116-ce13-4ca6-b169-f01fac80ff3c%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
--
Wysłane za pomocą K-9 Mail.