{"id":3431,"date":"2021-08-20T13:59:00","date_gmt":"2021-08-20T11:59:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=3431"},"modified":"2021-08-20T13:19:04","modified_gmt":"2021-08-20T11:19:04","slug":"deploying-a-wordpress-site-to-the-aws-cloud-like-a-pro-our-guide-for-painless-maintenance-using-docker-and-aws-managed-services","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/deploying-a-wordpress-site-to-the-aws-cloud-like-a-pro-our-guide-for-painless-maintenance-using-docker-and-aws-managed-services\/","title":{"rendered":"Deploying a WordPress site to the AWS Cloud like a pro: our guide for painless maintenance using Docker and AWS Managed Services."},"content":{"rendered":"\n
WordPress is the easiest way to manage and create content. Its flexibility is loved by authors: with a couple of plugins you can do everything from hosting a cute kittens photo gallery to hosting an e-commerce site.<\/p>\n\n\n\n
Let\u2019s face it: seen from the IT guy point of view, WordPress is a technical nightmare. When someone has to deal with it the horror begins: scalability is challenging, installation isn\u2019t scripted and a LAMP stack is not always easy to maintain.<\/p>\n\n\n\n
In this article we\u2019ll give you some technical hints and examples to ease your relationship with WordPress in a cloud environment based on AWS. <\/p>\n\n\n\n
We’ll try to use as many AWS managed services as we can to be able to offload boring and dangerous tasks.<\/p>\n\n\n\n
We want our database to be highly available and scalable, so obviously we\u2019ll use Amazon Aurora with MySQL compatibility. <\/p>\n\n\n\n
With Amazon Aurora we don\u2019t have to worry about space usage because the underlying storage can automatically scale when needed. In addition, with point-in-time recovery you can restore your data with the granularity of a second.<\/p>\n\n\n\n
You can also use Multi-AZ configurations with read replicas that can take over in case of an Availability Zone failure. <\/p>\n\n\n\n
AWS will automatically assign a reader endpoint and a writer endpoint (with a DNS record) when you create an Amazon Aurora Cluster instance. <\/p>\n\n\n\n
In case of a failure (or maintenance) the read replica will be automatically promoted to become the writer and the endpoint will be automatically updated: simply configure your wp-config.php file with the writer endpoint and AWS will do all the work for you. Instead, if you are starting small and don\u2019t know how and when your site will need to scale, Aurora Serverless is the best choice for you: it has the ability to scale the compute layer and to \u201cpause\u201d if your website isn\u2019t accessed, so you can also save money !<\/p>\n\n\n\n We want to take advantage of the elasticity of the cloud, so using EC2 and Autoscaling Groups can be the natural choice.Also, we can go further and use Docker containers with an ECS Fargate cluster with a little bit of application refactoring. <\/p>\n\n\n\n Using containers reduces maintenance activities for operating systems updates and makes scaling more easily. As a bonus point we can also automate the deployment workflow using pipelines.<\/p>\n\n\n\n
If you know that your database will be stressed by a lot of read traffic you can add up to 15 read replicas to a single Aurora Cluster but you\u2019ll need to tell WordPress to use them. In this case, you can take advantage of the hyperdb plugin<\/a>: with hyperdb you can define as many database read replicas as you want in your configuration file and use them. The example configuration file<\/a> is well documented; here\u2019s an example configuration:<\/p>\n\n\n\nwpdb->add_database(array(\n 'host'\t=> mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com,\n 'user'\t=> DB_USER,\n 'password'\t=> DB_PASSWORD,\n 'name' \t=> DB_NAME,\n));\n\n$wpdb->add_database(array(\n 'host' \t=> mydbcluster.cluster-ro-123456789012.us-east-1.rds.amazonaws.com,\n 'user'\t=> DB_USER,\n 'password'\t=> DB_PASSWORD,\n 'name'\t=> DB_NAME,\n 'write'\t=> 0,\n 'read'\t=> 1,\n));<\/code><\/pre>\n\n\n\n
Compute<\/h2>\n\n\n\n