Terraform Series - Bài 11 - Terraform Blue/Green deployments
Bài viết gốc - Bài 11 - Terraform Blue/Green Deployment
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.
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 sẽ 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 đó.
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 của ALB 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.
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 down time 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à Canary deployments để ta có thêm nhiều sự lựa chọn nữa khi tiến hành deploy ứng dụng với version mới. 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ề một phương pháp deployment tiếp theo là A/B Testing Deployment.
DevOps VN
Học DevOps tại các trung tâm uy tín.
Kiến thức dinh dưỡng IT.
Ủng hộ trang tại đây.
All rights reserved
