I had some interesting traffic patterns on my blog over the past week and a half. I have several blog posts of considerable utility for the students in CS 462. Take a look at this pageview graph:

Luckily my hosting provider, A Small Orange, didn’t have any trouble with the “spikes.”

Amazon announced a new AWS product this morning: the Elastic Beanstalk. Insert your own trite fairy tale references here.

The thing that strikes me about Beanstalk is that it’s the first product in AWS that was designed to be accessible to the common end user. It’s based on Platform as a Service designs used by other industry players (some examples are Google App Engine and Red Hat’s JBoss PaaS). The developer has only to create his application, package it into a WAR file, and upload it to the PaaS provider.

The difference between Amazon’s offering and, say, Google’s is that Amazon gives you full, transparent control over the stack being used to run your application. App Engine doesn’t give you anywhere near that kind of control. With Elastic Beanstalk, you’re free to go log in to the EC2 instances running your application, inspect the contents of S3, etc.

If you’re a power user and want to tinker with those things, you can. If you’re just an average developer who just wants a scalable application without having to worry about the implementation details, you’re free to leave them alone.

For the time being, Beanstalk only runs Java apps on Tomcat, but I’m excited to see what else they will support in the coming months.

I’ve been getting a lot of questions today about why we do this whole process of creating and registering a custom AMI and then bootstrapping it, rather than just starting from scratch each time. Their questions are motivated by various things, ranging from frustration with the process to not understanding the purpose. I haven’t been very articulate in describing why this is part of Lab 1, so I’ll try my hand at an explanation here.

The Concept of a Stem Cell Server
The Image Project requires you to create a web server and a two-part app server. These both have the same basic configuration: Apache with Python, or Apache with PHP, or IIS with .NET, etc. (as per your preference). It will save you a lot of trouble in the coming labs if you’ve created a good, general AMI configuration that can serve adequately as a base for all your real servers. You don’t want to have to write a configuration script every time that installs the same things–the AMI ought to have those already there. That way, your configuration only needs to reflect what is different or unique about each server.

You have to have perspective beyond just Lab 1.

Efficiency of Scaling

One of the primary things to keep in mind when working with Amazon Web Services is that you have to think like Amazon. They have a huge system and need to be able to scale up or down dynamically as demand fluctuates. The requirements of that system led to the current architecture of services like EC2 and S3.

The Image Project is not anywhere near the scale of Amazon.com, simply because we only have a semester to build it. But the architecture of the project is designed to imitate that of a real-world massively scalable system. Keeping that in mind throughout the semester will make some project requirements easier to understand.

When Amazon needs to fire up another EC2 instance for their company infrastructure, it needs to occur rapidly. The longer it takes, the more business they may lose. The process of creating custom AMIs was designed with that in mind.

In our case, the speed at which an instance starts up is not very important. We’re not doing it dynamically, and we do it infrequently. As far as the performance of our system is concerned, it doesn’t really matter to us whether it takes two seconds or two minutes.

But consider two setups in a large, scalable production system:

1. In the first setup, we start from a default base AMI, which has just a bare installation of Ubuntu Server. When the instance starts up, we run a script that downloads and installs Apache, Python, several support libraries, and all our website code.
2. In the second setup, we have created a custom AMI that has everything we need already installed. All we have to do when we launch the instance is dump our code into the Apache root and go.

In this hypothetical large, scalable system, we need to fire up instances dynamically. Setup #1 will take a few minutes to download, install, and configure everything—all that in addition to the time it takes to start the instance in the first place. In those few minutes, the rest of our instances are still struggling to handle all the requests, and a few customers have left because the pages are taking so long to load.

Setup #2 requires no extra time besides initially starting up the instance (a sunk cost). As soon as it starts up, it’s registered with the load balancer and ready to help the other instances handle the traffic. In addition, it doesn’t use any extra network bandwidth to download and install packages that could be downloaded just once and stored in the AMI.

You can see that in this type of a system, the efficiency with which we can spin instances up or down makes a difference. We’re designing The Image Project so that it is ready to scale like that as soon as our traffic starts increasing.

Summary
Keep the big picture in mind. This is designed to be a potentially huge system with loosely-joined components that can scale independently and flexibly. Think like Amazon.

This process is fairly self-explanatory. There is an in-depth screencast here that describes the whole process on a Windows machine. But to make it even simpler, here is a description of the process for Lab 1:

Click “Launch Instance” at the top of the AWS Console:

The AMI I’m using for the class is ami-a403f7cd. Select that from the list.

Nothing needs to be changed here.

Nothing needs to be changed here the first time, but you’ll paste your User Data script in that box in subsequent times you launch your custom AMI.

Give the server a name that you will remember.

Create a keypair, which will allow you (and only you) to log in. You only need to do this once; the next time you launch an instance, you will simply select your keypair from the list.

Choose a security group. Default is fine.

Confirm all the details.

Now the server is starting. This usually takes 1-2 minutes.

Right-click on your server and choose “Connect” to get details about connecting to the instance.

Follow the instructions here to connect, making sure to change the username from “root” to “ubuntu” if you’re using an Ubuntu image.

I’m now logged into my Ubuntu server!

Here are some useful pages I collected while helping people with Lab 1 today:

