автоматическая перезагрузка пушки при смене источника

113

Наконец, я перенес свою среду разработки с сервера запуска на gunicorn / nginx.

Было бы удобно реплицировать функцию автоматической перезагрузки runserver на gunicorn, чтобы сервер автоматически перезагружался при изменении источника. В противном случае мне придется перезапустить сервер вручную с помощью kill -HUP.

Есть ли способ избежать перезапуска вручную?

— Паоло
источник

Ошибка: в моем env gunicorn управляется / контролируется supervisord, поэтому я бы не kill -HUPстал обрабатывать PID, а вместо этого использовал supervisorctl. Однако не думайте, что это сильно изменится.

— Паоло

3

github.com/benoitc/gunicorn/issues/154 предлагает несколько решений

— KZ

232

Хотя это старый вопрос, просто для единообразия - начиная с версии 19.0 Gunicorn есть --reloadопция. Таким образом, сторонние инструменты больше не нужны.

— Дмитрий Циолковский
источник

5

согласовано. Другие ответы могут сработать, но это, безусловно, самый простой и не обходной путь. Это именно то, чего хотела ОП.

— J-bob

1

Я не верю, что в gunicorn есть опция --reload. Где ты нашел это? В их документах говорится, что нужно перезагрузить конфигурацию, отправить HUP ( killall -HUP procnameбудет нормально работать), чтобы новые рабочие были запущены, а старые корректно закрылись.

— softly

3

Спасибо @Guandalino, должно быть, я это пропустил. Однако интересно отметить, что они говорят: «Этот параметр предназначен для разработки». Очевидно, что в некоторых случаях это сработает для производства, но также может быть проблематичным для многих других. Да, я видел ниже, что вы, по-видимому, не заинтересованы в производстве / развертывании.

— softly

Как сделать это простым способом для производственных серверов?

— хуан Исаса

@juanIsaza, вы никогда не должны использовать такую функциональность в продакшене. Если вы думаете, что вам это нужно - вам нужно переосмыслить свой подход к разработке или развертыванию.

— Дмитрий Циолковский

20

Одним из вариантов было бы использовать --max-requests, чтобы ограничить каждый порожденный процесс обслуживанием только одного запроса, добавив --max-requests 1к параметрам запуска. Каждый новый порожденный процесс должен видеть изменения вашего кода, а в среде разработки дополнительное время запуска для каждого запроса должно быть незначительным.

— Дэйв Форгак
источник

1

Хороший, элегантный трюк для разработчиков env. Не может использоваться на продукте ... но вам может не понадобиться автоматическая перезагрузка на продукте, если вы не выполняете «непрерывное развертывание». Если вы это сделаете, то подход Брайана Хельмига будет лучше, даже если он требует pipпакета способностей,watchdog .

— hobs

2

На загрузку нового воркера уйдет ~ 3 секунды, что для меня слишком медленно. (середина 2009 г.)

— Blaise

11

Брайан Хельмиг придумал это, и я изменил его, чтобы использовать run_gunicornвместо gunicornпрямого запуска , чтобы можно было просто вырезать и вставить эти 3 команды в оболочку в корневой папке вашего проекта django (с активированным виртуальным окружением):

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

— варочные панели
источник

Просто использовал его для себя на Fedora 15 с Django 1.5.4, gunicorn 18.0, watchdog 0.6, bash 4.2.

— hobs

Не забудьте указать свой IP или FQDN и порт вместо 127.0.0.1:80, если необходимо.

— плита

1

@Guandalino, удачи? У меня это хорошо работает уже пару недель. Только время мне нужно вручную перезапуск при изменении settings.py, models.py(требуется миграция), или исходный код какого - либо внешнее приложения не в моих watchmedoмоделях.

— hobs

Спасибо за напоминание. Но я не хочу голосовать за успехи других. К чему такая (ненужная) спешка? Нарушаю ли я какое-то правило StackOverflow? Если да, дайте мне знать, как исправить.

— Паоло

1

Не беспокойся. Определенно не нарушая правила SO, просто внимательно / заботливо / вдумчиво приложить усилия / приоритет для оценки полезных ответов. Похоже, что мы с Дейвом не торопились, помогая вам (много месяцев), поэтому мое чувство безотлагательности заставить вас проверить наши решения непропорционально - я слишком хочу знать, есть ли скрытые недостатки в том, как я Я настроил свой сервер, и если мне нужно переключиться на подход Дэйва . Счастливых праздников!

— hobs

5

Я использую git push для развертывания в производственной среде и настраиваю перехватчики git для запуска скрипта. Преимущество этого подхода в том, что вы также можете выполнять миграцию и установку пакета одновременно. 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

Затем создайте сценарий /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

Обязательно chmod u+x post-receiveдобавьте пользователя в sudoers. Разрешить запуск sudo supervisorctlбез пароля. https://www.cyberciti.biz/faq/linux-unix-running-sudo-command-without-a-password/

Я настроил свой локальный сервер / сервер разработки, git remoteкоторый позволяет мне отправлять на рабочий сервер

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

В качестве бонуса вы увидите все запросы во время выполнения скрипта. Так вы увидите, есть ли проблемы с миграцией / установкой пакета / перезапуском супервизора.

— user3628119
источник

обратите внимание на использование shebang, #!/bin/bashкак указано выше, вместо того, #!/bin/shчто было в post-receiveпримере Git !

— curtisp