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 email@example.com.
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 running your WordPress site in the cloud on AWS.
In this video, we'll explore managing and optimizing your DNS, that is Domain Name Server access. If you created your WordPress site on an AWS EC2 instance, it was by default, given a dynamic IP address. Of course, if you want your users to have regular and reliable access to your site, you'll have to at least have a permanent, or a static IP address, an address that won't necessarily change every time you reboot the server. To do that, you might want to purchase an elastic IP, that will be an IP address that is reliably available, and points all the time to your server and nowhere else.
But that's obviously not your ultimate goal. Really, you'd like a human readable URL, a Uniform Resource Locator, like Google.com or CloudAcademy.com that your users can remember and type easily and find.
To do that, you can of course register a domain. AWS has a resource for doing that. It's called Route53. Route53 has three facilities, DNS management that allows you to create sub domains and redirect traffic between domains. Health Check, which monitors the health and performance of your application and Domain Registration, which is what we're interested in now.
Let's register a domain. Let's think of a good name for a new domain. How about CloudAcademy? I think that's free. We'll go with CloudAcademy.com. Obviously, we can choose many other domains, but let's stick to .com. I think that's the one that will work the nicest. We should check to make sure it's not currently being used.
Oh, it looks like somebody else got there first. I can't imagine who that might be. So, that won't work. Let's, however, try CloudAcademy2.com, and hope I'm not giving anybody ideas, but it's available. Once we've purchased our domain, we can now manage it using DNS Management. Let's create a hosted zone. Create hosted zone.
Let's enter our new domain name CloudAcademy2.com. You might want to add an identifying comment and create. Now, you'll need to enter registration data with your domain registrar before any requests can be routed to our new zone.
Now let's go to record sets, and click on create record set. Let's use, say, my data. This sub-domain will be MyData.
CloudAcademy2.com. We now have to give that a value. In other words, data at which location will be served to anybody who points his browser to MyData.
CloudAcademy2.com. Well, let's just make up a URL, 126.96.36.199, let's say. Let's hit create, and we now have a new record set.
Of course, at some point, we will have to make sure that this 188.8.131.52 address is a permanent address and not a dynamic address that may disappear the next time an EC2 instance happens to be restarted.
So you'll have to, for instance, create an elastic IP address and associate it with this instance. Now a service that AWS offers that is closely related to domain management is CloudFront. CloudFront allows you to create a distribution that will serve specified data from the most geographically available location. We know that Amazon has servers all over the world. If you have a user coming to your website asking for a video, or large graphic images, or some other resource-heavy database function, or something like that, it would be efficient if you could deliver that asset from a server much closer to him geographically. By creating a distribution, CloudFront can do that. If you're looking for a web-based delivery method, as we might, we'll be required to fill out this configuration page. First, we'll tell CloudFront where our data is going to be located. Do we intend to use CloudFront to serve data from an existing website; perhaps an AWS EC3 instance, or maybe some other data source. By clicking in the box, we'll be shown all the data sources that already exist on our account that might be useful. Let's choose an S3 bucket as our data source. Origin ID is a comment, really, we can make to identify it in later menus and from lists of data sources that could be useful. It's always a good idea to add some clearly defining information to any ID value. Will we allow users to access this data directly from an S3 URL, or do they have to come through the CloudFront URL? We can select either yes. If we select yes, we will either have to create a new identity or select an existing identity.
Either way, we'll have to update the permissions on this bucket. We can choose to do this, right now automatically through this configuration, or choose to do it manually later on our own. Let's, however, leave it as unrestricted for now.
Let's scroll down a little bit. What type of browsers or protocols will we allow to view our data? HTTP and HTTPS, that is, Port 80 and Port 443, either secure HTTP or unsecured HTTP or do we want HTTPS only, only secured browsers. Or, any unsecured browser will be redirected to HTTPS? Choice again, is ours. Cache control determines how long CloudFront will continue serving a cached version of an object before it goes back and replaces it with an updated object. This can either be controlled through cache headers or you can choose to customize it, creating a minimum time to live, measured in seconds.
So let's say you would say 600 seconds, which of course is 10 minutes, is the minimum time to live. We would never bypass the cached versions of the objects in less than 10 minutes. You could do that, or again, you could leave it up to the configuration of the cache headers.
Restricting viewer access, would force users to access the data, the objects, only using signed URLs. Now distribution settings. Obviously, the most expensive class of distribution you can have would use all edge locations.
That is, every server, every AWS server everywhere in the world, will be put to use serving your CloudFront objects. But that takes up more resources from Amazon, and obviously, they're going to charge us for the difference. We could restrict access only to US and Europe servers, or only to US, Europe and Asia servers. It largely depends on how much money we have to spend and where our users are likely to come from. Alternate domain names, or C names, allows access not only through a CloudFront domain, but also through any of our own domains, assuming that we update the record of our own domain names to point them towards the CloudFront location. So for instance, we might have created a subdomain MyData@CloudAcademy2.com, and we might like any users who access MyData@CloudAcademy2.com to be redirected to the contents of this CloudFront distribution. SSL certificates and other security details must be dealt with.
Default root object. When a user requests a resource from the root of the CloudFront distribution rather than from the specific address or URL of an object. Let's say, the request is made to MyData.
CloudAcademy2.com rather than MyData. CloudAcademy2.com/data. What object should be served? You can define, let's say, a file called index.html to be the first object that is provided in response to this request. This means that you could actually use an S3 bucket that is distributed through CloudFront as a static website. You could create a web page called index.html, which would contain links to other objects, both in this CloudFront distribution, or anywhere else on the web. And, in fact, it would work assuming, again, that this is a static website. It doesn't have to be index.html. It could be any object, but here is where you define what the default route object would be for a request for the route of this CloudFront distribution.
Should this distribution log or not? If it does log, you'll have to define a bucket for logs. So you could choose from the S3 buckets that currently exist on your account, a log prefix, just to clarify what the log is MyData/ perhaps, which would become the prefix of all logged data. You can log cookies, or not log cookies and leave a comment. The distribution state will either be enabled or disabled. Of course if it's disabled, nothing will work.
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.