• Linux Access with SSH & PuTTY How to get PuTTY to use your private keypair
• Setting Up and Using WinSCP How to get WinSCP to use your private keypair
• SFTP Client Certificate with gFTP How to get gFTP to use your private keypair for authentication instead of a password
• Installing PHP5 and Apache on Ubuntu How to modify my instructions here to use PHP instead of Python.

I’ll keep this updated throughout the day, but I thought I’d post it right now.

This is mostly for my own benefit, since I’ll more likely than not have to explain the process to others in the class.

This describes all the pieces I needed to set up to get my dev machine set up to work with Amazon Web Services.

The first thing I needed were the security credentials. To find these, log in to the AWS Console, click on Account at the top, and then click on Security Credentials. (At the time of writing, the URL for that page is this.)

There are four security credentials you need:

• Access Key ID (string)
• Secret Access Key (string)
• X.509 Certificate (.pem file)
• Private key associated with the X.509 (.pem file)

All of those are accessible to anyone who can log in to the account, except for the private key. Amazon does not keep a copy of the private key for the X.509 certificate; you can download it when you create the certificate, but if you lose it after that you’ll have to revoke the certificate and create a new one.

Store all of these in a secure place.

Next, you’ll need a key pair to run instances on EC2. You can create this when you launch an instance. Select the option “Create a New Key Pair” when you get to that step in the launch process. This will give you a .pem file. Save that in a secure location as well; you’ll need it to SSH into your machine.

Once you have all of those things, there are a couple other things that are useful. I set up my .ssh/config file to allow me to SSH in easily. Here’s what the EC2 section looks like:

Host ec2
    HostName {host name}.amazonaws.com
    User ubuntu
    IdentityFile ~/.ec2/snay2.pem

The last thing that’s useful to have, especially when you’re creating AMIs, are the EC2 API tools for the command line. I installed these into my home directory (since the BYU CS labs don’t give me write access to the more sensible location of /usr/share) and set up my .bashrc to initialize the necessary environment variables to run the tools:

export EC2_HOME=~/.ec2/tools/
export PATH=$PATH:$EC2_HOME/bin
export EC2_PRIVATE_KEY=~/.ec2/PrivateKey.pem
export EC2_CERT=~/.ec2/X509Cert.pem

I think that’s about it.

Now that I’ve gotten the hang on Amazon EC2, I’m ready to start building my actual stem cell server. I’m starting from the Ubuntu 10.04 LTS image provided by Canonical (ami-a403f7cd). It’s a bare-bones server instance that doesn’t even have Apache on it yet, although it does have Python.

Setting up the Server

I’m going to need the EC2 AMI tools, which requires allowing the Multiverse repository, so I added these to lines to my /etc/apt/sources.list.d/multiverse.list first:

deb http://us.ec2.archive.ubuntu.com/ubuntu/ karmic multiverse
deb-src http://us.ec2.archive.ubuntu.com/ubuntu/ karmic main

Here are the packages I installed (after running apt-get update):

ec2-ami-tools
ec2-api-tools
apache2
libapache2-mod-python

These packages may also be useful but aren’t strictly necessary at this point:

python-cheetah
python-dev
python-setuptools
python-simplejson
python-pycurl
python-imaging

I ran apt-get upgrade as well. This presented me with a couple prompts (one from GRUB), which I had to get through. And since it included a kernel update, I restarted the machine.

Next, I added the necessary Python directives to my /etc/apache2/sites-available/default file, as I documented earlier.

I added a simple index.py page in /var/www to handle CGI requests. One thing that confused me for a long while is that index.py can’t just be any old Python script; it has to be a CGI request handler. Here’s a simple example:

def index(req):
  return "Hello, world!"

Creating and Registering the AMI

The next step is creating an AMI from this image and saving that to S3. I’m using this tutorial from Amazon as my guide.

There are three basic steps:

1. Bundle the volume

   First, I got the X509 certificate and my private key and put them on /mnt. I also got my account number handy (available from the same place in the AWS console as the public/private keys). Then I ran these commands:

   sudo mkdir /mnt/image
   sudo ec2-bundle-vol -k PrivateKey.pem -c X509Cert.pem -u 000000000000 -d /mnt/image

   Replace the 000000000000 with your account ID.

   After several minutes, that created the AMI bundle in /mnt/image.

2. Upload the bundle to S3

   I used this command:

   ec2-upload-bundle -b cs462-machines/snay2-test1 -m /mnt/image/image.manifest.xml -a <access key> -s <secret key>

   Replace the snay2-test1 with your own folder name inside the bucket.

3. Register the AMI

   I have my dev machine set up such that I don’t have to pass the keys along on the command line (see this post for how I did that). But if you don’t have it set up that way or if you want to run the command from your EC2 instance directly, that’s possible too. Here is the command:

   ec2-register cs462-machines/snay2-test1/image.manifest.xml --K PrivateKey.pem -C X509Cert.pem

   Replace the snay2-test1 with your own folder name inside the bucket.

   After a second, that came back with the AMI name. We’re done!

EDIT: Here is a detailed tutorial from the Ubuntu community on the AMI tools and other necessary EC2 things.

EDIT: Revised the last portion of the post to reflect the three basic steps of persisting an AMI.