Ex
Ratione
About • GitHub • Blog • Archives • Feed

Setting Up Movable Type 4 (Or 5) on EC2

By Reason October 21st, 2010 Permalink

This blog runs on a micro instance in Amazon EC2. It could run on any cheap web hosting setup, but I picked Amazon because while I work with EC2 while consulting, I'm rarely the person deeply involved in the minutiae of provisioning server instances. Most small organizations have an IT resource of some sort in place, and division of labor means that it makes no sense for a software-focused consultant such as myself to be hands-on with EC2 day in and day out. Running some of my own websites on EC2 enables me to become usefully familiar with the quirks and common operational needs in the Amazon ecosystem.

To replicate my setup here, you must have an Amazon Web Services and EC2 account - that is the work of moments to register. You'll need to enter payment information and create a key pair for SSH access before firing up a server. The key pair creation tool is under "Security Credentials" in your account.

Fire up an EBS Instance of AMI ID ami-225aac4b

Now bring up the EC2 Console and choose to start a new server instance. You'll be asked to select an AMI - a server image - from a very long list of AMIs, some provided by Amazon, but most built and shared by the community. You want AMI ID ami-225aac4b, which is a bare bones Fedora 14 machine, and which boots from a 10 gigabyte Elastic Block Store (EBS). An EBS instance acts much like a normal physical server until you terminate it: changes you make are persistent, and you can stop and start it without losing data.

If you enter the AMI ID into the search box in the new instance dialog, it'll pull it up as an option. The rest of the dialog allows you to choose the horsepower of the server (micro in this instance), give it a name, and a few other options relating to the kernel and other items that you should leave as default.

You will have to choose or create a security group - a list of firewall rules created in a simple web form in the EC2 console. For your purposes here, you need to make sure that ports 80 (http) and 22 (ssh) are open so that you can log into the machine and view the website that will be running on it.

When an EBS server fires up, it also creates an associated EBS volume which you can see in the volumes section of the EC2 console. So long as you don't terminate the server, that volume persists as the server's filesystem.

Create and associate an Elastic IP

You're going to want a fixed IP address for your server, so request an Elastic IP in the EC2 console, and then associate it to your newly created server instance. Like all operations in EC2, it's somewhat random as to how long this requires to take effect after it declares it's done - it might be immediate, it might take a few minutes. I've seen occasions on which an Elastic IP address association failed to take, despite showing a success in the console, but then worked when I dissociated it from the server and re-associated it again.

You can now log in to the server over SSH using the key pair you created earlier. Note that for this particular AMI, you'll have to log in as "ec2-user" and then "sudo su" to become root in order to carry out the necessary installations and configurations.

Install the necessary software

You'll need to install and set up a few items. Log in as root and run the following commands: 

yum install mysql
yum install mysql-server
yum install httpd
yum install mod_ssl
yum install php
yum install cpan
yum install gcc
yum install gd
yum install gd-devel
yum install perl-XML-Parser
yum install perl-Crypt-SSLeay
yum install perl-Crypt-DSA
yum install ImageMagick
yum install ImageMagick-perl

From here I moved into a CPAN shell out of force of habit, but most or all of the necessary Perl modules can be installed via yum as well, and with less time and hassle. You may find make errors cropping up depending on the order in which you install the modules, and no-one is ever going to describe a CPAN update as fast. If you choose the yum route, you can find packages for the modules listed below using "yum list *perl* | more" or a similar search. 

cpan
>install Bundle::CPAN
>install Test::Harness
>install Archive::Zip
>install MIME::EncWords
>Install GD
>Install Mail::Sendmail
>install HTML::Parser
>install HTML::Entities
>install IPC::Run

Don't forget to ensure that services restart after a reboot:

chkconfig --add httpd
chkconfig --level 2345 httpd on
chkconfig --add mysqld
chkconfig --level 2345 mysqld on
chkconfig --level 2345 sendmail on

The inevitable DNS setup

The DNS zone file for exratione.com is managed through a registrar, which is a service that all the large registrars offer for a small price. Setting up A records for www.exratione.com and exratione.com to point at the Elastic IP address for this server was the work of a few minutes: buy the service, and update the DNS records.

Because Movable Type needs to know the domain as a part of the base URLs for its install (set in the mt-config.cgi file), you might as well get the DNS sorted out before installing MT - but there's nothing stopping you from using the naked IP address in that configuration and then changing it later if you want to forge ahead.

Install and configure Movable Type

I don't need to say much on this. Plenty of documentation exists out there, and hopefully by now you know that the default webroot directories in Fedora are under /var/www/, and that you'll probably want to tweak the default httpd configuration in /etc/httpd/conf/httpd.conf and the PHP configuration in /etc/php.ini.

For my part I just tacked a simple virtual host at the end of httpd.conf, mainly to let me use a .htaccess file for tinkering with mod_rewrite directives and other similar items:

<VirtualHost *:80>
    ServerAdmin fake.address@exratione.com
    DocumentRoot /var/www/html
    ServerName www.exratione.com
    ServerAlias exratione.com

    <Directory /var/www/html>
       Options +Includes -Indexes +FollowSymLinks
       AllowOverride All
    </Directory>

    Alias /cgi-bin/ /var/www/cgi-bin/
    <Directory /var/www/cgi-bin>
       Options +ExecCGI -Indexes +FollowSymLinks
       SetHandler cgi-script
       AllowOverride All
    </Directory>

</VirtualHost>

One thing that might trip you up is that if you configure the base URL for Movable Type to be www.mydomain.com and then access the administration interface through mydomain.com (without the "www.") - or vice versa - then the editing tool for entries will appear blank and empty. Because I type fast and would otherwise do this all the time, I set up a .htaccess file and mod_rewrite rules: 

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteCond %{HTTP_HOST} !^www.exratione.com$
RewriteRule ^(.*) https://www.exratione.com/$1 [L,R=301]

RewriteCond %{SERVER_PORT} 443
RewriteCond %{HTTP_HOST} !^www.exratione.com$
RewriteRule ^(.*) https://www.exratione.com/$1 [L,R=301]

Take a first backup

There are two backup strategies for an EBS instance using the mechanisms of EC2. Firstly, you can use the EC2 console to create an AMI from a running EBS instance. You can later fire up other instances from this AMI template, which makes it a form of backup. Creating an AMI is a slow process, and will take your server instance out of commission for the 10-15 minutes while it is happening, however. This is less than ideal.

The second option is to use the volume snapshot tool and a little tinkering. First open up the volumes section of the EC2 console and find the volume associated with your server instance. Take a snapshot of it. This snapshot is your first backup - hopefully you will make a habit of taking regular backups. To restore a backup or launch a new server from a backup, you can take actions that are equivalent to swapping out disks in a server, but using EBS volumes:

  • Fire up a new instance of AMI ID ami-84db39ed. This will come into being with its own newly attached volume - but which isn't the volume you want. Make a note of the device the volume is attached to (most likely /dev/sda1, shown under "Attachment Information" in the list of volumes).
  • Stop the instance (but don't terminate it, as that will completely remove it). Then detach the volume it started with. Delete this volume, as you won't need it.
  • Pick the snapshot you want to restore and create a volume from it. Once the volume is ready, attach it to your volume-less instance, using the same device as the old volume was attached to. Now start your instance again.

Neither of these processes are frictionless, but they'll get the job done for a small business.

Protect your EBS instance from accidental termination

As you work with the EC2 console, you'll notice that it isn't all that hard to terminate an instance instead of stopping it if you're distracted or careless. Terminating your EBS instance will destroy the boot volume it was created with - so unless you are running a restored backup that isn't using the original volume created with the instance, you will lose data. This is exactly the sort of thing that will turn around and bite you one day, but fortunately there are some ways to mitigate the risk - see this excellent article on the topic, for example.

You will want to set up the EC2 command line tools on your local machine. These enable you to perform all of the actions possible through the EC2 console - and much more - via API calls issued on the command line. Amazon provides a good getting started guide and command reference. There are third party tools and user interfaces built on top of this API, but I think it is a good idea to have some knowledge of the API itself before working with them.

Once you are set up, issuing the following command will disable the ability to terminate the instance that hosts your Movable Type website. Substitute your instance ID for "INSTANCEID": 

ec2-modify-instance-attribute --disable-api-termination true INSTANCEID

If you now try to terminate your instance in the EC2 console, you will find the action is blocked.