Following on from my post on how to create an S3 backed custom AMI for AWS EC2, I thought I would jot down the steps to go through if you wanted to make use of persistent disk storage by using Amazon’s Elastic Block Storage (EBS).
In my recipe I decided to use as a base AMI, the original S3 image that I rolled in my previous post:
After starting up an AWS instance using the S3 custom AMI I created, I went through the following process. – There are better ways to approach this, but this is a good starting point for anyone that is starting to experiment with the AWS platform.
Inside the AWS Dashboard create yourself an EBS volume. – This will be the one that will be used to build your future EBS machine image
Make a note of the block device id that the Dashboard assigns to your EBS volume once it has finished the provisioning process, you will need this in order to mount the EBS volume inside the S3 Instance that you have already booted up (You can find this under ‘Attachment Information’ in the Dashboard). It will be on here that you will run debootstrap,etc to build the EBS image.
Once the EBS volume is available you will see an entry like this in the dash:
Next, click the ‘Attach’ button in the AWS Dashboard as follows:
Upon clicking the Attach button you will be asked which Instance you want to attach the EBS volume to. – You need to select the Instance ID of your S3 backed AMI you just started.
Once everything is attached you will see an entry like:i-aws-instance-id:/dev/sdX. ie: i-a62bc123:/dev/sdf (attached). Notice that the ‘available‘ changes to ‘In Use‘ once you complete the attachment process. ( the ‘sdf’ is the block device id you will need to note down for the next step.)
Now on your running S3 AMI login and execute the following command as root to build an ext3 filesystem on the now attached EBS volume
mkfs.ext3 -F /dev/sdX
remember to set your TERM id to something valid before starting the copy_into_chroot, otherwise the LOCALE will fail
export TERM=vt220
You need to grab the latest compatible kernel sources from S3 as well. – Which ones you need will depend on if you are rolling a 32-bit or 64-bit AMI.
You can get them by pointing your browser to http://s3.amazonaws.com/ec2-downloads/ (or using curl from your instance) and grep’ing for the required Xenu modules,i.e:ec2-modules-2.6.21.7-2.fc8xen-ec2-v1.0-x86_64.tar, if you are building the 64-bit version.
Next run mkdir /EBSmountpoint
Next run debootstrap to pull down a netinstall of Debian Squeeze into the mountpoint we just created called /EBSmountpoint
debootstrap –arch [i386|amd64] squeeze /EBSmountpoint http://ftp.debian.org
Once this has finished, create a directory to unzip your kernel sources into:
mkdir 64bitmodules
then untar the downloaded source in that directory
cd 64bitmodules
tar xvf ec2-modules-2.6.21.7-2.fc8xen-ec2-v1.0-x86_64.tar
this should create a lib directory inside 64bitmodules, which you can then copy intolib/modules inside your /EBSmountpoint directory
cp -r 64bitmodules/* /EBSmountpoint/lib/modules
Next copy the two ec2 scripts. You’ll recognise these next few steps from my last post on Custom AMI’s, the copy_into_chroot.sh, shellscript contains additional configuration parameters that I have passed to the Debian image before it gets converted into an Amazon Machine Image.
cp /etc/init.d/ec2-get-credentials /EBSmountpoint/etc/init.d/
cp /etc/init.d/ec2-ssh-host-key-gen /EBSmountpoint/etc/init.d/
cp copy_into_chroot.sh /EBSmountpoint/
chroot /EBSmountpoint /bin/bash
mount -t proc none /proc
mount -t devpts none /dev/pts
execute copy_into_chroot.sh from inside your chroot environment.
type ‘exit‘ to leave your chroot
On your S3 Instance umount your EBS filesystem, as your almost ready to fire it up!!
create snapshot of EBS (make note of the EBS snap id)
Next register your EBS backed image, specifying the id of the snapshot you just took (snap-1ab23c45).
ec2-register –private-key=/ec2_creds/pk-.pem –cert=/ec2_creds/cert-.pem –region=EU-WEST-1 -a x86_64 -b /dev/sda1=snap-1ab23c45:20:false -d “Matts EBS backed Squeeze test” -n “SqueezeEBS” –kernel=”aki-780d250c” –ramdisk=”ari-7f0d250b” (the 20 after the snap id is the volume size, so it must match your AMI image size).
This will send you back an ami-id to use when starting an instance, this is done in the same way as an Instance-store AMI, although you will notice that instead of ‘instance-store‘ it will now display ‘ebs‘.
What you will notice starting and stoping this Instance is that any changes that you make will be preserved and available on start, which might suit some peoples requirements.
Hope someone finds these pointers useful.
Matt Palmer – 6th June 2011
