Triển khai không ngừng hoạt động: Nâng cấp ứng dụng Dockerized của bạn bằng kỹ thuật Blue-Green

Trong một bài viết tôi đã viết cách đây một tháng, tôi đã nói về cách triển khai liên tục ứng dụng web Python của bạn vào môi trường sản xuất (hoặc tiền phát triển/dàn dựng).

Gần đây, tôi được giao nhiệm vụ xây dựng một vi dịch vụ (sử dụng Python và FastAPI) để khớp hai giọng nói và đưa ra điểm dự đoán nếu cả hai giọng nói đó có khớp nhau hay không. Các bên liên quan đã yêu cầu tính năng mở khóa bằng giọng nói.

Chúng tôi có một cuộc họp kỹ thuật, và tôi đứng lên nhận nhiệm vụ (hoặc trưởng nhóm của tôi đứng lên thay tôi, haha).

Đó là một nhiệm vụ thú vị, vì tôi chưa bao giờ làm việc (được đào tạo hay không) với một mô hình ML trước đây. Tôi mất một tuần để thiết kế, xây dựng và gửi mã tới phiên bản AWS EC2. Tôi là một fan hâm mộ lớn của CI/CD, vì vậy tôi đã sử dụng thứ mà tôi cảm thấy thoải mái nhất - GitHub Actions.

Một tuần sau… Các thay đổi đã được yêu cầu và tôi muốn thử một kỹ thuật [triển khai] mới mà tôi đã nghiên cứu. Tôi cần ứng dụng vi dịch vụ dockerized chạy mượt mà trên Phiên bản AWS EC2 để không gặp bất kỳ thời gian ngừng hoạt động nào khi tôi triển khai lại.

Và tôi đã có mánh khóe hoàn hảo trong tay áo.

Thủ thuật đó là: kỹ thuật xanh-lục .

Theo Báo cáo chính thức của AWS về Triển khai xanh/xanh lục, đây là một chiến lược triển khai trong đó bạn tạo hai môi trường riêng biệt nhưng giống hệt nhau.

Một môi trường (màu xanh dương) đang chạy phiên bản ứng dụng hiện tại và một môi trường (màu xanh lục) đang chạy phiên bản ứng dụng mới. Sử dụng chiến lược triển khai xanh lam/xanh lá cây sẽ tăng tính khả dụng của ứng dụng và giảm rủi ro triển khai bằng cách đơn giản hóa quy trình khôi phục nếu triển khai không thành công.

Sau khi thử nghiệm đã hoàn thành trên môi trường màu xanh lá cây, lưu lượng truy cập ứng dụng trực tiếp sẽ được chuyển hướng đến môi trường màu xanh lá cây và môi trường màu xanh lam sẽ không được dùng nữa.

Nói một cách đơn giản, kỹ thuật triển khai blue/green là một cách để giảm thời gian ngừng hoạt động và rủi ro bằng cách chạy hai môi trường sản xuất giống hệt nhau.

Nếu đây là lần đầu tiên bạn nghe thấy một kỹ thuật triển khai như vậy, thì hoàn toàn không có gì phải sợ, tôi sẽ cung cấp cho bạn các bước chi tiết sẽ giúp bạn đạt được triển khai xanh lam.

Hãy bắt tay ngay vào các bước:

1. Bắt đầu bằng cách xây dựng một hình ảnh docker mới với mã được cập nhật của bạn và gắn thẻ nó với một số phiên bản mới.

   
   

 $ docker build -t myexample:v2 .

Thao tác này sẽ tạo một hình ảnh Docker mới với thẻ myexample:v2 bằng cách sử dụng Dockerfile trong thư mục hiện tại.

Trong đó myexample:v2 là tên của hình ảnh docker mới xây dựng. Trong trường hợp của tôi, đó là tên của dự án ML. Ví dụ: docker build -t companyx-servicename-backend:v2

