WordPress is an open-source CMS originally built as a web publishing platform, quickly becoming a de-facto standard for blogs. Thanks to its huge third-party plugin ecosystem, WordPress has been adopted for use in many different situations never imagined by its creators, including dynamic websites, e-commerce platforms, and online newspapers. It's a terrific software package with a huge user base, but getting the most out of it can be tricky.
This course demonstrates installing and running WordPress on Amazon Web Services. Expert Linux System Administrator David Clinton will guide you through installation, from the easy way (using a Cloudformation template), up to deploying a highly customizable instance on EC2 and RDS. You will learn to use optimization tools like Varnish and Route53 and to monitor availability and costs with CloudWatch.
If you have thoughts or suggestions for this course, please contact Cloud Academy at firstname.lastname@example.org.
This is an intermediate course that will assume some basic knowledge of the AWS system. Some familiarity with the Linux Command Line Interface and MySQL might also be helpful.To move to the next step, check out our EC2 and RDS courses, and our introductory AWS video. You might also enjoy our courses on CloudFormation, LAMP stacks on AWS and Security on Linux based AWS instances, which make great follow-ups. If you want to challenge yourself, check out our questions.
Hi and welcome to CloudAcademy.com's video series on hosting your WordPress site in the cloud on AWS.
In this video, we'll learn how to offload your WordPress database function to the AWS RDS service, to allow you to scale up and meet the demands of your millions of users. Amazon RDS provides enormous flexibility and reliable access, while automatically keeping your database software patched and your data securely backed up. The first thing we'll have to do is create a new group and user in IM.
We'll first click on groups, create a new group. Let's call it administration. Click on next step. Let's give this group administrator access. So we'll select administrator access. Next step, review and create the group. Now let's create a new user. Let's call this user Ubuntu.
Just happens to match the name we have given the owner of the database we'll be using in our EC2 instance. Create. Let's close. Let's create a password for this new user, Ubuntu, assign a custom password, and let's assign a custom password. Apply. Now let's add our user to a group, and I'll bet you can guess which group we'd like to add him to, the administration group. We see that he is currently in administration, and we could remove him from that group if we so desire. But he just got there. There's no reason to throw him out just yet.
Now let's go create an RDS instance. Let's get started now. We'll select an engine. In our case, that obviously is going to be MySQL, because that's the database powering our WordPress instance. We, in our case, don't want to use multi AZ deployment or provisioned IOPs storage.
Both of those can be critically important. Multi A to Z deployment allows for redundant backups in case one server goes down somewhere, there's another one that'll have your data and be able to provide it to internet users. And provisioned IOPs storage can really speed up access to the database. But for our purposes, that's absolutely not necessary.
So let's go onto next. The engine is MySQL, regular license. The version of MySQL we want to use is the latest. It's fine for us. DB instance class, we'll go with the smallest one available. Multi AZ deployment, we'll say no. Allocate to storage has to be at least five gigabytes, and that's more than enough for us.
Provisioned IOPs, we'll say no. The DB instance identifier, let's call it WordPress-DB. The same happens to be the same name as our WordPress database, but it doesn't have to be. Master username, we'll go with Ubuntu and we'll enter our password twice, and move on to the next step. This is our VPC, our virtual private cloud. It's good to remember that. Our subnet group is subnet-WP. Is it publicly accessible? No, we don't want this to be publicly accessible. We want this to be accessible only to our instance. The availability zone, we would like to be in US-East-1a, because that matches the zone where our EC2 instance, which serves WordPress actually lives. The VPC security group, we'll stick with the default.
Our database name, we're not going to enter right now. We're going to do that from the command line in our EC2 instance later. That seems to be everything we need. We'll find out in a minute if it was, because if there's anything that we've left our, the web interface will catch us on it. Seems that everything was done properly. It'll take a few minutes for that to complete. But for now, we're where we want to be. While the RDS instance is still launching, let's take a look at some of its configuration. At this point there's still no end point available, because the RDS isn't actually running yet. However, let's take a look at security groups. There is one security group that exists. Let's highlight it.
It's the EC2 security group and it's called default. It's authorized, we have already authorized it. And it is the security group that this RDS instance will use. Let's go back to the RDS dashboard to see if our RDS instance has completed. It hasn't quite completed, as you can see these little circles running around in circles, getting themselves dizzy. But at least we have an endpoint. Let's highlight the endpoint and copy it, because we're going to use it pretty quickly. Now we'll copy or dump the WordPress database on our EC2 instance, up to our RDS instance, using MySQL dump. MySQL Dump-U, Ubuntu is our user name, -P, so it's going to prompt for a password. Then we specify databases will be WordPressDB. We pipe that, we pipe the dump of WordPress DB to the host, that is the end point that Amazon RDS has given us, using port 3306, specifying that we'll be using the user, Ubuntu. The user on the RDS instance is also named Ubuntu. Doesn't have to be, but it was. And I'm using our ultra secret, very high password, actually password.
Hit enter. We are prompted for our local password. And everything seems to have worked. Now, let's update our wp-config.php file to reflect the new location of our database. Sudo nano wp-config.php. We will scroll down 'til we get to define DB host. No longer is it local host. It is now the end point which was given to us by AWS, which in this case, is Mydbinstance etc, etc, :3306.
That's the port we are going to use. It's the default MySQL port. Let's control X, Y to overwrite and save this file, enter to finish it. And let's see if that still works. Let's send our browser to our WordPress site to see if it still works.
We have a blog, and even a blog entry, which includes a hello from Cloud Academy. It seems everything is up and running, just the way it should.
David taught high school for twenty years, worked as a Linux system administrator for five years, and has been writing since he could hold a crayon between his fingers. His childhood bedroom wall has since been repainted.
Having worked directly with all kinds of technology, David derives great pleasure from completing projects that draw on as many tools from his toolkit as possible.
Besides being a Linux system administrator with a strong focus on virtualization and security tools, David writes technical documentation and user guides, and creates technology training videos.
His favorite technology tool is the one that should be just about ready for release tomorrow. Or Thursday.