A month or two ago, Amazon Web Services (AWS) announced that their EC2 instances will now be bootable from an elastic block store (EBS) volume. This seems like a small change, but in fact has opened up a world of possibilities in the Elastic Computing Cloud (EC2).
EBS provides “block level storage volumes for use with Amazon EC2 instances.” Keep in mind that prior to this, instances were limited to booting off of S3-backed Amazon Machine Images (AMI), which were not persistent images. This meant 2 things:
- instance-store AMIs cannot be “stopped,” only rebooted or terminated
- rebooting an instance-store AMI reverted the instance back to the AMI defaults
Since EBS originally debuted as a high-performance attachable block device to a given instance, booting off of EBS AMIs has shown to be faster than the traditional instance-store boot as well.
Another benefit is that EC2 instances booted off of EBS volumes can be stopped, which effectively equates to shutting down a machine in the real world. You are still responsible for the charges incurred while this instance is reserved, but all of the changes made to said instance will persist after you start it again.
The last major benefit of booting off the EBS volumes is that AWS has made it easy for you to create a new EBS AMI from a running EBS AMI. In the Console, right clicking on an EBS instance will yield a new option, “Create Image (EBS AMI).” This will basically shut down your instance, and proceed to generate a new EBS AMI from the contents on the disk of your instance. This command seems to have a failure rate of ~40%, which can be a little frustrating. I’ve found that if you put an instance into ‘stopped’ state before creating the EBS AMI, the process has a higher chance of success, but will still take anywhere from 20-45 minutes.
The rest of this article will focus on converting an instance-store AMI into an EBS AMI.
In order to perform this conversion, you will need to have an instance-store AMI that is the base OS you’d like to run (for the purposes of this article I used alestic’s Debian 5.0 base image), and access to EC2 via CLI as well as the portal (it’s all do-able from the CLI, but some of the tasks are a LOT easier and quicker through the web console). The stuff I did in the console will be suffixed with [console], and the stuff from CLI will be prefixed with #.
1) Booting an instance-store AMI – I executed the following to get a list of the images that fit my criteria (32bit, Debian, base install):
# ./ec2-describe-images –region eu-west-1 –all | grep -i lenny-base | grep i386
IMAGE ami-b13a6bf4 alestic-32-us-west-1/debian-5.0-lenny-base-20090804.manifest.xml
IMAGE ami-b33a6bf6 alestic-32-us-west-1/debian-5.0-lenny-base-20091011.manifest.xml
Note: ec2-describe-images outputs way more data than this, above is formatted for brevity.
Once you have the AMI (newer is better, generally speaking), boot an instance with this AMI:
# ./ec2-run –region eu-west-1 -k $keypair ami-b33a6bf6
Note: $keypair in this case is the name of keypair used to SSH into the server
2) Customizing the EBS volume – After the instance is up and running, look to see which availability zone the instance is in. If the region is eu-west-1, the availability zone is going to be either eu-west-1a, or eu-west-1b. In either case, find out which availability zone your instance is in, and then create a 10gb EBS volume is the same zone [console].
Why 10gb? 10gb is the maximum size for an S3-backed AMI, which makes a 10gb volume the largest any instance-store AMI will be. Obviously EBS AMIs can exist on larger volumes (all the way up to 1tb in size), and you can easily do so once you have an EBS-backed AMI.
After the EBS volume has been created, attach it to the running instance [console]. Remember what you chose as the device name the volume identified itself as (/dev/sdf for example).
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
3) Creating the AMI – At this point, you should have a 10gb EBS volume that shows available [console]. Simply right-click on the volume and create a snapshot for the volume [console]. Once the snapshot has completed, select from the list of available kernels on ec2 with the following command:
# ./ec2-describe-images -o amazon | grep -i xenu
Store the AKI for the kernel you want to use in the environment variable AKI:
# export AKI=aki-xxxxxxxx
Up to this point, we have booted an instance-store AMI, created an EBS volume, synchronized the instance-store filesystem with the EBS volume, and created a snapshot of the EBS volume. The only thing we need to do now is associate an AKI with the snapshot, and register the end result as an AMI in the EC2 repository.
# ./ec2-register –region eu-west-1 -s $SNAP –name $NAME –description “$DESC” –architecture $ARCH \
–root-device-name /dev/sda1
Where $SNAP is the ID of the snapshot, $NAME is the name of your AMI, $DESC is a description of the AMI, and $ARCH is either i386 (for 32-bit) or x86_64 (for 64-bit). The command will return an AMI, which will be yours to boot from once it finishes!
To track the progress of the AMI creation, you can do the following:
# watch -n 30 ‘./ec2-describe-images ami-xxxxxxxx’
This will execute the ec2-describe-images command for your new AMI every 30 seconds. You can stop the command once you see that the AMI is in available state.
Now that you have an EBS-backed AMI, any further customizations you make to this image can be preserved forever by simply right-clicking on the instance [console], and clicking “Create Image (EBS AMI).”
Enjoy!
