This post describes the techniques I'm using to host my application from a server whose IP changes over time. The post assumes the server's IP only changes when the server is not in use, and therefore I do
not address servicing requests during the IP change. Instead, I am concerned with restoring the mapping between the server's DNS entries and its IP in an automated and reasonably quick manner.
Overview
I signed up for dynamic DNS service. This gives me a DNS name that points to any IP I want, and some software that I install on my server to automatically change the DNS name. Then I set the user-visible DNS hostname (
www.something.com) as a CNAME pointing to the dynamic DNS hostname.
The technique generalizes to serving multiple applications (with separate domains) from a single server. The DNS entries for all the applications are set as CNAMEs pointing to the server's dynamic DNS entry. The HTTP port on the server is owned by a reverse proxy and load balancer dispatching requests to each application's backends based on the
Host: header in the HTTP request.
Dynamic DNS Service
You can get dynamic DNS for free. I use
dyndns.com's service, and it worked for me. If you want to shop around, here's a
list of providers, courtesy of Google Search.
Once you sign up for service, you should get a hostname (like victor.dyndns.com) that you can point to any IP. This host name will be transparent to your users, so you don't need to worry about branding when choosing it. Your only worry is having to remember it.
The important decision you have to make here is the TTL (time-to-live) of your entry. This is the time it takes to propagate an IP change. Shorter values have the advantage that your server can be accessed quickly after it is moved. Longer values mean the IP address stays longer in the users' browser cache, so they have to do DNS queries less often. This matters because the dynamic DNS adds an extra DNS query that users' browsers must perform before accessing your site, which in turn adds up in the perceived latency of your site. Your TTL choice will be a compromise between availability after a move and the average latency increase caused by the extra DNS lookup.
Dynamic DNS Updater
To make the most out of your dynamic DNS service, you need software that updates the IP associated with the DNS hostname.
My
Rails deployment script automatically configures the updater for me (
source code here). I use
ddclient, because it's recommended by my dynamic DNS service provider.
In order to use DynDNS on Ubuntu:
- sudo apt-get install ddclient
- Edit /etc/init.d/ddclient and replace run_daemon=false with run_daemon=true
- Use the following configuration in your /etc/ddclient.conf
pid=/var/run/ddclient.pid
use=web, web=checkip.dyndns.com/, web-skip='IP Address'
protocol=dyndns2server=members.dyndns.org
login=dyndns_username
password='dyndns_password'
dyndns_hostname
The updater will start on reboot. If you want to start it right away,
sudo /etc/init.d/ddclient start
Other Options
If you use DynDNS, but don't run Linux, they have
clients for Windows and OSX. If you don't use DynDNS,
this Google search might be a good start.
My home router (running
dd-wrt) uses
inadyn. I don't like that on my server, because it takes my password on the command-line, so anyone that can run
ps will see my password.
Application DNS Setup
Having done all the hard work, you close the loop by setting up a CNAME mapping your application's pretty DNS name to the dynamic DNS hostname. If you don't want to pay for a domain, you can give out the dynamic DNS hostname to your users... but it's probably not as pretty.
The process for setting up the CNAME mapping depends on your domain name provider (who sold you
www.something.com). The best source of instructions I know is the
Google Apps Help. If you use that, remember to replace
ghs.google.com with your dynamic DNS hostname.
Debugging
Chances are, your setup will not come out the first time. Even if that doesn't happen, your setup might break at some point. Your best aid in debugging the DNS setup is
dig, which comes pre-installed on Mac OSX and most Linux distributions.
Run dig www.something.com, and you'll get an output that looks like this:
moonstone:~ victor$ dig www.mymovienights.com
(irrelevant header, removed)
;; QUESTION SECTION:
;www.mymovienights.com. IN A
;; ANSWER SECTION:
www.mymovienights.com. 1742 IN CNAME chubby.kicks-ass.net.
chubby.kicks-ass.net. 2 IN A 18.242.5.133
;; Query time: 211 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
(irrelevant footer, removed)
I removed the part that is completely uninteresting, and made interesting parts bold. The answer section shows a DNS chain built following this post. If your chain doesn't look like this, you know where to fix the error. If everything looks good here, but you still can't reach your server, the problem is either at the networking layer (can you ping the server?) or at the application layer (your load balancer or application server is misconfigured).
Another interesting result you get from
dig is the query time, which shows the latency introduced by DNS to the users who visit your site for the first time. Unfortunately, this doesn't give accurate numbers if
dig's answer is in some DNS cache, so be sure to account for that in some way when measuring latency.
Monitoring
I use
Google's Webmaster Tools because they provide free monitoring. The overview is sufficient to see if the site is up or down. If you have a Gmail account and use it frequently, you can embed a gadget showing your site's status into your Gmail view.
Multiple Applications
I use the same server for multiple Web applications. I have a separate DNS hostname for each application, and they all point to the same dynamic DNS hostname via CNAMEs.
On the server, I use
nginx as my reverse proxy because it is fast and it can be reconfigured with no downtime, as it's serving user requests. You can use apache if you prefer, using
these instructions.
My reverse proxy setup is done automatically by my
Rails deployment script (
source code here). Here's how you can get a similar configuration:
- sudo apt-get install nginx
- For each application, create a file in /etc/nginx/sites-enabled/ with the following configuration
upstream application_name {
server 127.0.0.1:8080;
}
server {
listen 80;
server_name www.something.com;
root /path/to/your/application/html/files;
client_max_body_size 48M;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
proxy_redirect false;
proxy_connect_timeout 2;
proxy_read_timeout 86400;
if (-f $request_filename) {
break;
}
if (-f $request_filename/index.html) {
rewrite (.*) $1/index.html break;
}
if (-f $request_filename.html) {
rewrite (.*) $1.html break;
}
if (!-f $request_filename) {
proxy_pass http://application_name;
break;
}
}
}This configuration handles requests for
www.something.com by serving static files directly through nginx when they are available, and by forwarding the HTTP requests to your application server at port 8080 otherwise. If you do not want to serve static files from nginx, remove the
root clause, and all the
if clauses. Tweak any other numbers as needed.
Of course, you cannot use port 80 for any of your application servers.
The server will start on reboot. If you want to start it right away,
sudo /etc/init.d/ddclient start
DNS Prefetching
If you're worried about the latency added by the extra layer of DNS, you can use prefetching to go around this limitation. DNS prefetching is a fancy name for tricking the user to do a DNS lookup for your hostname, before he/she interacts with your application.
If you're wondering whether this prefetching thing actually matters, know that Google uses
DNS prefetching in Chrome. Sadly, most Web developers don't have enough leverage over their users to convince them to install custom software.
Firefox supports
link prefetching, and you can find it useful if your users install a widget / gadget that's served from a CDN (e.g. Google Gadgets).
You can also be more creative by looking at the bigger picture. For instance, if your users install an application of yours on their mobile phones, those phones will likely do DNS queries using your users' home routers. So, if your mobile application synchronizes with the server using a sync interval that's smaller than the TTL on your DNS entries... you've killed most of the latency.
Motivation
My servers have been hosted in random places. I've had my application server in my dorm room, in my friends' dorm rooms, and in random labs around MIT.
Given that my servers travel so much, I like to keep them light (Mac Mini or Dell Studio Hybrid) and I want to be able to move them without any manual configuration change. This means the servers can be headless, and that my friends can move the servers for me, without the need any training.
Conclusion
Thanks for reading, and I hope you found this post useful. Please leave a comment if you have any suggestion for an easier or better setup.
