Blue/Green Deployments On AWS Using Terraform
- Nitin Yadav
- Blog
About
Industries
- AWS, Blue/Green Deployment, Continuous Deployment, Terraform
Share Via
Introduction
With the rapid development on how applications are build & shipped, adopting the right deployment strategy is pivotal for ensuring robust Continuous Deployment (CD) and maintaining high software quality standards. Deployment strategies play a crucial role in DevOps practices, offering varied approaches to software release and infrastructure management. In this blog, we’ll explore several key deployment strategies, emphasising their relevance in Continuous Integration and Continuous Deployment pipelines, before focusing on the Blue-Green deployment method, particularly its implementation on AWS using Terraform, a leading Infrastructure as Code (IaC) tool.
Rolling Deployment: This technique, integral to Continuous Deployment, involves incrementally updating servers with the new version. It’s highly compatible with Agile methodologies, ensuring minimal downtime and facilitating a stable Continuous Delivery process.
Canary Deployment: A strategic fit for Continuous Deployment, canary deployment targets a small segment of the production environment first. Its gradual approach aligns well with Agile and DevOps principles, allowing for real-time monitoring and quick rollback if needed.
A/B Testing Deployment: This strategy is crucial for user-centric Continuous Deployment, providing direct feedback on user engagement and experience. It’s a data-driven approach, often used in conjunction with Continuous Testing practices.
Recreate Deployment: Simple yet effective, this strategy involves downtime but is sometimes used in Continuous Deployment when zero-downtime isn’t a critical factor. It’s straightforward and suitable for applications with flexible availability requirements.
Shadow Deployment: Often used in Continuous Deployment and Continuous Testing, this strategy involves duplicating real traffic to a shadow version. It’s excellent for performance testing under real conditions without impacting the end-user experience.
Focusing on Blue-Green Deployment, this strategy is used for Continuous Deployment with zero downtime. It involves maintaining two identical environments: the Blue (current production) and Green (new version). At any given time, only one of these environments is live, serving all production traffic. When it’s time to release a new version of the software, the update is first deployed to the inactive environment (e.g., green). The switch from Blue to Green ensures minimal downtime and provides a quick rollback mechanism in case of issues, aligning seamlessly with Continuous Deployment and Continuous Integration (CI) practices.
Integrating Terraform, a prominent Infrastructure as Code tool, into Blue-Green deployment on AWS enhances the strategy. Terraform automates the creation and management of both environments, ensuring consistency and alignment with DevOps, Continuous Integration, and Continuous Deployment principles. This integration is particularly beneficial in AWS cloud environments, where managing complex infrastructures requires both precision and flexibility.
When to use Blue-Green Deployment?
There are several benefits to using blue-green deployment:
Zero downtime: By routing traffic to the new environment before taking the old one out of service, you can ensure that there is no disruption to the end users.
Easy rollback: If there are any issues with the new version of the software, you can quickly roll back by routing traffic back to the old environment.
Improved reliability: By testing the new version of the software in a separate environment before releasing it to production, you can catch and fix any issues before they affect the end users.
Confidence in Release: Blue-green deployment allows you to release software updates with confidence, knowing that you have a fallback plan in case anything goes wrong.
Integrating Terraform with EC2 Autoscaling for Blue-Green Deployments
While Blue-Green deployments offer significant advantages, integrating this strategy with tools like Terraform and EC2 Autoscaling groups presents its own set of challenges. In this section, we’ll delve into these challenges and outline the effective solutions we’ve developed at SquareOps
The problem with Terraform and EC2 Autoscaling groups
When implementing Blue-Green deployment using Terraform on AWS a key challenge emerges with EC2 Auto Scaling groups & how terraform operates. This challenge is crucial for DevOps engineers and cloud architects who rely on Terraform for infrastructure as code (IaC) practices and AWS CodeDeploy for seamless deployment processes. Addressing this issue is essential for optimizing Continuous Integration/Continuous Deployment (CI/CD) pipelines and ensuring efficient cloud resource management.
The core of the problem lies in how Terraform interacts with AWS Auto Scaling groups during a Blue-Green deployment orchestrated by AWS CodeDeploy. AWS CodeDeploy, a critical service in AWS for automating software deployments, plays a vital role in this setup. According to the AWS CodeDeploy documentation, during a Blue-Green deployment, a new Auto Scaling group is created to transition to the new version of the application.
However, when Terraform is used to create and manage these Auto Scaling groups, it does not automatically recognize or incorporate the new Auto Scaling group created by CodeDeploy into its state management. This discrepancy leads to Terraform attempting to recreate the Auto Scaling group with its original configuration during subsequent terraform apply operations. As a result, cloud engineers face errors and inconsistencies, which can disrupt the deployment process and lead to potential downtime or resource mismanagement.
To delve deeper into this topic, it’s essential to understand the intricacies of Terraform’s state management and how it interacts with AWS services. Terraform’s state file is crucial for tracking the current state of the infrastructure it manages. When external changes are made to the infrastructure that Terraform manages (in this case, by AWS CodeDeploy), Terraform’s state file does not automatically update to reflect these changes. This leads to a state mismatch, causing Terraform to try to enforce the configuration as defined in its code, which doesn’t account for the new Auto Scaling group.
Solution to Seamless Blue-Green Deployment for EC2 Autoscaling Groups with Terraform and AWS CodeDeploy
To navigate this challenge, we’ve developed an approach that ensures Terraform, AWS CodeDeploy, and EC2 Autoscaling groups work in harmony. This section provides a detailed step-by-step implementation of the solution.
1. Modify the official terraform module ( here Terraform-aws-module) to accommodate the solution requirements
Add support for an additional variable to ignore resource tag-related changes.
whenever blue/green deployments are done by AWS CodeDeploy, a new autoscaling group is created on every deployment with a new name and additional tags like deployment ID. These details are not present in the Terraform state since the AWS Code triggered the change deploy service and not Terraform. To avoid the Terraform state deviation after each deployment, we created the AWS EC2 autoscaling group’s name with a unique tag ID.
Add lifecycle policy in resource "aws_autoscaling_group to ignore_changes in tag property here –Terraform-aws-autoscaling
2. Sample Terraform code to deploy an EC2 Autoscaling group
To avoid the AWS Autoscaling group module from creating auto-scaling groups with random names, we have set use_name_prefix to false
Then using the terraform data source feature, we fetched the name of the new auto-scaling group with the help of tags and referred to it while calling the module again for any changes.
This code snippet assumes that the VPC network and AWS Application Loadbalancers are already created. To get a complete example of creating an autoscaling group using Terraform, that includes VPC and ALB as well, send an email to [email protected] to get full access to the Terraform library maintained by SquareOps
Configuring AWS CodeDeploy for Blue-Green Deployment
3. We have used Terraform to create the AWS code deploy service resources also and its configurations
This terraform code snippet creates an IAM Role and Policy for CodeDeploy that grants AWS CodeDeploy the necessary permissions to perform deployments across EC2 instances and Autoscaling groups. This role will be assumed by the CodeDeploy service. It also creates the CodeDeploy Application and sets up deployment groups ( one for each of the Blue and Green environments. )
4. Solution to the terraform state deviation problem
We also created a script that needs to be run before any terraform operations. This will import new auto-scaling groups created by AWS Codedeploy Service’s Blue-Green Deployment strategy and replace the older auto-scaling group details. Now the terraform plan and terraform apply will not create a new auto-scaling group after the CI/CD deployments.
Let us go through all the commands in this script:
a.terraform refresh command refreshes the state of terraform to identify any changes.
b. This command will match the name in outputs and state
c. If the above command gives an exit status code value other than “0”, it means the autoscaling group’s name has changed as a part of CI/CD runs.
d. The next commands will then remove the existing autoscaling group from the terraform state and import the new one. Along with the auto-scaling group, we need to import a new auto-scaling policy as well that is associated with the new autoscaling group created by AWS Codedeploy.
Conclusion
In this blog, we’ve navigated through the challenges of setting up Blue-Green deployments using AWS, Terraform, and AWS CodeDeploy. Blue-Green deployment is more than just a deployment strategy; it’s a pathway to ensuring zero downtime, enhancing the reliability of your applications, and providing a safety net through easy rollbacks.
By integrating this approach with Terraform’s powerful infrastructure as code capabilities and AWS’s scalable cloud infrastructure, we offer a solution that not only optimizes your deployment processes but also aligns with the best practices in cloud computing and DevOps.
At SquareOps Technologies, our commitment to innovation and excellence in cloud services is unwavering. We understand that every organization’s needs are unique, and our team of experts is equipped to provide tailored solutions that meet your specific requirements. Whether you’re just starting your cloud journey or looking to optimize existing systems, our comprehensive suite of services in Kubernetes, CI/CD, Observability, Infrastructure as Code, Security, and Cost Optimizations is designed to guide and support you at every step.
We invite you to reach out to us for any assistance in implementing Blue-Green deployments or other cloud and DevOps solutions. Let’s work together to transform your deployment strategy and propel your business toward greater efficiency and success.
Frequently asked questions
A Blue/Green Deployment is a strategy used to minimize downtime during application releases. It involves maintaining two identical environments: Blue (current production) and Green (new version). Traffic is switched from Blue to Green after the new version is validated, ensuring zero downtime and quick rollback if necessary.
Blue/Green Deployment ensures zero downtime, provides an easy rollback mechanism in case of failures, and allows for improved reliability by testing the new version in isolation before releasing it to production.
The primary challenge is that AWS CodeDeploy creates a new Auto Scaling group during the deployment process, but Terraform doesn’t automatically recognize or track this new group in its state. This leads to state mismatches and errors when Terraform tries to manage the Auto Scaling group.
AWS CodeDeploy automates the process of shifting traffic from the Blue environment to the Green environment. It creates a new Auto Scaling group to deploy the updated version and automatically switches traffic once the new version is validated.
EC2 Auto Scaling groups are used to automatically manage the scaling of EC2 instances based on the environment’s load. During Blue/Green Deployments, new instances are launched in the Green environment, and traffic is routed to them once they are ready.
Terraform fails to manage the new Auto Scaling group created by AWS CodeDeploy because it doesn’t automatically update its state to reflect changes made by external services. This results in Terraform trying to recreate the group, causing inconsistencies and errors.
A solution involves modifying the Terraform AWS module for Auto Scaling to accommodate changes made by AWS CodeDeploy. Specifically, we add a variable to ignore resource tag-related changes and implement a lifecycle policy to prevent Terraform from trying to update the Auto Scaling group tags during subsequent apply operations.
Terraform manages infrastructure state using a state file, which tracks resources under management. When AWS CodeDeploy creates resources like a new Auto Scaling group, Terraform doesn’t recognize the change unless the state file is updated, which leads to potential conflicts and errors.
To ensure smooth operation, you should modify the Terraform module to ignore changes to tags or resources that are updated by AWS CodeDeploy. Additionally, applying unique tag identifiers to the Auto Scaling group helps prevent state discrepancies.
Terraform simplifies the automation of infrastructure creation and management, ensuring consistent and repeatable environments for Blue/Green deployments. By combining Terraform with AWS CodeDeploy and Auto Scaling, you can effectively manage complex deployment workflows with minimal manual intervention and high reliability.
Related Posts
DevOps Services and Solutions Consulting
- Blog
Best Practices for Implementing DevSecOps: A Technical Guide
- Blog
Terraform State Management Strategies: Effectively managing Terraform state
- Blog
Zero Trust Architecture in the Cloud: Implementing a zero trust model
- Blog
Stress Testing for Resilience in Modern Infrastructure
- Blog
How DevSecOps Enables a Shift-Left Approach in Security
- Blog