Streamlining Deployment with ECS Fargate Blue-Green Deployment and CI/CD

Prerna Singh

Introduction:

 

Ensuring seamless and reliable deployments is essential in software development. Pairing Amazon ECS (Elastic Container Service) with Blue/Green Deployment strategies boosts application availability and reduces downtime. This blog discusses how to implement Blue/Green Deployment with ECS, integrated with a CI/CD pipeline using AWS tools such as CodePipeline and CodeDeploy. We will offer practical steps to establish a Blue/Green Deployment pipeline, enabling you to deliver features quickly and efficiently.



Understanding Blue-Green Deployment:

Blue/green deployment is a software deployment approach that helps organizations  to update their software smoothly and safely. They have two sets of their software running at once: the current version (blue) and the new one (green).The blue environment runs the existing software version, while the green environment runs the new version. Users only see one version live at a time. When the new version is ready, they switch over. If any issues pop up, they can quickly switch back to the old version without causing downtime.


Benefits of Blue-Green Deployment with ECS Fargate:

  1. Minimized Downtime:
    • Zero-Downtime Deployments: Traffic can be shifted from the Blue environment to the Green environment seamlessly, ensuring that users experience no downtime during the deployment.

  2. Reduced Risk:
    • Quick Rollbacks: If issues are detected with the Green environment, traffic can easily be reverted to the Blue environment, ensuring a quick rollback with minimal impact.
    • Isolated Testing: The Green environment can be tested in isolation before switching traffic, allowing for comprehensive testing without affecting the production environment.

  3. Improved Reliability:
    • Consistent Environments: By deploying in identical environments (Blue and Green), you ensure that the new version is running in an environment that mirrors production exactly.
    • Automated Health Checks: ECS Fargate can automatically perform health checks on the Green environment before traffic is switched, ensuring reliability.

  4. Enhanced Continuous Delivery:
    • Seamless Integrations: Integrates well with CI/CD pipelines, enabling automated testing, deployments, and rollbacks, facilitating a smoother continuous delivery process.
    • Progressive Delivery: Allows for phased traffic switching, such as canary releases, where only a portion of traffic is directed to the Green environment initially.

  5. Cost Efficiency:
    • Optimized Resource Usage: While there are costs associated with running two environments temporarily, ECS Fargate allows you to scale the environments based on demand, optimizing resource usage.
    • Pay-As-You-Go Model: Fargate’s pricing model helps manage costs effectively by charging only for the resources used during the deployment process.

  6. Operational Simplicity:
    • Managed Infrastructure: ECS Fargate handles the infrastructure management, allowing you to focus on application deployment and management rather than underlying infrastructure concerns.
    • Simplified Management: With Fargate, there is no need to provision or manage servers, simplifying the deployment process and reducing operational overhead.

  7. Enhanced Security:
    • Isolation: Each environment (Blue and Green) runs in isolated containers, enhancing security by reducing the risk of cross-environment contamination.
    • Secure Rollouts: Allows for secure deployment and rollback processes, ensuring that any vulnerabilities in the new deployment can be quickly mitigated by reverting to the previous environment.

  8. Scalability:
    • Auto-Scaling: ECS Fargate supports auto-scaling, ensuring that both Blue and Green environments can handle varying loads without manual intervention.
    • Flexible Resource Allocation: Resources can be dynamically allocated based on the requirements of each environment, ensuring efficient scaling and performance.

Understanding CI/CD Integration with ECS Fargate:


To integrate CI/CD with ECS Fargate we will be utilizing the AWS codepipeline.
Configure all the necessary stages including source code, build and deploy for setting up a CI/CD.

  1. Source Stage:
    The source stage is where the pipeline begins, fetching your application’s source code from a version control system like GitHub or AWS CodeCommit. It initiates the pipeline whenever there’s a change in the chosen repository, pulling in the source code along with any Dockerfiles or application code. Configuration involves selecting the repository and branch to monitor for changes, and you can also establish webhooks or event notifications to automatically trigger the pipeline.

  2. Build Stage:
    In the build stage, your application undergoes compilation, packaging, and readiness for deployment. Specifically within ECS, this phase revolves around constructing Docker images from your application’s code and Dockerfiles for which AWS codebuild utilizes buildspec.yml file which contains all the build steps. These images encapsulate all components necessary for running your application. Configuration entails defining build commands or scripts, pinpointing Dockerfile locations, and outlining any additional dependencies essential for generating your application’s artifacts.

  3. Deploy Stage:

    The deploy stage handles the deployment of your application to the ECS cluster. It takes the Docker images produced in the build stage and executes deployment to ECS Fargate or EC2 instances. This phase involves updating the ECS task definitions with the latest container images and overseeing the deployment process. Configuration includes supplying ECS cluster specifics, defining task definitions, specifying container image repositories (like Amazon ECR), and setting other deployment parameters such as service names or desired task counts.

