Deploy WordPress On Aws By First Decoupling Assets

You want to make your wordpress site bulletproof? No server outage worries? Want to make it faster & more reliable. And also host on cheaper components?

I was after all these gains & also wanted to kick the tires on some of Amazon’s latest devops offerings. So, I plotted a way forward to completely automate the deployment of my blog, hosted on wordpress.

Here’s how!

The article is divided into two parts…

Deploy A WordPress Site On Aws – Decouple Assets (Part 1)

In this one I decouple the assets from the website. What do I mean by this? By moving the db to its own server or RDS of even simpler management, it means my server can be stopped & started or terminated at will, without losing all my content. Cool.

You’ll also need to decouple your assets. Those are all the files in the uploads directory. Amazon’s S3 offering is purpose built for this use case. It also comes with easy cloudfront integration for object caching, and lifecycle management to give your files backups over time. Cool!

Terraform A WordPress Site On Aws – Automate Deploy (Part 2)

In the second part we move into all the automation pieces. We’ll use PHP’s Composer to manage dependencies. That’s fancy talk for fetching wordpress itself, and all of our plugins.

1. Get Your Content into S3

How to do it?

A. Move Your Content

$ cd html/wp-content/
$ aws s3 cp uploads s3://iheavy/wp-content/

Don’t have the aws command line tools installed?

$ yum install aws-cli -y
$ aws configure

B. Edit your .htaccess File with These Lines

These above steps handle all *existing* content. However, you also want new content to go to S3. For that, WordPress needs to understand how to put files there. Luckily there’s a plugin to help!

  RewriteEngine On
  RewriteRule ^wp-content/uploads/(.*)$ http://s3.amazonaws.com/your-bucket/wp content/uploads/$1 [P]

C. Fetch WP Offload S3 Lite

You’ll see the plugin below in our composer.json file as “amazon-s3-and-cloudfront”

Theoretically, you need to specify your aws credentials inside the wp-config.php. However, this is insecure. You don’t ever want stuff like that in S3 or any code repository. What to do?

The best way is to use AWS ROLES for your instance. These give the whole instance access to API calls without credentials. Cool! Read more about AWS roles for instances.

Related: Is there a devops talent gap?

2. Move to Your Database to RDS

You may also use a roll-your-own MySQL instance. The point here is to make it a different EC2 instance. That way you can kill & rebuild the webserver at will. This offers us some cool advantages.

A. Create an RDS Instance in a Private Subnet.

• Be sure it has no access to the outside world.
• note the root user, password
• note the endpoint or hostname

I recommend changing the password from your old instance. That way you can’t accidentally login to your old db. Well, it’s still possible, but it’s one step harder.

B. mysqldump your Current wp DB from Another Server

  $ cd /tmp
  $ mysqldump –opts wp_database > wp_database.mysql

C. Copy That Dump to an Instance in the Same Vpc & Subnet as the Rds Instance

  $ scp -i .ssh/mykey.pem [email protected]:/tmp/wp_database.mysql /tmp/

D. Import the Data Into Your New DB

  $ cd /tmp
  $ echo “create database wp_database” | mysql
  $ mysql E. Edit your wp-config.php

  define(‘DB_PASSWORD’, ‘abc123’);
  define(‘DB_HOST’, ‘my-rds.ccccjjjjuuuu.us-east-1.rds.amazonaws.com’);

Conclusion

That’s all about how to deploy a WordPress site on AWS by decoupling assets and automating deployment. In part one, we have explained how you can move your files to S3 for easy management, backup, and cache integration. In part two, you can learn about the automated deployment with Composer and how to move your database to a separate EC2 instance or RDS for increased reliability. Remember, you must avoid storing credentials in code and should use AWS roles for security.