Welcome back and in this advanced demo lesson you're going to get the chance to experience how to do a practical architecture evolution. Now one of the things that I find very common amongst my students is that they complete the certification and as soon as they get their first job interview, many of them which have an architectural scenario component, they struggle on how to get started, how to design an architecture for a given scenario. So in this advanced demo series you're going to step through and evolve an architecture yourself. So you'll start with a single EC2 instance running the WordPress blogging engine and this single instance will be running the application itself, the database, and it will be storing the content for all of the blog posts. And for this example we're going to assume it's an animal pictures blog. Now crucially in this first stage you're going to build this server manually to experience all of the different components that need to operate to produce this web application. Once you've built the instance manually, next you'll replicate the process but using a launch template to provide automatic provisioning of this WordPress application. But crucially it will still be the one single WordPress instance. Next you'll perform a database migration moving the MySQL database off the EC2 instance and running it on a dedicated RDS instance. So now the database, the data of this application, will exist outside the lifecycle of the EC2 instance and this is the first step of moving towards a fully elastic scalable architecture. Next, once you've migrated the database, instead of storing the content locally on the EC2 instance, you'll provision the elastic file system or EFS, which provides a network-based resilient shared file system and you'll migrate all of the content for the WordPress application from the instance to this elastic file system. Once done these are all the components required to move this architecture to be fully elastic and that is being able to scale out or in based on load on that system. So the next step will be to move away from your customers connecting directly to the single EC2 instance. Instead you'll provision an auto scaling group which will allow instances to scale out or in as required and you'll configure an elastic load balancer to point at that auto scaling group. So your customers will connect in via the application load balancer rather than connecting to the instances directly and this will abstract your customers away from the instances. It will allow your system to be fully resilient, self-healing and fully elastically scalable. So by completing this advanced demo lesson you'll learn how to get started with scenario based questions as part of job interviews. With that being said let's go ahead and get started and to do that we need to move to the AWS console. To get started you're going to need to be logged into a full AWS account without any restrictions. You should be logged in as an admin user. If you're watching this demo as part of any of my courses then you need to use the General AWS account, so that's the management account of the AWS organisation which we've set up in the course, and as always please make sure that you've selected the Northern Virginia region. Now attached to this lesson are two links, one of them is a one-click provision for the base infrastructure of this advanced demo lesson, and the other is a link to the GitHub repository which contains text-based instructions for every stage of this advanced demo. So to start with go ahead and click on the one-click provisioning link. This is going to take you to the quick create stack page and everything should be pre-populated. The stack name should say A4LVPC. All you need to do is check this acknowledgement box and then go ahead and click on create stack. Now you'll need to wait for this stack to move from create in progress to create complete before you can continue with the demo so go ahead and pause the video and you can resume it once this stack is in a create complete state. So now this stacks moved into the create complete state the first stage of this advanced demo series is to manually create a single instance WordPress deployment. Now this CloudFormation template has created the architecture that you can see on screen now so the VPC together with the three tier architecture so database, application and public split across three different availability zones. So what you're going to do in this first part of this demo series is to create this single EC2 instance and you're going to do it manually so that you can experience all of the associated limitations. So make sure that you do have the text-based instructions open and the link for those is attached to this lesson because it will make it easier because you can copy and paste any commands or any configuration items. The first thing to do though is to click on services and then type EC2 into the services drop-down and click on EC2 to move to the EC2 console. We're going to be launching our WordPress instance so what I need you to do is to click on launch instance and then again on launch instance. Now you should be fairly familiar with creating an EC2 instance so we're going to go through this part relatively quickly. So So first you need to name the EC2 instance so go ahead and enter WordPress-Manual in the name box and then scroll down and select Amazon Linux specifically Amazon Linux 2023 and just make sure that it's shown as free tier eligible. Additionally make sure that it says 64bit x86. Once set scroll down again and go to the instance type box. Click in the drop down and just make sure that you have a free tier eligible instance selected. For most people this should be t2.micro but just make sure that it's an equivalent sized instance which is under the free tier. Continue scrolling down and under the key pair box just click in the drop down and select proceed without a key pair because we won't be connecting to this instance using an SSH key we'll be using a session manager. Once selected scroll down further still and click on edit next to network settings. In the VPC box make sure that A4L VPC is selected. This is the Animals for Life VPC created by the one-click deployment. Then under subnet make sure that SN-PUB-A is selected. This is the public subnet in availability zone A. Below this make sure that for both auto-assign public IP and/or to assign IPv6 IP both of these need to be set to enable. Once done scroll down again and next to firewall security groups check the box to say to select an existing security group and then in the drop-down make sure that you pick A4LVPC-SG WordPress. Now this will be followed by some randomness and that's okay just make sure that it's the SG-WordPress security group. This will allow us to connect into this instance using TCP port 80 which is HTTP. Once selected scroll down and we won't be making any changes to the storage. We'll be using the default of H GIB of GP3 storage. Below this expand advanced details and there are a couple of things that we need to change. First click on the drop down under IAM instance profile and just make sure that you select the the A4LVPC-WordPress instance profile. And again, this will have some randomness after it, and that's okay. Scroll down, and next you're looking for a box which says 'Credit Specification'. Now for this, my preference is that you select 'Unlimited', because this will make the performance of the EC2 instance potentially better than not selecting anything at all or selecting 'Standard'. Now on brand new AWS accounts, it's relatively common that you can't select unlimited. AWS don't allow you generally to select unlimited until the account has a billing history. So you might want to select standard here to avoid any problems. I'm going to select unlimited because my account allows it, but if you've got a new AWS account, then go ahead and select standard. If you do choose to select unlimited and you do receive an error, then you can go ahead and repeat this process but select standard. So go ahead and select standard in your case and then scroll down and that's everything that we need to set at this point everything else looks good so go ahead and click on launch instance. So now that our instance is provisioning just go ahead and click on instances at the top and that will allow us to monitor the progress. Now we'll need this to be in a running state before we perform the WordPress installation, but there's one more set of steps that I want to do first. Now, throughout this advanced demo lesson, we're going to be taking this single instance WordPress application and moving it towards a fully scalable or an elastically scalable design. Now to do that, we need to move away from statically setting any configuration options. So we're going to make use of the parameter store, which is part of systems manager, and we're going to create some parameters that are automatic build processes later in this demo will utilize. For now we're going to be performing everything manually but we'll still be using these variables because it will simplify what we have to type in the EC2 instance. So go ahead and click on services, start typing systems manager and then once you see it populated in the list you can right-click and open that in a new tab. Once you're at the systems manager console on the left under application management just locate parameter store and click it to move to the parameter store console and we're going to create a number of parameters. Now if you're watching this demo as part of my courses you may already have some parameters listed on this screen. If you have any existing ones which begin with /a4l then go ahead and delete them before continuing. So go ahead and click on create parameter and the exact naming for each of these is in the full instructions contained on the GitHub repository which is attached to this lesson so make sure you've got that open it'll make it significantly easier and less prone to errors. We're going to create a number of parameters for WordPress and the first is the database username so the username that will have permissions on the WordPress database so I want you to set the name to /a4l/wordpress/dbuser For description WordPress database user you can set the tier for the parameter to standard or advanced. To keep things in the free tier we're going to use standard. It's going to be a string parameter. The data type is going to be text and the value needs to be our actual database username. So for this demonstration we're going to use A4L WordPress user. So enter that and click on create parameter. Now we're going to be moving quicker now, now that you've seen the process. Our next parameter is going to be the database name so enter this in the name field for description WordPress database name again standard string data type of text and the value is going to be the WordPress database name so a4l WordPress DB scroll down and click on create parameter next is going to be the database endpoint so the hostname that WordPress will connect to so for name enter this a4l WordPress DB endpoint for description wordpress endpoint name again standard string text for data type and then to start with because the database is on the same instance as the application the value will be localhost so enter that and go ahead and click on create parameter next we'll be creating a parameter to store the password of the wordpress user so click on create parameter this time it's a4l WordPress DB password. For description, WordPress DB password. Again, standard tier, but this time it's going to be a secure string. For KMS key source, use current account and then for KMS key ID it will be alias AWS SSM which is the default KMS key for this service. For value, go ahead and enter a strong password. Again, this is for the WordPress user that has permissions to access the database so if this were production it would need to be a strong password. Now I recommend that you use the same password as I'm using in this demo. It uses number letter substitution and I know that it works with all of the different system components. Now I've included this password in the text-based instructions and I do recommend that you use it in your demo as well. Go ahead and enter something in this value and then scroll down and click on create parameter and And then last time click on create parameter again For name this time A4L WordPress DB root password and this is the root password for the local database server that's running on the EC2 instance So for description WordPress DB root password standard again and then again secure string because we're storing a password KMS key source is my current account leave everything else as default and then enter another strong password If this were production, generally this would be different from the previous password but as this is a demo, you should use the same strong password as you used previously. Whichever you choose, go ahead and enter that into the value box and then click on 'Create parameter'. Now that we've created all of those, we need to go ahead and install WordPress on our EC2 instance. So move back to instances. By now the instance should be in the running state. Right click, select 'Connect', change it to Session Manager and then go ahead and click on Connect and this will allow us to connect into the EC2 instance without worrying about direct network access or having an SSH key pair. Once you're connected go ahead and type shudubash and press enter then type cd and press enter and then type clear and press enter and that will just clear the screen to make everything easy to see. Now at this point there are a lot of commands that you'll need to type in to manually install WordPress. Now you can copy and paste these out of the text instructions for this stage of the demo lesson, but while you're doing so I want you to imagine that you'd have to type these in one by one, because I want you to get an appreciation for just how long this install would take if you were doing it entirely manually. So first we need to set some environment variables on this instance with the parameters that we've just stored in Parameter Store. So go ahead and copy all of this set of commands out of this stages instructions and this will set environment variables on this instance with values from the parameter store and again imagine how long this would take if you had to type all of this manually once we've got those variables configured next we need to just update the operating system on the instance make sure it's running with all the patches and just update the package repositories and we can do that with this command the next set of commands in this stage's instructions install prerequisites. So this is the MariaDB database server, the Apache web server, wget, some libraries and a stress test utility. So go ahead and paste in the next block of commands to install all of these packages. Now again this is something that we will automate later in this demo series but I want you to have an appreciation for just how long this takes. I'll type clear again to clear the screen and then the next set of commands will start up the web server and the database server and ensure that both of them start up automatically when the instance operating system is first started so if we restart this instance both of these services will start up automatically. Again make sure you press enter on the last command to make sure that starts up successfully so that's the Apache web server and MariaDB that that are both started and set to automatically start on operating system boot. Again, I'll clear the screen, and the next command that you'll run sets the root password for the MariaDB database server. So this is MySQL admin, and you're setting the password for the root user, and we're using the environment variable that we created earlier with values taken from the parameter store. So that sets the root password for the local database instance. Next we're going to download and install WordPress and we do that with the next block of commands. So this first downloads the WordPress package, it moves into the Webroot directory, it expands that package and then clears up after itself. So now we have WordPress installed. Again I'll clear the screen to make it easier to see. This next set of commands replaces some placeholders in the wp-config.php file which is the configuration for WordPress and it replaces the placeholders with values taken earlier from the parameter store. So this is how we're configuring WordPress to be able to connect to the local MariaDB database server. The next block of commands that we use will fix up the permissions of all of this directory structure structure so we don't have any problems accessing these files or any other security issues. Again make sure you press enter on the last command and then we're almost done. The last step is to actually create the WordPress database, create the WordPress database user, set the password and then grant permission on that database to that user. So these are all steps that we need to do because we're using a self-managed MariaDB database instance. So paste in this next block of commands and press enter. So this has created a db.setup file with a number of SQL commands and then it's used the MySQL utility to run those commands which have created the database, the database user and set permissions and then it's cleared up the temporary file after all that's been done. And at this point that's all of the configuration needed. We've installed WordPress, we've installed MariaDB, we've started them both up, we've corrected permissions and adjusted the configuration files. Now you've had the ability to copy and paste these commands from the lesson instructions, but imagine if you had to type them in all one by one. It would take much longer and is also something that's prone to many errors. That's something important to keep in mind as we move through this advanced demo. So the next step is to move back to the EC2 console, make sure you've got the WordPress - manual instance selected and then copy down the IP version 4 public IP address into your clipboard and make sure that you do copy the public IP address and don't click on the open address link because that uses HTTPS which we're not using. So go ahead and open that in a new browser tab. Now this is going to take you to the setup screen for WordPress. We're going to perform a quick setup. So under site title I want you to enter 'catergram' Under 'Username' I want you to enter 'Admin' - we'll keep things simple. For 'Password' enter the 'Animals for Life' password that we've been using in previous steps. Under 'Email' go ahead and enter a fake email address and then click on 'Install WordPress'. That'll perform the final installation steps at which point you can click on 'Login'. You'll need to enter the admin username together with the password that you've just chosen. and then click on login. So this is the WordPress dashboard and this suggests that our WordPress application is working absolutely fine. So to test it just go to Posts, we're going to delete the default post of Hello World. Once done, go ahead and click on Add New. You can just close down this Welcome to Block Editor dialog. Under Title, use the Best Animal and then S because we might have more than one animal and then just put an exclamation mark at the end for effect. Click on the plus underneath that title, select 'Gallery' Click on 'Upload' Select some animal pictures to upload, if you don't have any you can go to Google Images and download some cat or dog or gerbil or guinea pig pictures Anything that you want, chickens, snakes, just select a couple of animal pictures to upload and then click on 'Open' And then once they've uploaded you can go ahead and click on 'Publish' and then 'Publish' again and this will publish this post and what it's doing in order to publish it is it's uploading the images into a local image store that's called wp-content and in addition to that it's storing the metadata for this post into the local MariaDB database. So there are two different places that data is stored, the local content store as well as the database. So keep that in mind as we move on throughout this lesson. At this point click on view post Just verify the post loads it does, so that means everything's working as expected. Now the configuration that you've just implemented has a number of important limitations. The first is that the application and database have been built manually, which takes time and doesn't allow automation. It's been slow and annoying and that's very much the intention. Additionally, the database and the application are on the same instance, neither of them can scale without the other. The database of the application is stored on an EC2 instance and that means that scaling in or out risks data in this database. The application media, so the content, is stored also local to the instance in a folder called WP-Content and this means again any scaling events in or out risks this media. Additionally, customer connections are directly to an instance, which prevents us from doing any form of scaling, automatic healing, or any health checks. One final part about WordPress that isn't commonly known is the IP address of the instance is actually hard-coded into the database. Now, where this starts to exhibit problems is when running inside AWS because EC2 instances don't have static IP addresses. If we go back to the EC2 console, right click on this instance and then stop the instance. Remember a stop and start of an instance force the change of the public IP address of the instance. So restarting it isn't enough, you need to stop and then start. Watch what happens when the instance fully moves into a stopped state. First it loses this public IP address and it moves into the stop state. If I right click and then start, that will take a few moments. But what will happen is once it's fully started it will have a different IP version 4 public address. So now if I copy that IP address into my clipboard, move back to the tab where the website was previously open and then open this new IP address in a different browser tab and note how it doesn't load. Even though the IP address is correct it's not loading our WordPress website. The reason for that is the application is hard coded with the IP address that was used to install WordPress. And so what it's attempting to do now is reference the old IP address. It's trying to contact the previous EC2 instance. Now this is crucial because it prevents us from scaling the application. If we create new EC2 instances they'll all point back at this instance. Even if we fix the database and content issues, we need to resolve the ability of WordPress to scale. And don't worry, we'll look at that later in this demo series. For now, that's everything you needed to do in stage one of this advanced demo. You've manually created a WordPress application with the application and database running on the same instance. In stage two, you're going to automate this process. So this is the end of this stage of the mini project. so this might be a great time to go and take a break or have a coffee. When you're ready I'll look forward to you joining me in the next part of this mini project. Welcome back to stage two of this advanced demo lesson and again I've included full instructions attached to this lesson and this stage of the demo will be another one where you're entering lots of commands because you're going to automate the build of the WordPress application instance. So again, I would recommend opening the instructions for this demo lesson and copy and pasting the commands rather than typing them out by hand. Now at this point in the Advanced Demo Series, you're going to have a leftover instance that you used to manually install WordPress in the previous stage. It should be called WordPress-Manual. So I'm going to want you to go ahead and right click on that and select "Terminate Instance" and confirm that process to remove this instance from your AWS account. We're going to be setting up exactly the same single instance deployment of WordPress, so both the database and the application on the same instance, but instead of manually building this we're going to be using a launch template. So from the EC2 console just go ahead and click on launch templates under instances. The first step is to create a launch template for our WordPress application, so go ahead and click on create launch template. Now launch templates are actually a new version of launch configurations that were previously used with auto scaling groups. Launch templates allow you to either launch instances manually using the template or they can be part of auto scaling groups. But what a launch template allows you to do is to specify all of the configuration in advance to launch an instance and that template can be used to launch one or many instances. So we're going to create a launch template which will automate the installation of WordPress MariaDB and perform all of the configuration. And a launch template can actually have many different versions, which is a feature we'll use throughout this demo series as we evolve the design. So the first step is to name this template and we're going to call it WordPress. Under template version description go ahead and enter single server DB and app and then check this box which says provide guidance to help me set up a template that I can use with EC2 auto scaling. We're not immediately going to set it up as part of an auto scaling group, but it will help us highlight any options which are required if we want to use it with an auto scaling group. Now launch templates can actually be created from scratch or they can be based on a previous template version. If we expand source template, you're able to specify a template which this template is based on. But in this case, we're creating one from scratch, so we won't set any of those options. Now just scroll down. So the next thing we're going to define in this launch template is the AMI that we're going to use. So go ahead and click on Quickstart. And once this has changed, we're going to use the same AMI we've been using previously. So I want you to go ahead and click on Amazon Linux, specifically Amazon Linux 2023. It should be the SSD volume type. It should be listed as free tier eligible and just make sure that you've got 64-bit x86 selected. And then scroll down further still and in the instance type dropdown, we're looking for the T series of instances. And then you need to select the one that's free tier eligible. In most cases, this will be T2.micro, but select whichever is free tier eligible. we want to keep this advanced demo as much as possible within the free tier. Scroll down again and for Key Pair, just make sure that it says 'Don't include' in the launch template. Move down further still to Network Settings. Then make sure 'Select existing security group' is selected. And then in the Security Groups dropdown, click in that and make sure that you select the A4L VPC-SG WordPress. So this is the security group, which will automatically be associated with any instances launched using this launch template. So select A4LVPC-SG-WordPress, and there will be some randomness after this. That's fine. Just make sure you select the SG WordPress group, and then we can scroll down further still. Now we can leave storage volumes as default. We won't set any resource tags. We won't do any configuration of network interfaces. but I will want you to expand Advanced Details. There are a few things that we need to set within Advanced Details. The first is an IAM instance profile. So click in this dropdown and then make sure that you pick A4LVPC-WordPressInstanceProfile. Again, there will be some randomness, that's fine. What this is doing is creating the configuration which will attach an instance role to this EC2 instance. and this instance role is going to provide all the permissions required to interact with the parameter store and the elastic file system and anything else that this instance requires and this was pre-created on your behalf using the CloudFormation template. Next, scroll down further still and look for 'Credit Specification'. Remember this is the same option that you set when launching an instance manually. Now as before it's always best to set this to unlimited But if you are using a brand new AWS account, then it's possible that AWS won't allow you to use this option. So you should probably go ahead and pick Standard. It won't make that much of a difference. I'm going to pick Unlimited, but I do suggest if you are using a fairly new account, you go ahead and select Standard. So that's the configuration for the instance, the base level configuration. What I want you to do now though is to scroll all the way down to the bottom and there's a User Data box. This user data allows us to specify bootstrapping information to automatically configure our EC2 instances. So into this user data box I want you to paste the entire code snippet within stage 2b of this stage's instructions. And again they're attached to this lesson. The top line should be #/bin/bash-xe and then if you scroll all the way down to the bottom, the last line should be RM space forward slash TMP forward slash DB dot setup. And now we can see we've pasted this entire user data. Once you've done that, go ahead and click on create launch template. Now that user data that you just pasted in is essentially all of the commands that you ran in the previous stage of the demo, only instead of pasting them one by one, you've defined them within the user data. So this simply automates the process end to end. So to test this, go ahead and click on launch templates towards the top of the screen. It should show that you have a single launch template. It's called WordPress, the default version is 1, and the latest version is 1. And as we move throughout this demo series, the latest version and the default version will change. So just keep an eye on those as we go. For now though, I want you to click in the checkbox next to this launch template, Click on Actions and then Launch Instance from Template. So this is going to launch an EC2 instance using this launch template. We're asked to choose a launch template and a version and define the number of instances and we can leave all of these as the defaults. If we just scroll down you'll see how it's pre-populating all of these values with the configuration from the launch template and that's what we want. Under key pair name, just select to proceed without a key pair not recommended and that's the default value. Scroll down further still, even the networking configuration is partially pre-populated. The only thing we need to do is specify a subnet that this instance will be launched into. And when we configure auto scaling groups to use this launch template, the auto scaling group will configure the subnets on our behalf. Because we're launching an instance directly from the launch template, we have to specify this subnet. So click in the subnet dropdown and then look for sn-pub-a because we're going to deploy this WordPress instance into the public subnet in availability zone A. So select that, scroll down, look for the resource tag section and click on add tag. We're going to add a tag to the instance launched by this template so into key just type name and then for use WordPress -LT and this will just tell us that this is an instance launched using the launch template. Once you've entered those just scroll all the way down to the bottom and click launch instance and this will launch an EC2 instance using this template and this will automate everything that we had to do in the previous stage manually so this saves us significant time and it enables us to use automation in later stages of this demo series. So now go ahead and click on the instance ID in the success box. And this will take you to the EC2 console. Just give this instance a couple of minutes to finish its build process. Even though we're automating the process, it does still take some time to perform the installation and the configuration of all of those different components. So go ahead and just copy the public IP version four address of this instance into your clipboard and then after you've waited a few minutes open that in a new tab. If you get an error or it opens with a blank page then you just need to give it a few minutes longer but when it's finished it should show the same WordPress installation screen. Once it does load the installation screen we're going to follow the same process so site title is 'catergram', username is 'admin', enter the same password and then enter the the fake test@test.com email address, and then click on Install WordPress. Then click on Login, enter admin again, enter the password, click on Login. It looks as though our automated WordPress build has worked because the dashboard has loaded. Click on Posts, delete the default post, click on Add New. For the title, the best animals again, click on the plus, select Gallery, click on Upload, and again, pick a selection of animal pictures and click on open. Remember this is a new EC2 instance, so the one we previously terminated will have also deleted the data on that previous instance. Once these images have uploaded, click on publish and then publish again to upload the images to the EC2 instance and store the data within the database. So remember two components, the data stored in the database and the images or media stored locally on the EC2 instance. Click on View Post to make sure that this loads correctly. It does, so that means the automatic build has worked okay. Everything's functioning as we expect. This has been an automatic build of a functional WordPress application. Now the only thing that's changed from the previous stage of this advanced demo series is we've automated the build of this instance. It still has much the same limitations as the previous stage. So while we can improve the build time and we can use launch templates to support further automation. The database and application are still on the same instance, so neither can scale without the other. The database of the application is still located on that instance, meaning scale in or out operations risk this data. The WordPress content store is also stored locally on the instance, so again any scale in or out operations risk the media that's stored locally, as well as the database. Customers still connect directly to the instance, which means we can't perform health checks or automatically heal any failed instances. For this, we need a load balancer, which we'll be looking at in later stages of this demo series. And of course, the IP address of the instance is still hard coded into the database. So this is something else we need to resolve as we move through the demo series. With that being said though, that is everything that you needed to do in stage two of this demo series. So in this stage, you've automated the build of the WordPress instance using a launch template. Now in stage three, you're going to migrate the data from the local database on EC2 into RDS, and this will move the data out of the lifecycle of the EC2 instance, and this makes it easier to scale. So in stage three, you're going to perform that migration and then update the launch template to take account of that configuration change. So go ahead and complete this stage of the demo lesson and when you're ready, I'll look forward to you joining me in the next. Welcome back, and in stage three of this demo series, you're going to change the single server architecture that's on screen now, and move towards something a little more scalable. You're going to migrate the database from the EC2 instance into a separate RDS instance, and that means each of these can scale independently, so you can grow or shrink the database independently of the EC2 instance. It also means that the data in the database lives past the lifecycle of the EC2 instance and this is required for later stages in the demo where we want to scale in and out based on load. So let's go ahead and do that. So you'll need to be at the AWS console, click on services and in the find services dropdown, type RDS and then open that in a new tab. Now we're going to create a subnet group first, and a subnet group is what allows RDS to select from a range of subnets to put its databases inside. In this case we'll be giving RDS a selection of three subnets, so SN-DB-A, B and C. So three availability zones which it can choose to deploy database instances into. So to do that, look on the left hand menu and just click on subnet groups. Click on 'Create DB Subnet Group'. For name, call it 'WordPress RDS Subnet Group'. Under 'Description', just type 'RDS Subnet Group' for WordPress. In the VPC dropdown, select the A4L VPC. Scroll down a little and then under 'Availability Zones', click in the dropdown and check the box next to 'US East 1A, 1B and 1C' because we have database subnets in each of those availability zones and these were created as part of the infrastructure CloudFormation template that you applied at the start of this advanced demo. Once you've selected those availability zones, next we need to pick the subnets inside those availability zones that the databases will go into. So click in the subnets dropdown. Now you could go to the VPC console and get the IP address ranges that correspond to the different database subnets, but I'm gonna save us some time. So in US East 1A, you need to pick 10.16.16.0/20. That's the database subnet in Availability Zone A. In Availability Zone B, you need to pick 10.16.80.0/20. That's the database subnet in AZB. and then in US East 1C you need to pick 10.16.144.0 because that's the database subnet in Availability Zone C. So now you've selected the three Availability Zones, the three subnets in those Availability Zones so you can scroll down and click on 'Create'. So that creates the database subnet group that RDS uses in order to select which subnets database instances should go into. The next step is to actually create the RDS instance itself and to start with we're going to use a free tier eligible database So go ahead and click on databases Click on create database Select standard create RDS is capable of using lots of different database engines but we're going to select MySQL So select MySQL Scroll down and under version put the version number that's inside this lesson's description AWS regularly make changes and instead of using the version you see on this video, pick the one that's inside this lesson's description. Scroll down. Under Templates, click on Free Tier because this will make sure that we're only selecting options that are eligible under the Free Tier. And we want to keep the first part of this demo series completely within the AWS Free Tier. Now under DB Instance Identifier, we need to give this instance a name. So delete this placeholder and then just enter A4L WordPress. Now for Master username and password we need to enter the values from the parameter store that we entered previously. So click on services, start typing sys and then right click on systems manager and open in a new tab. Go to the parameter store, look for the dbuser parameter and then copy what's in the value field and then go back to the RDS console and paste that in for master username. So that should be A4L WordPress user. Do the same for the master password. So for that you need to go back to parameter store and this time you're looking for A4L WordPress DB password. So select that. Once you're here click on show and then copy the value for this parameter. Once you've got that value, paste it into both the master and confirm password boxes. Scroll down further still and now you need to pick the database instance size. Now because we've selected free tier eligible, we can only select db.t3.micro, where in some cases this may be slightly different, but it's only going to allow you to pick free tier eligible instance types. So we can leave that selected, it is the default because we picked free tier only. Now scroll down to connectivity, under the Virtual Private Cloud VPC, click in the drop down and select the A4L VPC. So this defines the VPC that this database is going into. Once you've selected that, make sure for subnet group you've got WordPress RDS subnet group selected. Choose no for publicly accessible. And then for existing VPC security groups, I want you to go ahead and click on the cross next to default and then click in the drop down and select A4L_VPC-SG_DATABASE and again this will have some randomness on the end but that's perfectly okay. So select A4L_VPC-SG_DATABASE. Under availability zone preference, select US-East-1A. This makes sure this database, just to start off with, is in the same availability zone as the EC2 instance. Scroll down further still, go past Database Authentication, and then expand Additional Configuration. And this is important because we need to set an initial database name. So for the initial database name, we'll need to go back to the Parameter Store. This time we need the value for the A4L WordPress DB name parameter, so select that and then copy its value. So copy that into the clipboard, go back to the RDS console, and paste that in for the initial database name. And that should be A4L-WordPressDB. At this point we can leave everything else as default, so scroll all the way down to the bottom and click on 'Create Database'. Now this can take anywhere up to 30 minutes to create the database, and it will need to be fully ready before you move on to the next step. So now is a great time to pause this video, go and grab a coffee and wait for this database to become available at which point you can resume the video. Now that this database instance is available, the next thing to do is to migrate the actual WordPress data and to do that we need to move back to the EC2 console. So open the EC2 console, locate WordPress-LT and then select that instance, right click, select connect, choose session manager, and then click on connect. We're going to perform the migration from this instance itself. To start with, run shudu space bash and press enter, cd and press enter, and then type clear and press enter. We're going to be running some commands which are in the text instructions for this stage of the demo series. The first set of commands will load data from the parameter store into environment variables within the operating system. So go ahead and copy all of the first block of commands and paste it in to this terminal. This will load the db password, the db root password, db user, db name, and db endpoint all into environment variables. And make sure to press enter on the last line just to complete that command. Next we're going to export the data from the local MariaDB database instance and we'll do that using this command. So my SQL dump space hyphen H space and then uses these environment variables. So the database endpoint which will be local host and then a space hyphen U and then a space and then the database user which is also an environment variable and then a space hyphen P and then DB password which is an environment variable and then a space, and then dbname, which is also an environment variable. And then we direct the output of this command into a file called a4lwordpress.sql, which is a database export file. So the best way is to copy and paste this out of the lesson instructions, and then press Enter. And then run an ls space hyphen la, and just make sure that you've got that a4lwordpress.sql file, and this is an output of the current SQL database for WordPress. Now next, we need to change the parameter in parameter store for DB endpoint so that it points at our new RDS instance. So go back to the RDS console, click on the A4L WordPress instance, and then copy this endpoint name into your clipboard. So it should start with A4L WordPress, and then some random, and then the region, and then RDS, and then AmazonAWS.com. So copy all of that into your clipboard, and then either open the Systems Manager console and go to the Parameter Store, or if you've still got it open in a previous tab, then you can open that tab. So click on Parameter Store to list all the parameters. Now at this point, we're going to delete one of these parameters, and it needs to be a deletion because we're going to recreate it. Please make sure that you do delete it and recreate it rather than just editing the value for the existing parameter, because that won't work. You'll need to select the checkbox next to A4L WordPress DB endpoint, and then click on delete. And once you've done that, click on delete parameters to confirm that deletion, and we're going to create a new parameter with the same name. So click on create parameter. For name, put /a4l/wordpress/dbendpoint, which is the same name as before. For description, put WordPress endpoint name. We're going to use the standard tier again. It's going to be a string type. The data type is going to be text. And then in the value, paste in the RDS endpoint that you just copied into your clipboard. And once you've done that, scroll down and click on create parameter. Go back to the session manager tab that you've got open to the instance, and we need to refresh the environment variable with the updated parameter store parameter. So to do that, copy and paste this next block of commands and this updates the DB endpoint with the new RDS DNS name. Once we've updated that, then we can run the MySQL command to load in the A4L WordPress.SQL export into the RDS instance and that's using this command. So again, MySQL-h space and then the RDS endpoint name which is in that environment variable and then specifying the dbuser, dbpassword, and dbname, and then directing the command to load in the contents of this file. So if we paste all that in and press Enter, that imports that database export into RDS. So now RDS has the same data as our local MariaDB installation. Now to finalize the migration, we need to update the WordPress configuration file, so instead of pointing at the local MariaDB instance, it points at RDS and we can do that using sed and perform a replace of localhost with the contents of the dbEndpoint environment variable which remember now contains the DNS name for the RDS instance and the location of the file that will be performing this replace on is /var/www/html/wp-config.php which is the WordPress configuration file. So paste that in and press enter and that's reconfigured WordPress now so that it talks to the RDS instance for the database functionality. Lastly, we can run these commands to both disable MariaDB so it doesn't start every time the operating system boots and set it to stopped right now. So now MariaDB is no longer running on this EC2 instance. So we can verify that the functionality of our application is still there by going back to the EC2 console selecting WordPress-LT, just copy this public IP address into your clipboard if you already have it open in an existing tab you can refresh it should still load the blog and yet we've still got the same best animals blog post but now WordPress is loading the data for this blog post from the RDS instance. Now to be really clear at this point, WordPress when you create a blog post has two different sets of data. It has the data of the blog post, so the text, the metadata, the author, the date and time, the permissions, the publish status and many other things, they're stored in the database. But any media, any content for this blog post is still stored locally in a directory called wp-content. That is still on the EC2 instance. All that we've migrated in this stage of the demo is the database itself from MariaDB through to RDS. Now before we finish with this stage of the demo series, there's one final task, and that's to update the launch template so we can launch additional EC2 instances, but using this new configuration, so pointing at the RDS instance. So to do that, go back to the EC2 console and click on launch templates. Click in the checkbox next to the WordPress launch template, select the actions dropdown, and then locate and click modify template to create new version. Now for the description, we're going to put single server app only. So we're indicating with this version of the launch template, we no longer have the database inside the instance itself. Now because we're creating this from a previous version, all of the boxes will be pre-populated. What we need to do is to update the user data. So go all the way down to the bottom and expand Advanced Details, scroll all the way down to the bottom of that and find the User Data box. And I find it's easier if we just expand it to make it slightly easier to see. There are a number of things which we need to adjust in this user data. First just scroll down and you need to locate this block of commands. So systemctl enable and systemctl start. What we need to remove are the lines that refer to MariaDB. So the top one is systemctl enable MariaDB. Select that and delete. And then locate systemctl start MariaDB. Select that and delete. So that prevents MariaDB starting on the EC2 instance. Now because we're using an RDS instance, we also need to remove this line, which attempts to set the root password of the MariaDB database instance. We don't need that anymore, so delete that. Scroll all the way down to the bottom and look for this block. So it starts with echo create database DB name, and it finishes with rm /tmp/db.setup. This is the block that creates the database within MariaDB, creates the user and sets all of the permissions. But because we're using RDS now, we don't need to do any of this. So we're going to delete this block as well. Once you've done that, you can go ahead and click on create template version, and this will create a new version, but this time designed to use RDS. Once you've done that, go back to the launch template screen and click on the launch template. We need to change it so that the new version is the default version that's used whenever we launch instances from this template. So click on the launch template. Once that's loaded, you'll see we're currently on version one. Change this to version two and you'll see the updated details. And then click on the actions dropdown, select set default version. In the dialog, make sure that version two is shown under template version and then click on set as default version. And at this point, version two, or the one which uses RDS, is now set as default. and this means when we use this template to launch any instances, this is the version that will be used by default. Now, at this point, that's everything that I wanted you to do in stage three of this demo series. So you've migrated the data for a working WordPress installation from a local MariaDB database instance through to RDS. And that's essential to be able to scale this application, because now the data is outside the lifecycle of the EC2 instance. So we know that for any scale in or out events, it won't impact the relational or SQL based data. It also means that we can scale the database independently of the WordPress application instances. So that helps us reach the desired outcome of a fully elastic architecture. Now at this point we've actually fixed many of the limitations of this design. at this point the only things that we need to fix are the application media so the WordPress content which still resides in a folder local to the EC2 instance so we need to migrate this out so that we can scale the instances in and out without risking that data. The other things that are still limiting factors are that customers are still connecting directly to the instance so we need to resolve that by using a load balancer and the IP address of the instance is still hard coded into the database so if this EC2 instance fails for whatever reason and we provision a new one it won't function because WordPress expects everything to be loaded from this IP address so that's something we need to resolve but at this point that's everything you need to do in stage 3 in stage 4 you'll be migrating these images from the EC2 instance into an elastic file system and that's one of the last stages that we need to do before we can make this a fully elastic design. So this is the end of this stage of the mini project. So this might be a great time to go and take a break or have a coffee. When you're ready, I look forward to you joining me in the next part of this mini project. Welcome back to stage four of this advanced demo series. Now in stage four, we're going to perform the last step before we can make this a truly elastic and scalable design. and we're going to migrate the wp-content folder which stores these priceless animal images from the ec2 instance onto efs which is the elastic file system. This is a shared network file system that we can use to store images or other content in a resilient way outside of the life cycle of these individual ec2 instances. So to do that we need to move back to the AWS console click on the the services drop-down and type EFS. Right-click and open the EFS console in a new tab. Once that's opened click on create file system. Now we're going to step through the full configuration options so rather than using this simplified user interface go ahead and click on customize. So the first step is to create the file system itself. So for name go ahead and call this a4l-wordpress-content. Leave the storage class as standard. These cat images are critical data and so we are going to leave automatic backups enabled and we're also going to leave lifecycle management set to be the default so 30 days since the last access. For throughput mode pick bursting which links the throughput to the size of the storage. Then expand additional settings. You've got two performance modes general-purpose and max I/O for this demonstration go ahead and select general-purpose Max I/O is for very specific high performance scenarios for 99% of use cases You should select general-purpose Now also go ahead and un-tick enable encryption of data at rest If this were a production scenario, you would leave this on but for this demo which is focusing on architecture evolution it simplifies the implementation if we disable it. So go ahead and make sure that encryption is disabled. Once you've done that, that's all of the file system specific options that we need to configure. So go ahead and click on Next. In this part you're configuring the EFS mount targets, which are the network interfaces in the VPC, which your instances will connect with. So in the Virtual Private Cloud drop-down, select it and then pick A4L VPC. so this is the VPC that these mount targets are going to go into. Now each of the mount targets is secured by a security group. The first thing we need to do is to strip off the default security group for the VPC, so click in the crosses next to each of these security groups. Now you should have three rows, one for each availability zone, so in my case US East 1A, 1B and 1C, and make sure that you've got the same selected, So one row for each Availability Zone A, B and C. Now in the Subnet dropdown for Availability Zone 1A, I want you to go ahead and pick SN-APP-A. So this should be 10.16.32.0/20. For the US East 1B row, I want you to go ahead and pick SN-APP-B. This should be 10.16.96.0/20. And then finally for US East 1C, I want you to go ahead and pick SN-APP-C which should be 10.16.160.0/20 Now for all three rows within the Security Groups dropdown, I want you to go ahead and select A4LVPC-SG-EFS Again for each of these it will have some randomness after it, but just make sure you pick the right one A4L VPC-SG EFS and you need to pick that for each of the three rows. Make sure you pick the right one because if you don't it will impact your ability to connect. So there the mount targets configured and they'll be allocated with an IP address in each of these subnets automatically which will allow you to connect to them. At this point go ahead and click on next. You can configure some additional file system policies. This is entirely optional. We won't be using that so just go ahead and click on next and then on the review screen scroll all the way down to the bottom and just click on create. Now the file system itself will initially show as being in the creating state and it will then change to available. Go ahead and click on the file system itself, click on the network tab and then just scroll down and these are the mount targets which are being created. Now in order to configure our EC2 instance we will need all of these mount targets to be in the available state but what we can do to save some time is we can note down the file system ID of this EFS file system so this is this value you can see it at the top header here or you can see it in this row at the top just note that down and copy that into your clipboard because we need to configure another parameter to point at this file system ID because remember when we're scaling things automatically it's always best practice to use the parameter store to store configuration information. So click on services, type sys which are the first few letters of systems manager and open that in a new tab. Once you're at the systems manager console go ahead and click on parameter store and then you need to click create parameter to create a new parameter. We're going to call this parameter /a4l/wordpress/ and then efs for elastic file system fs for file system and then id so efs file system id for description put file system id for wordpress content and then in brackets wp-content and that will help us know exactly what this parameter is for. As before we'll be picking the standard tier, the type will be string, the data type will be text, and then into the value just go ahead and paste that file system ID. And once you've done all that you can go ahead and click on create parameter. Once that's done go back to the EFS console and if required just hit refresh and make sure that all of these mount targets are in the available state. This is what it should look like with all three showing a green tick and available. Once that's the case, go to the EC2 console because now we're going to configure our EC2 instance to connect to this file system. So go to 'Running Instances', locate the WordPress-LT instance, right-click, select 'Connect', choose 'Session Manager' and then click on 'Connect'. And this will open a Session Manager console to the EC2 instance. As always, type 'shoo doo bash', press Enter, CD and press Enter and then type clear and press Enter again just to clear the screen making it easier to see. Now even though EFS is based on NFS which is a standard in order to get EC2 instances to connect to EFS we need to install an additional tools package and to do that we use this command. So type or paste that in and press Enter to install the EFS support package. Once that's installed, again, I'm going to clear the screen to make it easier to see. Then I'm going to move to the 'webroot' folder by typing 'cd /var/www/html' and what I'm going to do is to move the entire 'wp-content' folder somewhere else. So if I just go inside this folder to illustrate exactly what it looks like and then do a list, you'll see that inside there are plugins, themes and uploads and inside those folders are any media assets used by WordPress so I'm just going to type "cd .." to move back upper level out of this folder and then I'm going to move this entire folder to the /tmp folder which is a temporary folder So, MV, space, WP hyphen content, forward slash, space, forward slash TMP. And that moves that entire folder to the temporary folder. Then we're going to create a new folder, so, shudu, space, MKDIR, space, WP hyphen content. This will be the mount point for the EFS file system. So I'm making an empty directory. Then I'm going to clear the screen and then paste in the next two commands from the lesson instructions. and this populates an environment variable called EFSFSID with the value from the parameter you just created in the parameter store. So this is now the file system ID of the EFS file system. Now there's a file called FSTAB which exists in the /etc folder and inside there it's called FSTAB and this contains a list of file systems which are mounted on this EC2 instance. initially this only has the single line for the boot volume. What we're going to do is add an additional line to this fs tab file and this line is going to configure the ec2 instance so that it mounts our EFS file system on boot every single time and this is this command so it echoes this line so the file system ID from the environment variable we're going to mount it to the folder that we just created so the WP-content folder and these are all of the file system options so we're going to put that into the FS tab file so if we now cap this file it's got this extra line and this means this file system will be mounted whenever the operating system starts and we can force this just for now by running mount space - a space - T space EFS space defaults and this will mount the EFS file system onto this EC2 instance. We can verify that by doing a df space hyphen K and the bottom line should show us that we've now got this EFS file system mounted as the WP hyphen content folder so this is the folder that WordPress expects its media to be inside. Now all that remains is for us to migrate the existing data that we moved to the temporary folder back in to wp-content and to do that we use this command. So we're using the mv command to move /tmp/wp-content/* so any files and folders and then we're moving it back into /var/www/html/wp-content So this is the EFS file system. So run that and that will copy the data back to EFS, which remember is now mounted where WordPress expects it to be. Now that might take a few moments to complete. Once it's done we just need to fix up the permissions. So run this command chown -R ec2-user/var/www. So this just re-establishes permissions and ownership of everything in this particular part of the file system. Just make sure we won't have any problems going forward. Now at this point we're going to use the reboot command to restart this instance and if everything goes well the instance should start, the EFS file system should be loaded and WordPress should have access to all of this wp-content which is now running from a network file system. So go ahead, type reboot and press enter. If you press enter just to make sure that you are disconnected, and I am, so that's good. So now I need to wait a few minutes for this EC2 instance, or at least its operating system to restart. So I'll go ahead and close down this session manager tab. Go back to the EC2 console. After waiting a few minutes, I'll right click, select connect, check session manager, click on connect. Assuming the instance has restarted. I'll be back at the prompt and if I do a DF space - K If everything's working as expected The EFS file system will still be mounted into the directory that we configured if I go back to the ec2 Console and just copy down the instances public IP version 4 address Either refresh the tab if you still got it open or paste in the IP address and reload that page and if everything's working as expected, all of these high quality, critical cat pictures should still load from the WordPress blog. So now at this point when we're interacting with the application, both the database and the wp-content both exist away from the EC2 instance and this means we're now in a position where we can scale the EC2 instance without worrying about the data or the media for any of the posts and this means we can now further evolve this architecture to be fully elastic. Now there is one more thing that we need to do before moving on to the next stage of the demo and implementing this final step towards a fully elastic architecture and that's that we need to update the launch template to include this updated configuration so that it uses EFS. To do that go back to the EC2 console, go to launch templates, select the launch template, so check the box, click on the actions drop down, select modify template, create new version. For template version description use app only, users EFS file system defined in and then the parameter store value that contains the file system ID. So this is just the description. Now again because we're creating a new version it will populate all of the configuration with the previous template version but I'll need you to scroll all the way down to the bottom expand advanced details and scroll all the way down again we're going to make some edits to the user data so expand this box a little bit to make it easier to read what I'll need you to do is to put your cursor after the end of this top line and just press enter twice to make some space and then paste in this set of configuration and again this is stored within the instructions for this stage of the demo series. That will just populate an environment variable with the file system ID that it will get from the parameter store. Scroll down and next you're looking for a software installation line. You're looking for this line, the line that performs the installation of the MariaDB server, the Apache web server and the Wget utility. Position your cursor after the word stress and then press space and then I'll want you to add this text followed by a space which is Amazon - EFS - utils. Next scroll down a little bit further and you're looking for the line that says system CTL start HTTP D click on the end to position your cursor at the end of that line and then press enter twice to add some space and then paste in this next block also contained within this lesson's instructions. What this does is to make a WP-content folder before we install WordPress, configure the ownership of the entire folder tree, and then add the line for EFS to the FSTAB file and then mount this EFS file system in to var www/html/wp-content and this means that when we're automatically provisioning this instance before we install WordPress we're creating and mounting this EFS file system and then we go on to installing WordPress configuring the database and performing the final fix of all of the permissions at that folder structure next scroll down we're done with all of the launch template user data configuration just go ahead and click on create template version we need to make this new version the default so click on launch templates Select the WordPress launch template, click on actions, scroll down, select set default version, click in the dropdown. Version two should currently be the default, change that to version three and click set as default version. So at this point you further evolved the architecture. Now we have both the database for WordPress stored in RDS and the WP-content data stored within the Elastic file system. So we've solved many of the applications limitations. We can scale the database independently of the application. We've stored the media files separate from the instance. So now we can scale the instance freely out or in without risking the media or the database. We do still have two final limitations which we'll be fixing together in the next stage of this demo series. One is that customers still connect to the instance directly. So we don't have any health checks. we don't have any auto healing capabilities, and we're limited to how we can scale. And then finally, the IP address of the instance is still hard coded into the database. And so even if we did provision additional instances, WordPress would expect all of the data to be loaded from that one single original instance. And to allow us to scale, we have to resolve both of those problems. At this point though, you've done everything required in stage four, so go ahead, complete this video, and when you're ready, I'll look forward to you joining me in Stage 5 of this Advanced Demo Series. Welcome back to Stage 5 of this Advanced Demo Series, and in this stage you're going to be adding a load balancer and auto scaling group to provision and terminate instances automatically based on the load of the system. By adding a load balancer, you'll also abstract connections away from individual instances which will allow elastic scaling and self-healing if any of the instances have problems. Now the first step to moving towards this elastic architecture is to create the load balancer. To do that, move to the EC2 console, scroll down, and toward the bottom under load balancing, click on load balancers. Go ahead and click on create load balancer, and it's going to be an application load balancer that we're creating, so click on create. We're going to be calling the load balancer A4L WordPress ALB. It's going to be an internet facing load balancer, which means the nodes of the load balancer will be allocated with public IP addressing, and we want the IP address type for this demonstration to be IP version 4. Okay. So now we need to select the subnets that the load balancer nodes will be placed into. So first make sure that the animals for life VPC is selected. so A4L VPC, and then check the box next to US East 1A, 1B and 1C. For US East 1A, I want you to select the SN-PUB-A, which is the public subnet inside Availability Zone A, so US East 1A. For US East 1B, I want you to select the public subnet in AZB, so SN-PUB-B. And then lastly, for US East 1C, we'll be selecting the SN-PUB-C. So this configures the subnets that the load balancer nodes will be placed into, because they're public subnets, and because we have the scheme set to internet facing, these nodes will be provided with public IP addressing. Next, under Security Groups, click on the cross to delete the default security group, and then click in the drop down and go ahead and select A4L VPC-SG load balancer. Now there will be some random afterwards that's okay just make sure you select A4L VPC-SG load balancer. Now scroll down and under listeners and routing make sure that the protocol is set to to HTTP and the port is set to 80. Application load balancers work using target groups and so we need to define a target group to forward the traffic to. Now we don't currently have any target groups which have been created, so we need to go ahead and click on create target group. Now under basic configuration, the target type is going to be instances, so make sure that that's selected. Under Target Group Name just enter A4L-WORDPRESS-ALBTG Scroll down further still, make sure the protocol is set to HTTP and port is set to 80 on this screen as well Make sure the VPC is set to A4LVPC The protocol version by default should be HTTP 1, you can leave that as the default Under health checks, make sure the health check protocol is HTTP and the health check path is forward slash. Once that's set, go ahead and click next. Now we won't be adding any instances to the target group. These can either be added manually or a target group can be integrated with an auto scaling group. And that's something that we'll be configuring later in this advanced demo. For now, just scroll down to the bottom and click create target group. Then go back to the previous tab, click on the refresh icon, and then select the A4L WordPress ALB TG from the dropdown. Now we won't be picking any add-on services, so you don't need to check the AWS Global Accelerator. Just scroll down to the bottom and click 'Create load balancer'. Next, click on 'View load balancer' and then select the load balancer that you've just started creating. And we'll need to create another parameter in the parameter store, So we'll need the DNS name of the load balancer. So go ahead and click on the little symbol next to that to copy that into your clipboard. Next you'll need to move back to the parameter store. Now because we're automating this environment we need to provide a way so that all of the EC2 instances know the DNS name of the load balancer because this will be used as a workaround to the fact that the IP addresses are hard coded into the database, so we need to provide an automatic way of exposing the load balancer DNS name to the EC2 instances. Click on create parameter. For the parameter name, /a4l/wordpress/alb for application load balancer and then DNS name. So /a4l/wordpress/alb, DNS name. For description, put DNS name of the application load balancer for WordPress. We're going to be picking a standard tier parameter. It's going to be a string parameter. It's going to be a text for data type. And in value, go ahead and paste the DNS name of the load balancer, which you just copied into your clipboard. Scroll down to the bottom and click on create parameter. Now the next thing we're going to do is to update the launch template. And this is quite a complex update. so you need to understand exactly what we're doing. Currently, and I've mentioned this a few times throughout this demo series, the IP address of the first EC2 instance that's used for a WordPress deployment is hard-coded into the database. Now this is fine if it's a static IP address, but if it's not, or if you're using multiple EC2 instances, then you can't use IP addresses, because they change both on an individual EC2 instance and if you're scaling using multiple instances. So we need to replace this hard coded value with the DNS name of the load balancer. So that's what we're going to do. We're going to update launch template with some final configuration so that it can adjust this configuration, replacing the IP address with the DNS name of the load balancer. So go back to the EC2 console, click on launch templates, select the WordPress launch template and click on Actions, Modify Template, Create New Version. Under the template version description, we're going to use app only, users EFS file system defined in /a4l/wordpress/efsfsid and then ALB_HOME added to the WP database. So we're going to make some on-the-fly adjustments to the WordPress database when every instance is provisioned to make sure that the load balancer DNS name is set to be the home URL for WordPress. So again, scroll all the way down to the bottom because we're using an older template as the foundation for this one. All of the values will be pre-populated. Expand advanced details and scroll all the way down to user data and then just expand this text entry to make it slightly easier to interact with. As with the previous step, position your cursor at the end of this top line and press enter twice, we need to add the first two lines of script, which will bring in the application load balancer DNS name into an environment variable using Systems Manager Parameter Store. So now this instance, when it's provisioning, has the DNS name of the load balancer. Now next, move all the way down to the bottom of this user data. So the last step that we want a machine to do when it's provisioning, is to perform this update of the database. So there's a fairly large block of text which you need to copy from this stage's text instructions, it's stage 5, and you need to paste this into the bottom of this file. So right at the bottom, after these last two find statements, paste in this block. So this should start with the cat command on the top line of what you've just pasted in and then all the way down at the bottom it should end with /home/ec2-user/update_wp_ip.sh Essentially what this does is to bring in the WordPress configuration file to get the current authentication details for the database. So all these lines at the top are just designed to get the authentication information, so So the DB name, the DB user, and the DB password. This line runs a database script to get the old value for the IP address, so the original IP address of the EC2 instance. So this is pulling in the original hard-coded IP address. Then we're going to take the load balancer DNS name and we're going to run a series of SQL commands to update the database, moving from that hard-coded IP to using the ALB DNS name. Now what this is actually doing is this line here is creating a script file and it's going to put into this script file everything until this EOF directive so scrolling down this means that everything between these two lines is going to be stored in this script then we're going to make the script executable using chmod 755 We're going to echo the path to this script into /etc/rc.local which is run every time the instance is started up and then finally we're going to run this script the once to update this information right here and now. So this new version of the launch template essentially changes what this hard-coded IP address is every time to be the DNS name of the load balancer. And it means if we ever change the DNS name of this load balancer this script will automatically correct this hard-coded value. Now this is a thing specific to WordPress and there are many situations where you'll have applications which have certain nuances that you need to be aware of when creating elastic architectures. This is the one for WordPress. So now that we've made these changes, go ahead and click on 'Create Template Version' to create that new version of this launch template. Click on 'Launch Templates' and for the final time we need to update the default version. So make sure this launch template is selected. Click on actions, scroll down, select set default version, click in the drop-down. The current default version is version 3, we want to select version 4, so select that and then click set as default version. Now that means the launch template is updated and we can now provision instances in a fully elastic way. The last step to enabling that functionality though is to create an auto scaling group, which allows for the automatic provisioning and termination of the EC2 instances. So to do that on the EC2 console, scroll down to the bottom under Auto Scaling and select Auto Scaling Groups. Click on Create an Auto Scaling Group. We're going to call the Auto Scaling Group A4L WordPress ASG. Then for the Launch Template, click in the drop down and select the WordPress Launch Template. This is the one that you've been working on throughout this advanced demo series. and then under version you can either pick an explicit version or set to use the latest. We're going to pick the latest so select latest which should be version 4. Scroll down to the bottom because now the auto scaling group's been configured with the launch templates and version to use. Next we need to carry on and set other options for this auto scaling group so click on next. For networking it's here where we provision exactly which subnets are going to be used to to provision our instances into. So click on the VPC dropdown and make sure that the A4L VPC is selected. So this is the Animals for Life VPC. And then under subnets, we need to select the three public subnets. So SN-PUB-A, SN-PUB-B, and SN-PUB-C. So this allows the AutoScaling group to automatically provision instances into any of these subnets as required. At this point, go ahead and click on Next. Now it's here where we can integrate the auto scaling group with the load balancer. Load balancers actually work for EC2 with static instance registration. Instances are registered with a target group within a load balancer configuration. What auto scaling groups do when you integrate them is it links this with a target group. So any instances provisioned by the auto scaling group are added to the target group and anything which the auto scaling group terminates is removed from the target group. So we need to attach to an existing load balancer. Make sure Choose from your load balancer target groups is checked. Click in the drop down and select the A4L WordPress ALB TG target group which is the one that we just created. Under health checks we can actually pick to use ELB health checks which are much more feature rich than the normal EC2 status checks so we will be using ELB health checks. Scroll down, check Enable Group Metrics Collection within CloudWatch and then click on Next. To start with we're going to select one desired capacity, one minimum capacity and one maximum capacity. It's the job of an auto scaling group to keep the number of running instances to be the same as the desired capacity. This is the value that changes up or down and the minimum and maximum capacity provide limits to this. So for now we're going to leave desired, minimum and maximum all at one and we're not going to configure any automatic scaling policies. For now it's going to be a static auto scaling group. So go ahead and click on next. We won't be adding any notifications for any scaling events so click on next. Now we want to make sure that any instances provisioned by this auto scaling group are recognisable. So we're going to click on add tag, under key we're going to type name and then under value WordPress - ASG and make sure this tag new instances is selected and this means that any instances launched by this auto scaling group will be tagged with this name. Go ahead and click on next, scroll down to the bottom and click on create auto scaling group to create this auto scaling group. Now if we just click on instances, right click on this existing WordPress-LT instance and then select terminate instance and confirm. Let's just get rid of that old instance that was created directly using the launch template. While that's terminating, scroll down and just open a new tab to the Auto Scaling Groups console. Click on the Auto Scaling Group, click on Activity and then just hit refresh. Now what you should see, because we've created this Auto Scaling Group with a desired capacity of one and because it has zero running instances it's going to begin the creation of an instance in order to bring the running number of instances to be equal to the desired number of instances which is one so at this point it's going to automatically provision an ec2 instance if we go to the ec2 console and instances and then hit refresh we should see a new ec2 instance and it should be called WordPress - asg and this is the ec2 instance that's been automatically provisioned by the auto scaling group. But that's just a simple static auto scaling group. What we want to do is add some intelligence. So let's do that. So we're going to move to the auto scaling groups console. And we're going to add some scaling policies. So click on the auto scaling group, select automatic scaling, click on create dynamic scaling policy, and we want to create two policies. We want to add instances when the average CPU utilization is above 40%. And we want to remove instances when the average CPU utilization is below 40%. So to do that, we need to use simple scaling policies. Remember target tracking scaling adjusts automatically and aims to try to keep a certain value at a certain level. So for scaling policy name, we're going to call this one a high CPU and we need to define a CloudWatch alarm. So go ahead and click on create CloudWatch alarm. Click on select metric, then EC2, and then buy auto scaling group. And if you don't see a list, you might just need to wait a couple more minutes for all of this to be populated. What you need to do is to scroll down and you're looking for CPU utilization next to A4L WordPress ASG. So select that and then click on select metric. Now we want to create an alarm which goes into an alarm state whenever the average CPU utilization is above 40%. So scroll down. Threshold type is going to be static. Whenever CPU utilization is should be set to greater and then the value needs to be 40 so greater than 40%. So go ahead and click on next if you see anything next to notification then click on remove because we won't be configuring a notification Click on next again and then for the alarm name, we're going to use WordPress high CPU. So enter that and click on next Scroll down and click on create alarm then move back to the previous tab where you should still have open the create scaling policy and just click on the refresh icon and then click in the cloud watch alarm drop-down and select WordPress high CPU now for action whenever the CPU is above 40% we need to add one capacity unit so make sure that take the action is set to add and change this to one and make sure it says capacity unit so add one capacity unit and then go ahead and click on create Next we're going to create the other side of this. Click on create dynamic scaling policy. It's going to be a simple scaling policy. This time it's going to be called low CPU. We'll need to create another CloudWatch alarm so click on create CloudWatch alarm, select metric again, EC2 again, buy auto scaling group again, locate CPU utilization and click on select metric. This time though scroll down it's going to be static again but instead of greater it's going to be lower and again 40 in this threshold box click on next click on remove again we don't want to notification click on next again for the alarm name WordPress low CPU so enter that and click Next scroll down and click on create alarm once again go back to the create scaling policy tab click on refresh this time I'm clicking the drop down and select WordPress Low CPU only this time the action is going to be to remove one capacity unit. So remove one capacity unit. Then go ahead and click on create. So now we have two scaling policies. When the CPU is above 40% we add one capacity unit and when the CPU is below 40% we remove one capacity unit. Now to make this work we need to click on the details tab and adjust the Auto Scaling Group settings so that the maximum capacity of the Auto Scaling Group is more than one because if it's one, then the desired capacity can never increase beyond that value. So click on Edit and change the maximum capacity to equal three. So it should be desired one, minimum one, maximum three. And then click on Update. Now at this point, that is actually a fully scalable architecture. We can test this by simulating some load. Now to simulate this, move back to the EC2 console and connect using Session Manager to this instance. So WordPress-ASG Right click, go to Connect, Session Manager, and then click on Connect. Once connected, type "shoodoo bash" and press Enter. And then we're going to run a command called "stress" and the whole function of stress is to stress the CPU of this EC2 instance. So in this case, stress is going to use two cores and it's going to run for 3,000 seconds. This command again is within this lesson's instructions which are attached to this lesson. So go ahead and paste that in and press enter and that begins stressing out the CPU on this EC2 instance. Now what should happen at this point is the auto scaling group is going to detect the increase in CPU It's going to trigger the automatic scaling rule So when CPU is above 40% it will add one capacity unit This will add one to the desired capacity value of the auto scaling group And because desired capacity will be at 2 and the number of running instances will be at 1 It will provision a new instance Now this instance will be provisioned using the launch template. It will be added to the target group of the load balancer, and then we can cope with more load in our application. Now this can take up to 20 minutes. So at this point, go ahead and pause the video and keep refreshing this activity history, because at some point you should see one additional EC2 instance, which begins the provisioning process. So pause the video and resume it once you see an additional line in this activity history. After a few minutes you'll note that auto scaling groups have detected an increase in CPU utilisation, the high CPU alarm was triggered and this causes an increase of the desired capacity from 1 to 2. Now how this translates if we go to the EC2 console and hit refresh is that an additional EC2 instance is being provisioned in a different availability zone. And this is automatic behaviour. You can configure auto-scaling groups to perform these automated scaling actions based on lots of different criteria. Auto-scaling groups also allow us to perform self-healing. So if I right-click on this new EC2 instance that's being provisioned and then terminate and confirm that with "Yes, Terminate", then the auto-scaling group will detect that the number of running instances has decreased by one and it will automatically provision a new instance to operate in its place. So this is an example of a self-healing architecture and the same will be true if any of these instances fail the health checks provided by the load balancer. If they fail the health check they'll be terminated and reprovisioned automatically by the auto scaling group. A few moments later. And there we go, we can see that we've now got a new instance which is being provisioned as part of that auto healing process. Now if we move back to the EC2 console, and then we move down to load balancers, click there, select the load balancer, scroll down, copy the DNS name into your clipboard and then open that in a new tab. You can see that we can now access this WordPress application using the load balancer. and doing it with this method means that any sessions in general won't experience any disruption through these scaling or auto healing processes and so this is a way that we've implemented a self-healing resilient application architecture. Now at this point you've completed everything required for stage five of this advanced demo series. You've actually now implemented a fully scalable, elastic, self healing architecture. You've removed all of the limitations of WordPress. You've split the application and database into separate pieces of compute. You've moved the data into an RDS instance. You moved the WordPress content onto a shared EFS file system. You've added a load balancer and auto scaling group to allow automatic scaling actions and the load balancer abstracts the sessions so they no longer connect directly to the EC2 instances. And at this point, the architecture can scale in and out based on the CPU load. Now this is a simple example, but it illustrates how you can evolve the architecture of a simple application like WordPress from being a simple single server design to something that's highly scalable and highly resilient. and it just requires knowledge of the nuances of the application as well as knowledge of AWS products and services. Now at this point that's everything that you need to do in this advanced demo series. The only thing that's left is to clean up the account and return it to the same state as it was at the start of the demo series and that's what we're going to do in the next and final part. So go ahead and complete this video and when you're ready I'll look forward to joining you in the next. Welcome back to the final stage of this advanced demo series and all that remains is to tidy up the account and put it back into the same state as it was when we started this demo lesson. So we need to go back in reverse order through all of the things that we've implemented. So first we need to remove the load balancer. So move to the EC2 console, select load balancers, select the load balancer, click on actions and then delete. you'll need to confirm it and that will delete the load balancer. Once the load balancer has gone, select target groups and select the target group that you created for this demo series. It's called A4L WordPress ALB TG. So go ahead and click on actions and then delete and then confirm by clicking yes delete and that will delete the target group. Next we need to delete the auto scaling group. So scroll down, click on 'Auto Scaling Groups' You should only have the one, it's called 'A4L WordPress ASG' So select it, and then click on 'Delete' This time you'll need to confirm by typing 'Delete' And then clicking on 'Delete' Now this one might take some time because it's going to terminate the instances that it provisioned as part of the process So while this one finishes, click on 'Services' Type 'EFS' and then open that in a new tab Select the EFS file system and click on delete. You'll need to confirm by typing or pasting in the file system ID and then clicking on confirm. That will first delete the mount targets and then the file system itself and again that could take a few minutes to complete. Next click on services and move to the RDS console. Select databases. Then go ahead and check the box next to A4L WordPress. Then click on actions. and then select delete. On this dialog, uncheck create final snapshot. Also uncheck retain automated backups. Check this acknowledgement box, then type delete space me into this field and then click on delete and that will begin the process of deleting the RDS instance. Move back to EFS, that's finished deleting. Go back to EC2, check whether the auto scaling group has been deleted. It has so that's good so now we can go to launch templates select the launch template go to actions and then delete template and to confirm that you need to type delete in the box and then click on delete Okay next we need to move to the parameter store Once we're at the parameter store we need to delete all of the parameters that we created for this WordPress advanced demo so that should be any of the parameters which begin with /a4l/wordpress and then anything else. So go ahead and select all of those, click on delete, confirm that you don't have any extras selected by mistake and click on delete parameters. At this point RDS is all that's left, so go back to the RDS console and you'll need to wait for this to finish before we can fully delete the infrastructure. Go ahead and pause the video and wait for a4l/wordpress to finish deleting and then we can perform the final cleanup step. Once that's deleted, go ahead and click on subnet groups and select the WordPress RDS subnet group and then click on delete and confirm that deletion. And at that point, you've deleted all of the infrastructure in this account. So all of the instances have been terminated and the last thing which remains is to go back to the CloudFormation console and delete the CloudFormation stack that you applied at the very beginning. So select the stack, click on delete, and then click on delete stack. And this will remove all of the infrastructure created by the one-click deploy at the start of this lesson. So it will remove all of the subnets and the VPC used for this demo lesson. Now with that being said, that's everything that you need to do in this last stage of the demo series. And it is the end of this demo series. Now I hope it's been enjoyable and useful. I find that this specific advanced demo lesson is really useful for any students looking to get their first job in AWS. So anyone who is applying for that first job in AWS, which requires a scenario style task as part of an interview. Because this demo has been all about evolving an architecture using your knowledge of that product. So working around the limitations of WordPress in this case using AWS products and services to move from that single server design through to a fully scalable, resilient and self-healing platform. Now this is a simple example but it's the type of thing that you'll need to be able to do for these scenario-based tasks as part of most job interviews for solutions architect or consultancy style positions. Now I will be releasing many more advanced demos and all of them will be available within my courses and on the GitHub repository. So I do encourage you to keep an eye on that repository and in my courses and do all of these advanced demos because I find that they're really valuable for real world situations. If you're looking to interview for a new position or if you need to learn how to do something in practice for your current position, then these advanced demos are really invaluable. At this point though, that is everything that you need to do in this lesson. So go ahead, complete the lesson, and when you're ready, I'll look forward to you joining me in another exciting advanced demo series, or another lesson in one of my courses.
