Migrating a website from one server to another is usually a straight forward process. This is if DNS propagation does not bite you in the ass.
The problem: I host several websites for a number of my clients who publish new content on a daily basis. I need to migrate them from server A to server B.
Nothing fancy here, I usually go through the following steps:
- Warn the customers that I’m performing a migration, and ask them to refrain from posting content during a predefined amount of time
- Copy files and databases from A to B
- Test the website on the new server by forcing the new IP in my
/etc/hostsfile - Switch the server IP address in the zone file of the domain Hope that the DNS propagation is performed as quickly as possible
But even if your zone TTL is low, some ISP will still resolve to the old IP address. This even happens 48 hours after the domain’s zone has been updated.
Some users will still be served content from A and you will have no control over this. If your customer lands on B and posts new content, these users will not be able to see it.
The situation gets even trickier if your customer ISP is still resolving requests to the old server. New content may be published on the old server, and it gets messier to sync things from A to B.
Of course, you could change your scripts on A to make them use the new database hosted on B. But what if your customer publishes images along with the new post? The new binary files will be on A, the new DB contents will be on B, and you’ll be in a lot of trouble:
Don’t worry, this can be handled properly: Apache Proxy to the rescue!
The idea here is that we’re going to turn the website on A to a simple proxy forwarding all incoming requests to B. It’s easier than it sounds. Here are its three simple steps:
- Make sure you have enabled
mod_proxy_httpon your Apache server on A:sudo a2enmod proxy_http - Make sure A resolves the new IP address for your domain name, by forcing it on the server’s
/etc/hostsfile:server.B.ip.address example.com - Change the virtual host configuration on A to add the green lines (without the +):
<VirtualHost *:80>
Define SITE_BASE ${SERVER_BASE}/customer/example.com
ServerName example.com
+ ProxyRequests Off
+ ProxyPass / http://example.com/
+ ProxyPassReverse / http://example.com/
LogLevel warn
ErrorLog ${SITE_BASE}/logs/apache.error.log
CustomLog ${SITE_BASE}/logs/apache.access.log vhost_combined
</VirtualHost>
Test your Apache configuration and restart it.
By watching the Apache access logs on both server, you can see the proxy forwarding all incoming requests 🎉🎉
A request to enbref.tn being resolved to A and forwarded to B
If your site is configured to server contents through SSL, you will need to include this additional line in your proxy configuration: SSLProxyEngine on
I can now watch the requests count on A get lower and lower until they completely go away, and my customers can publish their new content with confidence.
PS: This solution comes with a small tradeoff: The requesting IP on B will be the public address of A. This is not a problem in my case.
This is one quick way to solve an urgent problem. Other ways may exist and be more efficient and I’d love to hear about them!
Top comments (1)
A great thanks for sharing the little tutorial.
that line is quite cool "This is if DNS propagation does not bite you in the ass."
However, for the detailed propagation lookup, you can refer to that tool
dnschecker.org/
with over 100+ public servers available to check detailed propagation results globally.