In this video, Jeff Winesett demonstrates creating a new RDS instance and connects to this new instance from an Apache web server.
- [Instructor] Now that I have the web server working, it's time to get a database server working. For this, we're going to take advantage of Amazon's Relational Database Service, RDS, which was introduced back in chapter three. From the console, find the RDS service. Click on that. And once in the RDS dashboard we can click the get started now button. The first thing I need to do is select an engine. I've already configured the web server with MySQL, so I'm going to choose that.
But just so that you know, Amazon's Aurora DB is MySQL compatible and has some interesting performance features compared to MySQL. So something to consider. In this case I'm going to choose MySQL, also free tier eligible, which is great. I'll select that. Now Amazon is asking me whether I want to launch this instance using good practices for production environments, or if this is only going to be used for testing. The good practice for production environments includes multiple availabilities on deployment which results in two database instances being launched.
One is a primary database in one availability zone, and another is a stand-by or backup database in a separate availability zone. This provides great durability for your database tier. AWS will take care of all the syncing of data between the two, and if the primary database ever has an issue all connection requests will be routed to the stand-by database server, thereby turning it into the primary database. Your application downtime will basically be none, and a new DB instance will be launched to replace the failed one, and then this one becomes the secondary database.
This is one of the many areas where using RDS greatly simplifies what had previously been complicated and time-consuming setups. The other suggested practice for your production environment is to use services with fixed provision IOPS. Provisioned IOPS is an option that delivers fast and predictable and consistent throughput performance on the server, which is often a requirement of the database layer in a production application. Of course, all of this does cost more, which is why Amazon is asking the question. I would argue that the cost of implementing them is far less than the cost of dealing with database-related performance issues in a production environment, or dealing with disaster recovery yourself.
These are of course business decisions that will need to be made at the time of the application launch. For the purposes of this demo, I don't need these additional features, this is just a test demo, so I'm only going to use the test version. And I'll continue on to the next step. Here is where I specify a lot of the database details. For the purposes of this demo, most of these defaults are just fine. The licensing model, the DB version engine, the DB instance class, which I do need to choose. So I'm going to choose just the micro instance, something that won't cost very much.
It asks me again about the multi-AZ deployment. I don't need that right now, I'll say no. And you can notice here we've got the tool tips on the side that help with each step. Storage type, I'm going to use the defaults there. Allocated storage, I don't need much for this demo. It does provide a little warning about the amount of storage needed for high throughput workloads and some latency issues that could incur based on this particular allocated storage decision. This is something that you can read through as you're creating your own database and make that decision.
For the purposes of this demo, this is fine. Now I need to set up the settings here. The instance identifier? I'll choose something that's easy to remember like AWS essentials. Master username? I'll make it admin. The password? Something that you can remember. And move on to the next step.
Here is where I configure the advanced settings. Most of these defaults are going to work fine for this demo. I want the default VPC, I'll allow it to launch into the subnet of its choosing. I'm going to keep it as publicly accessible. Availability zone, since I did choose a specific availability zone for the instance that I launched, I want to go ahead and make sure that the instance and the database are in the same availability zone. This isn't necessary but I wanted to just make sure just in case there's any latency issues.
The VPC security group, in this case it's a database. I want to choose the database tier security group that we created. And now I can choose some of these database options. So the database name, I'll again just go with AWS essentials. Well maybe I'll make it something different so that we can see that. AWS training. Port, default port. Parameter groups are fine, copy tags to snapshots, enable encryption, all these defaults are fine.
Backup retention, monitoring, maintenance window, again all these defaults will be just fine. So now I can launch the DB instance. Great, it's telling me that it's been created. We can go into the dashboard for the DB2 instance and monitor the status as it's being created. Again, over here in this column here it'll tell us the status, and we have similar to the instance, we have some tabs that we can look at the monitoring, all of the configuration details, and read replica information if we happen to have that implemented, we don't at this time.
So similar to the instance that we created, we have to wait for the status checks to all pass before we can access this instance. So we need to wait a little bit for it to finish creating the instance. Great, my RDS instance is up and available. Now I can try to access it from the web tier so the application can save data. In order to do that, I need to get this endpoint here. So let me grab the endpoint.
And toggle over to the terminal. And I'm already SSH'd into the instance here, so we can try to connect to MySQL directly from the command line. The first thing I want to do is just check to make sure that MySQL was installed at all. I used the user data upon launching the instance to install MySQL, and I just want to make sure it's there. It is, great, so let me just use MySQL. Client command, MySQL -h. I'll specify the host name without the port.
It'll default to 3306 unless I specify otherwise. I'll specify the user, admin, and I'll be using a password. If you recall the password when launching the instance, we'll be using that one for admin. And great, I'm in. I can even use the show database command to see that I have, AWS training was created for me. That was one of the settings that I specified in launching the RDS instance.
Okay, this demonstrates the web server tier is able to connect and talk to the database tier. So I'm getting closer to completing the system architecture. The next step is to create an AMI of the web server that we can use to create additional web servers to horizontally scale the web server layer. We'll be doing that next.
- Benefits of cloud services
- Making architectures scalable
- Examining cloud constraints
- Virtual servers, EC2, and Elastic IP
- Using the Amazon machine image
- Elastic load balancing
- Using CloudWatch for monitoring
- Security Models
- Elastic block storage
- S3, CloudFront, and Elastic Beanstalk
- Handling queues, workflows, and notifications
- Caching options and services
- Identity and access management
- Creating a custom server image
- Application deployment strategies
- Serverless architectures