I spent a good part of the past 24 hours trying to get a basic WordPress 4.2.2 deployment up-and-running on Elastic Beanstalk. It is part of the “homework” in preparing for the next generation of store location and directory technology I am working on . I must say that even for a tech geek that loves this sort of thing, it was a chore. This article is my “crib sheet” for the next time around. Hopefully I don’t miss anything important as I wasted hours chasing my own rear-end trying to get some things to work.
I used the Deploying WordPress with AWS Elastic Beanstalk fairly extensively for this process. It is easy to miss steps and is not completely up-to-date with the screen shots and information which makes some of it hard to follow the first time through. I will try to highlight the differences here when I catch them.
The steps here will get a BASIC non-scalable WordPress installation onto AWS. Part 2 will make this a scalable instance. If my assumptions are correct, which happens from time-to-time, I can later use command-line tools with git on my local dev box to push updated applications out the the server stack. If that works it will be Part 3 of the series on WP ELB Deployment.
Getting Started
The “shopping list” for getting started using my methodology. Some of these you can change to suit your needs, especially the “local dev” parts. Don’t go setting all of this up yet, some things need to be setup a specific way. This is just the general list of what you will be getting into. In addition to this list you will need lots and lots of patience. It may help to be bald; if not you will lose some hair during the process.
Part 1 : Installation
A local virtual machine. I use VirtualBox.
A clean install of the latest WordPress code on that box, no need to run the setup, just the software install.
An AWS account.
A “WP Deployment” specific AWS user that has IAM rules to secure your deployment.
AWS Elastic Beanstalk to manage the AWS Elastic Load Balancer and EC2 instances.
Part 2 : Scalability
AWS S3 bucket for storing static shared content (CSS rules, images, etc.)
AWS Elasticache for setting up Memcache for improved database performance.
AWS Cloudfront to improve the delivery of content across your front-end WordPress nodes.
AWS RDS to share the main WordPress data between your Elastic Beanstalk nodes.
Creating The “Application”
The first step is to create the web application. In this case, WordPress.
I recommend creating a self-contained environment versus installing locally on your machine, but whatever you’re comfortable with. I like to use VirtualBox , sometimes paired with Vagrant if I want to distribute the box to others, with a CentOS GUI development environment. Any flavor of OS will work as the application building is really just hacking some of the WordPress config files and creating an “environment variables” directory for AWS inside a standard WP install.
Got your box booted? Great!
Fetch the latest download of WordPress.
Install it locally.
Remove wp-config-sample.php.
Create a new wp-config.php that looks like this:
Do not move this wp-config.php file out of the root directory. It is a common security practice but it will be missing from your AWS deployment. There are probably ways to secure this by changing your target destination when setting up AWS Cloufront, but that is beyond the scope of this article.
Settings like the $_SERVER[‘RDS_USERNAME’] will come from the AWS Elastic Beanstalk environment you will create later. This is set dynamically by AWS when you attach the RDS instance to the application environment. This ensures the persistent data for WordPress, things like your dynamic site content including pages, posts, users, order information, etc. is shared on a single highly-reliable database server and each new node in your scalable app pulls from the same data set.
Settings for the “Salt” come from a YAML-style config file you will add next. This is bundled with the WordPress “source” for the application to ensure the salts are the same across each node of your WordPress deployment. This ensures consistency when your web app scales, firing up server number 3, 4, and 5 while under load.
Create a directory in the root WordPress folder named .ebextensions.
Fetch new salts from WordPress.
Create a new file named keys.conf in the .ebextensions directory that looks like this, but using YOUR salts:
Zip up your application to make it ready for deployment.
Do NOT start from the parent directory. The zip should start from the WordPress root directory. On Linux I used the this command from the main WordPress directory where wp-config.php lives:
zip -r ../wordpress-site-for-elb.zip .
Create The Elastic Beanstalk Environment
Login to the AWS Console.
Go to Elastic Beanstalk.
Go to ELB Create New Application.
Select Create Web Server.
Select the default permissions (I didn’t have a choice here).
Set the Environment to PHP and Load Balancing, auto scaling.
Upload your .zip file you created above as the source for the application.
Leave Deployment Limits at their defaults.
As a side note, this will create an application that you can later user for other environments, making it easy to launch new sites with their own RDS and Cloudfront settings but using the same WordPress setup.
Set your new Environment Name.
If your application name was unique you can use the default.
If your application name is “WordPress” it is likely in use on ELB, try something more unique.
Tell ELB to create an RDS instance for you.
I chose not to put his in a VPC, which is the default.
The guide I linked to above, shows a non-VPC, but then gives instructions on a VPC deployment. This caused issues.
Some instance sizes for both RDS and the EC2 instance ELB creates will ONLY run in a VPC (anything with a “t” level).
You will need to choose the larger “m-size” instances for RDS and EC2 otherwise the ELB setup will fail after 15-20 minutes of “spinning its wheels”.
Set your configuration details.
Choose an instance type of m*, I chose m3.medium the first time around, but m1.small should suffice for a small WP site.
Select an EC2 key pair to be able to connect with SSH. If you did not create one on your MAIN AWS login, got the the IAM panel and do that now. Save the private key on your local ox and make a backup of it.
The email address is not required, I like to know if the environment changed especially if I did not change it.
Set the application health check URL to
HTTP:80/readme.html
Uncheck rolling updates.
Defaults for the rest will work.
You can set some tags for the environment, but it is not necessary. Supposedly they help in reporting on account usage, but I’m not that far along yet.
Setup your RDS instance.
Again, choose an m* instance as the t* instances will not boot unless you are in a VPC.
If you choose the wrong instance ELB will “sit and spin” for something that seems to be a decade, before booting to “gray state” which is AWS terminology for half-ass and useless.
If you cannot tell, this was the most frustrating part of the setup as I tried SEVERAL different instance classes. Each time the ELB would hang and then take forever to delete.
Enter your DB username and password.
They will be auto-configured by the wp-config.php hack you made earlier.I do recommend, however, saving these somewhere in case you need to connect to MySQL remotely. I hosed my host and siteurl and needed to go to my local dev box, fire up MySQL command line, and update the wp_options table after I booted my application in ELB. Having the username/password for the DB is helpful for that type of thing.
Review your settings, launch and wait.
Reviewing ELB Settings
When you are done your Elastic Beanstalk should look something like this:
Useful Resources
Deploying WordPress with AWS Elastic Beanstalk – single or multiple zone, fully scalable, cached.
Deploying a WP install with git on ELB – single zone and may not scale.