I'm running five wordpress sites (#EC2) all having it's own elastic IP tied to a proper domain name. I reached the max limit when wanted to launch another site (another domain).
Besides of the obvious; asking for more EIPs, can I use route 53 and pointing to the dynamic EC2 hostname?
As far as I understand this will destroy/mess-up all internal links of the wordpress instance, the moment I reboot or stop/start the instance, because it gets a new IP/hostname and all image-links of wordpress by default are absolute for SEO reasons.
Has anybody found a solution to this, or is my only option to ask for more EIPs?
In my opinion, requesting more EIP's is going to be the easier way to go.
You can set up your DNS to point the public ip of any instance, if its not an eip, it will change if the instance ever stop/started again. In which case you need to update DNS.
Wordpress doesn't really care what the hostname or ip address is of the instance. It cares what hostname you want it to respond to. Even if the underlying ip changes, as long as the hostname records are updated to the new IP, you wont have any issues.
Related
Setup within the AWS ecosystem is multiple web sites across 2 domains using ELB, SSL, IIS & ASP.NET across 2 EC2 instances.
After a security audit, we discovered our cookies weren't set to secure, so I setup a URL rewrite to look for the appropriate header from ELB and set HTTPS to true. The problem is, users started getting emails stating https://www.test.com:80/ as the domain and unfortunately, we have too many references to Request.Url to make a change quickly.
Obviously IIS requires a different IP address (or port number) to host 2 SSL certificates. If we change the port number, we'll still have the same issue, so we were hoping to add a secondary IP address and point ELB to use it, but that doesn't appear to be supported. I'm fairly new to AWS, so I was hoping someone could give me some direction in terms of getting SSL to terminate within IIS on ELB.
So what I am asking is, is there a way to get ELB to use a specific IP Address instead of a generic EC2 instance which uses the primary IP Address?
Thank you in advance,
Andrew
If we change the port number, we'll still have the same issue,
No, you wouldn't.
Set up a second ELB using standard ports toward the Internet and custom ports toward the instance(s).
When firing up multiple new EC2 instances, how do I make these new machines automatically accessible publicly on my domain ****.example.com?
So if I fire up two instances that would normally have a public DNS of
ec2-12-34-56.compute-1.amazonaws.com and ec2-12-34-57.compute-1.amazonaws.com
instead be ec2-12-34-56.example.com and ec2-12-34-57.example.com
Is there a way to use a VPC and Route53 or do I need to run my own DNS server?
Lets say you want to do this in the easiest way. You don't need a VPC
First we need to set up an elastic ip address. This is going to be the connection point between the Route53 DNS service (which you should absolutely use) and the instance. Go into the EC2 menu of the management console, click elastic ip and click create. Create it into EC2-Classic (option will pop up). Remember this ip.
Now go into Route53. Create a hosted zone for your domain. Go into this zone and create a record set for staging.example.com (or whatever your prefix is). Leave it as an A record (default) and put the elastic IP in the textbox.
Note you now need to go into your registrar login (e.g. goDaddy) and replace the nameservers with the ones shown on the NS record. They will look like:
ns-1776.awsdns-30.co.uk.
ns-123.awsdns-15.com.
ns-814.awsdns-37.net.
ns-1500.awsdns-59.org
and you will be able to see them once you create a hosted zone.
Once you've done this it will redirect all requests to that IP address. But it isn't associated with anything. Once you have created an instance, go back into the elastic ip menu and associate it with the instance. Now all requests to that domain will go to that instance. To change just re-associate. Make sure your security zones allow all traffic (or at least HTTP) or it will seem like it doesn't work.
This is not good cloud architecture, but it will get the job done. Better cloud architecture would be making the route point to a load balancer, and attaching the instance to the load balancer. This should all be done in a VPC. It may not be worth your time if you are doing development.
I am currently building an web app which also utilizes websockets. (Rails for webserver and Nodejs for socket.io)
I have structured my application to use subdomains to separate between connection to the Nodejs server and the Rails webserver. I have "socket.mysite.com" redirected to the Node server and everything else to the webserver.
I am able to test this functionality on localhost. I simply modified my /etc/hosts to include the following:
127.0.0.1 socket.mysite.com
127.0.0.1 mysite.com
I know that on production I simply have to generate a CNAME record for socket.mysite.com and this will also work on my users' computers.
However, I am accustomed to testing my application by passing an IP address around. My team typically set up the server on our own machines and do development. When we want to test our individual servers, we just pass around an IP like "http://123.45.123.45".
With the new subdomain hack, this is no longer possible without modifying each of my tester's /etc/hosts. I honestly don't expect my testers to modify their /etc/hosts on the spot. What I can do is have each member of my team have their own domain and create the appropriate CNAME records for each individual team member.
Is there an easier way to allow me to run my app on an IP and just pass that IP around?
It sounds like your needs have scaled beyond the days of just simply editing a host file. While you could continue to have everyone on your team continue to edit host files, there are two main risks that I see here:
For your idea to just use IP Addresses, you risk missing something in testing that you wouldn't see unless you were on production, as the issue may be dependent on something in the domain configuration.
For using host entries, you introduce a lot of complexity and unnecessary changes to each developer and tester's configuration, which of course leaves the door open for mistakes, and it also takes time that will add-up over the long term.
Setting up a DNS server may be helpful in your case. You could map a set of domains for each developer that match a certain pattern so that your application will still run correctly. This would allow you to share the URLS without having to constantly reconfigure each person's computer. Additionally, marketing and sales stakeholders can easily view product demos as well, without needing to learn what the elusive host file is for.
If you have an IT department, they can help you setup the DNS. However, if you are a small team without a real IT department, some users have found success using DNS systems designed for home or small office networks.
I would like to know if it is possible using IIS and ASP.NET (and ideally something that might be employed on a shared hosting account, but this isn't required) to mimic WordPress.com's ability to allow end users to use their own domain names.
WordPress has users who own their own domains change the domain's DNS settings to point to WordPress's own DNS. My guess is this is not something that would be able to be done on a shared hosting account since it would involve adding an entry to the DNS server's table for each custom user domain.
However, for future reference, is this something that might be automated programmatically on perhaps a VPS?
My guess is this is not something that would be able to be done on a shared hosting account
You're nearly correct. The default site in IIS listens to all connections on port 80 for the default IP address.
You can add more sites in 3 ways:
Add new sites listening on different ports. This is not entirely practical if you want "ordinary" sites litening on port 80.
Add more IP addresses to the box (not too eaisly done) and set up new IIS sites to listen to the new IP addresses independently.
Add new sites to the server listening to different "host headers" (domain names to you and I) but on the same (default) IP address .
So called "Shared hosting" usually uses options 3, because a hosting company can get away with only using a single IP address for possibly hundreds of sites.
Therefore you would have to go through the tedious process of adding each host header to the box, and while I'm almost certian this could be done with Wscript, I'm no expert in that area.
If you really wanted to get into it, you could write an ISAPI module to intercept the calls and set up some clever (ish) database/hash table of domain names and target folders to server as the different sites.
Bottom line is, there are various ways to achieve this on Windows. Probably none quite as easy as on a *nix platform where everything is super-scriptable.
What we do is have a wildcard DNS entry set up for our domain. That way, whatever domain the user types will resolve to our website as long as it ends with ".mydomain.com". Then our .Net code just looks at the "HOST" header coming in and serves up the content that matches that domain name.
How to efficiently create subdomains dynamically that are resolved to different IP than the original domain?
Most dynamic subdomain creation solutions I've found here would add a *.domain.com A-record to the DNS server (usually using BIND), but that's not what I want.
Does that mean the zone file needs to be set to always Expire? Wouldn't that tax our DNS server heavily?
However, what if the client ISP doesn't go and fetch the new zone file I just dynamically changed? Wouldn't they not able to resolve our new sub-domain entry?
Would setting up DDNS in BIND be the logical path for implementing such system? DDNS would allow me dynamically insert A-record without restarting BIND, right?
I'm sure there are some way to do this, since most large blogging service that doesn't point all account to the same IP as the blogging engine, are doing something similar to what I need.
Thank you!
Yes, you could use dynamic DNS updates to push zone file changes into your zone without having to put them into a text zone file and reloading BIND each time.
Many large domain name registries use exactly that technique whenever a domain name is registered.
That doesn't mean, though, that it's the right technique for your application. As recommended yesterday to your other question, there's really no reason not to go with the wildcard option.
A low-end server running Apache would be more than enough to front-end reverse proxy your first few thousand sites, and better still you don't even need to deploy it until you get enough users to set up your second partitioned cluster.
I would imagine that most services that do this have their wildcard (*.) DNS entry setup for these accounts, and probabley point it to a load balancer, that distributes requests based on host name etc. They then have the non-standard entrys setup as normal A records in DNS.