Decoupling my WordPress Architecture:
In a previous post I described the creation of this site in AWS. Now is the time to decouple the infrastructure and remove the reliance on the previously created EC2 instance.
By default WordPress is storing data in two different ways, often locally on the same VM/instances.
- MySQL database: articles, comments, users and parts of the configuration are stored in a MySQL database, I’m already using an RDS managed MySQL database here to avail of the benefits that brings.
- File system: media files uploaded are stored on the file system, in my case under /var/www/html/wp-content. This means if the EC2 instance is terminated that data is lost.
The Aim:
- To create an ephemeral, stateless instance, outsourcing content to S3 and EFS.
- Create an Auto Scaling group, with a launch template to scale in/out a fleet of instances, in my case, to stick to the free tier, I will set a maximum capacity of 1.
EFS: Elastic File System:
Amazon EFS provides scalable file storage for use with Amazon EC2 and I will use it for my wp-content folder. I also have some images stored in S3. Like S3 EFS has resiliency across Availability Zones. With Amazon EFS, you do pay for the resources that you use, but my footprint is very low and I do not expect any charges over a few cents.
To use EFS I:
- Created a new EFS file system and mounted as /efs/wp-content
- Copied the contents of /var/www/html/wp-content to the temporary mount
- Unmounted the EFS and remounted in /var/www/html/wp-content, making the mount persistent by updating /etc/fstab
- Check the website and the WordPress Update functionality.
Auto Scaling:
An Auto Scaling group contains a collection of Amazon EC2 instances that are treated as a logical grouping for the purposes of automatic scaling and management. An Auto Scaling group also enables you to use Amazon EC2 Auto Scaling features such as health check replacements and scaling policies.
Here I:
- Created a new AMI from my original EC2 instance
- Created a Launch Template (LT) containing the configuration information to launch new instances, including passing specific launch commands in the user data section.
- Tested new instances by updating the ELB targets
- After successfully testing, I terminated my previous instances, created a new ASG and updated the ELB targets.
Wrap Up:
My environment is much more resilient now with no dependency on a single EC2 instance, high-availability has been introduced at all levels, although to keep to the free tier, my RDS DB instance is not Multi-AZ. Next I’ll tear everything down and redeploy with CloudFormation.