AWS Data Management
AWS Solutions Architect Associate Level Certification Course - Part 3 of 3
Having completed parts one and two of our AWS certification series, you should now be familiar with basic AWS services and some of the workings of AWS networking. This final course in our three-part certification exam preparation series focuses on data management and application and services deployment.
Who should take this course?
This is an advanced course that's aimed at people who already have some experience with AWS and a familiarity with the general principles of architecting cloud solutions.
Where will you go from here?
The self-testing quizzes of the AWS Solutions Architect Associate Level prep materialis a great follow up to this series...and a pretty good indicator of your readiness to take the AWS exam. Also, since you're studying for the AWS certification, check out our AWS Certifications Study Guide on our blog.
For the final video of our AWS solutions architect certification exam series, we'll create a highly available, fault tolerant WordPress blog with a twist. We'll use a pre-existing locally hosted WordPress install and migrate it along with its MySQL database to our AWS deployment. To do all that, we'll need to work with two availability zones within a VPC, create an instance image of our working migrated WordPress install, create an AMI from that image and launch it within an auto scaling group, giving each instance access to a multi AZ RDS MySQL database. And all sitting behind a load balancer, serving web traffic evenly to any instances that user demand requires to be running. But we'll start by creating a highly available RDS MySQL instance. We'll use our account's default VPC and VPC subnets in a way that will spread our data across multiple availability zones, known as multi AZ. First though, to illustrate what we're going to do, we'll use this image that you might remember from a previous video. The VPC will have two availability zones, enclosed by dotted line rectangles.
Each one, using a different subnet. Each of our two database instances is hosted in a different availability zone, so that even if one should ever go down, the second will still be available to us. The security group attached to each MySQL instance is connected only to the security groups of our web application servers, and not to the routing table that heads out to the internet. This is because for security considerations, we don't want there to be any inbound internet traffic reaching our databases. Now let's get to work. After confirming that we're in the correct AWS region, we'll create a DB subnet group.
From the RDS dashboard, click on subnet groups, then on create subnet group. We'll give our group the name, MySQL group, and the description. We'll select our default VPC, the only choice right now, and then add two subnets. One in each of two availability zones. First, we'll select US East 1A, and click to drop down the subnet menu. There's only one subnet available in this zone, so we'll use it. Clicking add, we'll assign the subnet to our group. Now let's do the same thing with availability zone, US East 1B and its subnet, clicking add again. Now let's create our DB instance. Click on instances and then launch DB instance. We'll select MySQL.
We'll say yes to be given the option of multi AZ deployment and provisioned IOPS storage and click next step. We'll stick with the default MySQL release version.
We'll select a DBT2 micro as our instance, but naturally, most projects would require something a bit more powerful. We'll say yes to multi AZ and leave the storage options as default. These configurations can be easily scaled upwards later, should it be necessary. We'll use WPDB, standing for WordPress database as our DB identifier. We'll choose admin as a master user name and enter a complicated password that's at least eight characters long.
We'll now assign our DB to our default VPC. We'll select the MySQL subnet group and leave the instance privacy setting as not publicly available. Now what about a security group? We'll need to open up access to our EC2 application servers within our availability zones that will be running WordPress, so we'll be best off with a new security group made especially for this instance. We can give the database a name if we like, but we'll actually be creating a new WordPress database later, so it makes little difference. Leave the port and parameter option groups as default. We'll leave the timing for automatic data backup and minor version upgrades as they are. Finally, click launch DB and we're done. After a few minutes, once the instance set up is complete, we'll find our inpoint address displayed in the RDS dashboard. We've SSHed into our EC2 instance, so we can build WordPress the way we like it. First, we'll update the repositories, using pseudo apt get update. Then we'll run task sel, using pseudo. Task sel stands for task select, to install the software we'll need for a full lamp server with MySQL.
Not that we'll be using our local MySQL installation to serve WordPress, but because we'll need to use it as a client to access our RDS based MySQL. Using the arrow keys, we can move down among the choices, hitting the space bar to select or deselect an item. Tab and enter will finalize our choices. Let's take a quick look at the RDS dashboard to remind ourselves of our database settings. First of all, note the end point. Although we won't be using the port number in any of our connection. Don't forget our DB name and username. We're soon going to use all that information. Just to make sure we're connected, you can log into RDS MySQL instance using MySQL, where the value of H is our RDS endpoint, and providing the password we created earlier, while in the RDS launch wizard. Now from our home directory, home/ubuntu in our case, or from whatever space we'd like to use to unpack WordPress, run WGet to download the latest version of WordPress. Unpack the WordPress package using tar, and run LS to get a view of the folder's current contents. Latest doctar.gz is the WordPress package, and WordPress is the new directory into which everything has been unpacked. Then copy wpconfigsample.php to wpconfig.php as WordPress looks to wpconfig.php for its configuration details. We'll use the text editor nano to work on wpconfig.php.
We'll edit the DB name value to read WordPress DB. And the DB user value to admin. I'll enter the password, which only because this is a very temporary deployment and because it will appear on this video, will be the word password, the very worst password you can use. Next, we'll enter our RDS endpoint for the DB host value.
Finally, we've got some keys and SQLs from the WordPress website, mentioned in the notes to this config file, and we'll paste them here. Using control K, we'll remove the sample lines. That's it.
Control X will exit and save. Now that our configuration is done, we can copy the whole WordPress install directory with its sub directories to the var/www/html directory that's currently served to the internet by Apache. We'll need to use pseudo, because the target directory is owned by root. Then we'll disable Apache's index.html file so users won't land there, but will be forced to access our WordPress files. In the next video, we'll create an uploaded dump of our local MySQL WordPress database and finish configuring our deployment.
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.