How to target one host from a list?

Archives Ansible Project
1

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

2

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

3

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!
4

Much better.

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

Thanks for the help!

5

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!

6

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

7

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 :slight_smile:

Thanks.

8

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.

9

"- hosts: “{{ outgoing|default([‘no-match’]) }}[0]”

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

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.

10

Last line should be “might not work for your use case”

11

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

Learned a lot along the way.

Thanks for the comments!