EC2 IP Address : How can a web server identify db server ip address at startup?
I have a simple 2-tier arrangement - one web server (Websphere hosted on windows), and one oracle db server. The web server needs to connect the oracle database server.
I am trying to write a script that
- Brings up a EC2 instance with the Oracle database
- Brings up a EC2 instance with Websphere
- Configures the Websphere instance to communicate to the database
I am stuck at #3. Every time I run the script, the DB server gets a different ip address. How do I tell my Websphere instance "Use this ip address for the DB"?
Some solutions I have considered -
- Configure Websphere to connect to a host name. When the DB server comes up and is assigned an IP Address, update the DNS record (probably Route 53)
- Pass the DB server ip address as user data when launching the websphere instance, and run a startup script to update the configuration
- Use Elastic IP Addresses - but that would require routing db traffic over the internet, right?
Each of these solutions seem more work than usual. Is there something I am missing? What is the standard way to solve this problem?
EDIT for Bounty Elastic IP Address solution works, but I don't like using wasting public ip addresses on servers that should never connect to the internet. I am curious to hear any other solution you have employed to solve this problem.
You can use an Elastic IP, but connect via its domain name, and it will resolve to the internal address. So obviously you derive the DNS name from the elastic IP, e.g. ec2-46-147-161-187.eu-west-1.compute.amazonaws.com
corresponds to 46.147.161.187 in eu-west-1. The domain will be fixed so you can hardcode it if you wish.
See https://forums.aws.amazon.com/message.jspa?messageID=299889.
You have to assume that you can't use a broadcast-response mechanism like DHCP for this job, which means that the only option left is to update and query some directory somewhere.
Dynamic DNS (e.g. DNS UPDATE; RFC 2136) is an obvious solution. If you already have a nameserver, this solution takes about 5 minutes to set up. See http://linux.yyz.us/nsupdate/ for a quick-start tutorial on setting up bind
for dynamic updates and using the nsupdate
command. See this blog entry for information on using DDNS with Route 53.
Alternately, you can roll your own solution using something like a simple private PHP script on a webserver somewhere to handle IP registration updates and query-response mechanics. Obviously this solution is a bit more flexible, but it lacks the simple elegance of DDNS.
I'd suggest that one solution is to use Amazon's Virtual Private Cloud (VPC) - this sounds like a good use case for it. (Additionally, VPC has no additional cost, in this scenario).
Essentially, you could create a new VPC and a public subnet (typically 10.0.0.0/24) within that VPC. Then launch both instances into the subnet.
- Launch the websphere instance into the subnet and then associate an elastic IP with it
- Note: you need special VPC Elastic IPs - the regular ones don't work in VPC - when allocating them, specify the domain as 'vpc'.
- Launch the Oracle instance, and pass the
PrivateIpAddress
parameter with a valid IP address from your subnet.- This will assign the requested private IP to your instance, it will be available to other instances in the VPC (but no internet access without an elastic IP in VPC) and you will not waste public IP addresses. It is worth noting that VPC addresses are retained for the life of the instance - even if the instance is stopped, the address is not dissociated. Also, you cannot route traffic between instances in a VPC using an elastic IP.
Of course, in this setup or any setup not using NAT each instance that has any sort of internet access will be assigned a public IP (even if it is not an elastic IP address). Only by using both private and public subnets with a NAT instance configured for routing, can you allow an instance to have no public IP at all, but still be able to access the internet. (The downside of course, being that for a small setup - e.g. 2 instances - you require a 3rd instance to perform NAT, which isn't practical).
Further Reading:
- AWS News Release: IP Address Assignment
- EC2-run-instances Reference (Note the VPC specific options)
- Public subnets on VPC