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.
Join 28,000 others and follow Sean Hull on twitter @hullsean.
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 it’s 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 !
Deploy a wordpress site on aws — automate (part 2)
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!
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.
o Be sure it has no access to the outside world.
o note the root user, password
o 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 firstname.lastname@example.org:/tmp/wp_database.mysql /tmp/
D. import the data into your new db
$ cd /tmp
$ echo “create database wp_database” | mysql
$ mysql < wp_database.mysql E. Edit your wp-config.php
Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters
Originally published at Scalable Startups.