Docker部署Django+Celery+Nginx遇启动错误，求排查解决

核心问题是Celery/Celery-beat容器默认执行了gunicorn命令，这说明容器启动时没有使用Celery专属的启动指令，而是沿用了Web服务的默认启动逻辑。以下是具体排查点和解决方法：

1. 检查docker-compose.yml中Celery服务的command配置 #

生产环境的docker-compose里，必须给Celery和Celery-beat服务明确指定启动命令，否则会继承Dockerfile/entrypoint里的默认命令（也就是gunicorn）。

示例配置：

services:
  # Web服务（用gunicorn启动Django）
  web:
    build: .
    command: gunicorn your_project.wsgi:application --bind 0.0.0.0:8000
    # 其他配置：端口、依赖、环境变量等...

  # Celery Worker服务
  celery_worker:
    build: .
    # 替换成你的项目名，指定启动Celery Worker
    command: celery -A your_project worker --loglevel=info
    depends_on:
      - redis
      - db
    # 其他配置：环境变量、网络等...

  # Celery Beat服务
  celery_beat:
    build: .
    # 替换成你的项目名，指定启动Celery Beat
    command: celery -A your_project beat --loglevel=info
    depends_on:
      - redis
      - db
    # 其他配置：环境变量、网络等...

  # Nginx服务
  nginx:
    # 你的Nginx镜像、配置映射等...

2. 调整entrypoint.sh的执行逻辑 #

如果你的entrypoint.sh最后强制启动了gunicorn，会导致所有容器（包括Celery）都默认跑gunicorn。需要修改成支持自定义命令传入的逻辑：

错误示例（强制启动gunicorn）：

#!/bin/sh
# 初始化步骤（迁移、收集静态文件等）
python manage.py migrate --noinput
python manage.py collectstatic --noinput

# 强制执行gunicorn，会覆盖容器传入的command
exec gunicorn your_project.wsgi:application --bind 0.0.0.0:8000

正确示例（优先执行传入的命令，默认才跑gunicorn）：

#!/bin/sh
# 初始化步骤（迁移、收集静态文件等）
python manage.py migrate --noinput
python manage.py collectstatic --noinput

# 如果容器启动时传入了命令，就执行该命令；否则默认启动gunicorn
if [ $# -gt 0 ]; then
  exec "$@"
else
  exec gunicorn your_project.wsgi:application --bind 0.0.0.0:8000
fi

3. 检查Dockerfile的CMD指令 #

如果Dockerfile里写了CMD ["gunicorn", ...]，而entrypoint没有处理自定义命令，Celery容器会继承这个默认CMD。此时需要确保docker-compose里的command配置能覆盖这个默认值（上面第1点的配置已经能做到）。

内容的提问来源于stack exchange，提问作者Алексей Шаков