MySQL on EBS AMI and persistancy

Question

I am trying to install MySQL on an EBS backed AMI.

An EBS backed AMI means, an AMI which is stored in EBS and not in S3.

• I pick an existing EBS-backed Ubuntu AMI offered by Amazon/Ubuntu, I launch it, customize it and create a new AMI which is specific to my needs. What process should be used to create this new AMI ? Should I be careful about any Public Key and .SSH folder (I say this because I tried this and was unable to login)

• Once I have a new AMI ID, a snapshot of the original EBS is added to the list of volumes, this is where the new customize AMI resides. From the list of AMIs, I can now launch this new AMI. When I launch my newly created AMI (customized), the snapshot size (root volume size) is the same as the original AMI's root size. I would like to increase this size to achieve more storage space. How do I do that ?

• Once I have enough storage space, I would like to install MySQL on this AMI. After this, should I recreate another new AMI to save this new installation ? or will this be automatically persisted in the root EBS volume.

Answer 1

Here are some points that relate to your question and situation as you have described it:

• If you are creating an AMI for use by other people or by the public, then you need to take great care with any information that touches the disk. It is often possible for others to recover information even from deleted files. Here's an article I wrote which touches on that: http://alestic.com/2011/06/ec2-ami-security

• If you are creating an AMI for your own exclusive use (not for others to use), then you don't have to take quite as much care with sensitive information. Just remember that you can never turn a private instance that once contained sensitive information into a public AMI.

• You should be able to create your private AMI from a running instance with the ec2-create-image command or the equivalent in the AWS console. The new AMI should support passing in new ssh keys and will also (as you alluded to) probably allow you to ssh in with any ssh keys that were in placed when you created the AMI.

• An EBS boot AMI is stored in an EBS snapshot. EBS snapshots are stored behind the scenes in S3, but not in a way that you can access them through standard S3 APIs. When you run an EBS boot AMI it starts an EBS boot instance where the root disk is an EBS volume (created from the EBS snapshot of the AMI).

• You can start an instance with a larger boot disk than the AMI specifies by using the block-device-mapping parameter when you run it. Here's an article I wrote that explains this: http://alestic.com/2009/12/ec2-ebs-boot-resize

• You can change the root disk size of an instance that has already been running by stopping it, replacing the EBS volume with a bigger copy, and restarting it. I provide sample steps here: http://alestic.com/2010/02/ec2-resize-running-ebs-root

• I recommend separating your MySQL database files onto a separate data EBS volume. I wrote an article that describes the steps to do this: http://aws.amazon.com/articles/1663

• If you use a separate data EBS volume, you probably won't need to resize the root EBS volume.

• No matter if you use one or two EBS volumes, the volumes and the software and data installed on them are persisted whether or not you create a new AMI. In fact, it is a little odd to create an AMI with a complete database in it as the information in the database will quickly grow stale. That said, you should regularly snapshot your EBS volumes, especially the ones that contain data.

• Always document/automate exactly how you started a new instance including software installation and configuration. Being able to reproduce this in the future will come in handy, especially in certain emergencies.

The more I think about your questions, the more I think you're probably assuming you need to do things you don't need to do. Here's my recommendation:

1. Start an EBS boot instance, and start documenting everything you do in following steps.

2. Attach a separate EBS volume for MySQL and other data (see above article).

3. Install and customize all other software.

4. Set up regular EBS snapshots for both EBS volumes.

You probably don't need to create custom AMIs and you probably don't need to resize root disks.

Answer 2

Actually an EBS ami means an ami where the instance will boot from an EBS volume, rather than an instance store. The actual ami is stored the same way regardless.

You do want to be careful about what data is in ami - don't leave anything there you wouldn't want a user of the ami to see.

When you boot an ami, one of the options is the block device mapping. You can use this to increase the size of the boot device, add extra devices. Note that this doesn't change the partition itself - you'll still have to run something like resize2fs to grow the partition (some Amis are setup to run this for you)

Any changes made to an instance started from an ami have no effect on the ami itself.