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

Giới thiệu Chào các bạn tới với series về Terraform, ở bài trước chúng ta tìm hiểu về Zero-downtime deployments, nhưng ta chỉ mới tìm hiểu cách thực hiện ZDD cho một resource đơn giản là EC2. Ở bài này ta sẽ tìm hiểu cách thực hiện ZDD cho một resource phức tạp hơn là

Giới thiệu

Chào các bạn tới với series về Terraform, ở bài trước chúng ta tìm hiểu về Zero-downtime deployments, nhưng ta chỉ mới tìm hiểu cách thực hiện ZDD cho một resource đơn giản là EC2. Ở bài này ta sẽ tìm hiểu cách thực hiện ZDD cho một resource phức tạp hơn là Autoscaling Group bằng phương pháp Blue/Green deployments.

Bài này mình tham khảo từ cuốn Terraform in Action, các bạn nên đọc thử cuốn này vì nó rất hay 😁.

Blue/Green deployments

Blue/Green deployments là một phương pháp giúp ta thực hiện Zero-downtime khi triển khai một version mới của ứng dụng. Đây là phương pháp cũ nhất nhưng lại được sử dụng nhiều nhất, các phương pháp cải tiến hơn của Blue/Green deployments là Rolling Blue/Green hoặc Canary deployments.

Để thực hiện Blue/Green deployment thì ứng dụng của ta sẽ có hai môi trường production, một thằng sẽ được gọi là Blue và một thằng được gọi là Green, chỉ một trong hai thằng này sẽ ở trạng thái live để nhận request của user, còn một thằng con lại sẽ ở trạng thái idle (không làm việc).

Khi ta muốn triển khai version mới của ứng dụng, ta sẽ triển khai trên môi trường đang ở trạng thái idle (có thể là Blue hoặc Green), sau đó ta kiểm ta mọi thứ trên môi trường idle đã hoạt động ổn hết thì ta chuyển router từ môi trường live sang idle.

Blue/Green deployments with Autoscaling Group

Trong bài này chúng ta sẽ làm ví dụ Blue/Green deployments cho resource Autoscaling Group trên AWS. Kiến trúc của ta sẽ bao gồm:

  • Virtual Private Cloud (VPC).
  • Application Load Balancer (ALB).
  • 2 Autoscaling Group (Blue/Green).

Base resource and Application resource

Khi thực hiện Blue/Green deployments, việc đầu tiên ta cần làm là xác định resource nào là base resource và resource nào là application resource. Với base resource là các thành phần được sử dụng chung và sẽ không thay đổi nhiều trong quá trình deploy, còn application resource có thể thay đổi nhiều trong quá trình deploy, thậm chí có thể xóa nó luôn và tạo lại thằng mới mà không ảnh hưởng gì tới hệ thống của ta.

Ví dụ với mô hình Autoscaling Group ở trên thì các thành phần thuộc base resource là VPC và ALB, còn application resource là Autoscaling Group. Khi ta triển khai một version mới của ứng dụng thì chắc chắn là VPC của ta sẽ giữ nguyên không thay đổi gì (bởi vì chả có lý do gì mà ta cần phải tạo mới VPC để deploy version mới của ứng dụng cả), còn ALB thì có thể thay đổi một chút. Còn Autoscaling Group thì ta có thể xóa thằng cũ và tạo lại thằng mới cũng được.

Đối với các resource dùng để lưu dữ liệu như là database, thì để chuyển đổi database giữa các môi trường là một vấn đề rất phức tạp nên thông thường ta sẽ xếp database vào trong base resource.

image.png

Và khi deploy ta chỉ cần tác động tới application resource, sau đó ta sẽ tiến hành thực hiện chuyển traffic của application resource từ môi trường live sang idle, có thể là tự động hoặc làm bằng tay.

Implement

Ta sẽ có một Autoscaling Group cho version 1.0, và ta gán cho nó là Green. Sau đó ứng dụng của ta sẽ có version mới là 2.0, ta sẽ tạo thêm một Autoscaling Group cho version 2.0 và gán cho nó là Blue. Hiện tại thì Green sẽ là môi trường live, còn Blue sẽ là môi trường idle.

Và sau đó ta sẽ tiến hành chuyển router cho traffic từ Green sang Blue bằng tay (việc chuyển router như vậy được gọi là cutover). Tạo một file tên là main.tf với đoạn code sau.

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
}

Ở trên ta sẽ sử dụng module là terraform-in-action/aws/bluegreen cho ví dụ này, trong module trên có base resource là VPC với ALB từ submodule modules/autoscaling, còn application resource là Autoscaling Group từ submodule modules/autoscaling.

