Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question

4 Answers 4

up vote 7 down vote accepted

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.

share|improve this answer
    
Accepting this because it directly answers my question. But everyone should also take a look at Eric Hammond's best practice recommendations! –  Jonik Jan 15 '12 at 9:06

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...

share|improve this answer
    
Scripting? I dunno about you, but I build mine out with Puppet. –  Tom O'Connor Dec 18 '11 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 '11 at 21:32
    
Fair enough. I suppose the line between a DSL and a script is pretty slim. –  Tom O'Connor Dec 19 '11 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 '12 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 '12 at 21:24

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.

share|improve this answer

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.

share|improve this answer
    
I came in here to suggest blueprint. +1 for you! –  ceejayoz Sep 20 '11 at 21:55

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.