Babble On

The following will generate a dummy 500 MB file named ‘outputdata’ in no time whatsoever:

dd if=/dev/zero of=outputdata bs=500M count=1

Until Amazon release a Fedora 9 AMI for EC2, you have three choices as far as getting a Fedora 9 instance goes:

1. Build yourself one from scratch
2. Fine one that somebody else has built and made available to the public
3. Upgrade one of the existing Amazon Fedora 8 images

Maybe building an AMI from scratch is a bit more effort than you were hoping to expend today? And perhaps using an untrusted 3rd party AMI will leave you feeling a little uneasy about your security?

Assuming you trust Amazon to some extent (and if you don’t, perhaps EC2 isn’t your best bet), how do you go about upgrading a Fedora 8 image?

Thankfully, the answer is fairly simple. First, boot a suitable Fedora 8 image, then follow the instructions kindly provided by Carson McDonald on ioncannon.net - which, incidentally, is an invaluable resource for Fedora upgrades of all kinds. Before you know it, you’ll be up-and-running with Fedora 9 on EC2!

Update: the above works fine with a 32-bit AMI. If working with a 64-bit AMI, you’ll need to run the following before using rpm to install the new release:

rpm -e --nodeps curl.x86_64 curl.i386

Babble On is now running on a single Amazon EC2 ’small’ instance, along with all my other websites. It’s taken a couple of weeks to get it right, but it’s been very interesting working out how to get the best from EC2.

Since EC2 was originally launched, there have been several obstacles in the way of using it for traditional web hosting and as a replacement for a shared server or virtual private server (VPS). For my purposes, there were always three main issues putting me off getting up and moving from my comfy VPS:

• Lack of static IP address
• Lack of persistent file system storage
• Uncertainty as to whether emails sent from the server will be flagged as spam

Elastic IPs, which have now been around for a few months, completely solve the problem of not having a static IP address. Having been an avid follower of the latest AWS developments, it was the announcement of Elastic IPs in particular that started me thinking about moving my hosting to EC2.

For my purposes, I don’t really see persistence as an issue. As long as you can live with a minor amount of data loss (which I can as none of my sites are critical) then regular backups to S3 are painless and cheap and go a long way to mitigating any problems. If it really bothers you then hang on a few months for Amazon’s new persistent storage volumes, which are probably exactly what you are looking for.

Emails I have discussed previously. For now, I will observe with keen interest.

On the whole the move has been a very positive and interesting experience. I now get 1.7 GB RAM as opposed to 512 MB for only 2/3 the price. And the persistence ‘issue’ really forced me to get my backup/restore solution working as well as it could. Backups are kicked-off automatically by cron and dumped on S3 - and my restore script provides a fully automated means of transforming any instance of my AMI into a running clone of the original machine - right down to the point where the services get switched on and started up.

The best thing about EC2 is that upgrading my web server becomes trivial, risk-free and inexpensive. I just fire up another AMI instance, run my restore script and within ten minutes I have an identical server to work on - without any danger of bringing down my live sites or interfering with my live environment at all. Should I then want to replace the original server, it’s just a case of re-assigning the Elastic IP and within two minutes the new system is live. Who said that EC2 wasn’t suitable for traditional web hosting? Perhaps it’s time to stop thinking about things the traditional way.