Launch an AWS EC2 AMI instance with an EBS disk larger than the default

When you launch an EBS instance on EC2, you get a root disk size that is the same as what the machine image was created with.  For example, the Ubuntu AMIs by default are 8GB.  Typically, the best approach is to leave the root volume this size and add additional volumes provisioned with the size needed for particular data (mysql data files or whatever).

However, sometimes, you just need a bigger root disk than 8GB.  It IS possible to launch such an instance.  Use this command:

# Launch an instance with a specific root disk size instead of the default
 
UBUNTU_EBS_IMAGE=ami-d0f89fb9
# New volume size in GB
VOLUME_SIZE=30
 
SNAPSHOT_ID=`ec2-describe-images $UBUNTU_EBS_IMAGE | egrep "^BLOCKDEVICEMAPPING" | cut -f4`
 
ec2-run-instances $UBUNTU_EBS_IMAGE \ # Don't forget all your other normal parameters
  --block-device-mapping "/dev/sda1=$SNAPSHOT_ID:$VOLUME_SIZE:true:standard"
 
# Ubuntu images on boot will auto-resize their root disk to match the available EBS size

Fixing Passenger error: PassengerLoggingAgent doesn’t exist

While doing a new install of Passenger & nginx, I ran into some strange errors:


2012/09/25 20:09:54 [alert] 2593#0: Unable to start the Phusion Passenger watchdog because it encountered the following error during startup: Unable to start the Phusion Passenger logging agent because its executable (/opt/ruby-enterprise-1.8.7-2011.12/lib/ruby/gems/1.8/gems/passenger-3.0.12/agents/PassengerLoggingAgent) doesn't exist. This probably means that your Phusion Passenger installation is broken or incomplete. Please reinstall Phusion Passenger (-1: Unknown error)

Our environment is using Ubuntu 12.04 LTS & Chef with the nginx::source & nginx::passenger_module recipes from the opscode cookbook. It turns out there were two root causes here that needed to be resolved:

  1. Even though the config explicitly stated to use version 3.0.12, the 3.0.17 passenger gem was also getting installed.  Some things were going to one place, some to another.
    • SOLUTION: I figured it’d just be easier to stick with the latest release.  So I changed the setting to just use 3.0.17 and uninstalled the old version
  2. The PassengerLoggingAgent was failing to be installed (but was failing silently.

SOLUTION: It turned out that we were missing some libraries.  Building the passenger package manually showed the details:

root@w2s-web01:/opt/ruby-enterprise-1.8.7-2011.12/lib/ruby/gems/1.8/gems/passenger-3.0.17# rake nginx RELEASE=yes
g++ ext/common/LoggingAgent/Main.cpp -o agents/PassengerLoggingAgent -Iext -Iext/common -Iext/libev -D_REENTRANT -I/usr/local/include -DHASH_NAMESPACE="__gnu_cxx" -DHASH_NAMESPACE="__gnu_cxx" -DHASH_FUN_H="<hash_fun.h>" -DHAS_ALLOCA_H -DHAS_SFENCE -DHAS_LFENCE -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wpointer-arith -Wwrite-strings -Wno-long-long -Wno-missing-field-initializers -g -DPASSENGER_DEBUG -DBOOST_DISABLE_ASSERTS ext/common/libpassenger_common.a ext/common/libboost_oxt.a ext/libev/.libs/libev.a -lz -lpthread -rdynamic
In file included from ext/common/LoggingAgent/LoggingServer.h:46:0,
from ext/common/LoggingAgent/Main.cpp:43:
ext/common/LoggingAgent/RemoteSender.h:31:23: fatal error: curl/curl.h: No such file or directory
compilation terminated.
rake aborted!
Command failed with status (1): [g++ ext/common/LoggingAgent/Main.cpp -o ag...]

So the libcurl development headers were the true issue.

apt-get install libcurl4-openssl-dev

was the solution.  Or in our case it was to add:

package 'libcurl4-openssl-dev'

to the nginx recipe in chef.   I hope this helps someone else out there!

Celebrating WhyDay: My new project StatusBench.com

I searched long and hard for an idea on how I could celebrate #whyday.  In the end, I decided to launch a new website service that I (and I’m hoping a few others) have a need for:  StatusBench.com

Status Bench is a service that provides an easy-to-use status or health dashboard.  It performs the same function as http://www.google.com/appsstatus or http://status.37signals.com.  This allows you to have an independent site that is not part of your normal infrastructure.  When and if your site has downtime or outages, your customers will be able to rely on your status page to get updates about what is going on.

StatusBench.com screenshot

StatusBench.com screenshot

The current featureset is small, but solid:

  • Set up multiple status sites under your account
  • Use your own domain name: ‘http://status.YOUR-DOMAIN.com&#8217;
  • Each site can have multiple services underneath it for different parts of your app that may need independent updates
  • Each service can be in the states of: ‘Normal’, ‘Degraded’, ‘Offline’
  • Post multiple event updates about each service (mini-blog style)

I plan to add a lot of awesome new things in the future, so please look out for:

  • RSS Feed
  • History of updates / status over time
  • API to automatically change service status
  • E-mail subscriptions
  • SMS alerts
  • Twitter / Facebook / OpenID integration
  • Put your logo on the status page
  • Style your status page to your liking

Of course, any suggestions or ideas are welcome.  E-mail: support ~~AT~~ statusbench.com for whatever you need and I’ll help as much as I can.

This is a first draft of the service and I intend to expand it significantly (release-early and all that).  I’ll probably be adding premium options at some point as well.  But for now, I hope you enjoy the service and find good uses for it.

Happy #whyday