Integrating Blue-Green Deployment with ECS Fargate:

Files to be added in source code repo:
To integrate blue-green deployment with ECS fargate we need to add 2 files namely taskdef.json and appspec.yaml in the root directory of your source code repository in our case i.e. AWS code commit.

 

  1. taskdef.json:

    Purpose: The taskdef.json file is used to define how your containerized application should run within ECS. It includes configuration details such as the Docker image to use, CPU and memory requirements, environment variables, networking settings, and any data volumes to mount.

    Usage: This file is essential for ECS to understand how to run your application. It serves as a blueprint for ECS to create and manage tasks based on your specifications.
    In the source code repo create a file with the name taskdef.json paste the exsisting content  of taskdef file and edit image section to add <IMAGE_1> as highlighted in below snapshot:

    NOTE:
    <IMAGE_1>  is a placeholder for the Docker image URI, typically stored in a Docker image repository such as Amazon ECR, During deployment, <IMAGE_1> will  be replaced dynamically with something like  123456789012.dkr.ecr.us-east-1.amazonaws.com/my-image:latest

  2. appspec.yaml

    Purpose: The appspec.yaml file is used by AWS CodeDeploy to manage the deployment process. It defines the deployment lifecycle events and scripts that should be executed during each stage of deployment.

    Usage:
    This file provides instructions to CodeDeploy on how to deploy your application to ECS Fargate. It specifies actions such as pulling the latest Docker image, updating the ECS service with the new task definition, and executing any necessary validation or cleanup tasks.

    In the source code repo create another file named appspec.yaml, paste the following code in it and push it to the root directory of your  repository.

    NOTE:
    Replace “dev-info-service” with the actual name of your container.
    Replace “80” with your actual container port.

 

 

 

Changes to be done in existing Buildspec.yml:
In the exsisting buildspec.yml file add the below line in the post build commands section to generate imageDetail.json as highlighted in below snapshot:

Now in the artifacts stage add imageDetail.json, appspec.yaml and taskdef.json as highlighted in below snapshot:

 

 

And update the buildspec to save the changes.


Changes to be done in CodePipeline configuration:


Now for our codepipeline to utilize  the appspec.yml and taskdef.json file during deployment we need to integrate these files to codedeploy for which in the existing pipeline edit the deployment stage:

 






After that in Amazon ECS task definition and AWS CodeDeploy AppSpec file choose BuildArtifact from the dropdown and if you have given any other name to your taskdef.json and appsepc.yaml manually specify the names besides the BuildArtifact section.Also in the Placeholder text in the task definition write <IMAGE1_NAME> as highlighted in below snapshot:

 

And update the pipeline to save the changes.

 

Conclusion:

 

In summary, employing Blue-Green Deployment with Amazon ECS Fargate, integrated into a comprehensive CI/CD pipeline, delivers a highly efficient and reliable deployment workflow. This methodology ensures zero-downtime updates, mitigates deployment risks, and boosts scalability, all while simplifying operational processes. Automation of testing, deployments, and rollbacks facilitates continuous delivery, empowering organizations to accelerate innovation and maintain high application availability. This approach not only maximizes resource efficiency but also strengthens security, making it an indispensable solution for contemporary DevOps methodologies.

About Author

Prerna Singh is a DevOps Engineer and Certified Solutions Architect Associate. Her passion lies in constantly learning, improving, and evolving to stay up-to-date with the latest technologies and trends.

Take your company to the next level with our DevOps and Cloud solutions

We are just a click away

Related Post

ELG Setup Blog

Introduction: In today’s fast-paced digital landscape, efficient log management and analysis are crucial for businesses to maintain operational efficiency, security, and troubleshooting capabilities. The ELG

Read More »