AWS Fargate: From Start to DevSecOps

Test, Roll Back, and Deploy:

During this blog, I will go through each and every AWS service that was leveraged to build a robust infrastructure such as Amazon ECS on AWS Fargate, AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy, AWS CDK, and many other services that we will discuss later in this article. Together, these services help you securely store, version control your Node.js application source code, automatically build, test, and deploy your application to AWS.

To start with, instead of manually creating all the services that we have mentioned above, AWS CDK (TypeScript) was used to automate the provisioning of the infrastructure shown in the below diagram while using code reviews and revision controls to review stack changes and keep an accurate history of the running resources. AWS CDK is an open-source software development framework to define your cloud application resources using familiar programming languages.

We will now go through the provisioning process of this application and explain how a fully functional production environment was created with the help of AWS CDK Stacks to achieve a successful Dockerized deployment with minimal effort. Three stacks were created where the first one will be responsible for creating all the networking components of this infrastructure (VPC, Subnets, NAT Gateway, Internet Gateway, etc.), the second one will create the ECS Cluster along with its Task Definition, and ECS Service, and the Application Load Balancer with Two Target Groups. Finally, the third stack will be responsible for creating the CI/CD Pipeline with all the needed configurations needed to complete this setup. One thing to mention here is that CDK for CodeDeploy does not currently support the Blue/Green deployment with CodeDeploy feature so this had to be configured from the console manually.

The first stage of the pipeline will fetch the latest Git version of the Dockerized application from GitHub and execute the build stage. Now that the source stage of CodePipeline has the latest Git version, AWS CodeBuild is now ready to start the build tasks that will first build our docker image, and automatically scan it for known vulnerabilities as well as the severity of the outdated libraries or CVE records right after pushing it to Amazon ECR. This build method will automatically scan the docker image for known vulnerabilities so as soon as we push the build, Amazon ECR will return all the discovered vulnerabilities as well as the severity of the outdated libraries or CVE records. So, what if a high or medium risk vulnerability was found? In this case, a bash script will get executed in the buildspec.yml file to check for high and medium severity vulnerabilities and fail the build automatically in the event of discovering a security threat preventing the pipeline from starting the deployment stage, else it will proceed to the deployment stage.

After successfully completing the build, CodeDeploy gets triggered and starts with deploying a replacement task set (or green task set) that has the latest task definition and docker image attached to it. Once the ECS Task status is "Running" CodeDeploy will use the AllAtOnce method to reroute the production traffic to the new replacement task set via the Green ALB Target Group and automatically roll back to the last known good version of the application revision if a deployment fails. Finally, CodeDeploy will wait for 1 hour before it terminates the original task set (or blue task set).

In conclusion:
AWS provides users with several deployment strategies that best meet the user's case and scenario (Canary, Linear, All-at-once). Moreover, ECS Blue/Green Deployments with CodeDeploy also supports adding a test listener port if you want to test your replacement version before traffic reroutes to it. This will allow you to run validation tests with the help of "AfterAllowTestTraffic" lifecycle hook Lambda function that can be updated in your AppSpec.yml file. I think it's really exciting to start getting your hands dirty with these deployments and improve your use cases gradually to get a fully DevSecOps strategy that best fits your organizational culture.

Happy deploying!