Trong mộ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). bài viết Bạn có thể tham khảo bài viết trước để triển khai ứng dụng của mình bằng bất kỳ ngôn ngữ nào khác. Chỉ cần đảm bảo sửa đổi tệp quy trình làm việc. 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. Chúng tôi sẽ sử dụng một sản phẩm tưởng tượng cho các mục đích ví dụ vì tôi không muốn thực hiện các bước triển khai với sản phẩm mà tôi đã tạo cho công ty của mình vì lý do NDA. Haha. Hãy bắt tay ngay vào các bước: 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ẻ bằng cách sử dụng trong thư mục hiện tại. myexample:v2 Dockerfile Trong đó 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ụ: myexample:v2 docker build -t companyx-servicename-backend:v2 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 từ hình ảnh . myexample-v2 myexample:v2 Đợ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. 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ủ: và . Từ khóa sao được sử dụng để đánh dấu máy chủ thứ hai là bản sao lưu. Chỉ thị được sử dụng để chuyển tiếp các yêu cầu đến nhóm thượng nguồn . myexample-v1 myexample-v2 backup proxy_pass 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. 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 . 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. myexample-v2 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 Nếu ứng dụng của bạn dựa trên cơ sở dữ liệu quan hệ, chiến lược triển khai xanh lam-xanh lục có thể gây ra sự không nhất quán giữa cơ sở dữ liệu Xanh dương và Xanh lục khi thực hiện cập nhật. Để đảm bảo tính toàn vẹn của dữ liệu ở mức cao nhất, bạn nên thiết lập cơ sở dữ liệu hợp nhất tương thích với cả phiên bản trước đây và tương lai. 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.
