在专用Docker容器中运行Celery时是否需要将其守护进程化？

在专用Docker容器中运行Celery worker时，完全不需要执行守护进程化操作，你测试时遇到的容器直接以退出码0终止的问题，本质是Celery的守护进程逻辑和容器运行模型天然冲突导致的。

官方文档提到的生产环境守护进程部署建议，针对的是传统裸金属、虚拟机部署场景：

• 这类场景下配置守护进程，是为了让Celery脱离启动它的终端会话，避免会话关闭时进程被连带终止，同时配合系统init服务实现异常重启、生命周期托管。
• 容器场景下不存在终端会话绑定的问题，容器的生命周期完全绑定内部PID为1的主进程：只要主进程退出，无论退出码是多少，容器都会直接终止。将Celery配置为守护进程后，Celery会fork出子进程在后台运行，原来的启动进程执行完守护化逻辑就直接退出，PID 1进程消失，容器自然会以0码终止，这不是配置错误，是容器的标准运行机制。

• 直接以前台模式启动Celery作为容器主进程，在Dockerfile的CMD或ENTRYPOINT中直接写入前台启动命令即可，示例：

  CMD ["celery", "-A", "your_app_module", "worker", "--loglevel=info"]
  

  启动时不要添加--detach这类后台运行参数，不要主动触发守护进程逻辑。
• 不需要在容器内部额外部署systemd、supervisord这类进程托管工具来运行守护态Celery：对于只跑单个Celery worker的专用容器，额外的进程托管层只会增加资源开销和故障排查成本。
• 原本由Celery守护进程配合系统init实现的进程托管、异常拉起能力，在容器环境下全部交由容器编排层实现：worker异常退出时由Docker、Kubernetes等编排组件自动拉起容器，日志直接输出到stdout/stderr即可由容器运行时统一采集管理，不需要Celery自身实现后台驻留逻辑。

补充：只有当你需要在单容器内同时运行多个进程（比如同时跑Celery worker和定时任务beat）时，才需要考虑引入轻量级init进程托管多个前台子进程，但这种场景下依然不需要让Celery自身做守护进程化。

内容的提问来源于stack exchange，提问作者Joaquim