如何在Google Cloud Run部署含Celery+Redis的Django应用（Docker Compose）

我有一个包含7个服务的docker-compose.prod.yaml文件，希望部署到Google Cloud Run。倾向无服务器方案，对比了另外两个GCP服务：

• Google App Engine：不支持多容器，排除；
• GKE：适配性好，但团队规模小，没有专职DevOps和Kubernetes经验，不想用。

想知道：

1. 在Cloud Run部署这类应用是否可行？是否值得？
2. 若可行，求简洁、成本友好的实现指导。

我预见到几个潜在问题：

• 容器间网络配置；
• 实例15分钟无请求会被销毁；
• 卷的连接配置；
• 单独部署7个容器流程繁琐。

另外，我知道Cloud Tasks，但它绑定GCP，功能不如Celery丰富，不想替换。计划把db容器换成Cloud SQL托管实例。

附docker-compose.prod.yaml配置：

version: '3.8'

services:

  nginx:
    build: ./compose/production/nginx
    volumes:
      - staticfiles:/app/staticfiles
      - mediafiles:/app/mediafiles
    ports:
      - 80:80
      - 5555:5555
      - 15672:15672
    depends_on:
      - web
      - flower

  web:
    build:
      context: .
      dockerfile: ./compose/production/django/Dockerfile
    command: /start
    volumes:
      - staticfiles:/app/staticfiles
      - mediafiles:/app/mediafiles
    env_file:
      - ./.env/.prod-sample
    depends_on:
      - redis
      - db

  db:
    image: postgres:14-alpine
    volumes:
      - postgres_data:/var/lib/postgresql/data/
    environment:
      - POSTGRES_DB=hello_django
      - POSTGRES_USER=hello_django
      - POSTGRES_PASSWORD=hello_django

  redis:
    image: redis:6-alpine

  celery_worker:
    build:
      context: .
      dockerfile: ./compose/production/django/Dockerfile
    image: django_celery_example_celery_worker
    command: /start-celeryworker
    volumes:
      - staticfiles:/app/staticfiles
      - mediafiles:/app/mediafiles
    env_file:
      - ./.env/.prod-sample
    depends_on:
      - redis
      - db

  celery_beat:
    build:
      context: .
      dockerfile: ./compose/production/django/Dockerfile
    image: django_celery_example_celery_beat
    command: /start-celerybeat
    volumes:
      - staticfiles:/app/staticfiles
      - mediafiles:/app/mediafiles
    env_file:
      - ./.env/.prod-sample
    depends_on:
      - redis
      - db

  flower:
    build:
      context: .
      dockerfile: ./compose/production/django/Dockerfile
    image: django_celery_example_celery_flower
    command: /start-flower
    volumes:
      - staticfiles:/app/staticfiles
      - mediafiles:/app/mediafiles
    env_file:
      - ./.env/.prod-sample
    depends_on:
      - redis
      - db

volumes:
  postgres_data:
  staticfiles:
  mediafiles:

项目配置文件结构：

├── compose
│   ├── local
│   │   └── django
│   │       ├── Dockerfile
│   │       ├── celery
│   │       │   ├── beat
│   │       │   │   └── start
│   │       │   ├── flower
│   │       │   │   └── start
│   │       │   └── worker
│   │       │       └── start
│   │       ├── entrypoint
│   │       └── start
│   └── production
│       ├── django
│       │   ├── Dockerfile
│       │   ├── celery
│       │   │   ├── beat
│       │   │   │   └── start
│       │   │   ├── flower
│       │   │   │   └── start
│       │   │   └── worker
│       │   │       └── start
│       │   ├── entrypoint
│       │   └── start
│       └── nginx
│           ├── Dockerfile
│           └── nginx.conf
├── django_celery_example
│     # files omitted for brevity
├── docker-compose.prod.yml
├── docker-compose.yml
├── manage.py
├── polls
│     # files omitted for brevity
└── requirements.txt

可行性与价值判断 #

完全可行，且非常适合你的团队情况：

• Cloud Run的无服务器特性刚好匹配你不想维护集群的需求，无需K8s经验，运维成本极低；
• 按请求/运行时间计费，闲置时几乎不花钱，成本效益符合你的要求；
• 虽然是单容器部署模式，但可以通过服务间调用+托管服务替代的方式适配你的多容器架构。

核心问题解决方案 #

针对你提到的潜在问题，逐个解决：

1. 容器间网络配置 #

Cloud Run服务默认可通过公网域名互相调用，但更推荐用VPC连接器让所有服务处于同一私有网络，既安全又能避免公网延迟：

• 创建一个VPC连接器，将所有Cloud Run服务关联到这个连接器；
• 每个服务部署时开启--vpc-connector参数，服务之间即可用内部域名或服务名直接访问。

