Rackspace CloudFiles PHP Binding error copying files

I’ve recently evaluated some CDN services and Rackspace CloudFiles, and its Akamai integration, have arisen as one of the most interesting services. This was mainly because Rackspace have the CORS headers as part of its service (something that CloudFront still does not have… what are you waiting for guys?) and because the response times are extremely low (I don’t have any measurement yet but I have the feeling that latency was significantly lower with CloudFiles).

But I’m not going to describe the service that Rackspace can offer as CDN, I maybe will do it in the future but not today. Today I’m going to describe how to fix a problem with the PHP CloudFiles API binding.

When working with the UK endpoint, you cannot use the copy_object_to and the move_object_to functions of the CFObject class because these ones are broken.

In odred to make the PHP binding working again you should only search for the lines below in the cloudfiles_http.php file:

$url_path = $this->_make_path(“STORAGE”, $container_name_source, rawurlencode($src_obj_name));
$destination = rawurlencode($container_name_target.”/”.$dest_obj_name);

And replace them with the next ones:

$url_path = $this->_make_path(“STORAGE”, $container_name_source, $src_obj_name);
$destination = $container_name_target.”/”.$dest_obj_name;

I don’t know why but, these lines are the last updates that the project received (six months ago or so), and reverting them, functions mentioned above were brought back to life.


My experience using Amazon’s CloudFront as CDN – Part I

Preparing a website for more than 4 million users per month can be a hard task to achieve. Obviously, you cannot start a project from scratch pretending to support this amount of users the first week (if you can support it economically… do you want to hire me? :) ) but maybe you can predict that you will reach a huge amount of visits before the end of the current year.

I’m not going to describe step by step how I’ve tried to support a large amount of users hitting a web application -it’s something that is not written on stone because all applications have different behavior and processes and maybe solutions that worked on my project can ruin everyone else applications- but I want share my experience while dealing with Amazon’s CloudFront.
This deep desire of sharing my thoughts, troubles and successes with CloudFront is due to the underneath complexity of this CDN system. Yes, it seems to be a very basic and simple distribution service and, sometimes, it may lead to think that you cannot go further with the Amazon’s CDN solution but… give it a try. As always, there is room to grow for CloudFront but, let’s see…
NOTE: The project that I’m using while writing this post (or set of posts) is developed in PHP, so I tried to keep my tools as close as possible to this programming language.

The Beginning

The first approach to CloudFront is always using the console provided directly by Amazon. This console allows us to see all our distributions and perform configuration updates on them. It’s easy to use, and easy to get on with but, believe me, you will need more tools than this to have your distributions under real control.
The easiest way to have a distribution up and running is linking it to an existing S3 bucket using only the download configuration (not the streaming one). It costs less than a minute to set up and its results are very competitive CDN resources.
Although the web console has useful features like creating, updating basic parameters, enabling/disabling and deleting distributions, it is only the spark that can light up a candle to guide us to more complex distribution deployments.

Getting into the dark

If your aim is just to have a basic CDN to distribute public content such as design images, videos and stylesheets stop reading now. Otherwise, you can keep on reading and discover what I was able to find behind the scenes.
A usual problem using CDNs for static content distribution is that hotfixes can be allowed and deployed as long as they do not impact on the static resources. Due to the distributed architecture of the CDNs infrastructures it’s really difficult to update static resources when you are short in time (but there are no IT projects with scheduling issues, are there?).
And guess what… Amazon provides a process to speed up this kind of operation. Using the official Amazon WebServices PHP SDK there is a way to delete all the copies of static resources on all geographic locations. This allows Amazon distributed datacenters to download the new version of modified resources. This process is called invalidation and must be used carefully.
A short sample of an invalidation code:

$cloudfront = new AmazonCloudFront();

$unwanted_files = array(‘file_to_invalidate1′, ‘file_to_invalidate2′, ‘…’);
$cloudfront->create_invalidation(CLOUDFRONT_DISTRIBUTION_ID, ‘Invaliation Name’, $unwanted_files);

NOTE: This code snippet is only valid if you have previously installed the PHP AWS SDK.

And that’s all for today, in the coming weeks I will try to write a post describing the mandatory steps to set up a CloudFront distribution for private content (or not strictly private but signed).

Hope it helps! :)