标签: google-cloud-build

今天早上我做了一个 PR，它为我的暂存环境触发了 Cloud Build，但未能将结果部署到 GAE。

错误如下：

错误：(gcloud.app.deploy) PERMISSION_DENIED：您无权充当“[redacted]@appspot.gserviceaccount.com”第 4 步：-“@type”：type.googleapis.com/google.rpc。 ResourceInfo 第 4 步：描述：您无权充当此服务帐户。第 4 步：resourceName：[redacted]@appspot.gserviceaccount.com 第 4 步：resourceType：serviceAccount

当我查看https://console.cloud.google.com/cloud-build/settings/service-account Cloud build 具有以下服务帐户权限ENABLED：

• 应用引擎管理员
• 云端知识管理系统

检查https://console.cloud.google.com/iam-admin/iam 我可以看到 cloudbuild 服务帐户具有以下角色：

• 应用引擎管理员
• 应用引擎部署者
• Cloud Build 服务帐号
• Cloud KMS 加密密钥解密器

我有一个 Google App Engine 应用程序，它连接到 Google Cloud Storage。

我注意到存储的数据量高得不合理（4.01 GB，应该是 100MB 左右）。

因此，我查看了每个存储桶的存储量，我发现有一个名为的自动创建的存储桶us.artificats.占用了大部分空间。

我往里面一看，里面只有一个文件夹：containers/images/.

从我用 Google 搜索的内容来看，这些图像似乎来自 Google Cloud Build。

我的问题是，我可以在不影响整个应用程序的情况下删除它们吗？

我有大约 10 个单独的微服务，它们主要是用于各种数据处理作业的云功能，它们都位于一个 github 存储库中。

目标是在推送到分支时触发将这些服务有选择地部署到 Google Cloud Functions - 当单个功能已更新时。

我必须避免单个服务更新导致部署所有云功能的情况。

我当前的存储库结构：

/repo
--/service_A
----/function
----/notebook
--/service_B
----/function
----/notebook

附带说明一下，使用 Github Actions VS Google Cloud Build 进行此类自动化的优缺点是什么？

我正在尝试在谷歌云上部署 node js 应用程序，但出现以下错误 -

Step #1: ERROR: (gcloud.app.deploy) Permissions error fetching application [apps
/mytest-240512]. Please make sure you are using the correct project ID and that
you have permission to view applications on the project.

我正在运行以下命令 -

gcloud builds submit . --config cloudbuild.yaml

我的 cloudbuild.yaml 文件看起来像 -

steps:
  #install
  - name: 'gcr.io/cloud-builders/npm'
    args: ['install']

   #deploy
  - name: 'gcr.io/cloud-builders/gcloud'
    args: ['app', 'deploy']

I\xc2\xb4m 尝试通过云构建触发器将 html 代码从一个云源存储库发布到 gcp 中的公共存储桶。但是，每次推送到主分支时，我都会在构建中遇到以下错误。

generic::invalid_argument: generic::invalid_argument: if \'build.service_account\' is specified, the build must either (a) specify \'build.logs_bucket\' (b) use the CLOUD_LOGGING_ONLY logging option, or (c) use the NONE logging option\n

我正在使用以下 cloudbuild.yaml

steps:\n  - name: gcr.io/cloud-builders/gsutil\n    args: ["-m", "rsync", "-r", "-c", "-d", ".", "gs://somedomain.com"]\n

我认为这与与云构建关联的服务帐户有关。

此解决方案的教程 I\xc2\xb4m 如下： https: //cloud.google.com/community/tutorials/automated-publishing-cloud-build

遇到构建部署功能的问题。尝试以编程方式部署该函数时，我在构建器日志（错误）中得到以下输出。

2020-10-20T02:22:12.155866856Z starting build "1fc13f51-28b6-4052-9a79-d5d0bef9ed5c"
 I 
2020-10-20T02:22:12.156015831Z FETCHSOURCE I 
2020-10-20T02:22:12.156031384Z Fetching storage object: gs://gcf-sources-629360234120-us-central1/${FUNCTIONNAME}-63f501f1-a8d2-4837-b992-1173ced83036/version-1/function-source.zip#1603160527600655 I 
2020-10-20T02:22:16.698838385Z Copying gs://gcf-sources-629360234120-us-central1/${FUNCTIONNAME}-63f501f1-a8d2-4837-b992-1173ced83036/version-1/function-source.zip#1603160527600655... I 
2020-10-20T02:22:16.848908949Z / [0 files][    0.0 B/  7.6 KiB]                                                
/ [1 files][  7.6 KiB/  7.6 KiB]                                                
 I 
