Welcome back and in stage three
of this demos 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 life cycle 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 drop down,
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 WordpressRDSSubnetGroup.
Under description, just type RDS subnet group for Wordpress.
In the VPC dropdown, select the A4LVPC.
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 drop down.
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 AZ-B.
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 A4Lwordpress.
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 DB user 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 A4Lwordpressuser.
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 A4Lwordpressdbpassword.
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 instant size.
Now, because we've selected free tier eligible,
we can only select db.t3.micro
or 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 dropdown and select the A4LVPC,
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 dropdown and select A4LVPC-SGDatabase
and again, this will have some randomness on the end,
but that's perfectly okay.
So select A4LVPC-SGDatabase.
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 A4Lwordpressdbname 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 A4Lwordpressdb.
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 sudo 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 mysqldump -h
and then uses these environment variables.
So the database endpoint, which will be local host
and then a space -u and then a space
and then the database user,
which is also an environment variable
and then a space -p and then DB password,
which is an environment variable and then a space
and then DB name, 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 -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 A4LWordpress instance
and then copy this endpoint name into your clipboard.
So it should start with A4LWordpress
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/DBEndpoint
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 a new RDS DNS name.
Once we've updated that, then we can run the mysql command
to load in the A4LWordPress.sql export
into the RDS instance and that's using this command.
So again, mysql -h and then the RDS endpoint name,
which is in that environment variable
and then specifying the DB user, DB password and DB name
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 local host with the contents
of the DB endpoint 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 data and time,
the permissions, the published status
and many of the things that are 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 drop down
and then locate and click modify template,
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 the 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 DBName"
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 dialogue, 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 three.
In stage four, 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 go ahead, complete this video and when you're ready,
I'll look forward to you joining me in stage four
of this advanced demo series.