Jazkarta Blog: Easily launch Plone sites on Amazon EC2 with mr.awsome

While we’ve been promoting our Plone 3 and Plone 4 AMIs which are really great to evaluate Plone on Amazon EC2 quickly, I want to tell you about another way you can get started with Amazon EC2 that gives you more control over where you launch the EC2 instances and what specific commands get executed on the server the first time it boots up. I mentioned this during my Scalable Plone hosting with Amazon EC2 talk at the Plone conference, but in this blog post, I want to go into more details about how to actually get it set up.

Here’s an example of a very simple set up of mr.awsome. You can either add this to an existing buildout (in which case you would name this file aws.cfg instead of buildout.cfg), or you can make a separate buildout as we have done here:

buildout.cfg:

[buildout]
parts = aws

[aws]
recipe = zc.recipe.egg
eggs = mr.awsome
entry-points =
    aws=mr.awsome:aws
    assh=mr.awsome:aws_ssh
arguments = configpath="${buildout:directory}/etc"

Then you put a config file in the  /etc directory of your buildout, that might look something like this:

etc/aws.conf:

[securitygroup:demo-server]
description = Demo Server
connections =
    tcp 22 22 0.0.0.0/0
    tcp 80 80 0.0.0.0/0
    tcp 8080 8080 0.0.0.0/0

[instance:demo-server]
keypair = demo-server-keypair
securitygroups = demo-server
region = us-east-1
placement = us-east-1c
instance_type = t1.micro
image = ami-480df921
startup_script = startup-demo-server.sh
fabfile = fabfile.py

There are a few things to note about this configuration:

1. We open port 8080 in the firewall so that we can access our Plone site directly without making an Apache vhost, but for a production server you would not want to do this. We leave it as an exercise to the reader to extend the startup-demo-server.sh script to create the Apache vhost config file  and activate it.

2. Creating a keypair

   You’ll need to have created a keypair in the AWS Management Console or using ElasticFox, that has the name “demo-server-keypair”. You’ll want to save the keypair file someplace safe on your computer, as you will need this in order to SSH into the server.

3. We specify the “demo-server” security group that we defined at the top of the config file. This is important not only for defining the ports to be open, but also for identifying which EC2 instance is the demo server, since Amazon doesn’t provide any other way to “tag” a server with such an identifier, so we use the security groups for that.
4. You might have to play around with the settings for the region, placement, instance type and AMI image ID. Not all instance types are available in all regions, and the AMI ID must match the architecture (32-bit or 64-bit) and the region (us-east, us-west, eu-west, ap-southeast). We use the Ubuntu 10.04 LTS AMIs provided by Canonical.
5. If you choose an AMI that uses EBS as it’s root store (also known as EBS bootable instances), then you will be able to stop the EC2 instance, restart it later and not lose all the data in the meantime. The other advantage is that you don’t pay for the instance while it’s in the stopped state. If you use the “instance store”, then your only option is to terminate the instance at which time you lose all the data, unless you’ve attached an EBS volume and have stored all data you want to persist there.
6. If you are a new AWS customer, you qualify for free AWS hosting for one year with the smallest t1.micro instance. This is probably enough horsepower  to run a very low traffic Plone 4 site, but I wouldn’t recommend trying to run Plone 3, or any site that has a significant amount of traffic. The t1.micro instance size is great for making demo sites or test instances, but should not be considered ideal for a production site.
7. The startup script is the script that will be run the first time the EC2 instance starts up. This makes it possible to use a very generic AMI, and then use the startup script to bootstrap the server with all the dependencies needed to run Plone. This is also where you can customize the script to take care of things specific to your Plone site, such as importing data.

Here is an example of an atypical startup script, but one that I think we’ll be making more use of in the future. I found out about this at the Plone Conference when Alan Runyan mentioned on a discussion list that his company Enfold Systems had come up with an Ubuntu package for Plone. This means that to install Plone, you literally can type: apt-get install plone-default, which will install Plone 4 and a default Plone site. This startup script makes use of this Ubuntu package to bootstrap the server.

etc/startup-demo-server.sh:

#!/bin/bash
set -e -x
export DEBIAN_FRONTEND=noninteractive
wget http://www.enfoldsystems.com/pubkey.gpg
apt-key add ./pubkey.gpg
echo "deb http://dist.clients.enfoldsystems.com/ubuntu lucid universe" >> /etc/apt/sources.list
apt-get update && apt-get upgrade -y --force-yes
apt-get install plone-default -y --force-yes
/etc/init.d/plone-default

What this script does it essentially add the plone-default and plone4 packages to your apt sources.list file, and then installs Plone 4 on the server and sets up a default Plone site, and starts it up. What’s great about this way of installing Plone is that it’s very fast since all the eggs are already pre-compiled for your platform (no need to install gcc), and you don’t have to run buildout on the server which can often be very error-prone and risky.

The last thing that you need to do is set up your AWS key and secret key. The way I do this is by making a simple bash script with the following:

setkeys.sh

#!/bin/bash
export AWS_ACCESS_KEY_ID="<your_access_key_id>"
export AWS_SECRET_ACCESS_KEY="<your_secret_access_key>"

Obviously, you need to replace the <your_access_key_id> and <your_secret_access_key> with your actual keys which you can find by logging into aws.amazon.com, and clicking on the Security Credentials tab.

Getting your access key and secret key

Then to set these environment variables:

$ source setkeys.sh

Once your keys are set, and you have the aws.conf file and startup-demo-server.sh script in place, then you can run your buildout and try starting up a demo-server on Amazon:

$ ./bin/buildout -v
...
$ ./bin/aws start demo-server

INFO: Instance 'demo-server' unavailable
INFO: Creating instance 'demo-server'
INFO: Instance created, waiting until it's available
....
INFO: Instance 'demo-server' available
INFO: Instance running.
INFO: Instances DNS name ec2-50-16-25-92.compute-1.amazonaws.com
INFO: Instances public DNS name ec2-50-16-25-92.compute-1.amazonaws.com
 

Your site is now running at http://ec2-50-16-25-92.compute-1.amazonaws.com:8080. You’ll need to substitute the domain name that is returned when you run this command, and remember to put the port :8080 at the end, since we haven’t set up an Apache vhost to proxy requests from port 80 to 8080.

Within a few minutes you should see the Welcome to Plone screen!

Please note that if you are not a new AWS customer, or you already have a t1.micro instance running, you will be charged by Amazon for every hour that this instance is running, so when you’re done evaluating it, you should either stop it (if you used an EBS bootable instance), or terminate it (if you used an instance store).

$ ./bin/aws stop demo-server
$ ./bin/aws terminate demo-server

You can also stop the instance from the AWS console or using ElasticFox. That’s it!  Hope you’ve found this little tutorial useful, and let me know if you have any questions about how mr.awsome or Amazon EC2 works for hosting Plone sites.