# Variables and ec2 deployments

**URL:** <https://forum.ansible.com/t/variables-and-ec2-deployments/14200>\
**Category:** Ansible Project\
**Created:** [December 21, 2013, 10:59am UTC](https://forum.ansible.com/t/variables-and-ec2-deployments/14200 "2013-12-21T10:59:01Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Trond\_Hindenes](https://avatars.discourse-cdn.com/v4/letter/t/96bed5/32.png) [@Trond\_Hindenes](https://forum.ansible.com/u/Trond_Hindenes)\
**Post date:** [December 21, 2013, 10:59am UTC](https://forum.ansible.com/t/variables-and-ec2-deployments/14200/1 "2013-12-21T10:59:01Z")

</div>

Hi all,  
I’m struggling with a concept in Ansible and hopefully you guys can provide some input for me:

I’m trying to create a playbook which performs the following:

1. Provisions 2 Amazon EC2 instances
2. Deploys mysql on one instance
3. Deploys and configures wordpress on the other, configered to use the mysql node configured in step 2 for database

I’m going to use this as a framework for some other work down the road. The important thing is that each playbook run will deploy its “own” EC2 instances, which means that I cannot use statically typed names.

Everything works as it should, until the step where I need to inject the internal ip address of the mysql server into the wordpress config file on the wordpress node. I just can’t get my head around how I should do this step. I don’t know the mysql hostname (and I don’t care), but I know that it’s a member of the “tag\_Group\_MySQL” group. I have a variable called “ec2\_mysql” on the “control node” containing the public ip of the mysql server, but this variable does not exist on the wordpress server (according to the docs, variables only live on the server where they are defined, if I understand it correctly).

The whole playbook is available at [https://github.com/trondhindenes/AnsibleTest/tree/master/ec2-env](https://github.com/trondhindenes/AnsibleTest/tree/master/ec2-env). I would love another set of eyes on this.

I’m thinking about running the ec2.py script as a local task after provisioning, and trying to use some filtering to grab the facts of the first member of the ec2\_mysql group or something but I still feel very limited by the fact that variables only seem to exist on the host where they got defined… Any pointers deeply appreciated!

-Trond

---

<div class="post-metadata">

**Author:** ![Peter\_Gehres](https://avatars.discourse-cdn.com/v4/letter/p/f17d59/32.png) [@Peter\_Gehres](https://forum.ansible.com/u/Peter_Gehres)\
**Post date:** [December 23, 2013, 8:53pm UTC](https://forum.ansible.com/t/variables-and-ec2-deployments/14200/2 "2013-12-23T20:53:04Z")

</div>

One thing to remember about internal AWS IP addresses is that they are ephemeral and will change if the instance is rebooted. If you want the IP to persist, use an Elastic IP. The elastic IP will also have an internal, static IP address that you can use for internal communication. This internal elastic IP address will survive a reboot.

---

<div class="post-metadata">

**Author:** ![Dmitry\_Horbach](https://avatars.discourse-cdn.com/v4/letter/d/c6cbf5/32.png) [@Dmitry\_Horbach](https://forum.ansible.com/u/Dmitry_Horbach)\
**Post date:** [December 25, 2013, 8:47pm UTC](https://forum.ansible.com/t/variables-and-ec2-deployments/14200/3 "2013-12-25T20:47:08Z")

</div>

Private IP's persist during reboot and elastic ones should not be used to connect applications  
If you setup servers from inside VPC with ec2.py - you can use group IP by tag directly assuming that group has single item  
In case of external setup - try to use combination of hostvars and groups [http://www.ansibleworks.com/docs/playbooks\_variables.html#id22](http://www.ansibleworks.com/docs/playbooks_variables.html#id22)

---

<div class="post-metadata">

**Author:** ![Peter\_Gehres](https://avatars.discourse-cdn.com/v4/letter/p/f17d59/32.png) [@Peter\_Gehres](https://forum.ansible.com/u/Peter_Gehres)\
**Post date:** [December 26, 2013, 4:51am UTC](https://forum.ansible.com/t/variables-and-ec2-deployments/14200/4 "2013-12-26T04:51:51Z")

</div>

This is only true for for instances launched in a VPC [1].

"For instances launched in EC2-Classic, a private IP address is associated  
with the instance until it is stopped or terminated.

For instances launched in a VPC, a private IP address remains associated  
with the network interface when the instance is stopped and restarted, and  
is released when the instance is terminated."

[1] -  
[http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html)

---

<div class="post-metadata">

**Author:** ![Greg\_Andrews](https://avatars.discourse-cdn.com/v4/letter/g/6bbea6/32.png) [@Greg\_Andrews](https://forum.ansible.com/u/Greg_Andrews)\
**Post date:** [December 30, 2013, 11:12pm UTC](https://forum.ansible.com/t/variables-and-ec2-deployments/14200/5 "2013-12-30T23:12:18Z")

</div>

Peter Gehres wrote:

> "For instances launched in EC2-Classic, a private IP address is  
> associated with the instance until it is stopped or terminated."

Notice "stopped" and "terminated" are listed, but "rebooted" is not. I  
have rebooted EC2-Classic instances and not lost the private/public  
addresses. The main thing is a normal reboot rather than having the  
instance down for a longer period of time.

The one time I experimented with this (on instances in Tokyo), I had to  
leave the instance stopped for 20-30 minutes before its addresses changed.  
IMO, it's overstating the case to say a simple reboot (down for only  
seconds) will force a new private/public address on an instance.

&nbsp;&nbsp;-Greg

---

<div class="post-metadata">

**Author:** ![Peter\_Gehres](https://avatars.discourse-cdn.com/v4/letter/p/f17d59/32.png) [@Peter\_Gehres](https://forum.ansible.com/u/Peter_Gehres)\
**Post date:** [December 31, 2013, 6:06pm UTC](https://forum.ansible.com/t/variables-and-ec2-deployments/14200/6 "2013-12-31T18:06:40Z")

</div>

Fair point. I suppose it is then just a risk that someone can choose to accept; in practice it probably won’t change, but Amazon makes no guarantees that it will be the same. 🙂