Ứng dụng version 1.0 của ta được deploy bằng submodule terraform-in-action/aws/bluegreen//modules/autoscaling và ta đặt tên cho nó là green.

Oke, giờ tiến hành deploy version 1.0 nào.

$ 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"

Đợi khi terraform chạy xong thì nó sẽ in ra cho ta domain của alb, ta truy cập vào domain đó.

image.png

Tiếp theo ta sẽ deploy version 2.0 của ứng dụng và đặt tên cho nó là blue.

...
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
}
...

Chạy câu lệnh.

$ 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"

Sau khi ta kiểm tra mọi thứ ở môi trường blue đều ổn hết, ta tiến hành đổi router của traffic vào ứng dụng.

Blue/Green cutover

Các bạn làm việc này bằng một cách đơn giản là thay đổi giá trị của biến production trong file main.tf.

Chuyển giá trị từ green.

...
variable "production" {
  default = "green"
}
...

Thành blue.

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
}

Chạy câu lệnh apply.

$ 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"

Sau khi terraform chạy xong, nó sẽ chuyển target group từ Autoscaling Group Green sang Blue. Ta tải lại trang và các bạn sẽ thấy nó chuyển thành blue với version 2.0.

image.png

Oke, ta làm một ví dụ đơn giản về Blue/Green deployments thành công 😁. Khi ta thực hiện Blue/Green deployments thế này thì ta có thể giảm thời gian downtime của ứng dụng nhiều nhất có thể.

Bây giờ thì ta đang có hai môi trường production là Green và Blue, nếu ta lại có một version mới của ứng dụng là 3.0, ta chỉ việc cập nhật giá trị app_version của module green lại thành 3.0 và chuyển giá trị của biến production lại thành green.

Ta nhớ chạy câu lệnh destroy để xóa resource nhé.

Kết luận

Vậy là ta đã tìm hiểu xong về Blue/Green deployments, đẩy chỉ là một trong những phương pháp để thực hiện Zero-downtime deployments, các bạn có thể tìm hiểu thêm về Rolling Blue/Green deployments và Blue/Green deployments để ta có nhiều sự lựa chọn hơn nữa khi deploy. Nếu có thắc mắc hoặc cần giải thích rõ thêm chỗ nào thì các bạn có thể hỏi dưới phần comment. Hẹn gặp mọi người ở bài tiếp theo ta sẽ tìm hiểu về cách sử dụng Terraform with Ansible.

Mục tìm kiếm đồng đội

Hiện tại thì công ty bên mình, là Hoàng Phúc International, với hơn 30 năm kinh nghiệm trong lĩnh vực thời trang. Và sở hữu trang thương mại điện tử về thời trang lớn nhất Việt Nam. Team công nghệ của HPI đang tìm kiếm đồng đội cho các vị trí như:

Với mục tiêu trong vòng 5 năm tới về mảng công nghệ là:

  • Sẽ có trang web nằm trong top 10 trang web nhanh nhất VN với 20 triệu lượt truy cập mỗi tháng.
  • 5 triệu loyal customers và có hơn 10 triệu transactions mỗi năm.

Team đang xây dựng một hệ thống rất lớn với rất nhiều vấn để cần giải quyết, và sẽ có rất nhiều bài toàn thú vị cho các bạn. Nếu các bạn có hứng thú trong việc xây dựng một hệ thống lớn, linh hoạt, dễ dàng mở rộng, và performance cao với kiến trúc microservices thì hãy tham gia với tụi mình.

Nếu các bạn quan tâm hãy gửi CV ở trong trang tuyển dụng của Hoàng Phúc International hoặc qua email của mình nha [email protected]. Cảm ơn các bạn đã đọc.

Nguồn: viblo.asia

Bài viết liên quan

Thay đổi Package Name của Android Studio dể dàng với plugin APR

Nếu bạn đang gặp khó khăn hoặc bế tắc trong việc thay đổi package name trong And

Lỗi không Update Meta_Value Khi thay thế hình ảnh cũ bằng hình ảnh mới trong WordPress

Mã dưới đây hoạt động tốt có 1 lỗi không update được postmeta ” meta_key=

Bài 1 – React Native DevOps các khái niệm và các cài đặt căn bản

Hướng dẫn setup jenkins agent để bắt đầu build mobile bằng jenkins cho devloper an t

Chuyển đổi từ monolith sang microservices qua ví dụ

1. Why microservices? Microservices là kiến trúc hệ thống phần mềm hướng dịch vụ,