Ở phần một https://blog.vietnamlab.vn/aws-elastic-beanstalk-deployment-mode-part-1/, chúng ta đã cùng tìm hiểu tổng quan về Elastic Beanstalk là gì và các cách để triển khai một ứng dụng Elastic Beanstalk.

Phần này chúng ta cùng đi vào chi tiết làm thế nào để sử dụng các deployment mode khác nhau cũng như ưu và nhược điểm của chúng nhé.


1. Tổng quan về Elastic Beanstalk

1.1 Triển khai ứng dụng Elastic Beanstalk

Đầu tiên, chúng ta cùng nhìn lại tổng quan về quy trình triển khai ứng dụng từ lúc bắt đầu đến khi kết thúc trên Elastic BeanStalk(sau đây mình xin phép viết tắt là EB) sẽ như thế nào nhé.

  • Bước 1: Tạo 1 ứng dụng
    1z2TkbxX2RZCvA-fwSFjS5fcP3-hejSDP
  • Bước 2: Kiểm tra quá trình khởi tạo ứng dụng
    138JJA65II9skYmbcib2Wi-RXQTmKlcFU
  • Bước 3: Xem thành quả mình vừa làm được.
    1QjsnsIt4KEcXvcuH77QVksBGAHRdZjZs

Nghe chừng thì có vẻ rất đơn giản mọi người nhỉ. Nhưng ẩn sau trong đó là rất nhiều tác vụ cũng như rất nhiều cách triển khai khác nhau mà mình cần nắm rõ để phục vụ cho từng mục đích khác nhau. Cùng mình đi đến chi tiết của từng cách triển khai để hiểu hơn về định nghĩa Deployment Policy trong EB ở những mục tiếp theo nhé.

1.2 Các thành phần của ứng dụng

  • EC2 instance - Được cấu hình để chạy các ứng dụng web trên nền tảng bạn chọn. Bao gồm application với version mà bạn đã lựa chọn và Apache hoặc NGINX như một reverse proxy để nhận request
  • Instance security group - Giúp quản lý inbound outbound của các instance
  • Load balancer - Bộ cân bằng tải Elastic Load Balancing được định cấu hình để phân phối request đến ứng dụng.
  • Load balancer security group - Giúp quản lý inbound outbound của ELB
  • Auto Scaling group - Được định cấu hình để thay thế một phiên bản nếu nó bị terminated hoặc không khả dụng.
  • Amazon S3 bucket - Nơi lưu trữ mã nguồn, log và các artifacts được tạo ra khi sử dụng Elastic Beanstalk.
  • Amazon CloudWatch alarms - Hai CloudWatch alarms giám sát tải trên các instance trong môi trường. Được kích hoạt nếu tải quá cao hoặc quá thấp. Khi một alarms được kích hoạt, Auto Scaling group sẽ scale up hoặc scale down.
  • AWS CloudFormation stack - Sử dụng để khởi chạy các tài nguyên trong môi trường và apply các thay đổi cấu hình.
  • Domain name - Một domain name route đến ứng dụng, ví dụ: subdomain.region.elasticbeanstalk.com.

2. Deployment Policy

2.1 All at once

1KgHLsCrBhU_SRlH_3ID-0xcRkKMkczzk
Nhìn vào bức hình trên ta có thể thấy là với option All at once thì tất cả các Instance được triển khai cùng lúc.

  • Ưu điểm của lựa chọn này là thời gian triển khai nhanh, nhưng ngược lại nhược điểm lớn nhất của lựa chọn này là sẽ dẫn đến tình trạng bị downtime khiến cho ứng dụng của chúng ta bị dán đoạn trong lúc triển khai.

Một số hình ảnh minh hoạ về quá trình triển khai với option là All at once

  • Giao diện lựa chọn option triển khai
    1zxj_HpM9Fc9yaEjpgsIY1YgYQZuvzl2L
  • Quá trình triển khai
    1fWz5NTT-YkeYmntH3TME5n4r7tgrH8fo
  • Kết quả sau khi triển khai
    1B-wx1tKY8n6dHvfDki1PHDzLxUor3456
  • Kiểm tra trạng thái Instance sau khi triển khai
    1RVA85bYGw7wBUkBndhnKSORKB_l5uUpW
  • Kiểm tra version của ứng dụng sau khi triển khai
    1QYJIRlr87TKsYnUXI21eua5J_1eNjjFg

2.2 Rolling