2. Bắt đầu một bộ chứa Docker mới từ hình ảnh mới, nhưng chưa đưa nó ra thế giới bên ngoài.

   
   

 $ docker run -d --name myexample-v2 myexample:v2

Thao tác này sẽ bắt đầu một bộ chứa Docker mới có tên myexample-v2 từ hình ảnh myexample:v2 .

3. Đợi vùng chứa mới khởi động và khởi chạy, đảm bảo vùng chứa đó hoạt động bình thường.

   
   

 $ docker logs myexample-v2

Sử dụng lệnh docker logs để kiểm tra nhật ký của vùng chứa mới nhằm đảm bảo rằng nó đã bắt đầu và được khởi tạo đúng cách.

4. Sử dụng proxy ngược, chẳng hạn như NGINX, để định tuyến lưu lượng truy cập đến cả vùng chứa cũ và vùng chứa mới. Định cấu hình proxy ngược của bạn để lắng nghe các yêu cầu và chuyển tiếp chúng đến cả vùng chứa cũ và vùng chứa mới. Điều này sẽ cho phép bạn chuyển dần lưu lượng truy cập sang vùng chứa mới.

Đây là một ví dụ về cấu hình NGINX định tuyến hai vùng chứa:

 upstream myexample { server myexample-v1:8000; server myexample-v2:8000 backup; } server { listen 80; server_name myexample.com; location / { proxy_pass http://myexample; } }

Cấu hình này thiết lập một nhóm ngược dòng có tên myexample với hai máy chủ: myexample-v1 và myexample-v2 . Từ khóa sao backup được sử dụng để đánh dấu máy chủ thứ hai là bản sao lưu. Chỉ thị proxy_pass được sử dụng để chuyển tiếp các yêu cầu đến nhóm thượng nguồn myexample .

Đảm bảo cập nhật cấu hình proxy ngược để phản ánh tên và cổng ứng dụng của bạn.

5. Chuyển dần lưu lượng truy cập từ vùng chứa cũ sang vùng chứa mới bằng cách điều chỉnh cấu hình proxy ngược.

   
   

Để chuyển lưu lượng truy cập sang vùng chứa mới, hãy điều chỉnh cấu hình proxy ngược để tăng trọng lượng cho vùng chứa mới. Điều này có thể được thực hiện bằng cách xóa từ khóa sao lưu khỏi chỉ thị máy chủ:

 upstream myexample { server myexample-v1:8000; server myexample-v2:8000; } server { listen 80; server_name myexample.com; location / { proxy_pass http://myexample; } }

Điều này sẽ khiến NGINX gửi thêm yêu cầu đến vùng chứa myexample-v2 . Theo dõi ứng dụng của bạn và điều chỉnh cấu hình nếu cần cho đến khi tất cả lưu lượng truy cập chuyển đến vùng chứa mới.

6. Khi tất cả lưu lượng truy cập đang chuyển sang vùng chứa mới, bạn có thể dừng và xóa vùng chứa cũ một cách an toàn.

   
   

 $ docker stop myexample-v1 $ docker rm myexample-v1

Thao tác này sẽ dừng và xóa vùng chứa cũ, giải phóng tài nguyên trên máy chủ.

Phần kết luận

Tôi mới sử dụng kỹ thuật này và rõ ràng là không biết nhiều về nó. Nhưng tôi sẽ tiếp tục tìm hiểu về sự đánh đổi của nó và các kỹ thuật khác sẽ hoạt động tốt hơn. Bạn có một hoặc hai thủ thuật trong tay áo mà bạn muốn chia sẻ với tôi không?

Tôi sẽ đánh giá cao nó. Hãy để tôi có nó (trong phần bình luận).

Ồ ồ. Đừng quên đăng ký nhận bản tin nhàm chán của tôi. Tôi đã học được rất nhiều điều kể từ Q1 và sẽ sớm chia sẻ chúng. chào.