部署在Google Cloud Run的Flask应用环境变量缺失原因排查

可能的原因及对应解决步骤 #

1. 持续部署流程覆盖了手动配置的变量 #

如果你的Cloud Run是通过GitHub自动部署（比如Cloud Build触发器或GitHub Actions），手动在Cloud Run控制台添加的环境变量会被自动化部署命令覆盖——因为CD流程会用gcloud run deploy或构建配置文件重新定义服务参数，不会继承控制台的手动设置。

解决：

• 用Cloud Build的话，在cloudbuild.yaml的部署步骤里加上环境变量参数：

  steps:
    - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
      args:
        - 'run'
        - 'deploy'
        - 'your-service-name'
        - '--image'
        - 'gcr.io/your-project/your-image'
        - '--region'
        - 'your-region'
        - '--set-env-vars'
        - 'API_KEY=$$API_KEY'
      env:
        - 'API_KEY=${_API_KEY}'
  

  然后在Cloud Build触发器的「变量」里添加API_KEY（类型选「用户定义」或「已存储的秘密」）。
• 用GitHub Actions的话，在部署命令里引用GitHub仓库的Secret：

  gcloud run deploy your-service-name \
    --image gcr.io/your-project/your-image \
    --region your-region \
    --set-env-vars API_KEY=${{ secrets.API_KEY }}
  

  同时在GitHub仓库的「Settings → Secrets and variables → Actions」里添加API_KEY。

2. 环境变量配置错了服务/版本 #

确认你配置环境变量的服务是当前运行的实例，并且是在活跃修订版本里设置的：

• 打开Cloud Run控制台，进入目标服务的「修订版本」标签，查看当前活跃版本的「环境变量」列表，确认API_KEY存在。
• 如果手动配置后又触发了CD，CD生成的新版本不会继承旧版本的变量，导致切换版本后变量丢失。

解决：

• 直接编辑当前活跃的修订版本添加变量；或者确保CD流程每次部署都带上变量配置，避免版本间的配置不一致。

3. 变量名大小写/拼写不匹配 #

os.environ的变量名是大小写敏感的，比如你控制台配的是api_key，代码里写os.environ.get("API_KEY")肯定拿不到值。另外也要检查有没有拼写错误，比如把API_KEY写成API_KET。

解决：

• 严格对齐代码里的变量名和配置的变量名，一字不差；打印os.environ.keys()日志，直接查看所有可用变量的名称。

4. 混淆了构建阶段和运行阶段的变量 #

Cloud Build的构建环境变量和Cloud Run的运行环境变量是完全独立的：如果把API_KEY配置在了Cloud Build的构建变量里（比如用于拉取私有依赖），那Cloud Run运行时是读不到这个变量的。

解决：

• 明确区分构建变量和运行变量，API_KEY要配置在Cloud Run服务的「环境变量」里（不是Cloud Build的构建配置里）。

快速排查命令 #

用gcloud CLI直接查看服务的当前配置，确认变量是否存在：

gcloud run services describe your-service-name --region your-region

查看输出里的envVars字段，检查是否包含API_KEY。

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