Các phương pháp tiếp cận “vụ nổ lớn” truyền thống để phát triển phần mềm không tương thích với nhu cầu cao về tính linh hoạt, nhanh nhẹn và triển khai liên tục của nền tảng phần mềm đám mây và DevOps ngày nay.
Chỉ chuẩn bị danh sách kiểm tra các bước thủ công cần tuân thủ trong quá trình triển khai sản xuất là chưa đủ. Nếu bạn đang làm điều đó thì bạn không thực sự nhanh nhẹn và bạn cũng không phải là một DevOps đúng nghĩa.
Triển khai xanh lam: tổng quan
Triển khai Xanh lam/Xanh lục là một cách tiếp cận triển khai phần mềm giúp giảm thời gian ngừng hoạt động và rủi ro liên quan đến việc phát hành phần mềm mới bằng cách tạo hai môi trường giống hệt nhau: hoạt động (xanh lam) và không hoạt động (xanh lục).
Môi trường hoạt động là nơi phiên bản hiện tại của phần mềm đang chạy và người dùng đang tạo ra lưu lượng sản xuất. Môi trường không hoạt động là nơi phiên bản mới của phần mềm được triển khai và thử nghiệm.
Sau khi thử nghiệm và chuẩn bị phiên bản mới, lưu lượng truy cập sẽ được chuyển từ môi trường hoạt động sang môi trường không hoạt động, biến nó thành môi trường hoạt động mới. Bạn có thể lặp lại quá trình này nếu cần thiết.
Nguồn: docs.aws.amazon.com
Bối cảnh DevOps
Việc triển khai Blue-Green phù hợp với tư duy và quy trình DevOps vì nó hỗ trợ phân phối và triển khai phần mềm liên tục, đồng thời giảm thiểu thời gian ngừng hoạt động cho người dùng sản xuất và loại bỏ nguy cơ lỗi phát hành sản xuất.
Việc có hai môi trường giống hệt nhau cho phép bạn thử nghiệm và triển khai các phiên bản phần mềm mới mà không ảnh hưởng đến môi trường sản xuất hiện tại của bạn. Điều này có nghĩa là các bản phát hành nhanh hơn và thường xuyên hơn, đây là khía cạnh quan trọng của DevOps.
Ngoài ra, khả năng chuyển đổi nhanh chóng lưu lượng giữa các môi trường là điều kiện tiên quyết để khôi phục nhanh chóng trong trường hợp có sự cố, điều này cũng rất quan trọng trong môi trường DevOps.
Các nguyên tắc chính để thực hiện xanh lam
# 1. Hai môi trường giống hệt nhau
Việc triển khai Blue-Green yêu cầu tạo ra hai môi trường giống hệt nhau. Vì vậy, giống hệt nhau từ quan điểm của dữ liệu và quy trình. Một cái đang hoạt động (màu xanh) và cái kia không hoạt động (màu xanh lá cây).
Môi trường xanh là nơi người dùng sản xuất thực hiện các quy trình hàng ngày của họ. Môi trường màu xanh lá cây luôn được đồng bộ hóa với môi trường màu xanh lam, nhưng người thử nghiệm sẽ chạy các trường hợp thử nghiệm của họ ở đó. Mặc dù môi trường này không phải là môi trường sản xuất nhưng bạn đang thử nghiệm trong điều kiện thực tế vì đây là môi trường giống sản xuất.
#2. Công tắc chuyển động
Sau khi thử nghiệm và chuẩn bị phiên bản mới của phần mềm, lưu lượng truy cập sẽ được chuyển từ môi trường hoạt động sang môi trường không hoạt động, biến nó thành môi trường hoạt động mới.
Việc chuyển đổi diễn ra ngay lập tức. Tất cả việc triển khai đều đã là quá khứ. Không có cửa sổ thời gian chết. Người dùng không phải làm gì để vào môi trường mới. Chúng được chuyển hướng tự động và tất cả cùng một lúc.
Nguồn: aws.amazon.com
#3. Rút tiền nhanh chóng
Khả năng chuyển đổi nhanh chóng lưu lượng giữa các môi trường cũng có nghĩa là khôi phục nhanh trong trường hợp có sự cố. Điều này đảm bảo thời gian ngừng hoạt động tối thiểu và ứng dụng vẫn có tính khả dụng cao.
Nếu có sự cố xảy ra với môi trường xanh, tất cả người dùng sẽ ngay lập tức chuyển về môi trường xanh ổn định ban đầu mà không bị gián đoạn.
#4. Kiểm tra tự động
Kiểm tra tự động là một khía cạnh quan trọng của việc triển khai Blue-Green. Nó đảm bảo rằng phiên bản mới của phần mềm được kiểm tra kỹ lưỡng trước khi được triển khai trong môi trường hoạt động.
Trừ khi bạn có một lượng thử nghiệm tự động đáng kể trên hệ thống của mình (bao gồm ít nhất là thử nghiệm đơn vị, thử nghiệm chức năng và thử nghiệm hồi quy), thậm chí có thể không có ý nghĩa gì khi nghĩ đến việc triển khai Blue-Green.
Việc thiếu các bài kiểm tra tự động sẽ làm bạn chậm lại đáng kể. Thời gian cần thiết để kiểm tra môi trường (xanh) mới sẽ đủ dài để đến khi bạn có thể chuyển sang môi trường xanh, nó đã “quá cũ” theo quan điểm của vòng đời phần mềm.
#5. Giao hàng liên tục
Việc triển khai Blue-Green là một phần của quy trình phân phối liên tục, điều này cuối cùng có nghĩa là đưa phần mềm vào sản xuất nhanh hơn và thường xuyên hơn.
Bạn có thể thực hiện thay đổi ngay khi sẵn sàng thử nghiệm phiên bản mới của phần mềm trong môi trường xanh. Vì quá trình triển khai đã hoàn tất và bạn chỉ cần thực hiện chuyển đổi lưu lượng nên nó nhanh đến mức bạn có thể thực hiện việc đó hàng ngày. Tất nhiên, giả sử bạn cũng nhanh chóng thực hiện các hoạt động thử nghiệm của mình.
Vòng đời điển hình
Nền tảng mà triển khai Blue-Green chạy trên đó có vòng đời riêng với các bước và quy trình cần tuân theo. Đây là những gì nó thường bao gồm:
Triển khai quy trình CI/CD
Việc triển khai Blue-Green trong quy trình DevOps CI/CD của bạn phải là một quá trình tự nhiên.
Một điều kiện tiên quyết mạnh mẽ là bạn đã có hai môi trường giống hệt nhau này. Vì đây sẽ là một quy trình tự động nên bạn có thể sử dụng cơ sở hạ tầng làm công cụ mã như AWS CloudFormation hoặc thậm chí là các tập lệnh Terraformation bất khả tri trên đám mây để xây dựng/tái tạo/cập nhật môi trường cho bạn trong quy trình tự động.
Khi bạn đã hoàn thành việc đó, đây là một bước tương đối dễ dàng để tạo quy trình triển khai hoàn toàn tự động. Bạn chỉ đơn giản là tái sử dụng các đường ống hiện có để tạo ra môi trường xanh lam và xanh lục. Tuy nhiên, lần này bạn cũng cần đưa các quy trình thử nghiệm vào quy trình.
Quá trình chuyển đổi lưu lượng có thể được tự động hóa bằng các công cụ như AWS Flex Load Balancer hoặc NGINX. Điều này bao gồm việc cập nhật bộ cân bằng tải hoặc cài đặt DNS để hướng lưu lượng truy cập đến môi trường xanh sau khi thử nghiệm và chuẩn bị phiên bản phần mềm mới.
Một phần khác của câu đố là việc giám sát. Để làm điều này, hãy sử dụng các công cụ như AWS Cloud Watch, New Relic hoặc Datadog.
Cuối cùng, tái sử dụng các đường ống hiện có, thậm chí là thanh lý môi trường xanh cũ. Bạn có quyền hủy bỏ tất cả các dịch vụ và thành phần trước khi tạo lại chúng từ đầu hoặc bạn chỉ có thể cập nhật tập lệnh cho từng dịch vụ trong chuỗi. Thông thường, phá hủy và tạo lại là lựa chọn an toàn hơn vì bạn có nhiều trường hợp khó khăn hơn cần cân nhắc khi nâng cấp.
Thực tiễn tốt nhất về triển khai xanh-xanh
Bạn đang thắc mắc làm cách nào để tận dụng tối đa việc triển khai Blue-Green của mình? Dưới đây là một số lời khuyên từ thực tế.
Có chiến lược di chuyển cơ sở dữ liệu vững chắc
Khi triển khai phiên bản phần mềm mới, hãy đảm bảo rằng lược đồ cơ sở dữ liệu được cập nhật chính xác. Sử dụng chiến lược di chuyển cơ sở dữ liệu như Flyover hoặc Liquibase để quản lý các thay đổi về lược đồ cơ sở dữ liệu.
Sử dụng công cụ phân tích canary
Mặc dù việc triển khai Canary là một phương pháp thay thế nhưng bạn vẫn có thể sử dụng một số kỹ thuật của nó để nâng cao việc triển khai Blue-Green của mình.
Sử dụng công cụ phân tích canary như Kayenta hoặc Spinaker để phân tích hiệu suất của phiên bản phần mềm mới trong môi trường thực tế. Điều này bao gồm việc so sánh hiệu suất của phiên bản phần mềm mới với hiệu suất của phiên bản phần mềm cũ.
Sử dụng khung chuyển đổi tính năng như Togglz để bật hoặc tắt các tính năng trong bản phát hành phần mềm mới. Điều này cho phép bạn triển khai dần dần các tính năng mới và cho phép bạn quay lại nhanh chóng nếu cần.
Sử dụng bộ cân bằng tải có kiểm tra tình trạng
Sử dụng bộ cân bằng tải như AWS Elastic Load Balancer hoặc NGINX cùng với các biện pháp kiểm tra tình trạng để đảm bảo lưu lượng truy cập chỉ được định tuyến đến các phiên bản hoạt động tốt. Điều này giúp ứng dụng có tính sẵn sàng cao và thời gian ngừng hoạt động được giảm thiểu.
Sử dụng kế hoạch khôi phục với tính năng khôi phục tự động
Chuẩn bị kế hoạch khôi phục trong trường hợp có sự cố và tự động hóa quy trình khôi phục bằng công cụ như AWS CodeDeploy hoặc Octopus Deploy. Điều này đảm bảo giảm thiểu thời gian ngừng hoạt động và tính sẵn sàng cao của ứng dụng.
Điều này chủ yếu là vì môi trường xanh khi bạn phát hiện ra một số vấn đề nghiêm trọng với phiên bản mới.
Bạn không cần kế hoạch khôi phục cho môi trường màu xanh lam vì công tắc này không ảnh hưởng đến môi trường này và bạn có thể hoàn nguyên về môi trường ổn định này bất kỳ lúc nào và ngay lập tức.
Những thách thức thực hiện xanh-xanh
Triển khai triển khai Xanh-Xanh có thể là một thách thức đối với các nhóm phát triển. Dưới đây là một số thách thức phổ biến:
Sự khác biệt giữa triển khai xanh lam và hoàng yến
Mặc dù sự khác biệt so với quy trình triển khai truyền thống là khá rõ ràng (không có hai môi trường song song chạy các phiên bản phần mềm khác nhau trong quy trình triển khai truyền thống), nhưng sự khác biệt so với triển khai Canary có thể thú vị hơn một chút.
Việc triển khai Blue-Green có nghĩa là hai môi trường (xanh lam và xanh lục). Nhưng đồng thời, hai môi trường này liên tục được đồng bộ hóa về mặt dữ liệu. Khi phiên bản mới được kiểm tra và coi là đã sẵn sàng, lưu lượng truy cập sẽ được chuyển từ môi trường hoạt động sang môi trường không hoạt động, biến nó thành môi trường hoạt động mới. Bạn không lãng phí thời gian triển khai mã mới và không có thời gian ngừng hoạt động trong quá trình sản xuất. Tất cả người dùng sản xuất vẫn đang làm việc trong môi trường hiện đang hoạt động và thậm chí không nhận thấy sự thay đổi.
Triển khai Canary liên quan đến việc triển khai phiên bản phần mềm mới cho một nhóm nhỏ người dùng trong khi hầu hết người dùng hoặc máy chủ vẫn đang sử dụng phiên bản hiện tại. Đây là sự triển khai dần dần, không phải là một sự thay đổi hoàn toàn. Trong trường hợp này, người thử nghiệm là người dùng sản xuất trực tiếp, mặc dù họ chỉ là một tập hợp con cụ thể trong số họ. Nhóm này đang tích cực thử nghiệm phiên bản mới với quy trình sản xuất và khi nó ổn định cuối cùng, phiên bản mới sẽ được tung ra cho những người dùng còn lại.
Vậy cái nào tốt hơn?
Câu trả lời “còn tùy” của nhà tư vấn phù hợp ở đây một cách ác ý nhất.
Nếu ưu tiên hệ thống của bạn là tính sẵn sàng cao thì việc triển khai Blue-Green sẽ là lựa chọn của bạn.
Nếu bạn chắc chắn thích phản hồi nhanh hơn và triển khai phiên bản hệ thống mới được kiểm soát nhiều hơn (mặc dù chậm hơn), thì việc triển khai Canary có lợi thế hơn Blue-Green.
Điều quan trọng là cả hai đều đủ nhanh nhẹn để được coi là đủ tốt để xây dựng các hệ thống DevOps nghiêm túc.
Nghiên cứu điển hình
Netflix đang sử dụng Blue-Green để tung ra các phiên bản mới của dịch vụ phát trực tuyến của mình. Bằng cách triển khai Blue-Green, Netflix có thể tung ra các phiên bản dịch vụ mới mà không ảnh hưởng đến trải nghiệm người dùng. Trên thực tế, Netflix sử dụng song song việc triển khai Canary trong các trường hợp khác, do đó, việc kết hợp các cách tiếp cận khác nhau để triển khai DevOps dưới một mái nhà không phải là không thực tế.
Ngoài ra Amazon và Etsy sử dụng Blue-Green để triển khai các phiên bản mới của nền tảng thương mại điện tử của họ.
Một trường hợp khác là LinkedIn, sử dụng triển khai Blue-Green để triển khai các phiên bản mới của nền tảng xã hội của mình.
Cuối cùng nhưng không kém phần quan trọng, IBM sử dụng Blue-Green để triển khai các phiên bản mới của nền tảng đám mây của mình.
Các công ty này đã triển khai thành công Blue-Green trong cơ sở hạ tầng nền tảng của họ và là tấm gương điển hình cho những công ty khác.
những từ cuối
Giống như Canary, việc triển khai Blue-Green cố gắng tối ưu hóa các quy trình và phương pháp linh hoạt hiện có nhiều nhất có thể để cung cấp phần mềm mới một cách liền mạch mà không bị ai nhận ra. Đây là mục tiêu cuối cùng của các phương pháp như vậy. Bạn giao hàng liên tục và rất thường xuyên nhưng không ai biết, không ai để ý và cuối cùng là không ai quan tâm.
Có thể khiến nhóm phát triển hơi khó chịu khi không có tin đồn nào xung quanh công ty về các bản phát hành mới nhất của họ. Nhưng nếu bạn hỏi tôi, đây chính xác là dịch vụ tốt nhất bạn có thể cung cấp. Không ai nói về nó, nhưng mọi người đều sử dụng nó hàng ngày.
Sau đó, hãy xem Câu hỏi thường gặp và câu trả lời trong cuộc phỏng vấn DevOps.
