Blue-green deployment là gì?

Blue-green deployment là một kỹ thuật phát triển phần mềm sử dụng 2 môi trường production (một "Blue environment" và một "Green environment") để làm cho quy trình triển khai phần mềm an toàn hơn. Đây là một chiến lược triển khai tương đối phức tạp nhưng hiệu quả trong việc giảm thiểu thời gian downtime(ngưng hoạt động) khi cập nhật ứng dụng của bạn trong môi trường production.

Hai môi trường production được giữ càng giống nhau càng tốt. Chúng ta sẽ deploy mã code mới được triển khai vào môi trường hiện tại không sử dụng. Khi các thay đổi mới đã được test trong môi trường production, một router sẽ chuyển đổi để trỏ vào môi trường nơi các thay đổi mới đang hoạt động, tạo điều kiện cho việc chuyển đổi mượt mà.

Chiến lược triển khai blue-green cho phép bạn cập nhật ứng dụng của mình trong môi trường production với thời gian downtime tối thiểu. Nó hoạt động bằng cách triển khai hai bản sao giống nhau của ứng dụng của bạn, một được gọi là "Blue" và một được gọi là "Green." Bản sao Blue là version (phiên bản) production hiện tại của ứng dụng của bạn đang chạy, và bản sao Green là version mới mà bạn muốn triển khai. Bạn chỉ định một số server của mình để chứa một version mới của ứng dụng và các server còn lại để chứa version trước đó.

Khi bản sao Green đã được deploy and test, bạn có thể dần dần chuyển hướng lưu lượng từ Blue. Bắt đầu từ từ, chẳng hạn bằng cách định tuyến 20% lưu lượng đến Green và sau đó tăng tỷ lệ dần theo thời gian. Điều này cho phép bạn giám sát các vấn đề trước khi chuyển đổi.

Nếu bạn gặp vấn đề, bạn có thể dễ dàng quay trở lại bản Blue bằng cách định tuyến lại toàn bộ lưu lượng đến đó. Đây là lý do tại sao triển khai blue-green được gọi là chiến lược triển khai "zero-downtime."

Với triển khai blue-green, bạn có được:

• No downtime: Việc chuyển đổi từ Blue sang Green là tức thì. Khách hàng không gặp phải thời gian ngưng hoạt động nào trong giai đoạn triển khai vì cả hai môi trường đều hoạt động và giống nhau.
• Rollback capability (Khả năng Rollback): Trong trường hợp xảy ra vấn đề, bạn có thể dễ dàng chuyển lại môi trường Blue.
• Risk mitigation(Giảm thiểu rủi ro): Bằng cách có một môi trường đã được test đầy đủ (Green) trước khi chuyển hướng lưu lượng trực tiếp vào nó, hạn chế rủi ro lỗi khi triển khai các cập nhật trực tiếp vào live production (Blue) được giảm đáng kể.

Tóm lại, triển khai blue-green giảm thiểu thời gian down-time và rủi ro liên quan khi triển khai các thay đổi mới vào live production.

Cách sử dụng blue-green deployment như thế nào?

Blue-green deployment là một chiến lược triển khai phức tạp. Hãy có một kế hoạch được xác định rõ ràng vì điều này có thể tốn kém hơn so với các chiến lược triển khai khác, như A/B testing.

• Sử dụng scalable infrastructure. Điều này sẽ giúp bạn giảm chi phí tổng thể.
• Thực hiện kỹ thuật chaos engineering trong môi trường Green. Điều này sẽ cho phép bạn kiểm tra tính đáng tin cậy của ứng dụng của mình mà không ảnh hưởng đến người dùng cuối của bạn.
• Quản lý trạng thái cơ sở dữ liệu một cách cẩn thận. Điều này là một trong những thách thức lớn nhất của việc triển khai blue-green.
• Thay đổi load balancers, không phải DNS. Điều này sẽ mang lại cho bạn sự kiểm soát hơn về quá trình định tuyến lưu lượng.

Các giai đoạn của blue-green deployment model

Dưới đây là 9 giai đoạn của blue-green deployment model:

1. Setup environments (Thiết lập môi trường): Tạo môi trường Blue và Green tương tự nhau.

2. Deploy updates to green (Triển khai cập nhật cho Green): Thực hiện các thay đổi trong môi trường Green.

