Quân HuỳnhGiới thiệu
Ở bài trước chúng ta tìm hiểu về Zero-downtime Deployment, 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 Deployment.
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 Deployment
Blue/Green Deployment là một phương pháp giúp ta thực hiện Zero-downtime khi triển khai một phiên bản 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 Deployment là Rolling Blue/Green hoặc Canary Deployment.
Để 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 yêu cầu 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 phiên bản 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 điều hướng từ môi trường live sang idle.
Autoscaling Group
Trong bài này chúng ta sẽ làm ví dụ Blue/Green Deployment 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 và Application
Khi thực hiện Blue/Green Deployment việc đầu tiên ta cần làm là xác định resource nào là Base và resource nào là Application. Với Base là các thành phần được sử dụng chung và sẽ không thay đổi nhiều trong quá trình triển khai, còn Application có thể thay đổi nhiều trong quá trình triển khai, 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.
Ví dụ với mô hình Autoscaling Group ở trên thì các thành phần thuộc Base là VPC và ALB, còn Application là Autoscaling Group. Khi ta triển khai một phiên bản 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 để triển khai phiên bản mới của ứng dụng). Còn Autoscaling Group thì ta có thể xóa thằng cũ và tạo lại thằng mới cũng không ảnh hưởng.
Đối với các resource dùng để lưu dữ liệu như 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.
Khi triển ta chỉ cần tác động tới Application, sau đó ta sẽ tiến hành thực hiện chuyển yêu cầu của Application từ môi trường live sang idle (tự động hoặc thủ công).
Thực thi
Ví dụ ta có một Autoscaling Group phiên bản 1.0 và gán cho nó là Green. Sau đó ứng dụng của ta có phiên bản mới là 2.0, ta sẽ tạo thêm một Autoscaling Group cho phiên bản 2.0 và gán cho nó là Blue. Lúc này Green sẽ là môi trường live, còn Blue sẽ là môi trường idle.
Tiếp theo ta sẽ tiến hành chuyển điều hướng cho yêu cầu từ Green sang Blue bằng cách thủ công (việc chuyển điều hướng như vậy được gọi là cutover). Tạo một tệp tin 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 là VPC với ALB từ Submodule modules/autoscaling, còn Application là Autoscaling Group từ Submodule modules/autoscaling.
Ứng dụng phiên bản 1.0 của ta được triển khai bằng Submodule terraform-in-action/aws/bluegreen//modules/autoscaling và ta đặt tên cho nó là Green. Tiến hành triển khai phiên bản 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"Khi Terraform chạy xong nó sẽ in ra đường dẫn của ALB, ta truy cập vào đường dẫn đó.
Tiếp theo ta sẽ triển khai phiên bản 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 kiểm tra mọi thứ ở môi trường Blue đều ổn, ta tiến hành đổi điều hướng của ứ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 tệp tin 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. Tải lại trang thì các bạn sẽ thấy nó chuyển thành Blue với phiên bản 2.0.
Ta đã làm một ví dụ đơn giản về Blue/Green Deployment thành công 😁. Khi ta thực hiện Blue/Green Deployment thế này thì ta có thể giảm thời gian chết 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 phiên bản 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 Deployment, đây chỉ là một trong những phương pháp để thực hiện Zero-downtime Deployment. Các bạn có thể tìm hiểu thêm về Rolling Blue/Green Deployment và Canary Deployment để ta có thêm nhiều sự lựa chọn nữa khi tiến hành triển khai ứng dụng với phiên bản mới. Ở bài tiếp theo ta sẽ tìm hiểu về A/B Testing Deployment.
Tác giả Quân Huỳnh
Nếu bài viết có gì sai hoặc cần cập nhật thì liên hệ Admin.
Tham gia nhóm chat của DevOps VN tại Telegram.
Kém tiếng Anh và cần nâng cao trình độ giao tiếp: Tại sao bạn học không hiệu quả?
Bài viết cùng series
