升级GCP Composer与Airflow镜像失败，寻求故障原因排查

我之前帮团队排查过好几起类似的Composer升级失败问题，结合你给出的报错信息——Cloud Build镜像构建失败，installer.sh返回非零退出码，大概率是以下几个常见原因导致的，你可以逐一排查：

1. 自定义依赖包冲突 #

这是最常见的原因。Composer升级时会重新构建环境镜像，如果你的环境里添加了自定义PyPI包、APT包或者本地依赖，很可能和新版本Airflow/Composer的依赖不兼容：

• 旧版本Airflow允许的某些包版本，在新版本里可能被标记为废弃，或者和Airflow新依赖的包版本冲突；
• 新版本Composer的基础镜像系统可能更新了（比如从Debian 9切换到Debian 10），你添加的APT包可能已经改名、停止维护，或者安装命令失效。

排查&解决步骤：

• 先临时移除所有自定义PyPI包和APT包，只保留Composer官方默认的依赖，再尝试升级。如果升级成功，再逐个把自定义依赖加回来测试，定位出冲突的包；
• 找到冲突包后，要么换成兼容新版本的版本号（可以查Airflow官方文档的依赖列表），要么移除不必要的自定义依赖。

2. 自定义配置/环境变量冲突 #

如果你设置了AIRFLOW__*开头的自定义环境变量，或者修改过Airflow的核心配置文件，这些配置在新版本Airflow里可能不再支持，或者和新的默认配置冲突，导致installer.sh执行出错。

排查&解决步骤：

• 临时重置所有自定义环境变量和Airflow配置到默认状态，再尝试升级；
• 如果升级成功，再逐步恢复你的配置，每次恢复一项后测试升级，定位出有问题的配置项。

3. Cloud Build权限不足 #

虽然报错里没直接提权限，但有时候Composer使用的Cloud Build服务账号缺少必要的权限，会导致镜像构建过程中无法拉取依赖、上传镜像，最终失败。

排查&解决步骤：

• 找到Composer环境对应的服务账号：通常是service-<你的项目编号>@gcp-sa-composer.iam.gserviceaccount.com；
• 检查该账号是否拥有以下权限：
  • Cloud Build Editor
  • Storage Object Admin（对应Composer环境的GCS存储桶）
  • Artifact Registry Reader/Writer（如果你的项目用了Artifact Registry存储镜像）
• 给账号添加缺失的权限后，重新触发升级。

4. 构建缓存残留问题 #

Cloud Build默认会复用之前的构建缓存，有时候旧版本的依赖残留会和新版本冲突，导致构建失败。

解决步骤：

• 使用gcloud命令升级时，强制禁用构建缓存：

  gcloud composer environments update <你的环境名> --location <你的区域> --image-version composer-1.12.0-airflow-1.10.10 --no-use-build-cache
  

5. 跨版本升级的兼容性限制 #

不是所有Composer版本都支持直接跨版本升级，比如从1.7.2直接跳到1.12.0可能跳过了某些中间版本的依赖更新要求。

排查&解决步骤：

• 查GCP官方的Composer版本升级路径，看看是否需要先升级到某个中间版本（比如先到composer-1.10.x-airflow-1.10.x系列），再升级到目标版本。

额外排查技巧：获取更详细的构建日志 #

你当前看到的报错比较模糊，想要看到installer.sh执行时的具体错误细节，可以手动模拟Cloud Build的构建过程：

1. 从Composer环境对应的GCS存储桶中，找到最新的构建上下文文件（路径大概是gs://<composer-bucket-name>/builds/<最新的构建ID>/）；
2. 把这些文件下载到本地，然后执行以下命令手动触发构建：

   gcloud builds submit --config cloudbuild.yaml .
   

这样就能看到installer.sh执行时的每一步输出，比如哪个包安装失败、哪个命令执行出错，帮你快速定位问题。

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