Using Rackspace Cloud Files with your own domain
As of April 27, 2011 – Rackspace Cloud Files now supports CNAMEs. This article will be left online for historical reasons.
At the time of writing back in 2009, Rackspace Cloud (Mosso) Files was their newest service offering and is a cloud based file storage system that also allows you to distribute content via the Limelight (now Akamai) CDN.
One of the biggest drawbacks so far is the fact that you are not able to use your own domain name (CNAMEs do not work) and are required to use a URL that Mosso provide (eg: http://c0006681.cdn.cloudfiles.rackspacecloud.com/mosso_logo.png).
There are several disadvantages to this limitation including locking you into using Mosso if you put yourself into a position where you are not able to update your URLs easily in the future.
This article will outline how to get around this limitation and turn a URL like this:
This article assumes you know how to get the public URL for your container, and are familiar with uploading files to the Mosso platform.
All implementations require an Apache web hosting account with mod_rewrite enabled. Implementations #3 and #4 require mod_proxy and mod_geoip.
You may use either a subdomain (eg: cdn.se.id.au) or a subdirectory (eg: www.se.id.au/cdn) to implement this. I recommend using a subdomain.
This implementation is the simplest approach and simply redirects all users to the CDN. You are limited to one bucket with this approach.
In the base directory of your subdomain you will need to create a ‘.htaccess’ file that looks like the following:
You will need to replace ‘c0006681’ with the ID of your container.
The rewrite condition will not redirect requests for / to Cloud Files. This allows you to create an index file. We’re using a 302 temporary redirect (instead of 301 permanent) so search engines will pick up the URLs under your custom subdomain (and not the Cloud Files URL).
This implementation is similar to implementation #1, except it allows you to have multiple containers so you can segregate your content. For example, this will allow you to have http://cdn.se.id.au/images/ and http://cdn.se.id.au/files/ going to two different Mosso containers.
We’re going to use ‘images’ as our first example.
To get started, create the directory in your subdomain.
In this directory, create a ‘.htaccess’ file that looks like the following:
You will need to replace “/images/“ with the name of your directory, and replace ‘c0006681’ with the ID of your container.
Like implementation #1, the rewrite condition will allow you to create an index file in your directory.
To link additional directories to different containers, simply repeat the instructions with a different directory name and container ID.
This implementation allows you to selectively redirect users to content hosted locally, or to their closest Limelight POP and assumes that you have mod_geoip and mod_proxy installed and configured.
If a user isn’t being redirected to Limelight and the file doesn’t exist locally, the file is pulled from the closest POP.
Ideally you would be using one of the first two implementations, however as Limelight as still building their Australian presence this implementation may be a better option if your primary site is in Australia.
This example shows how to send non-Australian users to Limelight and serve Australian users directly.
You’ll need to add the following to your ‘.htaccess’ file:
Don’t forget to replace c6681 with your container ID. If you have extremely popular files, you can store them in both your container and on the server itself – this way the server won’t need to proxy Australian users to Limelight.
This implementation is a combination of implementations #2 and #3, and is how I am using Limelight/Mosso. This implementation allows you to selectively redirect users to Limelight, and maintain the ability to have multiple containers.
By analysing the .htaccess snippets in implementations #2 and #3, you should be able to achieve this.
If you have any questions / comments, let me know.