1SCm464CPBTKFN4ESyYwqgJKz6gHI0jLJ
Nhìn vào bức ảnh ta cũng có thể thấy được sự khác biệt đối với cách triển khai All at oneRolling mọi người nhỉ. Cụ thể là đối với Rolling thì chúng ta sẽ deployment từng instance một.

  • Ở đây AWS có đưa cho mình một option là batch size. Như ví dụ trên hình thì mình đang để batch size là 50% (tương ứng với 2 instances). Mọi người có thể tuỳ chỉnh con số này để phù hợp với quy mô dự án mình cần triển khai.
  • Ưu điểm của lựa chọn này mình có thể dễ dàng nhìn thấy là sẽ không phát sinh quá trình downtime trong quá trình triển khai. Nhưng ngược lại thời gian triển khai của lựa chọn này sẽ nhiều hơn so với All at once.
  • Ngoài ra đối với lựa chọn là Rolling, mặc dù nó không xảy ra tình trạng downtime nhưng mà nó sẽ phát sinh vấn đề sẽ có nhiều hơn một version cùng đang chạy trên ứng dụng của chúng ta trong quá trình mình triển khai. Mọi người cùng tìm hiểu chi tiết về vấn đề này nhé.
  • Như ví dụ ở trên ta có thể thấy, tổng số instance chúng ta đang có là 4. Khi chúng ta triển khai một version mới thì 50% số instances sẽ được triển khai. Lúc đó lượng request sẽ được cơ chế Load Banlance tự động chuyển cho 50% instance còn lại dẫn đến trong quá trình triển khai version mới sẽ dẫn đến tính toàn vẹn không được đảm bảo. Vì vậy EB có một option mở rộng của Rolling được gọi là Rolling additional batch.

Một số hình ảnh mô tả cụ thể quá trình triển khai với option là Rolling

  • Giao diện lựa chọn option triển khai
    1yx2xtyznMaJi5duIIQhDqhbOqyrHNfcL
  • Quá trình triển khai
    1MU1MitACHMFhrUuH6FKxmxNUgenhXc41
  • Kết quả sau khi triển khai
    1OIvb_BDmaKjFrRmVV4q6Kc61JiXrLPHc
  • Kiểm tra trạng thái Instance sau khi triển khai
    1spzTY9gjW8YMvhWmUqY7o617cYQiEKhO
  • Kiểm tra version của ứng dụng sau khi triển khai
    1p9Qj840bAH-xWhIZ1mHWrXkNmwKRysYH

2.3 Rolling with addtional batch

1QhgSM5s6X8yAunPBMhXBVzJDqznIB8y_
Như đã đề cập ở trên, để đảm bảo tính toàn vẹn khi triển khai ứng dụng. EB đưa ra option là Rolling with additonal batch. Với lựa chọn này, chúng ta cũng đi kèm với tham số batch size nhưng thay vì chúng ta sẽ triển khai trên 50% instances đã có sẵn thì đối với lựa chọn này chúng ta sẽ tạo thêm các instances mới để triển khai nhằm đảm bảo tính toàn vẹn khi triển khai ứng dụng.

  • Ưu điểm của lựa chọn này là đã khắc phục được tính toàn vẹn khi triển khai mà lựa chọn Rolling đang gặp phải. Nhưng nó cũng có những nhược điểm nhất định như là thời gian triển khai sẽ nhiều hơn so với Rolling và một vấn đề khá quan trọng là nó sẽ phát sinh chi phí nhiều hơn hai lựa chọn ở trên vì vấn đề phải tạo thêm mới instance trong lúc triển khai.
  • Ngoài ra thì còn một vấn đề khá quan trọng đã mô tả ở trên là ứng dụng của chúng ta sẽ chạy nhiều hơn một version trong quá trình triển khai. Để khắc phục vấn đề này EB đã tiếp tục đưa đến cho chúng ta lựa chọn triển khai là Immutable mà dưới đây mình sẽ đề cập đến.

Trước khi đi đến option triển khai cuối được đề cập trong phần này, chúng ta cùng nhìn qua chi tiết về quá trình triển khai ứng dụng với option là Rolling with additional batch nhé.

  • Giao diện lựa chọn option triển khai
    11PqRWdkGbYxnNGAMJ3g8RJvPZuz2uJF_
  • Quá trình triển khai
    1bYmW2vpFjzXXAvFEjOp6MVb7gqxrntFU
    1TEiq3wW9LAJlZ1tbiJI4u5TjKyy_BJqC
  • Kết quả sau khi triển khai
    176pQE5de78HsElGiKaFPeHFMQRE7EQNz
  • Kiểm tra trạng thái Instance sau khi triển khai
    1AuzpfOmgb9C1LSPL4qiM2DkZmkLb6RJ1
    Như trên ta có thể thấy trong quá trình triển khai, EB đã tạo thêm 2 instances mới để đảm bảo tính toàn vẹn lúc triển khai.
    1m_3sJcDknuPu860lTfTcYT1btbvn2BLb
    Sau khi quá trình triển khai hoàn thành, EB sẽ dừng hoạt động 2 instances và xoá nó khỏi ứng dụng của mình.

