Docker-compose本地运行正常，部署GCP报错无法解析主机名db如何解决

核心问题原因 #

• 本地运行正常是因为docker-compose会自动创建内部虚拟网络，同网络下的服务可以通过服务名（此处为db）完成内部DNS解析
• GCP Cloud Run默认是无状态单容器运行服务，不原生支持docker-compose的多容器编排逻辑，你分开部署db和app容器时，二者不在同一私有网络内，无法解析db主机名
• PostgreSQL属于有状态数据库，本身不适合部署在Cloud Run上：Cloud Run面向无状态服务设计，实例会自动扩缩容、冷启动，存储为临时存储，即使部署成功数据也会在实例重启后丢失；同时Cloud Run要求容器必须监听PORT环境变量指定的端口且提供HTTP服务，PostgreSQL走TCP协议，无法通过健康检查，自然会报容器启动失败错误。

标准生产级解决方案 #

步骤1：使用GCP托管的Cloud SQL服务替代自建PostgreSQL

Cloud SQL是GCP官方提供的托管数据库服务，无需自行维护实例、备份、扩缩容：

1. 在GCP控制台创建Cloud SQL for PostgreSQL实例，配置好数据库名、用户名、密码
2. 为Cloud Run服务授予Cloud SQL Client权限
3. 记录Cloud SQL实例的连接名，格式为项目ID:区域:实例名

步骤2：修改Django数据库配置

'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': '你创建的Cloud SQL数据库名',
        'USER': '你的Cloud SQL用户名',
        'PASSWORD': '你的Cloud SQL密码',
        'HOST': '/cloudsql/你的Cloud SQL连接名',
        'PORT': "5432"
    }

步骤3：调整镜像与部署配置

1. 取消Dockerfile中安装libpq-dev gcc postgresql-client的注释，连接Cloud SQL需要相关依赖
2. 无需再单独部署db容器，仅部署app容器到Cloud Run即可，部署时在「连接」配置项中勾选你创建的Cloud SQL实例，平台会自动注入连接代理。

多容器编排替代方案 #

如果需要保留自建PostgreSQL的架构，可以选择以下两种方案：

• 使用Cloud Run多容器部署（Beta功能）：将db和app放在同一个Cloud Run服务的多容器配置中，同一服务下的多容器共享网络命名空间，可通过localhost互相访问，此时Django配置的HOST需改为localhost
• 使用GKE（Kubernetes引擎）部署：可以通过kompose工具直接将你的docker-compose配置转换为K8s资源配置，GKE会自动处理集群内的服务发现，db服务名可以正常解析。

额外优化建议 #

删除entrypoint启动脚本中的python manage.py makemigrations命令，该命令仅用于开发阶段生成迁移文件，生产环境运行会导致非预期的数据库schema变更风险，仅保留migrate命令即可。

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