Triển khai các bản phát hành Canary với Apache APISIX

Nói một cách ngắn gọn, ý tưởng đằng sau các bản phát hành canary là chỉ cung cấp phiên bản phần mềm mới cho một bộ phận người dùng, phân tích kết quả và quyết định xem có nên tiếp tục hay không. Nếu kết quả không phù hợp với mong đợi, hãy quay lại; nếu đúng như vậy, hãy tăng số lượng người dùng tiếp xúc cho đến khi tất cả người dùng được hưởng lợi từ phiên bản mới.

Trong bài đăng này, tôi muốn trình bày chi tiết phần giới thiệu này một cách ngắn gọn, giải thích các cách khác nhau để xác định phân số và chỉ ra cách thực thi nó với Apache APISIX.

Giới thiệu về phiên bản canary

Thuật ngữ "chim hoàng yến" bắt nguồn từ ngành khai thác than. Khi khai thác, việc thải ra khí độc không phải là hiếm: Trong một không gian kín nhỏ, điều đó có thể dẫn đến cái chết nhanh chóng. Tệ hơn nữa, khí gas có thể không có mùi nên thợ mỏ sẽ hít phải khí này cho đến khi quá muộn mới rời đi. Carbon monoxide khá phổ biến trong các mỏ than và không thể phát hiện được bằng giác quan của con người.

Vì lý do này, những người thợ mỏ đã mang theo chim hoàng yến xuống lòng đất. Nếu con chim hoàng yến đột nhiên chết, rất có thể túi khí đó đã bị thủng và đã đến lúc phải rời khỏi nơi này.

Nhiều năm trước, chúng tôi đã áp dụng phương pháp này để phát hành phiên bản phần mềm mới. Sự tương tự diễn ra như sau: thợ mỏ là nhóm Ops triển khai phiên bản, canary bao gồm tất cả các công cụ để đo lường tác động của việc phát hành và gas là một lỗi (nghiêm trọng).

Phần quan trọng nhất là bạn cần đo lường tác động của bản phát hành, bao gồm tỷ lệ lỗi, mã trạng thái HTTP, v.v. và so sánh chúng với phiên bản trước. Nó nằm ngoài phạm vi của bài đăng này, nhưng một lần nữa, điều quan trọng là nếu bạn muốn hưởng lợi từ các bản phát hành canary. Phần quan trọng thứ hai là khả năng khôi phục nhanh nếu phiên bản mới có lỗi.

Bản phát hành Canary so với cờ tính năng

Lưu ý rằng các bản phát hành canary không phải là cách duy nhất để quản lý rủi ro khi phát hành mã mới. Ví dụ: cờ tính năng là một cách phổ biến khác:

• Phương pháp canary cung cấp bộ tính năng hoàn chỉnh trong phiên bản thành phần mới
• Cờ tính năng cũng triển khai thành phần, nhưng các tham số cấu hình chuyên dụng cho phép kích hoạt và hủy kích hoạt từng tính năng riêng lẻ

Cờ tính năng thể hiện một cách tiếp cận linh hoạt hơn (theo đúng nghĩa của từ này) đối với việc khôi phục. Nếu một trong số 10 tính năng bị lỗi, bạn không cần hủy triển khai phiên bản mới; bạn chỉ tắt tính năng lỗi. Tuy nhiên, siêu năng lực này phải trả giá bằng sự phức tạp của cơ sở mã bổ sung, bất kể bạn dựa vào sản phẩm của bên thứ ba hay tự mình triển khai nó.

Mặt khác, canary yêu cầu một quy trình triển khai hoàn thiện để có thể triển khai và hủy triển khai theo ý muốn.

Các phương pháp tiếp cận việc phát hành chim hoàng yến

Ý tưởng đằng sau các bản phát hành canary là chỉ cho phép một phần nhỏ người dùng truy cập phiên bản mới. Hầu hết các định nghĩa canary chỉ định nghĩa "phân số" là phần trăm người dùng. Tuy nhiên, còn nhiều điều hơn thế nữa.

Bước đầu tiên có thể là chỉ cho phép người dùng đã được hiệu đính kiểm tra xem quá trình triển khai trong môi trường sản xuất có hoạt động như mong đợi hay không. Trong trường hợp này, bạn chỉ có thể chuyển tiếp một nhóm người dùng nội bộ cụ thể, ví dụ : người thử nghiệm, sang phiên bản mới. Nếu bạn biết trước những người đó và hệ thống xác thực người dùng, bạn có thể định cấu hình nó theo danh tính; nếu không, bạn cần dự phòng theo một số cách chung, ví dụ : tiêu đề HTTP - X-Canary: Let-Me-Go-To-v2 .

Hãy nhớ rằng chúng ta phải theo dõi hệ thống cũ và mới để xem xét những khác biệt. Nếu không có gì hiển thị thì đây là thời điểm tuyệt vời để tăng lượng người dùng được chuyển tiếp sang phiên bản mới. Tôi cho rằng bạn ăn thức ăn cho chó của chính mình, tức là ; các thành viên trong nhóm sử dụng phần mềm họ đang phát triển. Ví dụ: nếu bạn không có trang web thương mại điện tử dành cho ô tô sang trọng, bạn có thể bỏ qua phần này.

Để tăng tỷ lệ người dùng đồng thời hạn chế rủi ro, giờ đây chúng tôi có thể cung cấp bừa bãi phiên bản mới cho người dùng nội bộ. Chúng ta có thể cấu hình hệ thống chuyển tiếp sang phiên bản mới dựa trên IP máy khách để thực hiện việc này. Vào thời điểm mọi người đang làm việc tại chỗ, điều đó thật dễ dàng vì IP của họ nằm trong một phạm vi cụ thể. Điều khiển từ xa không thay đổi nhiều vì người dùng có thể truy cập mạng của công ty thông qua VPN.

