如何使用自定义容器镜像部署Google Cloud Functions并解决报错
报错排查与修复方案
核心问题定位
报错是两层问题叠加导致的:
- 直接触发报错的原因:当前Cloud Build执行环境访问GCS服务的网络连通性异常,云函数构建流程无法拉取存储桶内的源码包,返回
gslb: no reachable backends的负载均衡无可用后端错误- 架构设计错位:你制作了带Chrome的自定义容器用于适配webdriver,但部署时走了源码上传的标准云函数构建流程,自定义容器除了用来执行gcloud命令外,在实际运行的云函数实例中完全没有被加载,属于无效的冗余设计。
按优先级执行修复
1. 优先解决直接报错的网络连通性问题
- 排除谷歌侧临时波动:这类
no reachable backends大多是GCS服务的临时网络抖动,直接重跑一次Cloud Build任务,80%以上的单次报错会自动恢复 - 验证网络权限与连通性:在cloudbuild.yaml中新增前置测试步骤,在同一个网络环境下验证到GCS的可达性:
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk' entrypoint: curl args: ['-I', 'https://storage.googleapis.com/storage/v1/b/gcf-sources-967732204245-us-central1']
如果返回403而非连接超时,说明是权限问题,检查Cloud Build服务账号对该GCS桶的读取权限;如果返回连接超时,需要检查项目是否开启了VPC限制、私有出站规则,确保Cloud Build的执行流量可以正常访问storage.googleapis.com域名。
2. 修正错位的部署架构,从根源消除GCS源码拉取环节
你当前的部署逻辑完全绕远路:标准源码上传模式需要把代码打到zip包存到GCS,再由云函数构建服务下载、安装系统依赖、安装Python依赖,整个流程既用不到你自己做的带Chrome的容器,又会因为网络问题触发报错。
正确的webdriver适配云函数部署逻辑:
- 直接用Cloud Run Functions的自定义容器部署能力,跳过源码上传、云端构建的全流程,直接用你做好的带Chrome的业务镜像运行云函数
- 调整后的cloudbuild.yaml示例:
steps: # 第一步:构建带Chrome的业务自定义镜像并推送到Artifact Registry - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'us-central1-docker.pkg.dev/$PROJECT_ID/webcrawler-repo/webcrawler:tag1', '.'] - name: 'gcr.io/cloud-builders/docker' args: ['push', 'us-central1-docker.pkg.dev/$PROJECT_ID/webcrawler-repo/webcrawler:tag1'] # 第二步:用官方gcloud镜像部署云函数,直接指定构建好的自定义镜像,跳过源码上传环节 - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk' entrypoint: gcloud args: - 'functions' - 'deploy' - 'MY_FUN' - '--trigger-topic=MY_TOPIC' - '--region=us-central1' - '--memory=512MB' - '--timeout=540s' - '--image=us-central1-docker.pkg.dev/$PROJECT_ID/webcrawler-repo/webcrawler:tag1'
3. 清理Dockerfile的冗余错误配置
你当前的Dockerfile存在多处会导致构建/运行故障的问题,直接修正:
- 删除重复操作:移除两次重复的
COPY .、两次重复的pip install -r requirements.txt步骤 - 删除业务容器内的无效配置:不需要在业务容器中安装gcloud、配置gcloud环境变量,业务镜像只需要保留Chrome浏览器、系统依赖、Python依赖、爬虫代码即可
- 修正错误的启动配置:删掉无效的
ENTRYPOINT ["webcrawler"](该可执行文件不存在,会直接导致容器启动失败),直接保留正确的gunicorn启动命令作为容器启动入口。
内容的提问来源于stack exchange,提问作者Caprikuarius2
相关产品推荐
相关产品推荐

