So in my previous post I talked about all this work to make an EBS backed AMI.  At the end though I realized that I didn’t size the server right.  Doh!  This was fairly stupid of me.  So I followed the same set of steps because all the instructions I found on resizing an existing image didn’t seem to work.  And then I tried something, you know, for $#!*$ and giggles.  Imagined how annoyed I was when it worked.

So here is the command for registering an EBS backed image based on a particular snapshot:

ec2-register --block-device-mapping /dev/sda1=s<snapshot id>::false
--name "<ami name>" --kernel <kernel id> --ramdisk <ramdisk id>
-K <key file> -C <cert file>

(Note: If you want the volume to persist after termination then you’ll want to change the true in the –block-device-mapping flag to false)

So the key is in the –block-device-mapping flag.  The documentation for Amazon states:

Block Device Mapping Documentation

So it says somewhere in there that you can specify the size of the AMI in that particular flag, so if I want to increase the size of the instance all I would need to do is change the flag to read:

--block-device-mapping /dev/sda1=s<snapshot id>:50:true

or whatever size you want.  Afterwards you’ll need to log on to the server and resize the drive.  You can do this by running the following (assuming you’re using an ext3 root file system, which is what I used in my previous post):

sudo resize2fs /dev/sda1

it’ll resize the drive and you should be good to go.

There are tons of instructions out there on how to create an EBS backed images.  Most of them don’t work for me because they are either out dated or the person’s instructions for copying the file structure doesn’t work.  I finally found instructions though that do work.

So here is how I did it:

1) Start Up an Instance

The first thing I do is start up an instance.  Everyone has instructions on how to do this from the command line.  But I’m lazy and find that Amazon’s API tools change regularly which is annoying and makes it difficult to follow the instructions other people have written.  I recommend doing it in the AWS Console.

Go to EC2 in the AWS Console.  Choose AMI and find an image that you like (I tend to lean toward Alestic’s Ubuntu images, but that’s just me).  Once I found an AMI I like I highlight it and then choose “Launch Instance”.  I follow the instructions, making sure that I choose the correct security group (aka firewall) and the correct key pair (you access ec2 servers using a key pair rather than a password).

Once the server is up and running, I update everything, configure it, transfer data onto it, blah blah blah.  The usual things that you do when you are prepping a server.  Once I’m all set I’m ready to make it an EBS backed AMI.

2) Create a New EBS Volume

The next thing I do is create an EBS Volume, again doing it in the AWS Console.  Go to the EC2 section of the AWS Console.  Choose “Volumes” and then “Create Volume”.  You’ll want to make sure of two things:

First that the volume is large enough to hold everything.  I forgot to do that the first time around and *thought* I had to do everything all over again (see next post for how to really do it).  The easiest thing would be to just size it right the first time around.

Second that the volume is in the same availability zone as the instance you started up in step 1.  If you aren’t sure what the availability zone is for your instance, go back to the instance, highlight it, and in the bottom panel you’ll see what zone its in.

3) Attach Volume to Instance

When you are done you’ll want to attach the volume to the instance that you created in step 1.  Once the volume is available, highlight it and choose “Attach Volume”.  You’ll be stepped through attaching it to your server.  If you have only one instance running its pretty straightforward.  If you have multiple ones running, you’ll want to make sure that you’re attaching it to the right place.  You’ll be asked to indicate where you want the attached, I usually do /dev/sdf.  Oh and this process won’t work if the volume and the instance aren’t in the same availability zone, hence my warning in the previous step.

4) Copy the Data from the Server to the Volume

This part of the instructions I found over at Winners Don’t Lose.  This helps you format the volume and copy the data on the current instance over to the volume:

In a root shell on the instance:

# mkfs.ext3 /dev/sdf
# mkdir /mnt/target && mount /dev/sdf /mnt/target
# rsync -avHx / /mnt/target
# rsync -avHx /dev /mnt/target
# sync;sync;sync;sync && umount /mnt/target

The above commands did the following:

formatted the entire volume /dev/sdf as an extended 3 filesystem
created directory /mnt/target and mounted /dev/sdf at /mnt/target
rsync’d the root instance-store filesystem to the ebs volume
synchronized the /dev directory from the instance-store filesystem
flush all pending write ops, and unmount the EBS volume

To be honest these are the only instructions I’ve ever been able to follow that doesn’t produce some error that I have to debug.

5) Detach the Volume

The next step is to detach the volume that you just created from the running instance.  Again you can do this in the AWS console by finding the volume, highlighting it, and choosing detach.  Make sure the you’re detaching the right volume though!

6) Create a Snapshot of the Volume

You’ll want to create a snapshot of the volume that you just created.  You can again do that in the AWS Management console but finding the volume, right clicking on it, and choosing create snapshot.

7) Register your AMI

This is the part that took me forever to figure out.  Mostly because the documentation for the ec2-register command didn’t jive with the tools that i had access too.  The command I used was:

ec2-register --block-device-mapping /dev/sda1=<snapshot id>::true
--name <ami name> --kernel <kernel id> --ramdisk <ram disk id>
-K <your pk file>.pem -C <your cert file>.pem

(note i updated this:  if you want the volume to persist after termination then you’ll want to change the true in the –block-device-mapping flag to false)

You’ll want to make sure that you specify and kernel id and a ram disk id, I usually use the same one that my instance I’m creating this new AMI from was using.  You don’t have to do it, but that would mean that if your AMI users don’t choose one during start up, then the instance won’t work.

Note that you may have your key and cert file set as part of your environment variable.  I have multiple accounts so I don’t, and instead just specify them when I’m running any commands (annoying but I don’t do much from the commandline anyway).