How to target one host from a list?

743 views
Skip to first unread message

Steve Ims

unread,
May 23, 2014, 8:51:04 AM5/23/14
to ansible...@googlegroups.com
We have multiple versions of a multi-tier application deployed on EC2.  Each instance is tagged with version and role.

Versions might be clustered (so could be multiple instances with same version and role tag).

For example, we might have:
2 instances tagged version=1 and role=foo
2 instances tagged version=1 and role=bar

1 instance tagged version=2 and role=foo
1 instance tagged version=2 and role=bar


We want to use ansible to run a command on one instance of a specified version/role.

What's the best way to do that?


I tried the following, but seems that the index applies to the individual tag match -- not the result of the logical union.

$ ansible "tag_version_1:&tag_role_foo[0]" -m ping
No hosts matched

$ ansible "tag_version_1:&tag_role_foo" -m ping
10.0.14.123 | success >> {
    "changed": false,
    "ping": "pong"
}


Appreciate any advice!

-- Steve

Steve Ims

unread,
May 24, 2014, 10:29:32 PM5/24/14
to ansible...@googlegroups.com
Found a brute-force solution:

$ ipaddr=$(ansible "tag_version_1:&tag_role_foo" --list-hosts | head -n 2 | tail -n 1)
$ ansible ${ipaddr} -m ping

Michael DeHaan

unread,
May 25, 2014, 4:58:45 PM5/25/14
to ansible...@googlegroups.com
The Ansible way would prefer it simpler.

Here's how you select the first node out of a group:

- hosts: groupname[0]
  tasks:
     - ...

Here's how you select a node that is in two groups:

- hosts: group1:&group2

Here's how you would select a node that is in two groups and make a group of the union:

- hosts: group1:&group2
  tasks:
    - group_by: key=groupOneAndTwo

Here's how you would then pick the first host out of that group

- hosts: groupOneAndTwo[0]
  tasks:
     - shell: echo I am the first node in both!










--
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.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/1d872c11-4b70-487b-810a-bf7bc0d0dedd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Steve Ims

unread,
May 27, 2014, 6:00:45 PM5/27/14
to ansible...@googlegroups.com
Much better.

Thanks for the example.  Good lesson:  Playbooks may contain multiple "hosts".

Thanks for the help!

Steve Ims

unread,
May 29, 2014, 12:49:31 PM5/29/14
to ansible...@googlegroups.com
Michael's suggestion is working fine in our existing system.

I've now hit a bootstrapping problem when applying this to a new system, which results in "list index out of range" error.

We're automating replacement of servers behind a reverse proxy from one set to another.  With each transition, we must execute a command on one of the outgoing servers.  Our current playbook works fine when there is an outgoing server -- but in a new system, there is no outgoing server on the first run.

Following is the relevant portion of our playbook.  When applied on a first run to our new system, "outgoing_version" is empty.  The pattern "group_:&group2" contains no hosts, so the first task is not run.  Not surprisingly, we then hit an error on the second hosts pattern because "outgoing" is not defined.

Is there a proper way to do this with Ansible?  Perhaps some way to mark the second play conditional on "outgoing" being defined?

Thanks!


---
- hosts: "group_{{ outgoing_version }}:&group2"
  gather_facts: no

  tasks:
  - group_by: key=outgoing


- hosts: outgoing[0]
  gather_facts: no

  tasks:
  - command: do some work


Console output while running the playbook:

PLAY [group_{{outgoing_version}}:&group2] ***
skipping: no hosts matched

PLAY [outgoing[0]] ****************************************************
Traceback (most recent call last):
...
IndexError: list index out of range

Steve Ims

unread,
May 29, 2014, 12:57:42 PM5/29/14
to ansible...@googlegroups.com
Clarification:  Our playbook also includes plays for the incoming servers interleaved with plays for the outgoing servers.  Hoping to avoid one playbook for only incoming servers -- and another for incoming + outgoing servers (would have duplication).

Steve Ims

unread,
May 29, 2014, 1:44:44 PM5/29/14
to ansible...@googlegroups.com
Sorry for the spam, but I just stumbled upon a possible solution that uses Jinja's "default" filter.

I modified hosts in the second play to default to a list with one item that doesn't match any of our hosts.

The 'no-match' still feels like a hack, but has allowed us to use one playbook for bootstrap (first run) and beyond.

Still appreciate any pointers if there's a better way :-)

Thanks.


---
- hosts: "group_{{ outgoing_version }}:&group2"
  gather_facts: no

  tasks:
  - group_by: key=outgoing


- hosts: "{{ outgoing|default(['no-match']) }}[0]"
  gather_facts: no

  tasks:
  - command: do some work

Steve Ims

unread,
May 30, 2014, 1:15:20 PM5/30/14
to ansible...@googlegroups.com
After closer inspection:  The posted playbook works for bootstrap (first run), but not beyond.

Seems that "outgoing" is not defined in the Jinja template on the second play, so the default value ('no-match') is always used.

Seems that "groups" is also not available in the Jinja template (e.g. groups.outgoing).

Is there a way to access groups within the template ("{{ ... }}") ?

Thanks.

Michael DeHaan

unread,
May 31, 2014, 12:24:30 PM5/31/14
to ansible...@googlegroups.com
"- hosts: "{{ outgoing|default(['no-match']) }}[0]"

In Ansible, the general rule is if something looks ungainly like this, don't do it :)

I would probably consider having one playbook that includes another list of plays, and running either the top level one or the second one depending on whether you need to do the second step.

Might not work for you to me.


Michael DeHaan

unread,
May 31, 2014, 12:24:47 PM5/31/14
to ansible...@googlegroups.com
Last line should be "might not work for your use case"



Steve Ims

unread,
May 31, 2014, 12:40:51 PM5/31/14
to ansible...@googlegroups.com

I came to the same conclusion: We have separate playbooks now.

Learned a lot along the way.

Thanks for the comments!

You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/cuegEj7M0KA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.

To post to this group, send email to ansible...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages