Feb 01

Overview

This post covers the basics of managing Amazon Web Services (AWS) Elastic Cloud Computing (EC2) instances. Amazon EC2 service is the most well known cloud service operator providing computing instances and cloud storage in both Europe and the US. The service is charged by the hour of usage for the computing resources and by the amount of storage space used for the cloud storage. It is possible to choose from a number of different types of computing resources, which are priced according to several factors, for example, number of CPU’s or the amount of memory available to the node. The price increases with performance, for example, the price of a medium instance with 4 times the CPU power is 4 times the price of the small instance.

If the computing requirements are known beforehand, it is also possible to reserve the instances for 1 year or more paying an initial fee and getting lower monthly costs in return.

The service itself

Amazon provides a very nice service for people wanting to start using cloud computing resources with it’s easily accessible EC2 service. Getting starting with EC2 is quick once you know what you want to do with the nodes. The service is cheap enough to just start an instance and try out different options before making the decision on how to use it, too.

How to manage instances

As the whole point of a cloud service is the possibility to scale up to even a high number of instances based on the current demand, one of the most important topics is how to manage all of these nodes in an efficient way. It should be quick to start new ones when there is demand to do so, and also shutdown the nodes that are not needed thus saving unnecessary costs.

We will now take a look at different tools to manage the nodes and then go through the basic steps needed to setup your own instance.

EC2 Management tools

There is a number of options for managing the EC2 nodes. The most commonly used tools are:

  • AWS Management Console
  • Firefox Elasticfox Addon
  • Amazon EC2 tools
  • Custom scripts
AWS Management Console

The first one that the user comes in contact with is the AWS Management Console, which is part of Amazon AWS website that is accessible after signing up.

AWS Management Console

AWS Management Console

The dashboard can manage all aspects of the instances as can be expected so there are lots of different options available. The best was is to start it up, start some instances (Note: charges will apply) and try it out.

Elasticfox

Another way to manage the nodes is to use the Mozilla Firefox Elasticfox addon. The following screenshot does not really show the multitude of options the addon has. This view will show you a list of instances you have either starting up, running or stopped state. It will also show the terminated instances for an hour after termination.

Elasticfox Firefox addon

Elasticfox Firefox addon

Both of these tools are nice for starting up and instance once in a while or getting an overview of your nodes, but for the power-user or for managing a high number of nodes, they will be too cumbersome. And that’s where the command line tools come into the picture.

Amazon AMI Tools

The tools are available from Amazon, EC2 command line tools. First thing to do is to download the tools and unzip the package or install the RPM. To be able to use the tools, you need to get the private key and certificate from Amazon and set a number of environment variables. A good start is to create an .ec2 directory in your home directory and store the keys there.

Once that is done, you need to set the environment variables. On a Mac, you can add these lines to your .bash_login file:

export EC2_HOME=<directory where the tools are installed>
export EC2_URL=https://eu-west-1.ec2.amazonaws.com # your location
export EC2_PRIVATE_KEY=/Users/user/.ec2/pk-<YOUR KEY>.pem
export EC2_CERT=/Users/user/.ec2/cert-<YOUR CERT>.pem

The tool set consists of more than a 100 tools, which we are not going to go through here. The full documentation is available at CLI reference

Starting up an EC2 instance

The previous introduction will of course not suffice for understanding the tools, but is rather a starting point for the work.

The easiest way to start an instance is to click on the Launch Instance button on the dashboard.
The next step is to choose the image type you need. There are a number of different images types available, some of them from Amazon but most from other people that have been kind enough to provide their images for other peoples use.

Launch a new instance wizard

Launch a new instance wizard

The next step is to select the number of instances and the type of “hardware” to run on and the availability zone.

After that you need to choose a key pair to use for connecting to the instance from the ones you have already or create a new one. This is the key you need to use when connecting to the machine through SSH if running a UNIX/Linux instance. Last thing to do is to select a suitable firewall configuration. After that, review the instance parameters and start it. This is when Amazon starts charging you, so remember to shutdown instances you don’t need.

Next steps

While it is nice to have your own EC2 instance running, it’s usually not sufficient. When you terminate an instance, everything you have installed on it will be gone.

What you need is to build an AMI with all of the software you need, bundle it to an AMI and register it. Once that is done, you can just launch more instances of the same all having the correct software for your needs. You will also need some S3 storage for your files that you want to keep between the runs.

This can be done in several ways. The easiest one is to pick a publicly available image that is as close to your needs as possible. For example, one of the very nice Ubuntu images provided by Alestic. They have provided images for most Ubuntu versions and you can just pick one. Alestic images contain, for example, recent releases of Python and Ruby (1.8.7). Installing other software can be done with the usual Ubuntu tools.

It is also possible to build an image from scratch and then bundle it with the EC2 AMI tools.

Either way you do it, the image will be uploaded to S3 service for storage. Then the image can be registered to make it available for use in the dashboard or the other tools. You will need to choose the option “My AMI’s” from the EC2 dashboard when launching in an instance to use it.

And then you’re all set for some more serious work on the EC2.

Tagged with:
Oct 18

Building a Ruby on Rails test server on FreeBSD 8.0 RC1

We’re a Ruby on Rails shop at our place and we work on a number of different platforms for developing and testing our stuff; the devs normally work on macs, while the staging environment – this week – is Ubuntu’s Jaunty Jackalope (9.04) distribution. However I’m a big FreeBSD fan, and have been for a number of years. Speaking personally for myself, FreeBSD makes sense in every aspect of its operation and configuration, and the ports collection is second to none for all aspects of application management. (disclaimer – *nix distributions are more like pairs of jeans than they are operating systems in the hearts and minds of regular users; what fits well on one user, doesn’t fit at all on another. So I’m absolutely not saying FreeBSD is best, it’s just best for me). When the FreeBSD 8.0 RC1 build was made available I decided to put together a test server for deploying new builds of our apps for first round QA work. More or less from a standing start this is the road I travelled, which at the end resulted in a fully operational test server.

First off was the installation of the 8.0-RC1 build itself on the test server machine, which was my Lenovo X60 laptop with 2GB of RAM. I got a hold of a build ISO image from a mirror detailed on the main “Get FreeBSD” site page, and took disc 1 only. The idea was to make a minimal install which meant only the first disc was necessary. With a minimal install you don’t get add the ports collection by default, so the first post installation task was getting this added. At this point, I was ready to install Rails, but as I also wanted a desktop I went ahead and installed KDE4. I’m not going to go into the details here, as there are other fine posts about this easily found with a Google search, but the process is fairly straight forward with no major gotchas yet takes around 10 – 12 hours to complete.

If you follow the same thing then you’ll have all the main ports installed that you need and you can get to the meat and potatoes stuff. As a precondition to running Rails you need to have MySQL installed. It doesn’t make any difference if you go for 5.0 or 5.1 as long as it’s there (and up at the time you start final configuration on a rails app).

Checking what version of Ruby I had at this point I could see 1.8 installed (as default).

[root@iceman /usr/ports]# ruby –version
ruby 1.8.7 (2009-04-08 patchlevel 160) [i386-freebsd8]

This is fine, and the choice is there to install 1.9 if you want as there is a port for it in /usr/ports/lang/ruby19.

Gems isn’t installed as default, so the next task is putting that in. A simple “make search name=gems” shows the gem port in /usr/ports/devel/ruby-gems. Following the standard “make install clean” actions it will put the 1.3.5 version on your machine.

[root@iceman /usr/ports/devel/ruby-gems]# gem –version
1.3.5

