EC2: collect list of private-ip from on group, use it in a second group

437 views
Skip to first unread message

Tzach Livyatan

unread,
Jan 20, 2015, 8:14:57 AM1/20/15
to ansible...@googlegroups.com
Posted a similar question a few days ago, got the right answer.
Now I can better explain what I'm looking for.

I'm building a EC2 system from two types of servers:
- cluster nodes
- loader nodes
Each loader is generating traffic to ALL cluster nodes.

My goal is a playbook which collect private-ip from each the first group, and use it as part of a command to be executed on the second group.
I assume it should look something like:

---
- name: Collect private IPs
 hosts: tag_Name_ClusterNodes
 gather_facts: false
 tasks:
     - name: Create group
#      Pseudo Code Warning:
      all_cluster_ips += {{ ec2_private_ip_address }}}

- name: Run stress
 hosts: tag_Name_Cloader
 user: ec2-user
  tasks:
   - command: benchmark  {{ all_cluster_ips }}

But I cant make this works.
Suggestions will be appreciated!

Thanks

James Martin

unread,
Jan 20, 2015, 10:47:12 AM1/20/15
to ansible...@googlegroups.com
Here's a quick sample playbook that should do what you are trying to do.  Keep in mind that the ec2.py dynamic inventory script will gather the private IPs for you, you shouldn't need an explicit task.  

- hosts: localhost
  tasks
:

 
- debug: msg="{{ hostvars[item].ec2_private_ip_address }}"
    with_items
: groups.tag_Name_ClusterNodes
   
register: output

 
- debug: msg="{{ output.results|map(attribute='msg')|join(' ') }}"



You could also write a custom jinja2 filter to make this a single task.


- James

Tzach Livyatan

unread,
Jan 21, 2015, 3:37:09 AM1/21/15
to ansible...@googlegroups.com
Thanks James
Works like a charm. register is what I was looking for.

What should I use in production instead of the first debug?
I need the data, not the output to the screen.

James Martin

unread,
Jan 21, 2015, 4:26:06 PM1/21/15
to ansible...@googlegroups.com
Sorry, I'm not sure of a way to suppress that, outside of using a custom filter.

- James 

Brian Coca

unread,
Jan 21, 2015, 5:04:13 PM1/21/15
to ansible...@googlegroups.com
look at set_fact
> --
> 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/6601538e-b8c2-4177-8e6a-efe2021f5ecd%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



--
Brian Coca

James Martin

unread,
Jan 21, 2015, 5:30:19 PM1/21/15
to ansible...@googlegroups.com
Sorry, was a bit confused by your comment "What should I use in production instead of the first debug?"

If you mean, not to use "debug" in your first task because it's too verbose, you don't have to.  But using it is not going to harm anything even on production.  If you want to do it in a less verbose way:

- hosts: localhost
  tasks
:
 
- command: echo "{{ hostvars[item].ec2_private_ip_address }}"
    with_items
: groups.tag_Name_ClusterNodes
   
register: output
    changed_when
: no

 
- debug: msg="{{ output.results|map(attribute='stdout')| join(' ') }}"


as far as the second debug goes, you could, as bcoca pointed out, use set_fact:

- set_fact: ip_list=""{{ output.results|map(attribute='stdout')| join(' ') }}"

And subsequent tasks could then reference the list as "{{ ip_list }}"


- James

Tzach Livyatan

unread,
Jan 22, 2015, 4:49:44 AM1/22/15
to ansible...@googlegroups.com
Thanks James, Brain
This is precisely what I was looking for!
Reply all
Reply to author
Forward
0 new messages