Docker Compose部署Celery+Redis+Django的生产代码更新方案

你遇到的代码更新不生效、Celery任务还是旧版本的问题，本质是操作逻辑和Docker部署模型、Celery的运行机制不匹配，和你用的重启命令不对直接相关。

• 首先明确：kill -HUP <pid> 不会触发Celery重新加载业务代码，这个信号只会让worker重新读取配置文件、重启工作子进程，已经加载到内存里的任务模块不会被重新import，不管是改了任务逻辑还是加了新任务，都不会通过这个信号生效。
• 你在容器内部执行celery multi start/restart，只是在当前容器的独立文件系统里重启进程，如果容器本身用的是旧版本镜像，里面存的还是旧代码，不管重启多少次进程，加载的都是旧版本内容。
• docker-compose restart celery 也不会帮你更新代码，这个命令的作用只是重启已经存在的旧容器，不会拉取新构建的镜像，自然跑的还是旧代码。

官方文档提到生产环境要用init脚本、进程监控系统做Daemonization，核心目标是解决三个问题：进程异常退出后自动拉起、开机自启、统一管理进程的启动/停止生命周期，这套方案是针对物理机、虚拟机直接部署Celery的场景设计的。

在Docker Compose的部署模型下，Docker本身就是你需要的init系统和进程守护工具，完全不需要在容器内部再套一层celery multi、supervisord这类守护进程：

• 容器的标准设计是单容器跑一个前台进程，进程退出后容器直接退出，你只需要给服务配置restart: always这类重启策略，Docker daemon就会自动帮你拉起异常退出的Celery进程，完全实现了官方Daemonization要求的能力，容器内再套一层进程守护属于多余的反模式，反而会导致Docker无法感知容器内子进程的运行状态，出现僵尸进程、进程挂了没被拉起的问题。
• 你之前在容器里用celery multi启动worker本身就是错误用法，multi会fork后台进程运行，容器的1号进程是multi本身，不是worker进程，很容易出现信号传递异常、退出状态不对的问题。

不要在容器内部做任何进程重启操作，所有更新都围绕镜像重建、容器替换来做，流程如下：

• 生产环境不要用volume挂载本地代码目录同步代码，必须把所有业务代码在镜像构建阶段直接COPY进镜像，保证镜像本身包含完整可运行的版本代码，避免环境不一致问题。
• 每次代码更新后，重新构建包含最新代码的服务镜像：

docker-compose build --no-cache django celery flower

加--no-cache是为了避免Docker用旧的构建缓存，导致新代码没被打进镜像。

• 用新构建的镜像重建对应服务容器，不要用restart命令：

docker-compose up -d --no-deps celery django flower

up -d命令会自动对比当前运行的容器和镜像配置，如果检测到镜像有更新，会先销毁旧容器，再用新镜像启动新容器，这时候Celery worker启动的时候加载的就是最新的代码，修改的任务逻辑、新增的任务都会正常生效。

• 如果你部署的是多副本Celery worker，或者任务执行时间比较长，建议在Celery启动参数里加上--shutdown-timeout配置，给旧worker留足够的时间排空正在执行的任务，避免强制销毁容器导致任务中断丢失，示例启动命令：

# docker-compose.yml中celery服务的command配置参考
command: celery -A proj worker -l INFO -c 4 --shutdown-timeout=300

配合滚动更新配置可以实现零停机发布。

如果重建容器后还是加载旧代码，优先排查两个问题：

• 检查.dockerignore文件，是不是误把Celery任务所在的代码目录排除了，导致构建镜像的时候新代码没被复制进去
• 检查是不是有同名的旧镜像标签存在，构建的时候没有覆盖旧镜像，可以执行docker images查看镜像的构建时间，确认最新镜像确实构建成功

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