2.4 Immutable

1EI8EdV5Xgo24mv4zQ-8h4P0mv2dtruul
Để khắc phục tình trạng cùng một lúc ứng dụng của chúng ta sẽ chạy nhiều hơn một version. EB đưa ra option được gọi là Immutable để khắc phục nó.Như hình trên ta có thể thấy, trong quá trình triển khai EB sẽ tạo thêm một group mới được cài đặt dựa trên group có sẵn, sau đó sẽ triển khai ứng dụng lên group mới này. Sau khi quá trình triển khai ứng dụng lên group mới hoàn thành. EB sẽ tạo kết nối đến group mới và ngắt kết nối đến group cũ. Cuối cùng là sẽ xoá đi các tài nguyên không sử dụng đến để tiết kiệm chi phí cho ứng dụng của mình.

  • Vậy là cuối cùng thì cũng có một option có thể khắc phục được các tình trạng như downtime, tính toàn vẹn khi triển khai, cùng một thời điểm có nhiều hơn một version được triển khai trên ứng dụng. Nhưng ngược lại nó vẫn còn một số nhược điểm đáng để chúng ta lưu ý khi sử dụng như là thời gian triển khai là nhiều nhất và chi phí dành cho quá trình triển khai là nhiều nhất trong các lựa chọn đã nêu trên.
  • Dù gì đi nữa thì nó vẫn là một lựa chọn để chúng ta đáng suy nghĩ đến khi triển khai một ứng dụng đến với người dùng được tốt nhất.
    Một số hình ảnh mô tả quá trình triển khai ứng dụng với option là Immutable
  • Cấu hình trước khi triển khai
    1dKzx4g-4cEQWUG3rZgbc0sQtXu6sHnkY
  • Giao diện lựa chọn option triển khai
    1e7x5l9qXDkNvRY7_vKw-f-AMC6_jCx30
  • Quá trình triển khai
    1PfaLEDWBgPp55BfywHrae4D1zuR2k4Gr
    1TPqGS0JLamFYR2ATmNEit3E5nGID6s9x
  • Kết quả sau khi triển khai
    1apoGm9QyaAc_zgLNihZwfVvlvMJv4v2r
  • Kiểm tra trạng thái Instance trong quá trình triển khai
    1EQyb6WgAHkmGEGEc2_BWR2SLBItfMJD3
    Chúng ta có thể thấy trong quá trình triển khai, EB đã tạo thêm một group mới và triển khai các instances mới cùng version mới trên group này.
  • Kiểm tra version của ứng dụng sau khi triển khai
    14JRmw31b3rPFnqI50rON9vN_I_yByj00
    Sau khi triển khai xong version mới trên group mới thì EB sẽ ngắt kết nối đến group cũ và bắt đầu quá trình xoá các instances ở group cũ.
    1Go2gRf55mYbbk1TDUaMqIdir46seBr2H
    Cuối cùng là xoá đi group cũ để tiết kiểm tài nguyên sử dụng cũng như chi phí đối với ứng dụng của mình.

3. Tổng kết

  • Cuối cùng chúng ta cũng tìm hiểu được các cách triển khai ứng dụng khác nhau của EB. Ngoài các lựa chọn ở trên, EB còn đưa đến cho chúng ra 2 lựa chọn nữa là Traffic SplittingBlue/Green nhưng đáng tiếc là mình chưa tìm hiểu được chi tiết về 2 option này nên chưa thể chia sẽ chi tiết cho mọi người. Hi vọng thời gian sắp tới mình sẽ có một bài viết mới về 2 lựa chọn này.
  • Mình cùng nhìn lại kết quả mình đã tìm hiểu được thông qua 2 bảng so sánh phía dưới nhé.
    1GemOXTQHaf4m-B-3cCwC062DVEZOJ1Zf

1ejUsOYEDzDmznjWumN_QkzvBM9RG5Vse

Kết bài mình hi vọng với chút kiến thức mình chia sẽ ở trên sẽ giúp mọi người có được cái nhìn cụ thể về các cách triển khai ứng dụng trên EB.Sau cùng mong mọi người sẽ tiếp tục ủng hộ mình trong các bài blog tiếp theo.

4. Tài liệu tham khảo