Một lần nữa, hãy theo dõi và so sánh vào thời điểm này.

Toàn bộ chín thước

Tại thời điểm này, mọi thứ sẽ hoạt động như mong đợi đối với người dùng nội bộ, một số hoặc tất cả. Nhưng cũng như không có kế hoạch nào có thể tồn tại khi tiếp xúc với kẻ thù, không có cách sử dụng nào có thể bắt chước toàn bộ sự đa dạng của khối lượng công việc sản xuất. Nói tóm lại, chúng tôi cần cho phép người dùng thường xuyên truy cập phiên bản mới, nhưng theo cách có kiểm soát, giống như cách chúng tôi tăng dần số lượng người dùng cho đến nay: bắt đầu với một phần nhỏ, theo dõi nó và nếu mọi thứ đều ổn, hãy tăng phần đó lên .

Đây là cách thực hiện với Apache APISIX. Apache APISIX cung cấp kiến trúc dựa trên plugin và cung cấp plugin đáp ứng nhu cầu của chúng tôi, cụ thể là plugin traffic-split .

Plugin traffic-split có thể được sử dụng để tự động điều hướng các phần lưu lượng truy cập đến các dịch vụ Thượng nguồn khác nhau.

Điều này được thực hiện bằng cách định cấu hình match , là các quy tắc tùy chỉnh để phân chia lưu lượng truy cập và weighted_upstreams là một tập hợp các Luồng lên để hướng lưu lượng truy cập đến.

-- phân chia lưu lượng truy cập

Hãy bắt đầu với một số nội dung ngược dòng cơ bản, một nội dung cho mỗi phiên bản:

 upstreams: - id: v1 nodes: "v1:8080": 1 - id: v2 nodes: "v2:8080": 1

Chúng tôi có thể sử dụng plugin traffic-split để chuyển tiếp phần lớn lưu lượng truy cập sang v1 và một phần tới v2:

 routes: - id: 1 uri: "*" #1 upstream_id: v1 plugins: traffic-split: rules: - weighted_upstreams: #2 - upstream_id: v2 #3 weight: 1 #3 - weight: 99 #3

1. Xác định lộ trình tổng hợp
2. Định cấu hình cách phân chia lưu lượng; đây, tạ
3. Chuyển tiếp 99% lưu lượng truy cập sang v1 và 1% tới v1. Lưu ý rằng các trọng số có liên quan với nhau. Để đạt được 50/50, bạn có thể đặt trọng số 1 và 1, 3 và 3, 50 và 50, v.v.

Một lần nữa, chúng tôi giám sát mọi thứ và đảm bảo kết quả như mong đợi. Sau đó, chúng ta có thể tăng tỷ lệ lưu lượng được chuyển tiếp đến v2, ví dụ :

 routes: - id: 1 uri: "*" upstream_id: v1 plugins: traffic-split: rules: - weighted_upstreams: - upstream_id: v2 weight: 5 #1 - weight: 95 #1

1. Tăng lưu lượng truy cập lên v2 lên 5%

Lưu ý rằng Apache APISIX tải lại các thay đổi đối với tệp ở trên mỗi giây. Do đó, bạn phân chia lưu lượng truy cập theo thời gian gần như thực. Ngoài ra, bạn có thể sử dụng API quản trị để đạt được điều tương tự.

Nhiều bản phát hành được kiểm soát hơn

Ở phần trên, tôi đã chuyển từ người dùng nội bộ sang một bộ phận người dùng bên ngoài. Có lẽ việc phát hành cho mọi người dùng nội bộ là một rủi ro quá lớn trong tổ chức của bạn và bạn thậm chí còn cần kiểm soát nhiều hơn. Lưu ý rằng bạn có thể định cấu hình thêm plugin traffic-split trong trường hợp này.

 routes: - id: 1 uri: /* upstream_id: v1 plugins: traffic-split: rules: - match: - vars: [["http_X-Canary","~=","Let-Me-Go-To-v2"]] #1 - weighted_upstreams: - upstream_id: v2 weight: 5 - weight: 95

1. Chỉ phân chia lưu lượng truy cập nếu tiêu đề HTTP X-Canary có giá trị được định cấu hình.

Lệnh sau luôn chuyển tiếp tới v1:

 curl http://localhost:9080

Lệnh sau cũng luôn chuyển tiếp tới v1:

 curl -H 'X-Canary: Let-Me-Go-To-v1' http://localhost:9080

Lệnh sau chia lưu lượng truy cập theo trọng số được định cấu hình, tức là 95/5:

 curl -H 'X-Canary: Let-Me-Go-To-v2' http://localhost:9080

Phần kết luận

Bài đăng này giải thích các bản phát hành canary và cách bạn có thể định cấu hình một bản phát hành thông qua Apache APISIX. Bạn có thể bắt đầu với một số tuyến đường với mức độ ưu tiên khác nhau và chuyển sang plugin traffic-split . Cái sau thậm chí có thể được cấu hình thêm để cho phép các trường hợp sử dụng phức tạp hơn.

Mã nguồn hoàn chỉnh cho bài đăng này có thể được tìm thấy trên GitHub .

Để đi xa hơn:

• Triển khai giải pháp phát hành canary dựa trên Apache APISIX
• Bản phát hành Canary trong Kubernetes với Apache APISIX Ingress
• Phát hành Canary mượt mà bằng cách sử dụng Bộ điều khiển xâm nhập APISIX với Trình gắn cờ