gunicorn tự động tải về thay đổi nguồn


113

Cuối cùng, tôi đã di chuyển env phát triển của mình từ runningerver sang gunicorn / nginx.

Sẽ rất tiện lợi nếu sao chép tính năng tải tự động của máy chủ chạy sang gunicorn, do đó máy chủ tự động khởi động lại khi nguồn thay đổi. Nếu không, tôi phải khởi động lại máy chủ theo cách thủ công với kill -HUP.

Bất kỳ cách nào để tránh khởi động lại thủ công?


Errata: trong env gunicorn của tôi được quản lý / giám sát bởi giám sát viên, vì vậy tôi sẽ không thực sự kill -HUPxử lý PID mà thay vào đó sử dụng supervisorctl. Tuy nhiên, đừng nghĩ rằng điều này thay đổi nhiều.
Paolo

3
github.com/benoitc/gunicorn/issues/154 có một số giải pháp
KZ

Câu trả lời:


232

Mặc dù đây là câu hỏi cũ, nhưng chỉ để nhất quán - vì phiên bản 19.0 gunicorn có --reloadtùy chọn. Vì vậy, không cần công cụ của bên thứ ba nào nữa.


5
đã đồng ý. Các câu trả lời khác có thể hoạt động, nhưng đây là cách đơn giản nhất và nó không phải là một giải pháp thay thế. Đó chính xác là những gì OP muốn.
J-bob

1
Tôi không tin rằng có một tùy chọn - tải lại được tích hợp trong gunicorn. Bạn tìm thấy cái này ở đâu? Các tài liệu của họ nói rằng hãy tải lại cấu hình, gửi một HUP ( killall -HUP procnamesẽ hoạt động tốt) để các công nhân mới bắt đầu và các công nhân cũ tắt một cách duyên dáng.
sofly

3
Cảm ơn @Guandalino, tôi hẳn đã bỏ lỡ nó. Tuy nhiên, điều thú vị cần lưu ý là họ nói "Cài đặt này nhằm mục đích phát triển." Điều này rõ ràng sẽ hiệu quả đối với sản xuất trong một số trường hợp, nhưng cũng có thể là vấn đề đối với nhiều trường hợp khác. Có, tôi đã thấy bên dưới rằng bạn dường như không quan tâm đến sản xuất / triển khai.
sofly

Làm thế nào để làm điều đó một cách dễ dàng cho các máy chủ sản xuất?
juan Isaza

@juanIsaza bạn không bao giờ nên sử dụng chức năng như vậy trong sản xuất. Nếu bạn nghĩ rằng bạn cần nó - bạn cần phải suy nghĩ lại cách tiếp cận của mình cho nhà phát triển hoặc triển khai.
Dmitry Ziolkovskiy

20

Một tùy chọn sẽ là sử dụng --max-Request để giới hạn mỗi quá trình được tạo ra chỉ phục vụ một yêu cầu bằng cách thêm --max-requests 1vào các tùy chọn khởi động. Mỗi quy trình mới được tạo ra sẽ thấy mã của bạn thay đổi và trong môi trường phát triển, thời gian khởi động thêm cho mỗi yêu cầu sẽ không đáng kể.


1
Thủ thuật đẹp, thanh lịch cho dev env. Không thể sử dụng trên prod ... nhưng bạn có thể không muốn tải tự động trên prod, trừ khi bạn thực hiện "triển khai liên tục". Nếu bạn làm vậy, cách tiếp cận của Bryan Helmig sẽ tốt hơn mặc dù nó yêu cầu pipgói khả thi , watchdog.
hobs 19/1213

2
Sẽ mất ~ 3 giây để khởi động một worker mới, quá chậm đối với tôi. (giữa năm 2009 MBP)
Blaise

11

Bryan Helmig đã nghĩ ra điều này và tôi đã sửa đổi nó để sử dụng run_gunicornthay vì khởi chạy gunicorntrực tiếp, để có thể chỉ cần cắt và dán 3 lệnh này vào một trình bao trong thư mục gốc của dự án django của bạn (với virtualenv của bạn đã được kích hoạt):

