Archive for December, 2010

Rahr Winter Warmer prototype Kindle car

December 28, 2010
Best two things to curl up with!

Sent from my iPhone


Duct Tape Kindle Case

December 28, 2010

Sent from my iPhone

Hungry Like A Wolf – by Mango

December 17, 2010
Download now or watch on posterous

IMG_1178.MOV (4631 KB)

Sent from my iPhone


December 5, 2010

Sent from my iPhone

How to run Drupal on Amazon EC2 using a new micro instance | Sunset Lake Software

December 4, 2010

From Evernote:

How to run Drupal on Amazon EC2 using a new micro instance | Sunset Lake Software

Clipped from:

September 15, 2010

A while ago, I wrote an article about the steps required to set up a web server that runs the Drupal content management system (like this site).  Enough has changed in the interim that I figured I’d revisit this article with more up-to-date information.  In particular, Amazon just introduced their micro instances, which offer you the ability to host a website for as little as $5 a month.

About EC2 and micro instances

I covered Amazon’s Elastic Compute Cloud (EC2) in my previous article, along with the reasons why I think it is a fascinating option for web hosting, so I won’t go into detail on that here.

In short, EC2 lets you create virtual servers that run within Amazon’s data centers. Amazon bills you by the hour that these servers are operating, as well as by the disk capacity and bandwidth they consume. These rates are very low, and they let you easily scale your site to fit immediate needs.

I’ve been running both this site and SonoPlot’s from an EC2 small instance for the last two years. The performance has been awesome, and the sites have not once slowed down due to spikes in traffic. I’ve been able to experiment with new configurations without disrupting the main site by creating virtual clones and playing with them. The only reliability problems I’ve had have been due to my own stupidity when I’ve messed up backup scripts or other system configuration settings.

The new micro instances that Amazon has unveiled are pretty interesting. In my testing, I’ve not needed anywhere as near as much processing power or memory as the entry level small instances offer. A micro instance provides nominal computing power all of the time, with the ability to jump up to 2 EC2 Compute Units on demand, and 613 MB of memory. A normal small instance gives 1 EC2 Compute Unit all the time, along with 1.73 GB of memory.

This comes with a significant cost decrease for the micro instances. Current EC2 pricing has small instances priced at $0.085 per hour, or about $63 per month. Micro instances are only $0.02 per hour, or about $15 per month. If you pay a fee of $82 to reserve a micro instance for three years, your pricing drops to $0.007 per hour or around $5 per month ($7.50 per month with the reservation fee amortized across the three years).

$5 per month (plus bandwidth and disk space charges, of course) for a website that sits behind Amazon’s pipes seems like a pretty good deal to me. Note that this is a site you can configure however you like, because it’s a pure Unix virtual machine.

The sudden scaling capability of a micro instance fits the needs of a traditional website, which won’t have high computational needs most of the time. This site is now running on a micro instance, and I’ve seen no dropoff in responsiveness in moving from the small instance to a micro one.

However, micro instances are a little different in structure than the original EC2 instances that I described two years ago, so my old setup instructions no longer apply. Micro instances do not have any local (ephemeral) storage, with all disk access being through Amazon’s elastic block store (EBS). These instances use the relatively new capability for an image to boot from an EBS volume. In this article, I’ll describe how to create an image that is compatible with the new micro instances.

Setting up an EC2 account and configuring security group

Not much about this part of the process has changed since the last time I wrote. I refer you to that article for how to create an account, get a key pair, and configure the security group you will be using.

Starting and configuring your micro image

When I did this last, I used a Rightscale CentOS Amazon Machine Image (AMI) as my basis and built from there. This time around, I decided to start with an Ubuntu image because I’d heard good things about their ease of use. I grabbed one of the images linked to by Alestic, ami-1234de7b, which is a 32-bit Ubuntu 10.04 Lucid image that boots from an EBS volume. There is one slight glitch with this image that I will discuss later.

One new addition to the control software that I did not mention before is Amazon’s new AWS Management Console. We will be using this to start up the micro instance because Elasticfox currently does not support creating new instances of this type.

Sign in to the AWS Console and go to the Amazon EC2 tab. Click on the AMIs link on the left side of the screen and do a search for ami-1234de7b among all images. Right-click on that image and select the Launch Instance option. In the wizard that pops up, change the instance type to micro (t1.micro, 613 MB) and choose the availability zone, if you’d like. Continue twice, and select the appropriate key pair that you would like to use with this instance. Continue again and choose the security group you set up before. Continue once more and launch the instance.

Your instance will start and take a short time to get into a ready state. Click on the Instances link in the left side of the console to switch to your list of running instances. Right-click on the instance and choose Connect to bring up a help window. Copy the command that it lists at the bottom of the screen and paste that into a terminal window.

Edit that command so that it looks something like the following:

 ssh -i [path to key file]/[key file name].pem

where you provide the path to the .pem key pair file associated with this instance and keep the public DNS address that you were given in the window from the AWS console. Note that I’m using ubuntu instead of root as the login user, due to the way that the Ubuntu image is configured to prevent root logins.

This will connect you to the instance as the administrative ubuntu user. While you aren’t provided the root or ubuntu user password, the ubuntu user can use the sudo command without a password.

If you’d like, at this point you can use sudo to add a user account for yourself and set the ubuntu and root passwords:

 sudo passwd sudo passwd ubuntu
 sudo adduser newuser

If you wish to enable password-free sudo access for another user, edit /etc/sudoers and add a line like the following: