7

I have customised (EBS-backed) AMI for running a demo version of an application of ours. (The AMI contains Ubuntu 11.04 with a Tomcat & MySQL setup for the app itself, and Jenkins for easy one-click update of the demo).

This is a 32-bit AMI, which means I have the following instance type options:

  • Micro (t1.micro)
  • Small (m1.small)
  • High-CPU medium (c1.medium)

We've noticed that we'd like some more performance for the demo server than what c1.medium can offer. (Specifically, I suspect "I/O Performance: Moderate" might be a bottleneck, although I'm not sure if improving that would help given that we use EBS for everything.)

Anyway, in order to use the more powerful instance types (e.g. "m1.large" or "c1.xlarge"), I would need a 64-bit AMI.

One way to do this is to create a new instance from clean 64-bit Ubuntu AMI, then re-setup my system there, and finally save that as a new AMI. I could mount a volume with the current setup, and then cp -a some stuff over to the new instance's root disk, which would help somewhat. But even so, this approach can be somewhat tedious and time-consuming.

So, my question is, is there any easier, automated way of converting a 32-bit AMI to a 64-bit one?

Improve this question

4 Answers 4

Reset to default
7

No, there is no automated way. You will have to create a new AMI starting with the Ubuntu-plain one.

It's possible to convert an Unbuntu installation but it's really messy. It's best you make a fresh AMI.

Improve this answer
1
14

Best practices:

  1. Whenever you build an AMI (or even set up an instance) always document the exact steps you took to install and configure the software and what data you put on it and where. This has many benefits including making it easy to rebuild the same AMI for a different architecture.

    Even better, I recommend scripting most or all of the install, configure steps so that you can automate the building of the AMIs. This makes it easy to tweak the setup and test new versions.

    Here's a sample of how I build an Ubuntu AMI with Git and gitolite installed for private Git repository servers:

    https://github.com/alestic/alestic-git/blob/master/bin/alestic-git-build-ami

  2. The first recommendation above is for setting up the software which generally goes on the root volume. Your data should be placed on separate EBS volume(s) that you attach to your instance after running the AMI. This has many benefits including the ability to move the data between instances, like when you want to switch to running a new AMI. It also lets you make copies of your data volumes to attach to development instances.

You may think that this advice is too late for you, but you are about to build another AMI, so...

Improve this answer
5
  • 1
    Scripting? I dunno about you, but I build mine out with Puppet.
    – Tom O'Connor
    Dec 18, 2011 at 9:15
  • 1
    Tom: I consider writing Puppet or Chef configurations to be a form of scripting. All I mean is that you should automate the process so that it requires as little manual work as possible.
    – Eric Hammond
    Dec 19, 2011 at 21:32
  • Fair enough. I suppose the line between a DSL and a script is pretty slim.
    – Tom O'Connor
    Dec 19, 2011 at 22:35
  • Thanks, great advice. Intuitively this feels right, and I sort of knew it, but so far I've been too lazy to automate everything, or it always felt like a one-off case... :)
    – Jonik
    Jan 15, 2012 at 9:12
  • 1
    Jonik: Full automation isn't always necessary. Get in the habit of opening a text file and copying the commands you run and files you edit when you set up a new system. This documentation makes things much easier the next time and is a good start towards automation.
    – Eric Hammond
    Jan 15, 2012 at 21:24
5

You'll need to start with a new AMI I believe, but you can generate a package list on the old image using dpkg:

dpkg --get-selections | awk '{print $1}' > pkgs.old

Then use this on the new image to figure out what packages you might need to install:

dpkg --get-selections | awk '{print $1}' | fgrep -v -f - pkgs.old

Then probably copying files out of /etc should get you most of the way there.

And +1 for scripting it -- you hardly every set these things up once or twice -- it's usually many many times. Having all this automated and in source control is crucial.

Improve this answer
3

Try reverse engineering the 32bit AMI with blueprint:

https://github.com/devstructure/blueprint

Save the output as a bash script and use the user data hook when firing up the 64 bit version.

Improve this answer
1
  • I came in here to suggest blueprint. +1 for you!
    – ceejayoz
    Sep 20, 2011 at 21:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .