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 e-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 Quick Start,
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,
and then we're going to be using the Amazon Linux 2 HVM AMI.
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 drop-down, you'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 drop-down,
click in that, and make sure that you select
the A4LVPC-SGWordpress, so this is the security group
which will automatically be associated
with any instances launched using this launch template.
So select A4LVPC-SGWordpress, and there will be
some randomness after this.
That's fine.
Just make sure you select the SGWordpress 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 drop-down, 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
of 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 and then a space -xe,
and then if you scroll all the way down to the bottom,
the last line should be rm space /tmp/db.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 one, and the latest version is one,
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 check box
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 this subnet drop-down,
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 Value, 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 this 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 Catagram.
Username is admin.
Enter the same password, and then enter
the fake test@test.com email address.
Then click on Install WordPress.
Then click on Log in.
Enter admin again.
Enter the password. Click on Log in.
It looks as though our automated WordPress build
has worked because the dashboard has loaded.
Click on Posts.
Select the default Hello world post.
Click on the Bulk actions drop-down, Move to Trash,
and click on Apply to delete that 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 to load balance,
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.