ShortURL Redux with PHP and AWS Elasticbeanstalk and DynamoDB

We certainly had our share of shortURL discussion and implementations a few years back and the topic was well covered including some nice work by Dave Winer and Joe Moreno to do an Amazon S3 based solution to provide portability.

I’ve been wanting to play with Amazon’s Elastic Beanstalk since it started supporting PHP. And I’ve always still longed for a ShortURL software that was a “set it and forget it” solution. Infinitely scalable with little to no maintenance. Pretty much rules out the use of a relational database and in the unlikely event of extremely high usage I don’t even want to worry about hitting the limits of a single server.

Happily, with all the cloud based offerings these days we have some options. Even better, a PHP app on Elastic Beanstalk should scale without (in theory) any of the more complex setup that would be necessary if we just used EC2. there are plenty of other ways to skin this cat but, like I said, I wanted to try this method of app development.

Regarding persistent storage, back when the topic was hot, I had built a shortener based on Amazon’s SimpleDB, but that service has it’s limitations and the goal here was theoretically infinite scalability and as little maintenance as possible.

I chose Amazon’s DynamoDB for those reasons.

For the record, I don’t normally choose vendor specific offerings because I hate lock-in as much as the next guy, but this was the best fit for the goals of this exercise and it’s not so complicated of a piece of software that I couldn’t make an easy port to something like MongoDB (which I’ve also been playing with and beginning to love. Go NYC!).

Maybe the coolest thing about Elastic Beanstalk is the ease of use thanks to the Git integration.* Here is an excellent post about getting set up to use Git with Elastic Beanstalk. You install a Git extension that let’s you configure it with the credentials that AWS needs. This is for one-way pushes only so you’ll probably want to do development and testing locally or on another server to speed up your round-trips. James Gosling felt similarly. Though PHP doesn’t have all that overhead it still is a bit painful to develop straight to Elastic Beanstalk. No real need to anyway.

Once you have an app set up and are able to push your commits up to it, you are ready to roll. For me that meant setting up CodeIgniter and the AWS SDK for PHP.

I unzipped CodeIgniter 2.1.o and added it to my Git repository. Committed and pushed it using the “git aws.push” command. Looked at the app and it was serving a CodeIgniter page right out of the box.

I downloaded the latest AWS SDK for PHP and unzipped it. Making it work with CodeIgniter is pretty easy. I drop the entire folder into application/libraries. I called my folder ‘aws-sdk’.

Also in the libraries folder we add a file called aws.php withe the contents simply being:

<?php

class Aws {

 function Aws()
 {
 require_once('aws-sdk/sdk.class.php');
 }
}

Before you can use that class, you’ll need to edit the config-sample.inc.php file in the sdk folder as well. We could hard-code the AWS credentials into that file but Elastic Beanstalk provides a better way.

Rename that file to config.inc.php and where you’d put your AWS access key and secret key, instead put:

'key' => get_cfg_var('aws.access_key'),
'secret' => get_cfg_var('aws.secret_key'),

get_cfg_var() is a PHP function that returns values from the PHP.ini file. Elastic Beanstalk allows you to add some of these config values under the “container” tab when you edit your environment right through the AWS console. There are already two fields specifically for these two values and you can add some others if you need something similar. We will use one for our database.

While in the config file you’ll also need to set the ‘default_cache_config’ param. It’s required for DynamoDB. Set it to ‘apc’.

If you do indeed find yourself working on a live Beanstalk app one suggestion I would make is to have a stable file in use as the healthcheck URL. If for some reason your load balancer can’t connect with a HTTP 200 to that URL, your app app health will go to red status and you won’t be able to contact it and you’ll waste considerable time connecting¬† directly to the EC2 instance or rolling back to older versions till you aren’t dead in the water. It seems a little flaky in that regard, or is rather just a compromise one needs to make to get the¬† benefits that using an environment like this?

Leave a Reply

Your email address will not be published. Required fields are marked *