Photo by Campaign Creators on Unsplash

AWS Dev and Deploy Series: Connecting to an RDS instance using Fargate run time secrets

This is part 2 of a series, please go through Part 1 here for better understanding if you have not done already.

In the first part, I developed a basic Springboot API and deployed it on AWS Fargate through CodePipeline (AWS CI/CD way). While that was good enough for the application demo, the data is not really persistent and only limited to the run time. This step takes the application a bit closer to being production-ready by using a persistent RDS Database instance.

Why RDS?

RDS is a managed DB solution from AWS where the user only needs to specify the type of instance (MySQL, Aurora, Postgres etc), the memory, and the credentials to connect to the DB instance.

Some features:

1. It is highly scalable, fit for higher loads (with higher configuration), and highly available while the provisioning and infrastructure management comes out of the box.
2. It also comes with advanced features such as Read Replicas if you need to offload some traffic, automated backups, and in time snapshots of the DB.
3. It comes with a default security option to allow the traffic only within a VPC specified or within the default VPC. This means, only the applications within the VPC or the ones which can access the traffic of the VPC can only reach the DB.
4. It can be easily integrated with CloudWatch/SNS and critical cases such as expensive queries taking up on all the memory or DB crashes can be easily traced out.

Using Cloud is not only because you do not want to own servers but also because you can have your cloud provider do the management for you.

If you choose not to use RDS for any reason, the other cloud solution for a relational DB is the one where you manage everything. One such solution is to provision, manage and run the DB instance on an EC2 instance. Based on the instance type and configuration, it can be both expensive and troublesome given that now the Developer/Admin has to take care of the DB management and monitor its performance. While it sounds like a no-go, there are situations in which this approach is preferred, especially when more control and flexibility are desired or if organisations do not allow the DB management by their Cloud Provider.

Implementation

For this part, you would additionally need to create SSM parameters for Dev and Prod DB instances which are both used for DB Instance creation and for Fargate Application to connect to the Database.

The following parameters have been created additionally

1. /DataBaseCredentials/Stage/dbname
2. /DataBaseCredentials/Stage/host. In my case, database-stage.mydomainname
3. /DataBaseCredentials/Stage/password
4. /DataBaseCredentials/Stage/username

Thus a total of 8 parameters, each 4 for each environment have been created.

The code can be found here on my GitHub. The branch here is 2-rds-fargate-secrets.

Here is the workflow

Application workflow

Two DB Stacks, each for dev and prod environment are created using rds-database.yaml. A custom domain name has been used to map to the DB Endpoints since I prefer to use my database with database-dev.mydomain rather than a random constantly changing DNS name provided by AWS. This is, however, optional if you do not have your own domain name. In such cases, you will have to create the /DataBaseCredentials/Stage/host with the DNS name of your DB instance and then deploy the application.

The ECS task definition is changed to pull DB Credentials from SSM during run time by this

Task Definition Update

The application.properties file of the Springboot application is changed as follows to instruct the Spring framework to expect variables during run time.

application.properties

All requests done on the API would read/write from the persistent RDS instance now. Any change in the Application layer should not affect the data and consequent rolling updates in the Application can be deployed with ease.

The API consumer should be given the public DNS of the ELB, which is accessible without any authentication and thus, the API is not really secure. The next step of the series to enable authentication of the API by attaching an API Gateway to the ELB and giving the API consumer the endpoint that hits API Gateway but not the ELB directly.

This is covered in part3 here.

Happy Coding!

Clap on, Comment, Share, and Follow!

👋 Join FAUN today and receive similar stories each week in your inbox! ️ Get your weekly dose of the must-read tech stories, news, and tutorials.

Follow us on Twitter 🐦 and Facebook 👥 and Instagram 📷 and join our Facebook and Linkedin Groups 💬

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author! ⬇