pip install watchdog -U
watchmedo shell-command --patterns="*.py;*.html;*.css;*.js" --recursive --command='echo "${watch_src_path}" && kill -HUP `cat gunicorn.pid`' . &
python manage.py run_gunicorn 127.0.0.1:80 --pid=gunicorn.pid

Chỉ cần sử dụng nó cho tôi trên fedora 15 với Django 1.5.4, gunicorn 18.0, watchdog 0.6, bash 4.2.
hobs

Đừng quên đặt IP hoặc FQDN và cổng của bạn vào vị trí 127.0.0.1:80, nếu cần.
bếp từ

1
@Guandalino, có may mắn không? Nó đã hoạt động tốt cho tôi trong vài tuần nay. Chỉ thời gian tôi cần khởi động lại theo cách thủ công là khi tôi thay đổi settings.py, models.py(yêu cầu di chuyển) hoặc mã nguồn của một số ứng dụng bên ngoài không có trong watchmedomẫu của tôi .
hobs

Cảm ơn vì đã nhắc nhở. Nhưng tôi không muốn bỏ phiếu của mình cho thành công của người khác. Tại sao điều này (không cần thiết) vội vàng? Tôi có vi phạm một số quy tắc StackOverflow không? Nếu vậy xin vui lòng cho tôi biết làm thế nào để sửa chữa.
Paolo

1
Đừng lo lắng. Chắc chắn không vi phạm quy tắc SO, bạn chỉ cần cân nhắc / ân cần / chu đáo để đặt nỗ lực / ưu tiên vào việc đánh giá các câu trả lời hữu ích. Có vẻ như Dave và tôi đã dành thời gian ngọt ngào để giúp đỡ bạn (trong nhiều tháng), vì vậy cảm giác cấp bách của tôi về việc nhờ bạn xác minh các giải pháp của chúng tôi là không tương xứng - tôi quá háo hức muốn biết liệu có những sai sót tiềm ẩn trong cách tôi 'đã định cấu hình máy chủ của tôi và liệu tôi có nên chuyển sang cách tiếp cận của Dave hay không . Kỳ nghỉ vui vẻ!
hobs

5

Tôi sử dụng git push để triển khai tới sản xuất và thiết lập git hook để chạy tập lệnh. Ưu điểm của cách tiếp cận này là bạn cũng có thể thực hiện việc di chuyển và cài đặt gói cùng một lúc. https://mikeeverhart.net/2013/01/using-git-to-deploy-code/

mkdir -p /home/git/project_name.git
cd /home/git/project_name.git
git init --bare

Sau đó, tạo một tập lệnh /home/git/project_name.git/hooks/post-receive.

#!/bin/bash
GIT_WORK_TREE=/path/to/project git checkout -f
source /path/to/virtualenv/activate
pip install -r /path/to/project/requirements.txt
python /path/to/project/manage.py migrate
sudo supervisorctl restart project_name

Đảm bảo chmod u+x post-receivevà thêm người dùng vào sudoers. Cho phép nó chạy sudo supervisorctlmà không cần mật khẩu. https://www.cyberciti.biz/faq/linux-unix-running-sudo-command-without-a-password/

Từ máy chủ cục bộ / phát triển của mình, tôi thiết lập git remotecho phép tôi đẩy đến máy chủ sản xuất

git remote add production ssh://user_name@production-server/home/git/project_name.git

# initial push
git push production +master:refs/heads/master

# subsequent push
git push production master

Như một phần thưởng, bạn sẽ thấy tất cả các lời nhắc khi tập lệnh đang chạy. Vì vậy, bạn sẽ thấy nếu có bất kỳ vấn đề với việc di chuyển / cài đặt gói / khởi động lại trình giám sát.


lưu ý sử dụng shebang #!/bin/bashnhư đã nói ở trên thay vì #!/bin/shđó là những gì post-receiveví dụ Git có!
curtisp
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.