Monday 28 October 2013

AWS Elastic Beanstalk

AWS Elastic Beanstalk


During my last adventure we decided to use AWS Elastic Beanstalk. This technology from Amazon is a way to provide developers an easier way to manager their deployments, meaning this a PaaS. We used it for a Ruby on Rails application.

You can control your deployments from git and magically it will send your code and deploy it to an instance. So lets decipher some of this magic.

To get started using EB you need to AWS Elastic Beanstalk Command Line Tool. To set them up on your mac all you need to do is:

brew install aws-elasticbeanstalk

Once you have that setup to get yourself started is quite straightforward. All you need to do is follow the instructions here. As you can see this is pretty straightforward and very easy if you want to launch a basic site. However as I started to go deeper with this platform I realised that I would need do some more work. Why is that you ask? Well for two reasons:


  1. The flow of how you typically install a rails app is not exactly how the team at amazon designed it.
  2. A deployment always brings the site down.

Extending EB



One of the things that we quickly realised is that we needed to extend the platform. Luckily this was easy to do, the downside is that we were changing the internals of the scripts that were provided by Amazon. Luckily other people have encountered similar problems. So what I decided to do is create a repository where I could add these extensions that we needed to do to make sure it would work.

Please have a look here. There are some interesting things that needed to be done in order to make it work. If you need a further explanation don't hesitate to reach out.

Deployments


As I mentioned deployments are really easy with EB if you don't mind bringing the website down. I fortunately don't believe that a site should go down for a deployment. What we needed to do is build a more robust deployment pipeline. Luckily for me I am a massive believer of Continuos Delivery. So we knew we had to build a deployment pipeline. We decided that we would build multiple stacks (QA, UAT, LIVE) each having 2 environments within them (A and B, this is modelled around Blue/Green Deployments)

To accomplish these deployments we built a tool called mist. This tool takes the pain away from the deployment and we were extremely proud of it as all the developers could easily deploy the latest or a specific version to an environment. I urge you to take a look at the code and tell me what you think.


The Future


As with any platform there is definitely room for improvement. EB is still considered beta (which in some peoples eyes this can be seen as not production ready). Here are some of the limitations that I hit:

  1. An old version of Amazon Linux is used https://aws.amazon.com/amazon-linux-ami/2012.09-release-notes/. Unfortunately upgrading the AMI breaks EB.
  2. The ruby version is ruby 1.9.3p286 (2012-10-12 revision 37165) [x86_64-linux]. This is quite old. Could not successfully upgrade this.
  3. EB uses Phusion Passenger. The version is Phusion Passenger version 3.0.17. This again is quite old too. Could not successfully upgrade this.

We did explore other avenues like JRuby and I fell in love with the platform. Give enough time I wanted to get EB to work with JRuby.

Hopefully this is of help to anyone else out there that is thinking of using EB with Ruby on Rails.

Sunday 13 October 2013

Retina Images

Retina Images


On my recent project I got introduced to the concept of images that need to be used for retina devices. Basically it is an image that has twice as many pixels as the original image.

Converting Images


The convention for having a retina image is to have a file with the word @2x in it. Since the project was only using these types of images I needed to generate non retina images (in other words normal images). Luckily for us there is this awesome tool called mogrify

So here are the instructions to get you going:
  • Install ImageMagick run: brew install ImageMagick
  • Copy your @2x images to a safe location like /tmp/images
  • To downsize your images run: mogrify -resize 50% -define png:format=png32 *.png
  • To then rename your new images by removing the @2x run:

    for file in *; do
        mv "$file" "${file/@2x/}"
    done
  • Copy your images back to the original folder.

Detecting Asset


Now that we have our assets converted we would like to detect which asset we would like to serve. This fortunately is pretty straightforward. All we need to do is detect from JavaScript (I prefer CoffeScript)

if window.devicePixelRatio == 2 
  # Server your @2x asset
else
  # Server your normal asset

That is it. I know I will use this technique in the future and hopefully you will too.