Giới thiệu Elastic Beanstalk
AWS Elastic Beanstalk là một dịch vụ dễ sử dụng để triển khai và mở rộng các ứng dụng web và dịch vụ được phát triển bằng Java, .NET, PHP, Node.js, Python, Ruby, Go và Docker trên những máy chủ quen thuộc như Apache, Nginx, Passenger và IIS.
4 chiến lược deploy của Elastic Beanstalk
Elastic Beanstalk có 4 chiến lược để deploy:
- All at Once
- Rolling
- Rolling with additional batch
- Immutable
All at Once
All at Once là chiến lược deploy version mới tất cả các instance hiện có cùng 1 lúc.
Ở trong hình trên ta có 4 instance đang chạy version 1 của phần mềm và đang cần deploy lên version 2
Khi đó, chiến lược All at Once sẽ update version cho tất cả các instance như dưới đây. Điều đó sẽ dẫn đến cả 4 instance sẽ tạm ngừng hoạt động trong 1 khoảng thời gian gọi là downtime.
Sau khi deploy, tất cả các instance sẽ đều có version 2.
All at Once là chiến lược có downtime lớn nhất nhưng cũng có thời gian deploy nhanh nhất, đơn giản nhất.
Rolling
Rolling là chiến lược deploy có sử dụng batch
Khi deploy với Rolling, chúng ta cần định nghĩa batch size. Ở đây ở batch size là 50%.
Với batch size là 50% thì khi deploy sẽ có 2 instance được deploy trước. Khi này, capacity còn 50%
Sau khi deploy xong 50%, có 2 instance đã được update version mới. Sau đó mới là update 2 instance còn lại. Khi này, capacity là 100% nhưng user có thể truy cập vào version khác nhau của hệ thống
Sau đó, 2 instance còn lại cũng được update lại version mới. Quá trình giống trên.
Cuối cùng thì cả 4 instance được update.
Theo như quá trình như trên, Rolling sẽ không có downtime, nhưng người dùng sẽ gặp phải trường hợp có nơi version cũ, có nơi version mới. Và vấn đề về capacity cũng có thể ảnh hưởng tới tốc độ truy cập.
Rolling with additional batch
Về căn bản thì cái này nó cũng giống Rolling nhưng sẽ deploy thêm instance để sao cho capacity là 100%
Trước hết thì cũng đặt batch size là 50% như Rolling
Tiếp đó, hệ thống sẽ thêm 2 instance mới với version mới vào Auto Scaling group. Capacity là 100%
2 instance mới được attach vào hệ thống. User lúc này có khả năng sẽ truy cập vào các version khác nhau tại thời điểm này
Ngắt 2 instance version 1 ra và deploy version 2 vào 2 instance ấy. Hệ thống vẫn có 4 instance hoạt động với capacity 100%
Sau đó, hệ thống sẽ có 4 instance version 2 và 2 instance version 1. Ngắt kết nối 2 instance version 1 kia và ngắt chúng sẽ deploy xong
Rolling with additional batch khác Rolling ở chỗ deploy thêm instance để giữ cho capicity là 100%. Không gây ảnh hưởng tốc độ.
Immutable
Immutable là cách deploy mà không làm ảnh hưởng đến các version hiện có
Chúng ta lại có hình ảnh quen thuộc với 1 ứng dụng có 4 instance ở version 1
Khi áp dụng chiếc lược Immutable, 1 Auto Scaling Group mới sẽ được tạo ra với 1 instance được deploy version 2
Khi Auto Scaling Group mới và instance có version 2 được tạo thành công, Load Balancer sẽ kết nối tới Instance có version 2
Lúc này, trong Auto Scaling Group mới, có 3 instance version 2 được deploy thêm.
Kết thúc bước trên, Load Balancer được kết nối với 8 instance ở 2 Auto Scaling Group.
Bước cuối cùng, Load Balancer sẽ ngắt kết nối tới các instance cũ và việc deploy hoàn thành.
Chiến lược này sẽ không cho downtime, nhưng thời gian deploy là lâu nhất.
Lựa chọn môi trường và các deploy
| Môi trường | Lựa chọn |
|---|---|
| Instance đơn | All at Once |
| Immutable | |
| Load Balancer, Auto Scaling Group | All at Once |
| Rolling | |
| Rolling with additional batch | |
| Immutable |
Blue/Green
Các chiến lược deploy kia rất hay, trừ việc ngay cả không có downtime thì đều có tình huống: Trong thời gian deploy, các user khác nhau có thể truy cập vào các version khác nhau
Vì vậy, Blue/Green deploy được tạo ra để trong thời gian deploy, người dùng sẽ truy cập chỉ 1 version của ứng dụng.
Blue/Green deploy
Chúng ta lại có 1 hệ thống có 4 instance với v1.
Đầu tiên, môi trường sẽ được clone lại. 2 hệ thống sẽ giống nhau về mọi mặt ngoại trừ DNS.
Sau đó, ở hệ thống thứ 2 sẽ thực hiện deploy theo chiến lược All at Once. Do hệ thống thứ 2 chưa được công khai nên sẽ không có vấn đề gì.
Sau khi có hệ thống với version mới, DNS sẽ được thay đổi và việc deploy hoàn thành
Blue/Green khác gì Immutable
Bình thường nhìn từ kết quả vào thì nhau, nhưng như giải thích ở trên, Immutable vẫn xảy ra sự lẫn lộn version khi truy cập, còn Blue/Green thì không.
Blue/Green Dploy thì tạo hẳn 1 môi trường mới, còn Immutable chỉ diễn ra ở 1 môi trường
Leave a Reply