Photo by Markus Spiske on Unsplash

AWS Dev and Deploy Series: Deploying Springboot API on ECS Fargate through CodePipeline

The end goal of this series is to deploy a basic Springboot application on AWS ECS Fargate in a CI/CD way which is (almost) production ready, from the infrastructure and deployment side. The ideal application flow starts from GitHub where developers commit their code, which passes through certain stages in the pipeline and finally gets deployed into production with a little or no manual intervention.

This Part1 is very similar to my other post which demonstrates the same use case and I urge you to go through it first. In there, the VPC and the ECS service is created together which is usually not the way if you want to use the same VPC for multiple applications.

In this post, it is demonstrated to create the underlying infrastructure resources separately and deploy the application using AWS Developer tools. Thus, this approach is less complicated and closer to a real-life scenario.

Implementation

For a quick run-through, all you need is an AWS account with admin/root privileges and a GitHub account. You might need to create ssm parameters that are used and tweak the code to match your parameter names.

Since my opinion on ECS Fargate has been covered in my previous post, let us not dwell so much into it. I am creating two different environments for this application namely dev and prod. Upon each commit on GitHub, the code gets built and deployed till the dev environment automatically. After successful deployment in dev, a manual approval to Prod is necessary.

In a real production scenario, it is preferred that each environment has its own account for better access management and security. I however possess only one Free Tier account and I am doing it in the same account. The approval ideally is done after rigorous testing of Dev API and not done so often as the commits and deployments to dev. In my AWS account, I have limited the ability to approve/reject an upcoming change to go into the prod environment in the pipeline to “Admin” users only by explicitly denying this for Developer users. The implementation steps for that are out of scope for this post and here is my template for creating IAM users.

Since a picture is worth a thousand words, here you go

Workflow

The implementation code is found here on my GitHub page. Please refer to the branch 1-codepipeline-fargate

Here are the manual steps you need to do to deploy the application:

1. After cloning the repository, create your own ssm parameters and make sure they match with the templates. For this part of the series, only /github/AuthToken is of significance.
2. Create the VPC and subnets using the file network-config.yaml
3. Create a cloud formation stack using build-pipeline-docker-ecs.yaml

You may choose an AWS region closer to you for lesser latency but in principle, any region should be fine. I am writing this while sitting in India and I am deploying my application in the Mumbai region.

Step 3 creates the pipeline, which deploys the Fargate application within the VPC created in step 2. The stack name given in step 2 is referred to in step 3. Please make sure they match. In my case, I am naming my network stack as network-config and the same is being used in config-dev.json and config-prod.json files.

After successful deployment in the DeployDev stage, you should see the ELB endpoint in outputs for the dev stack. After testing your API using this endpoint, you may proceed to approve the application into Prod in the pipeline. This would create an additional Cloudformation stack which also has an ELB endpoint pointing to the Prod API. The load balancer here is public-facing.

The following are the Cloudformation created for this step. Among them, network-config and employee-service-pipeline are manually created and the other two are created by the pipeline.

CloudFormation Stacks

As you may rightly guessed so, there is no real DB instance running in this infrastructure. The Springboot application runs an in-memory database which is limited to the run time. This is covered in my next post where the application connects to a Postgres DB on RDS instance making it one step closer to a real production scenario.

Here is the part2 of the series.

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! ⬇