Okay, now you’re good to go with putting on the specific gems to get Rails apps running. We begin of course with rails itself. (‘#’ denotes running command as root; ‘>’ denotes running command as non privileged user). A word of advice here, you’ll save yourself errors later on if you install the 2.2.3 version explicitly. The 2.3.4 version seemed broken with the latest build of Ruby.

# gem install -v 2.2.3 rails

This gives you a collection of gems that comprise the rails framework, and the Ruby documentation pages as well. Next up you need the MySQL gem, and I needed authlogic gems as we use this functionality in our customer portal for user management.

# gem install mysql
# gem install authlogic
# gem install authlogic-oid
# gem install ruby-openid

Because of the way character sets are interpreted (more like mangled) at the O/S level it can cause headaches for Ruby. It’s easily resolved by installing the character set conversion library and the accompanying ruby bindings, if you don’t you’ll run into runtime problems (which is exactly what happened to me).

# /usr/ports/converters/iconv make install clean
# /usr/ports/converters/ruby-iconv make install clean

Rake is the Rails functionality that sets up your database schema and needs to be present for the application configuration stage (when you’re finalising your application setup). Getting that installed is done by:

# gem install rake

However this version was one step behind what was needed, so you need an upgrade right after with this command:

# rake gems:install

This does quite a significant upgrade as you’ll see when you follow it’s progress, but at the end of it, you’ve got a number of gems on up-to-date versions compatible with rails.

Next come the test framework gems, and “thin”, which is the Rails web server, which we use to run our web app(s).

# gem test-unit -v 1.2.3
# gem install thin.

Finally, because of the type of application we have, which has a brick that takes a feed from our blog, I needed to added a gem from a Ruby developer who has developed an extremely good library for this. However, it’s not installed on the usual gem source so this had to be configured and added seperately in this way (You will notice quite a few other gems being installed as dependencies).

# gem sources -a http://gems.github.com
# gem install pauldix-feedzirra

Once all this was done, I had everything in place gem wise. If you follow the same path you’ll end up with a gem list that looks something - if not exactly - like this.

[root@iceman /usr/ports/devel/ruby-gems]# gem list

*** LOCAL GEMS ***

actionmailer (2.3.4)
actionpack (2.3.4)
activerecord (2.3.4)
activeresource (2.3.4)
activesupport (2.3.4)
authlogic (2.1.2)
authlogic-oid (1.0.4)
builder (2.1.2)
daemons (1.0.10)
eventmachine (0.12.8)
hoe (2.3.3)
json_pure (1.1.9)
mdalessio-dryopteris (0.1.2)
mysql (2.8.1)
nokogiri (1.3.3)
pauldix-feedzirra (0.0.18)
pauldix-sax-machine (0.0.14)
rack (1.0.0)
rails (2.3.4)
rake (0.8.7)
ruby-openid (2.1.7)
rubyforge (2.0.3)
sources (0.0.2)
taf2-curb (0.5.4.0)
test-unit (1.2.3)
thin (1.2.4)

Now you’re right to configure your application database settings, and finally run your app. If you follow the standard convention for Rails development the database configuration is located in

# /path/to/your/app/config/database.yml

Create a mysql database; add the user (with GRANT); put these details here in this file. Once done, you can setup the database tables and schema with rake.

# rake db:schema:load

It’ll be pretty obvious if this worked or not by the output to stdout; you’ll either see a list of tables and properties that are defined, or error messages on some misconfigured property. Hopefully the former.

All that remains is to start your app server with

# /path/to/your/app/script/server

Which all things remaining equal will go through the successful bootstrap procedure of spinning up a web server instance and your application.

Best of luck, and I hope this was useful. It’s my experience that FreeBSD 8.0 makes setting up a Rails environment very simple and by-the-numbers. It just worked; which is really the catch cry of FreeBSD. I attempted to go through the same setup on an OpenSolaris 2009.06 environment and ran into so many problems I threw in the towel when I started running out of time to test a new build from our Dev team and fell back to getting old faithful - FreeBSD – configured and installed. If I feel like banging my head up against a brick wall again anytime soon I might retry that, but it won’t be for a while yet. I want to let the ringing in my ears and bleeding eyeballs subside first.

Andy.
Tagged with:
preload preload preload