Terraform Series – Bài 10 – Terraform Blue/Green deployments

Tram Ho

## Introduction Welcome to the Terraform series, in the previous post we learned about Zero-downtime deployments, but we just learned how to do ZDD for a simple resource, EC2. In this article, we will learn how to implement ZDD for a more complex resource than Autoscaling Group using Blue/Green deployments method. ![](https://images.viblo.asia/66d5204c-526a-4766-a4a0-71a2d778406e.jpg) This article is from the book Terraform in Action, you should read this book because it’s very good ?. ## Blue/Green deployments Blue/Green deployments is a method to help us achieve zero-downtime when deploying a new version of an application. This is the oldest but most used method, the more improved methods of Blue/Green deployments are Rolling Blue/Green or Canary deployments. To perform Blue/Green deployment, our application will have two production environments, one will be called Blue and the other is called Green, only one of these two will be in a **live** state. receive the user’s request, and another son will be in the **idle** state (not working). When we want to deploy a new version of the application, we will deploy on an idle environment (be it Blue or Green), then we check that everything on the idle environment is working fine. Switch the router from live to idle. ![](https://images.viblo.asia/280fc352-93a7-4af7-b86e-6271943d1c76.jpg) ### Blue/Green deployments with Autoscaling Group In this article we will make example Blue/Green deployments for resource Autoscaling Group on AWS. Our architecture will include: + Virtual Private Cloud (VPC). + Application Load Balancer (ALB). + 2 Autoscaling Group (Blue/Green). ![](https://images.viblo.asia/dd438d8a-1c1c-4916-8ee1-b18c2b5a4b36.jpg) ### Base resource and Application resource When implementing Blue/Green deployments, the first thing we need to do is verify Determine which resource is the base resource and which is the application resource. With base resources being shared components and will not change much during deployment, application resources can change a lot during deployment, even deleting it and creating a new one without affecting How does it affect our system? For example, with the Autoscaling Group model above, the components of the base resource are VPC and ALB, and the application resource is the Autoscaling Group. When we deploy a new version of the application, it is certain that our VPC will remain unchanged (because there is no reason why we need to create a new VPC to deploy the new version of the application), and The ALB may vary slightly. As for Autoscaling Group, we can delete the old guy and create a new one. > For resources used to store data such as databases, to convert databases between environments is a very complicated problem, so usually we will put the database in the base resource. ![image.png](https://images.viblo.asia/3656e57e-6da1-4248-bf23-1b818b26597a.png) And when deploying we only need to affect the application resource, then we will proceed to perform the migration application resource traffic from live to idle, can be automated or manual. ### Implement We will have an Autoscaling Group for version 1.0, and we will assign it Green. Then our application will have a new version of 2.0, we will create an Autoscaling Group for version 2.0 and assign it to Blue. Currently, Green will be the live environment, and Blue will be the idle environment. And then we will proceed to manually switch the router for traffic from Green to Blue (such a router switch is called **cutover**). Create a file named `main.tf` with the following code. “`main.tf provider “aws” { region = “us-west-2” } variable “production” { default = “green” } module “base” { source = “terraform-in-action/aws/bluegreen/ /modules/base” production = var.production } module “green” { source = “terraform-in-action/aws/bluegreen//modules/autoscaling” app_version = “v1.0” label = “green” base = module. base } output “lb_dns_name” { value = module.base.lb_dns_name } “` Above we will use the module `terraform-in-action/aws/bluegreen` for this example, in the above module there will be a base resource of VPC with ALB from submodule `modules/autoscaling`, and application resource as Autoscaling Group from submodule `modules/autoscaling`. Our version 1.0 application was deployed using the submodule `terraform-in-action/aws/bluegreen//modules/autoscaling` and we named it green. Ok, now let’s deploy version 1.0. “` $ terraform apply -auto-approve … Plan: 34 to add, 0 to change, 0 to destroy. … Apply complete! Resources: 34 added, 0 changed, 0 destroyed. Outputs: lb_dns_name = “terraforminaction-ovgcpc-lb-909615962.us-west-2.elb.amazonaws.com” “` Wait when the terraform finishes running, it will print out the domain of ALB, we access that domain . ![image.png](https://images.viblo.asia/a4f199c3-f2ab-4599-b43e-75e5da694d09.png) Next we will deploy version 2.0 of the application and name it blue. “`main.tf … module “green” { source = “terraform-in-action/aws/bluegreen//modules/autoscaling” app_version = “v1.0” label = “green” base = module.base } module “blue” { source = “terraform-in-action/aws/bluegreen//modules/autoscaling” app_version = “v2.0” label = “blue” base = module.base } … “` Run the command . “` $ terraform apply -auto-approve … Plan: 5 to add, 0 to change, 0 to destroy. … Apply complete! Resources: 5 added, 0 changed, 0 destroyed. Outputs: lb_dns_name = “terraforminaction-ovgcpc-lb-909615962.us-west-2.elb.amazonaws.com” “` After we check everything in blue environment is ok, we proceed to change the traffic router into the application. ### Blue/Green cutover You do this by simply changing the value of the `production` variable in the `main.tf` file. Transfer value from green. “`main.tf … variable “production” { default = “green” } … “` To blue. “`main.tf provider “aws” { region = “us-west-2” } variable “production” { default = “blue” // change here } module “base” { source = “terraform-in-action/ aws/bluegreen//modules/base” production = var.production } module “green” { source = “terraform-in-action/aws/bluegreen//modules/autoscaling” app_version = “v1.0” label = “green” base = module.base } module “blue” { source = “terraform-in-action/aws/bluegreen//modules/autoscaling” app_version = “v2.0” label = “blue” base = module.base } output “lb_dns_name ” { value = module.base.lb_dns_name } “` Run the apply statement. “` $ terraform apply -auto-approve … Plan: 0 to add, 2 to change, 0 to destroy. … Apply complete! Resources: 0 added, 2 changed, 0 destroyed. Outputs: lb_dns_name = “terraforminaction-ovgcpc-lb-909615962.us-west-2.elb.amazonaws.com” “` Once the terraform finishes running, it will change the target group of ALB from Autoscaling Group Green to Blue. We reload the page and you will see it turn blue with version 2.0. ![image.png](https://images.viblo.asia/7c4b12da-dd0d-4ab8-b226-0f2131e56066.png) Ok, let’s make a simple example of successful Blue/Green deployments ?. When we do Blue/Green deployments like this, we can reduce the application down time as much as possible. Now that we have two production environments, Green and Blue, if we have a new version of our application 3.0, we just need to update the app_version value of `module green` back to 3.0 and change the value of the variable. `production` becomes green again. **Remember to run destroy command to delete resources.** ## Conclusion So we have learned about Blue/Green deployments, this is just one of the methods to do Zero-downtime deployments, guys. You can learn more about Rolling Blue/Green deployments and Canary deployments so that we have more choices when deploying the application with the new version. If you have any questions or need more clarification, you can ask in the comment section below. See you in the next post, we’ll learn how to use **Terraform with Ansible**. ## Search for teammates ![](https://images.viblo.asia/17647fc7-67d1-44a8-aae1-a8a1f2266351.jpg) Currently, our company, Hoang Phuc International, with more than 30 years experience in the fashion industry. And owns the largest fashion e-commerce site in Vietnam. HPI’s technology team is looking for teammates for positions such as: + Senior Backend Engineer (Java). Link JD: https://tuyendung.hoang-phuc.com/job/senior-backend-engineer-1022 + Senior Front-end Engineer (VueJS). https://tuyendung.hoang-phuc.com/job/senior-frontend-engineer-1021 + Junior Backend Engineer (Java). https://tuyendung.hoang-phuc.com/job/junior-backend-engineer-1067 + Junior Front-end Engineer (VueJS). https://tuyendung.hoang-phuc.com/careers/job/1068 + App (Flutter). https://tuyendung.hoang-phuc.com/job/mobile-app-engineer-flutter-1239 + Senior Data Engineer. https://tuyendung.hoang-phuc.com/job/seniorjunior-data-engineer-1221 With the goal within the next 5 years in the technology field are: + There will be a website in the top 10 fastest websites in Vietnam with 20 million visits per month. + 5 million loyal customers and more than 10 million transactions per year. The team is building a very large system with a lot of problems to solve, and there will be a lot of interesting lessons for you. If you are interested in building a large, flexible, scalable, and high-performance system with microservices architecture, then join us. If you are interested, please send your CV on the recruitment page of Hoang Phuc International or via my email `hmquan08011996@gmail.com`. Thank you for reading.

Share the news now

Source : Viblo