2020-10-20T02:22:16.848965618Z Operation completed over 1 objects/7.6 KiB.                                       I 
2020-10-20T02:22:17.848654342Z replace /workspace/pb/__init__.py? [y]es, [n]o, [A]ll, [N]one, [r]ename:  NULL I 
2020-10-20T02:22:17.848694354Z (EOF or read error, treating as "[N]one" ...) I 
2020-10-20T02:22:17.848697209Z Archive:  /tmp/source-archive.zip I 
2020-10-20T02:22:17.848698273Z   inflating: /workspace/main.py       I 
2020-10-20T02:22:17.848699274Z    creating: /workspace/pb/ I 
2020-10-20T02:22:17.848700378Z   inflating: /workspace/pb/__init__.py   I 
2020-10-20T02:22:17.848701376Z …

在云构建中使用 terraform，但在这一步失败了

steps:
  # Terraform
  - id: 'configure_terraform'
    name: node:10.16.3
    entrypoint: "node"
    args: ["./create_terraform_config.js",
           "../terraform/override.tf",
           "${_TERRAFORM_BUCKET_NAME}",
           "${_TERRAFORM_BUCKET_PATH}"]
    dir: "app/scripts"
  - id: 'init_terraform'
    name: hashicorp/terraform:light
    args: ["init"]
    dir: "app/terraform"

正在初始化后端...

成功配置后端“gcs”！除非后端配置更改，否则 Terraform 将自动使用此后端。

错误：无法获取现有工作区：查询 Cloud Storage 失败：存储：存储桶不存在

将 docker 容器映像部署到 Cloud Run 时，我可以选择一个区域，这很好。Cloud Run 将构建委托给 Cloud Build，它显然创建了两个存储桶来实现这一点。意外的行为是存储分区不是在 Cloud Run 部署的区域中创建的，而是默认为美国多区域。

如何将区域指定为“us-east1”，以便“始终免费”层承担存储成本？ （显然，美国多区域存储桶将数据存储在免费层限制之外的区域，这导致了意外账单 - 我试图避免该账单。）

如果重要的话，我也在这个项目中使用 Firebase。我在 us-east1 区域创建了 Firebase 默认存储桶，希望它也能成为其他桶的默认存储桶，但事实并非如此。最终的存储桶列表如下所示，您可以在其中看到使用不需要的多区域设置自动创建的两个存储桶。

这是我用来构建和部署的 shell 脚本：

#!/bin/sh

project_id=$1
service_id=$2

if [ -z "$project_id" ]; then
    echo "First argument must be the Google Cloud project ID" >&2
    exit 1
fi

if [ -z "$service_id" ]; then
    echo "Second argument must be the Cloud Run app name" >&2
    exit 1
fi

echo "Deploying $service_id to $project_id"

tag="gcr.io/$project_id/$service_id"

gcloud builds submit \
    --project …

yarn install我正在尝试在使用 Docker BuildKit 构建 Docker 映像时生成并重用缓存。纱线缓存保留在目录中.yarn/cache，并且永远不应包含在最终映像中（.yarn/cache相对于构建上下文根）。该.yarn/cache目录应该在多个构建之间共享，以便始终从热缓存启动并具有快速yarn install命令（即使我们由于 的更改而导致缓存未命中package.json）。如果我们可以在结束后访问.yarn/cache内容docker build，则可以轻松在多个构建之间共享，例如将其上传到 Amazon S3 或 GCS 存储桶。

我考虑过两种选择：

1. RUN --mount=type=bind
2. RUN --mount=type=cache

下面描述为什么这两种方法都不起作用。

(1) 运行 --mount=type=bind

（简化的）Dockerfile 如下所示：

ENV YARN_CACHE_FOLDER ".yarn/cache"
COPY package.json yarn.lock ./
RUN --mount=type=bind,source=.yarn/cache,target=.yarn/cache,rw yarn install --frozen-lockfile

.yarn/cache不幸的是，命令结束后目录中不存在任何数据docker build。

rw选项文档中描述了没有保留数据的原因：Allow writes on the mount. Written data will be discarded。如果写入的数据被丢弃，那么第一次生成缓存的工作方式是什么？

(2)RUN --mount=type=cache

或者我考虑使用RUN --mount=type=cache. …

GitHub的Google Cloud Build集成未检测到cloudbuild.yaml或者Dockerfile它是否不在存储库的根目录中.

当使用包含多个的monorepo时cloudbuild.yamls,如何配置GitHub的Google Cloud Build集成来检测正确的cloudbuild.yaml？

文件路径:

services/api/cloudbuild.yaml
services/nginx/cloudbuild.yaml
services/websocket/cloudbuild.yaml

Cloud Build集成输出: