Joseph Mornin

Scalable WordPress on Amazon Web Services

January 06, 2013

These steps show how to build a secure, scalable WordPress setup on Amazon Web Services with auto scaling, caching, and cloud storage.

EC2 instance

Launch an Amazon EC2 micro instance running Ubuntu Server (the most recent version is 12.04 LTS). If you’re new to AWS, the EC2 Getting Started Guide shows how to fire up a server instance.

Make sure the security group allows connections via HTTP (port 80) and SSH (port 22). Connect to the server via SSH.

Update the pre-installed packages:

$ sudo apt-get update

Apache and PHP

Install Apache:

$ sudo apt-get install apache2

Create a new user to run WordPress and add a directory for the WordPress installation:

$ sudo adduser wordpress
$ sudo mkdir /home/wordpress/htdocs
$ sudo mkdir /home/wordpress/logs

Create a new Apache virtual host:

$ sudo vim /etc/apache2/sites-available/newsite.com

Add the following configuration:

<VirtualHost *:80>
        ServerAdmin your@email.com
        ServerName www.newsite.com
        ServerAlias newsite.com
        DocumentRoot /home/wordpress/htdocs
        <Directory />
                Options FollowSymLinks
                AllowOverride All
        </Directory>
        ErrorLog /home/wordpress/logs/error.log
        LogLevel warn
</VirtualHost>

Create .htaccess:

$ sudo vim /home/wordpress/htdocs/.htaccess
$ sudo chmod 777 /home/wordpress/htdocs/.htaccess

Enable the new virtual host, enable mod_rewrite, and install PHP:

$ sudo a2ensite newsite.com
$ sudo a2enmod rewrite
$ sudo apt-get install php5 libapache2-mod-php5 php5-cli php5-cgi php5-mysql php5-curl php5-gd php-apc
$ sudo service apache2 restart

RDS MySQL Database

Amazon’s RDS service provides cloud-based MySQL servers. I like it because it removes some of the the hassle of monitoring, backups, and other sysadmin overhead. The main tradeoff is that you lose certain fine-grained configuration options. The steps below show how to configure an RDS server, but you could easily swap in another database server setup.

Install the MySQL client on the EC2 instance:

$ sudo apt-get install mysql-client

Create an RDS MySQL instance (instructions here). Configure your RDS security group to allow access from your EC2 security group.

Note the RDS “endpoint” value, which should be something like mydb.XXXXXXXXXXXXX.us-east-1.rds.amazonaws.com. Connect to the database from the EC2 instance, specifying the value of the RDS endpoint as the host:

$ mysql -h mydb.XXXXXXXXXXXXX.us-east-1.rds.amazonaws.com -u {USERNAME} -p

At the MySQL prompt, run:

mysql> SHOW DATABASES;

You should see the database you created. The database server is working. Type Ctrl+d to exit.

Install WordPress

$ cd /home/wordpress/
$ sudo wget http://wordpress.org/latest.tar.gz
$ sudo tar -xzvf latest.tar.gz
$ sudo cp -r wordpress/* htdocs/
$ sudo rm -rf latest.tar.gz wordpress/

If you’re creating a fresh WordPress site, navigate to the instance’s public DNS address (the same address to which you connected via SSH—something like http://ec2-XX-XX-XXX-XXX.compute-1.amazonaws.com/). Enter your database information. On the next page, WordPress will generate the contents of a wp-config.php file. Copy these contents to a file at /home/wordpress/wp-config.php.

If you’re migrating an existing site, copy the contents of your current wp-config.php to the same file.

Media Storage with S3 and s3fs

This configuration uses Amazon S3 to store static files and s3fs to let WordPress access the S3 files.

Create an S3 bucket with a lowercase, alphanumeric name (there have been bug reports in setups using s3fs with non-lowercase, non-alphanumeric bucket names).

Install and configure s3fs:

 $ cd ~
$ sudo apt-get install build-essential libfuse-dev fuse-utils libcurl4-openssl-dev libxml2-dev mime-support
$ wget http://s3fs.googlecode.com/files/s3fs-1.61.tar.gz
$ tar -xzvf s3fs-1.61.tar.gz $ cd s3fs-1.61/
$ ./configure --prefix=/usr
$ make
$ sudo make install
$ sudo vim /etc/fuse.conf

# uncomment user_allow_other

$ sudo vim /etc/passwd-s3fs

# Add AWS security credentials in this format:
accessKeyId:secretAccessKey

$ sudo chmod 640 /etc/passwd-s3fs
$ sudo mkdir /home/wordpress/htdocs/wp-content/uploads
$ sudo s3fs BUCKETNAME -o allow_other /home/wordpress/htdocs/wp-content/uploads
$ cd /home/wordpress/htdocs/wp-content/uploads
$ touch hello-world.txt

You should see hello-world.txt in the bucket in the S3 web console.

Unmount the bucket:

$ cd ..
$ sudo umount uploads/

To launch s3fs when the server starts up, create an Upstart script to mount the S3 bucket:

$ sudo vim /etc/init/s3fsmount.conf

Add these contents:

start on startup
start on runlevel [2345]
script
exec s3fs {BUCKETNAME} -o allow_other /home/wordpress/htdocs/wp-content/uploads
end script

Make sure the Upstart script works:

$ sudo start s3fsmount
$ ls uploads

You should see hello-world.txt listed.

Reboot the instance from the AWS console and reconnect via SSH when it’s rebooted. Verify that the S3 bucket has been mounted:

$ ls /home/wordpress/htdocs/wp-content/uploads

You should see the contents of the S3 bucket (currently just hello-world.txt, unless you’ve added anything else).

Migrating an Existing WordPress Site

If you’re migrating an existing WordPress site, now’s the time to move your content. The key parts are:

• Database (export with mysqldump and import with mysql)
• .htaccess
• WordPress theme files
• Plugins
• Media files/uploads

Caching

This setup uses W3 Total Cache, a popular WordPress plugin for caching and CDN distribution.

$ cd /home/wordpress/htdocs/wp-content/plugins/
$ sudo wget http://downloads.wordpress.org/plugin/w3-total-cache.0.9.2.5.zip
$ sudo apt-get install unzip
$ sudo unzip w3-total-cache.0.9.2.5.zip
$ sudo rm w3-total-cache.*
$ sudo vim /home/wordpress/htdocs/wp-config.php
# add define('WP_CACHE', true); before require_once(ABSPATH .  'wp-settings.php');
$ sudo chmod 777 /home/wordpress/htdocs/wp-content/

Create a new S3 bucket.

Activate the plugin via the WordPress dashboard and navigate to the “Performance” tab. Adjust the settings:

• Enable page caching with Opcode (APC)
• Enable database caching with Opcode (APC)
• Enable object cache with Opcode (APC)
• Enable browser cache
• Enable CDN with Amazon S3

Click the CDN tab. Enter your S3 credentials and bucket name and save. Click the buttons and follow instructions to upload attachments, theme files, includes, and any others.

Disable preview mode. Restore proper filesystem permissions:

$ sudo chmod 755 /home/wordpress/htdocs/wp-content/

Security Precautions

These are initial security precautions. You may want to research WordPress security threats and take extra steps to protect your site. And, always, keep WordPress up to date and keep passwords safe.

Add this line to the end of wp-config.php to disable file editing from the WordPress dashboard:

define('DISALLOW_FILE_EDIT', true);

Install the Login Security Solution plugin:

$ cd /home/wordpress/htdocs/wp-content/plugins
$ sudo wget http://downloads.wordpress.org/plugin/login-security-solution.zip
$ sudo unzip login-security-solution.zip
$ sudo rm login-security-solution.zip

Activate the plugin from the WordPress dashboard.

Add the following line to wp-config.php. This is necessary if you’ll be using a load balancer—more on that below. If not, you can skip ahead.

$_SERVER['REMOTE_ADDR'] = preg_replace('/^([^,]+).*$/', '\1', $_SERVER['HTTP_X_FORWARDED_FOR']);

Load Balancing and Auto Scaling

One of the major perks of AWS is auto scaling, which lets you automatically launch new servers to handle bursts of heavy traffic, while scaling down when traffic is low. These steps show how to set up a load balancer to distribute traffic across multiple server instances and how to scale up and down.

In the EC2 console, create a new AMI from the instance you’ve been working on. Leave the instance running and note the instance’s ID. Create a load balancer and note the name. Add the instance to the load balancer group.

Enable load balancer–generated cookie stickiness for 3600 seconds. This allows user sessions to work properly when multiple server instances are running. User session data is stored on the server, and when multiple servers are handling requests, the client has to connect to the same server each time to preserve the session.

If you’re connecting a domain name to your WordPress instance, it’s best to host your DNS records with Amazon’s Route 53 service. The reason is that if you want your site to be available from the root domain (e.g., newsite.com, and not a subdomain like www.newsite.com or hello.newsite.com), you have to use Amazon’s DNS service, because of limitations in the DNS system and Amazon’s load balancing system (specifically, because Amazon requires CNAME records to point to load balancers, and the DNS system does not allow a CNAME record for the root domain). If you’re happy with sticking to a subdomain, you can host your DNS records elsewhere with no trouble.

Create a Route 53 hosted zone for your domain. For the root domain (domain.com), add a record set with type “A” and select Alias “Yes.” Point it to the load balancer A record name. Second, add a CNAME record for www.newsite.com and point it to the load balancer.

Once your DNS changes have propagated, you should be able to find your WordPress site at newsite.com or www.newsite.com.

There is no web console for Amazon’s auto scaling service, so you have to configure it from the command line. You’ll have to download and configure Amazon’s EC2 command line tools and auto scaling command line tools on your local machine.

After installing the command line tools, make sure your ~/.bash_profile (on your local machine, not the server) includes environment variables for your AWS account:

export EC2_PRIVATE_KEY=`ls ~/.aws/pk-*.pem`
export EC2_CERT=`ls ~/.aws/cert-*.pem`
export AWS_ACCESS_KEY=XXXXXXXXXXXXXXXXXXXX
export AWS_SECRET_KEY=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

The paths may vary depending on where you installed your security files. You may need to reload your configuration by running:

$ source ~/.bash_profile

The first step in configuring auto scaling is defining a “launch configuration,” which describes the instance to launch when scaling. Be sure to substitute your AMI ID and security group name.

$ as-create-launch-config MyLaunchConfig --image-id ami-XXXXXXXX --instance-type t1.micro --group {SECURITY GROUP NAME}

Next, create an auto scaling group, which contains some basic scaling rules for your setup. This configuration makes sure at least one instance runs at all times, but no more than four. You’ll probably want to play with these variables. Run $ as-create-auto-scaling-group --help for more.

$ as-create-auto-scaling-group MyScalingGroup --launch-configuration MyLaunchConfig --availability-zones us-east-1a,us-east-1b,us-east-1c,us-east-1d  --desired-capacity 1 --min-size 1 --max-size 4 --load-balancers {LOAD BALANCER NAME} --health-check-type ELB --grace-period 300

You have to define two scaling policies—one up, one down:

$ as-put-scaling-policy ScalingUpPolicy --auto-scaling-group MyScalingGroup --adjustment=1 --type ChangeInCapacity
$ as-put-scaling-policy ScalingDownPolicy --auto-scaling-group MyScalingGroup --adjustment=-1 --type ChangeInCapacity

The last step is to go to the AWS CloudWatch web console and create alarms for events that will trigger your scaling policies. This is where much of the fine tuning happens. As a starting point, try creating two alarms: (1) if the CPU utilization for your scaling group exceeds 70% for 5 minutes, scale up, and (2) if CPU drops under 20% for the same period, scale down.

To test your setup, terminate your running instance. Within a minute or two, you’ll see a new instance boot up from the AMI you defined in your launch config.

You can also test your setup by simulating real life load conditions. Start up a new Ubuntu EC2 instance and connect via SSH. Install Siege, a load testing tool that generates a given number of requests for a given duration:

$ sudo apt-get install siege

Now, launch a simulation of 20 concurrent users for 15 minutes:

$ siege -c20 -t15M  www.newsite.com

Use Amazon’s CloudWatch metrics to monitor activity on your servers. If the CPU utilization meets your threshold for the period you defined, you should see new servers deploy soon. When the test is done, they’ll gradually scale down to the minimum number of instances you specified.

Sometimes the load balancer won’t recognize the new instances. The most likely reason is that the load balancer isn’t configured to recognize instances from the instance group (us-east-1a, us-east-1b, etc.) where your new instances have been deployed. You can fix this from the EC2 load balancer web console.

Making Updates

At some point you’ll need to make changes to the code on your server. If you edit the code on the currently active instance, your changes will not appear when new instances launch, because those instance are based on the earlier AMI you created. To make your changes stick, you have to create a new AMI and reconfigure the launch configuration to use it instead of the old AMI.

Launch a new instance with your current AMI. Connect via SSH and make the changes. When you’re done, navigate to the WordPress dashboard and clear the cache from the W3 Total Cache plugin dashboard. Then, from the AWS web console, create a new AMI from this instance.

Create a new launch config:

$ as-create-launch-config MyLaunchConfig2 --image-id ami-XXXXX --instance-type t1.micro --group {SECURITY GROUP}

Update the auto scaling group to use the new launch config:

$ as-update-auto-scaling-group MyScalingGroup --launch-configuration MyLaunchConfig2

The update is done. Terminate any instances running the old AMI.

Where to Go Next

There are a few areas where you might boost security, optimization, and workflow:

• HTTPS: get an SSL certificate and enable HTTPS support.
• Extra security: explore other WordPress security plugins and techniques. You may also want to disable SSH access to your live EC2 instances.
• Enhanced caching: in particular, you might look into a separate caching server with memcached, especially if you plan to frequently run multiple instances. Varnish may also give a significant speed boost.
• Alternative HTTP servers: many sites, including WordPress.com, have benefited from switching from Apache to NGINX. Others like lighttpd and Cherokee.
• Development and staging: good web software design means building a workflow with proper development and staging servers. See, for instance, the 12 Factor App and the Pokayoke Guide to Developing Software.

Tagged: apache, web performance, aws, amazon, lamp, wordpress, dns, caching, php, auto scailng, web development, load balancing · Categorized: Programming