2. 实例15分钟销毁问题 #

这个特性对Web服务影响不大（请求来了自动扩容），但Celery Worker/Beat这类需要长期运行的服务需特殊处理：

• Celery Worker：设置--min-instances=1参数，保留至少1个实例运行；也可结合Cloud Scheduler定期发送心跳请求，维持实例存活；
• Celery Beat：由于是单节点定时任务，设置--min-instances=1确保持续运行即可；
• Flower：作为监控工具，设置--min-instances=0，有请求时自动启动，闲置时缩容节省成本。

3. 卷的连接配置 #

Cloud Run不支持Docker卷，用GCP托管服务替代即可：

• 静态/媒体文件：替换为Cloud Storage，修改Django配置用django-storages适配GCS存储后端，静态文件直接由Cloud Storage托管；
• Redis：改用Cloud Memorystore for Redis托管服务，自带高可用、备份，无需维护，服务通过私有网络连接即可。

4. 批量部署流程繁琐问题 #

用Cloud Build + 部署脚本简化流程：

• 编写Shell脚本，依次构建每个服务的镜像并推送到Artifact Registry；
• 编写部署脚本，批量创建/更新Cloud Run服务，复用VPC、环境变量等配置；
• 结合Cloud Build触发器，实现代码提交后自动构建部署的CI/CD流程。

分步实现指导 #

第一步：替换托管服务 #

1. 创建Cloud SQL PostgreSQL实例，配置用户、密码，迁移本地数据库；
2. 创建Cloud Memorystore Redis实例，记录连接地址；
3. 创建Cloud Storage存储桶，用于存放静态和媒体文件，配置CORS规则；
4. 修改Django的settings.py：
   • 数据库配置指向Cloud SQL；
   • Redis配置指向Cloud Memorystore；
   • 静态/媒体文件存储改为Cloud Storage，安装django-storages[google]依赖。

第二步：调整容器配置 #

1. Nginx：无需部署到Cloud Run，Cloud Run自带负载均衡和HTTPS，静态文件由Cloud Storage托管，Flower和Web服务通过Cloud Run自定义域名暴露；若需保留Nginx，可部署为Cloud Run服务，配置反向代理到其他服务域名；
2. Web/Celery Worker/Celery Beat/Flower：保留各自Dockerfile，移除本地卷挂载配置，确保启动命令正确。

第三步：构建并部署 #

1. 启用Artifact Registry，创建镜像仓库；
2. 编写构建脚本（示例）：

# 构建Web镜像
gcloud builds submit --tag us-central1-docker.pkg.dev/[PROJECT_ID]/[REPO_NAME]/web:latest . --dockerfile=compose/production/django/Dockerfile

# 构建Celery Worker镜像
gcloud builds submit --tag us-central1-docker.pkg.dev/[PROJECT_ID]/[REPO_NAME]/celery-worker:latest . --dockerfile=compose/production/django/Dockerfile

# 同理构建Celery Beat、Flower、Nginx镜像

3. 编写部署脚本（示例）：

# 部署Web服务
gcloud run deploy web \
  --image us-central1-docker.pkg.dev/[PROJECT_ID]/[REPO_NAME]/web:latest \
  --platform managed \
  --region us-central1 \
  --vpc-connector [VPC_CONNECTOR_NAME] \
  --allow-unauthenticated \
  --env-vars-file .env/.prod-sample \
  --add-cloudsql-instances [PROJECT_ID]:us-central1:[SQL_INSTANCE_NAME]

# 部署Celery Worker（保持运行）
gcloud run deploy celery-worker \
  --image us-central1-docker.pkg.dev/[PROJECT_ID]/[REPO_NAME]/celery-worker:latest \
  --platform managed \
  --region us-central1 \
  --vpc-connector [VPC_CONNECTOR_NAME] \
  --no-allow-unauthenticated \
  --env-vars-file .env/.prod-sample \
  --min-instances 1 \
  --add-cloudsql-instances [PROJECT_ID]:us-central1:[SQL_INSTANCE_NAME]

# 同理部署Celery Beat、Flower、Nginx

4. 运行脚本完成部署，测试各服务连接。

额外优化建议 #

• 敏感信息管理：用Secret Manager存储数据库密码、Redis密码等敏感信息，部署时通过--update-secrets参数加载，比env_file更安全；
• 监控告警：启用Cloud Monitoring，设置实例存活、任务队列长度等告警规则；
• 成本控制：给Celery Worker设置--max-instances限制峰值，避免突发任务导致成本飙升；Web和Flower服务设置--min-instances=0，闲置时自动缩容。

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