Migrate Your WordPress Blog to a Bitnami EC2 Instance

The cool thing about doing geeky things like this is the ability to share the howto with other folks who can actually get just as excited. Amazon’s announcement of a 12 month free usage tier, plus the fact that this blog doesn’t run on sugar plums and candy canes, put us in the short list for migration. As Matthias has done the bulk of the joyent server setups & linode migrations, it was high-time I got my hands dirty. Without further ado, here’s how I migrated AWO to our first Amazon EC2 instance. Let’s get our geek on!

Choosing BitNami

Initial plans were to grab some debian-based Amazon Machine Image (AMI) and follow the various “howto config wordpress on lamp” posts out there, but Matthias asked if I was going to take a look at BitNami. I’d never heard of it before and, truth be told, it actually sounded like some kind of BitTorrent client to me. Digging in a little deeper, I soon understood what all the hoopla was about and I was sold on a nicely contained, pre-configured BitNami WordPress AMI. There’s even an AMI which automatically bootstraps an Elastic Block Storage (EBS) – how’s that for easy?

Just in case you don’t know what EBS is good for – a running EC2 instance doesn’t come with a disk for storing your data by default. Meaning if you plan on making changes to your AMI at runtime that you’d like to see after a reboot, you need to attach a disk (EBS in Amazon AWS speak).

Setting up a new EC2 instance on AWS

One of the catches for a 12 month, free EC2 instance is a new Amazon account, so be sure to register a new email address or you might get a surprise bill next month! And, yes, you will also need a valid credit card to open your account, because if your instance exceeds the free usage tier limits, you will be charged.

Launch a new intstance, click over to Community AMI’s and copy/paste the BitNami image in question:

Note the ebs based root device – now we’re cooking with crisco! After selecting the image, you’ll be guided through a fairly simple setup. The free instance is “Micro”, so be sure to change the default selection:

You should definitely spend a few minutes considering the region in which to launch the instance. If you’re using Analytics, checkout your Map Overlay to see from where your visitors are coming. Our biggest block primarily comes from the U.S. West Coast, but there are significant folks throughout the continental U.S. and Europe.

We ultimately went with the mid-point “U.S. East” region.

Do not take the default security group setting as it provides neither SSH nor HTTP access. Create your own custom group adding at least these ports.

After your instance launches, click on it in the AWS Management Console. The description tab below will list a “Public DNS”. Point your browser to this URL and you’ll see the BitNami Welcome page with a few links including your new WordPress install. Not too shabby – a running blog on a new virtual server in all in the space of about 15 minutes.

At some point creation phase above, you were prompted to download a .pem file – this is your SSH keypair to get in the back door of your new instance. You’ll need to chmod 644 my_aws_ec2.pem & then ssh -i my_aws_ec2.pem bitnami@public_dns.amazonaws.com to access your EC2 server via ssh. The bitnami user has sudo access.

Last, but not least, make an EBS snapshot of your running instance so you have a known fallback before entering the next phase of the migration. Don’t forget about this capability – at every step where you feel you’ve accomplished an important step, back it up!

Migrating Your WordPress Blog

On your existing blog, dump your database and tarball your WordPress htdocs path.

$ mysqldump -uwordpress -p awo > awo_wp.sql
$ tar -cjf awo_htdocs.bz2 /home/awo/public

Now, let’s get those dumps copied over to your new EC2 instance:

$ scp -i my_aws_ec2.pem awo_wp.sql awo_htdocs.bz2 bitnami@public_dns.amazonaws.com:/home/bitnami/originals/

And, don’t forget to copy over any releveant configurations and performance tweaks in your Apache (apache2.conf, httpd.conf) and MySQL (my.cnf, conf.d/*.cnf) setups.

Moving on to the IP address. Goto the Elastic IP’s entry in your AWS console. Allocate New Address and associate it with your newly created (and probably only) EC2 instance. While we’re waiting for the DNS to catch up, edit your local (meaning the computer you’re using to do the migration) /etc/hosts accordingly, overriding your blog domain with this new IP address.

$ sudo vi /etc/hosts
...
<NEW_ELASTIC_IP> www.agileweboperations.com

On the new instance do something like the following (remembering your EBS snapshot above ),

$ rm -Rf /opt/bitnami/apps/wordpress/htdocs/
$ tar -xjf ~/originals/awo_htdocs.bz2 /opt/bitnami/apps/wordpress
$ mysql -uroot -pbitnami bitnami_wordpress < ~/originals/awo.sql

Note the location of the BitNami wordpress, and the MySQL root password and wordpress database schema.

Now, let’s setup a virtual host to point to your new blog:

$ sudo vi /opt/bitnami/apache2/conf/httpd.conf
...
# Virtual hosts
Include conf/extra/httpd-vhosts.conf
...
$ sudo vi /opt/bitnami/apache2/conf/extra/httpd-vhosts.conf
...
<VirtualHost *:80>
    DocumentRoot "/opt/bitnami/apps/wordpress/htdocs"
    ServerName agileweboperations.com 
    ServerAlias www.agileweboperations.com
    ErrorLog "logs/awo-error_log"
    CustomLog "logs/awo-access_log" common
</VirtualHost>
...

Any special apache configuration (KeepAliveTimeout, ServerTokens, etc.) can be edited @ /opt/bitnami/apache2/conf/extra/httpd-default.conf. Be sure to include these edited files in the base apache conf:

$ sudo vi /opt/bitnami/apache2/conf/httpd.conf
...
# Server-pool management (MPM specific)
Include conf/extra/httpd-mpm.conf
...
# Virtual hosts
Include conf/extra/httpd-vhosts.conf
...
# Various default settings
Include conf/extra/httpd-default.conf

Finally, remember your canonical redirects! No duplicate content here:

$ vi /opt/bitnami/apps/wordpress/htdocs/.htaccess
RewriteEngine On
RewriteCond %{HTTP_HOST} .
RewriteCond %{HTTP_HOST} !^www\.agileweboperations\.com
RewriteRule (.*) http://www.agileweboperations.com/$1 [R=301,L]

Restarting processes with Bitnami is accomplished using the ctlscript.sh. To restart Apache, just run sudo /opt/bitnami/ctlscript.sh restart apache.

MySQL my.cnf may be edited @ /opt/bitnami/mysql/my.cnf and the restart is accomplished in much the same way : sudo /opt/bitnami/ctlscript.sh restart mysql.

You can also use ctlscript.sh to check out your apache & mysql status:

$ sudo /opt/bitnami/ctlscript.sh status
apache already running
mysql already running

Gotchas & Caveats

Installing ec2-api-tools is not possible on a t1.micro Ubuntu instance. If you know you’ll need this, either install the instance initially as m1.small or you can stop/switch an existing instance (which is what I had to do).

This was also a bit of a learning experience, as stopping an instance removes the elastic IP address. Sure, makes sense – but if you don’t know this you’ll wonder why you can no longer ssh into your restarted instance. Additionally the “Public DNS” name will also dynamically change upon starting an instance. Plus, just starting an instance immediately costs you 1 hour of computing time, so don’t be surprised to see a bit more usage than you’d expect if you do this a few times.

YMMV, but the bitnami:daemon user:group which owned /opt/bitnami/apps/wordpress/htdocs was not sufficient for performing any “inline” wordpress upgrades/installs – meaning trying to upgrade/install a plugin asked for FTP access information. Performing a sudo chown -Rf daemon:daemon /opt/bitnami/apps/wordpress/htdocs did the trick, however. Anyone more familiar with BitNami, please feel free to step in and clarify.

MySQL died the first night after relaunch. A strange “Killed” showed up in the /opt/bitnami/mysql/data/mysqld.log:

101229 15:41:33 [Note] /opt/bitnami/mysql/bin/mysqld.bin: ready for connections.
Version: '5.1.50'  socket: '/opt/bitnami/mysql/tmp/mysql.sock'  port: 3306  MySQL Community Server (GPL)
Killed
101230 00:15:51 mysqld_safe Number of processes running now: 0
101230 00:15:51 mysqld_safe mysqld restarted
101230  0:15:53 [Note] Plugin 'FEDERATED' is disabled.
Killed
101230 00:15:54 mysqld_safe mysqld from pid file /opt/bitnami/mysql/data/ip-10-112-91-108.pid ended
101230 07:32:02 mysqld_safe Starting mysqld.bin daemon with databases from /opt/bitnami/mysql/data
...

Turns out, the Bitnami image makes use of Linux’s OOM Killer which takes a heavy-handed approach to potential Out of Memory issues before they over swap the server. The problem was I forgot to include the httpd-mpm.conf file I had altered so carefully above in the httpd.conf, so there were a bunch more simultaneous clients than this micro server could manage.

After upgrading to WP 3.0.4, and doing a sudo apt-get update & sudo apt-get upgrade, accessing any pages in wp-admin somehow deadlocked the entire server (loads of 10-15 observed). The only thing that finally fixed this was restarting the entire instance.

After you get an elastic IP setup, delete the /opt/bitnami/updateip file. Otherwise, restarting the instance, Bitnami resets the wp_options values to the Public DNS server name. If you forget, you must change this back or else your blog won’t work:

$ mysql -uroot -p bitnami_wordpress
mysql> update wp_options set option_value = 'http://www.agileweboperations.com' where option_name in ('siteurl', 'home');
Query OK, 2 rows affected (0.00 sec)

Let’s see how are “free” year works out – for such little effort (~1 day), it’s well worth the savings (and maybe AWO gets into the black for the first time in 2011 ). And, check out where the rubber meets the road – our Pingdom response times before and after the relaunch:

Professional Grade Virtual Computing for “Free”

In case you missed my other posts on acquiring, maintaining, backing-up and monitoring your virtual server, here’s the complete list:
• Performance : WordPress Caching For High Performance EC2 Micro Instances
• Backups : Poor Man’s Automated Snapshots for EC2
• Monitoring : Cloudkick Monitoring for EC2

Tagged as: bitnami, ec2, howto, migrate, wordpress