3. Testing and validation (Kiểm tra và xác nhận: Tiến hành kiểm tra toàn diện trên môi trường Green.

4. Verification and quality checks (Xác minh và kiểm tra chất lượng): Xác minh cập nhật cho hiệu suất và khả năng tương thích.

5. Switchover (Chuyển đổi): Chuyển hướng lưu lượng trực tiếp từ Blue sang Green.

6. Monitoring (Post deployment) - Giám sát (Sau khi triển khai): Liên tục giám sát green để phát hiện vấn đề hoặc biểu hiện bất thường.

7. Rollback (nếu cần): Nhanh chóng quay trở lại môi trường Blue ổn định nếu gặp vấn đề.

8. Promote green to blue (Thăng cấp green thành blue): Khi ổn định, biến môi trường Green thành môi trường sản production (Blue).

9. Clean up and prepare for the next cycle (Dọn dẹp và chuẩn bị cho vòng lặp tiếp theo): Đặt lại và chuẩn bị một môi trường green mới cho các cập nhật trong tương lai.

Quy trình này được tối ưu hóa để đảm bảo sự chuyển đổi liền mạch giữa các môi trường, giảm thiểu thời gian downtime và rủi ro trong quá trình cập nhật hoặc thay đổi trên hệ thống thực tế.

 Blue-green deployment use cases

Rollbacks

Một trong những lợi ích chính của blue-green deployment là khả năng khôi phục sau thảm họa. Bởi vì có hai môi trường giống nhau cho production, khi có thay đổi mới được triển khai vào một môi trường (ví dụ như phiên bản Blue), và bất kỳ vấn đề nào được phát hiện, một router có thể chuyển hướng ngay lập tức sang môi trường khác (phiên bản Green) có phiên bản code cũ, không gây ra thời gian chết (zero downtime). Điều này giúp cải thiện khả năng phục hồi sau sự cố và bảo vệ hệ thống khỏi những tác động tiêu cực của các thay đổi không mong muốn.

CI/CD pipeline

Một trong những mục tiêu của continuous integration (một kỹ thuật DevOps) là đưa phần mềm trực tiếp vào hoạt động càng sớm càng tốt và tăng tốc quá trình phát triển thông qua automated testing và code integration. Blue-green deployment là một chiến lược triển khai có thể giúp đạt được mục tiêu này bằng cách cho phép triển khai mã nguồn vào production nhiều hơn trong khi giảm thiểu rủi ro của các new releases.

Testing production

Thường có sự khác biệt nhỏ về tính tương thích giữa môi trường lưu trữ và production, bất kể có bao nhiêu nỗ lực được thực hiện để làm cho chúng giống nhau. Đối với các nhóm DevOps, điều này có thể dẫn đến các trường hợp lỗi mà không thể phát hiện ra cho đến khi mã được triển khai vào production. Blue-green deployment cho phép kiểm tra trong production bằng cách đẩy code mới vào môi trường production thực sự và xem cách hoạt động của nó, trước khi chuyển nó sang lưu lượng production và người dùng thực sự.

Triển khai canary

canary release là khi các thay đổi mới được release cho một phần nhỏ của người dùng của bạn, thay vì triển khai cho tất cả mọi người. canary sẽ kiểm soát nhỏ này để xác định xem có bất kỳ lỗi nghiêm trọng nào trong bản release mới của mã của bạn hay không. Blue-green deployment có thể được sử dụng cho kiểm tra canary như vậy bằng cách chỉ đơn giản là có router chuyển hướng một phần trăm lưu lượng của bạn sang một bản mới của mã code đã được cập nhập để xem nó hoạt động như thế nào với lưu lượng thực sự, trước khi triển khai thay đổi cho 100% người dùng của bạn.

A/B testing

Một trường hợp sử dụng tiềm năng khác cho blue-green deployment là A/B test. Trong trường hợp này, bạn sẽ load phiên bản mã code mới nhất của bạn lên môi trường Green và định hướng 50% lưu lượng người dùng của bạn đến phiên bản Green so với phiên bản Blue ban đầu của bạn. Sau đó, bạn có thể theo dõi cách hai môi trường hoạt động theo các chỉ số quan trọng của bạn, và sử dụng phân tích thống kê để xác định tác động chính xác của ứng dụng mới của bạn.

Load balancing

Một trường hợp sử dụng tiềm năng khác cho blue-green deployment là cân bằng tải. Nếu việc triển khai blue/green được thiết lập theo cách sao cho hai môi trường production nằm trên các máy chủ riêng biệt (thay vì máy ảo) thì một router có thể dễ dàng cân bằng lưu lượng giữa hai phiên bản Blue và Green của môi trường production vì chúng hoạt động giống nhau chức năng.

Các ưu điểm của triển khai blue-green là gì?

Dưới đây là một số ưu điểm chính của phương pháp triển khai này:

• Không gián đoạn: Bạn có thể cập nhật ứng dụng của mình trong môi trường sản xuất mà không gây gián đoạn với hai bản sao giống nhau đang chạy. Bạn có thể chuyển hướng lưu lượng từ một bản sao sang bản sao khác.
• Rollback: Nếu bạn gặp bất kỳ vấn đề nào với phiên bản mới của application, bạn có thể dễ dàng quay lại phiên bản trước đó.
• Rủi ro giảm: Bạn có thể kiểm tra phiên bản mới của ứng dụng trong môi trường Green trước khi triển khai nó vào môi trường production.
• Triển khai kiểm soát: Có kiểm soát về quy trình triển khai. Quyết định có bao nhiêu lưu lượng được chuyển hướng đến môi trường Green và theo dõi bất kỳ vấn đề nào trước khi bạn thực hiện việc chuyển đổi.
• Khả năng mở rộng: Triển khai blue-green có thể dễ dàng mở rộng để phục vụ thêm lưu lượng bằng cách thêm nhiều server vào môi trường Green.

Các nhược điểm của triển khai blue-green là gì?

Dưới đây là một số nhược điểm chính của blue-green deployment:

1. Tài nguyên phải sử dụng nhiều hơn: Việc duy trì hai môi trường giống nhau yêu cầu bạn phải sử dụng nhiều tài nguyên hơn, đắt đỏ, điều này có thể tốn kém hơn so với các chiến lược deployment khác.

2. Đòi hỏi phải phối hợp nhiều hơn: Bạn cần phải phối hợp triển khai phiên bản mới của ứng dụng vào môi trường mới (ví dụ: green), cũng như chuyển đổi từ môi trường hiện tại (ví dụ: blue) sang môi trường mới.

3. Chậm trong quá trình chuyển đổi: Quá trình chuyển đổi từ một môi trường sang môi trường khác có thể chậm hơn so với các chiến lược triển khai khác, chẳng hạn như A/B testing. Bạn cần phải hết lưu lượng từ môi trường hiện tại trước khi chuyển sang môi trường mới.

4. Không phù hợp cho tất cả các ứng dụng: Blue-green deployment không phù hợp cho tất cả các ứng dụng. Ví dụ, các ứng dụng sử dụng nhiều trạng thái, chẳng hạn như cơ sở dữ liệu.

5. Không có tính chi tiết tại mức tính năng: Quy trình triển khai môi trường mới không cho phép tính chi tiết tại mức tính năng. Vì vậy, nếu bạn gặp vấn đề với một tính năng cụ thể, bạn sẽ phải quay trở lại toàn bộ bản phát hành, không chỉ là tính năng bị ảnh hưởng. Nếu bạn triển khai một ứng dụng lớn hoặc phức tạp, việc áp dụng phương pháp này có thể gặp khó khăn.

Ví dụ về triển khai blue-green

Giả sử nhóm phát triển của bạn đang làm việc trên một ứng dụng web và muốn phát hành một tính năng mới nhưng muốn loại bỏ bất kỳ thời gian downtime và có một chuyển đổi mượt mà sang mã code mới. Bạn sẽ cần phải thiết lập hai môi trường production giống nhau (một " Blue version" và một "Green version") với một router chuyển hướng lưu lượng đến Green version.

Sau đó, bạn có thể đẩy các thay đổi mới vào Green version của môi trường production và xem cách nó hoạt động trong một môi trường production thực tế.

Khi bạn tự tin với hiệu suất của new version của ứng dụng đã OK, bạn có thể bắt đầu chuyển hướng một phần trăm lưu lượng người dùng của mình đến môi trường Green để chạy một canary test trên người dùng thực tế. Nếu không có vấn đề được phát hiện, sau đó bạn có thể chuyển hướng 100% lưu lượng của mình đến môi trường mới, mang đến một phiên bản tính năng mượt mà.

Nếu có bất kỳ vấn đề nào được phát hiện sau khi chuyển đổi đã được thực hiện, bạn có thể dễ dàng chuyển hướng lưu lượng trở lại môi trường Blue mà có version trước của mã code của bạn để thực hiện việc rollback dễ dàng.

Khi bạn tự tin rằng không có vấn đề nào với mã mới, bạn có thể sao chép môi trường Green ra nhiều servers giống nhau để phục vụ cho môi trường production. Bạn sau đó có thể tiếp tục vòng đời phát triển, hoặc sử dụng cho load banlancer khi có lượng lớn truy cập vào ứng dụng.

Tóm lại các bước sẽ như sau:

Cách thức hoạt động của blue-green deployment là:

• Thiết lập hai môi trường sản xuất độc lập, mỗi môi trường có một bản sao của ứng dụng với hai phiên bản khác nhau (một phiên bản hiện tại và một phiên bản mới).
• Triển khai các thay đổi mới vào môi trường mới (ví dụ: green).
• Kiểm tra và xác minh các thay đổi trong môi trường mới.
• Chuyển hướng lưu lượng người dùng từ môi trường hiện tại (ví dụ: blue) sang môi trường mới (ví dụ: green).
• Kiểm tra hoạt động của ứng dụng trong môi trường mới.
• Nếu không có vấn đề gì, chuyển hướng toàn bộ lưu lượng người dùng sang môi trường mới và tiếp tục vận hành ứng dụng trong môi trường mới.
• Nếu phát hiện vấn đề, dễ dàng chuyển hướng lưu lượng trở lại môi trường hiện tại và thực hiện rollback.

Sau khi kiểm tra và xác minh rằng không có vấn đề nào với phiên bản mới của ứng dụng, bạn có thể sao chép môi trường mới (ví dụ: green) để tạo ra một môi trường sản xuất độc lập khác, và tiếp tục quy trình triển khai cho các cập nhật tiếp theo.