在发布新版本以更新工作人员中的代码时,如何优雅地重新启动 celery 工作人员?
编辑: 我打算做的是这样的事情。
- Worker 正在运行,可能正在上传一个 100 MB 的文件到 S3
- 一个新的构建来了
- 工人代码有变化
- 构建脚本向 Worker(s) 发出信号
- 使用新代码启动新工作者
- 完成现有工作退出后收到信号的工人。
根据https://docs.celeryproject.org/en/master/userguide/workers.html#restarting-the-worker您可以通过发送 HUP 信号重新启动工作人员
ps auxww | grep celeryd | grep -v "grep" | awk '{print $2}' | xargs kill -HUP
celery multi start 1 -A proj -l info -c4 --pidfile=/var/run/celery/%n.pid
celery multi restart 1 --pidfile=/var/run/celery/%n.pid
http://docs.celeryproject.org/en/latest/userguide/workers.html#restarting-the-worker
如果您要走这kill
条路,请 pgrep 进行救援:
kill -9 `pgrep -f celeryd`
请注意,这不是一项长期运行的任务,我不在乎它是否会残酷地终止。只是在开发期间重新加载新代码。如果它更敏感,我会去重启服务路线。
你应该看看 Celery 的自动重载
长时间运行的任务应该怎么办?我喜欢这样:长时间运行的任务应该完成他们的工作。不要打断他们,只有新任务才能获得新代码。
但目前这是不可能的:https ://groups.google.com/d/msg/celery-users/uTalKMszT2Q/-MHleIY7WaIJ
我已经使用自动化脚本反复测试了 -HUP 解决方案,但发现大约 5% 的时间,工人在重新启动后停止接受新工作。
更可靠的解决方案是:
stop <celery_service>
start <celery_service>
我现在已经使用了数百次,没有任何问题。
在 Python 中,您可以运行:
import subprocess
service_name = 'celery_service'
for command in ['stop', 'start']:
subprocess.check_call(command + ' ' + service_name, shell=True)
聚会可能迟到了。我用:
sudo systemctl stop celery
sudo systemctl start celery
sudo systemctl status celery