Running the application as containers using AWS ECS with Fargate improved scalability tremendously. Fargate provides the containers and scales them to closely match resource requirements. Also, Fargate eliminated the need to provision and manage servers manually. This helped by allowing developers to focus on software rather than managing servers.
AWS CloudFormation gave us a chance to provision application resources in a repeatable way, allowing us to build and rebuild the infrastructure without any manual actions needed. We created AWS CloudFormation templates that acted as a single source of truth and helped us standardize infrastructure components, enabling configuration compliance and faster troubleshooting.
Using Amazon ECS with Fargate ensured availability zone spread while removing the complexity of managing EC2 infrastructure. ECS Tasks in a Replica Service are balanced across availability zones ensuring high-availability of the application. Launching Amazon RDS in Multi-AZ mode provided enhanced availability. In the case of infrastructure failover, Amazon RDS performs an automatic failover to the standby instance.
Deployment Overview
For deploying changes to the existing environment, we used AWS CodeCommit, AWS CodePipeline, AWS CodeBuild services. As a first step in the continuous delivery pipeline, we created separate AWS CodeCommit repositories for each microservice, and we created an AWS CodePipeline for each repository, so each microservice could be separately built and deployed onto the ECS cluster.
The Dockerfiles created earlier were placed in the repository of the corresponding microservice.
For each microservice, we created its own ecs-service-config.json, which AWS CodePipeline uses to deploy the ECS task and service.
Every CodePipeline consists of 4 stages:
Above: CI/CD within AWS using CodePipeline and deploying on ECS Cluster
Stage 1. AWS CodeCommit
AWS CodeCommit is a fully-managed source control service that hosts secure Git-based repositories. It makes it easy for teams to collaborate on code in a secure and highly scalable ecosystem. We created a separate repository in AWS CodeCommit for each microservice. A Dockerfile for each microservice and an ecs-service-config.json file is placed along with the source code in every repository.
AWS Cloudformation templates for creating ECS task definitions are placed in a S3 bucket. AWS CodePipeline uses this S3 bucket as a source for the CloudFormation template that deploys each microservice as an ECS service.
Stage 2. Build (AWS CodeBuild)
AWS CodeBuild is a fully managed build service that compiles source code, runs tests, and produces software packages that are ready to deploy. In this case, CodeBuild takes the Dockerfile present in the source code repository and builds a Docker image from it. Once the Docker image is built, that is pushed to the Elastic Container Registry.
To avoid installing Java SDK and other dependencies each time we build our project, we have created a custom build environment which is pre-installed with all dependencies.
Stage 3. Approval
We configured AWS CodePipelines with a manual approval step. Once the approval step is completed, CodePipeline deploys the ECS Service.
Stage 4. Deploy to ECS Cluster
Once the manual approval is completed, AWS CodePipeline will deploy the changes by updating the CloudFormation stack. Pipeline fetches the CloudFormation template from the S3 bucket, pulls the image from the Elastic Container Registry and updates the ECS Stack.
We used ecs-service-config.json file to set the path-based routing and routing priority of each microservice. Application Load Balancer was used to perform path-based routing. This JSON file is used by AWS CodePipeline parameter override during the deployment stage.