Quy trình triển khai Heroku hoạt động chính xác như thế nào?

Question

Khi tôi triển khai phiên bản dịch vụ mới của mình cho Heroku, điều gì xảy ra chính xác?

Giả sử tôi có N dynos web trực tuyến ngay bây giờ, M trong số họ hiện đang phục vụ các yêu cầu.

• Tất cả chúng có đóng trước khi phiên bản mới bắt đầu trực tuyến không? Điều gì sẽ xảy ra với mọi yêu cầu đang chờ xử lý hiện đang được bảo trì?
• Có thời gian ngừng hoạt động không? (giả sử tôi chỉ có dịch vụ không quốc tịch mà không có bất kỳ di chuyển nào)
• Có móc nối để thực hiện di chuyển tùy chỉnh (ví dụ: di chuyển bảng cơ sở dữ liệu) không?
• Tôi có thể đưa lên N máy chủ đang chạy phiên bản mới, yêu cầu họ bắt đầu các yêu cầu dịch vụ và đưa các máy chủ N trước xuống chỉ khi chúng không phục vụ bất kỳ yêu cầu nào không?
• Câu trả lời có phụ thuộc vào ngăn xếp/ngôn ngữ không? (Aspen/tre/Cedar, Ruby/Node.js/Java/...)

tôi không bất kỳ tài liệu chính thức về vấn đề này, chỉ cần viết ngược lại (một số nói nóng migrations are not possible, trong khi others say there is no downtime). Có bất kỳ chi tiết chính thức nào về quy trình triển khai và các câu hỏi ở trên không?

Answer 1

Đây là những gì xảy ra trong một Heroku triển khai (hiện tại như của 2011/10/20 *) [1]:

• Heroku nhận git push của bạn
• Một phát hành mới được biên dịch từ phiên bản mới nhất các ứng dụng của bạn và lưu trữ
• [Những xảy ra khoảng đồng thời]
  • lưới Dyno được báo hiệu chấm dứt [2] tất cả các tiến trình đang chạy cho ứng dụng của bạn
  • lưới Dyno là signall ed để bắt đầu quy trình mới cho ứng dụng của bạn
  • Lưới Dyno là tín hiệu để unidle tất cả các quá trình nhàn rỗi của ứng dụng của bạn
  • Router HTTP được hiệu để bắt đầu định tuyến lưu lượng HTTP đến dynos web chạy phiên bản mới

Việc rút tiền chung là giảm thiểu mọi thời gian chết có thể xảy ra, bạn nên giảm thiểu thời gian khởi động của ứng dụng.

Bằng cách làm theo các thực hành di chuyển cẩn thận, bạn có thể đẩy mã mới và sau đó di chuyển trong khi ứng dụng đang chạy. Dưới đây là ví dụ cho Rails: http://pedro.herokuapp.com/past/2011/7/13/rails_migrations_with_no_downtime/

Để giảm thiểu kết nối bị ngắt trong khi khởi động lại, hãy sử dụng webserve phản hồi phù hợp với SIGTERM bằng cách bắt đầu tắt hoàn toàn (kết thúc kết nối hiện có, không mất kết nối mới). Phiên bản mới hơn của thin sẽ xử lý SIGTERM chính xác.

1. Chủ đề này là chủ đề thảo luận nhiều nội bộ và có thể thay đổi trong tương lai.
2. SIGTERM sau 10s sau bởi SIGKILL nếu vẫn chạy

Answer 2

Tôi có thể trả lời "Có móc để thực hiện di chuyển tùy chỉnh (ví dụ: di chuyển bảng cơ sở dữ liệu) không?" một phần của câu hỏi này. Tôi đã xử lý việc di chuyển bằng cách viết một kịch bản lệnh shell thực hiện "heroku rake db: migrate" ngay lập tức sau khi tôi phát hành "git push heroku". Tôi không biết nếu có nhiều hơn "móc" - y cách để làm điều đó.