问题标签 [google-container-builder]

我们将Sinopia用于我们的 npm 存储库，并且凭证（Home 或当前目录中的 .npmrc 文件）是 nec。构建......直到今天，我当然避免在代码中保留这些凭据，并且还通过传递使用 .npmrc 凭据文件的内容设置的 env var 将它们排除在 docker 镜像层之外. 然后在构建期间：

RUN cat $NPMRC>.npmrc && npm install ; rm .npmrc

......一次运行避免了一层坚持其中的秘密......

但我正在尝试使用 YAML 文件设置容器构建请求来设置环境。var 但失败。build-request.yaml 必须在代码中，所以我不能把它放在那里，我试图在--build-arg NPMRC="$(<.npmrc)"从存储桶复制它之后添加......没有错误，但身份验证失败

我正在尝试使用这样的咒语创建构建参数： [..., '--build-arg', 'NPMRC=\""$(< ./.npmrc)"\"', ....] 这在构建历史中显示为

... build --build-arg "NPMRC=\""$(cat ./.npmrc)"\"" -t

...如果 bash 像我认为应该的那样掌握子外壳，那么哪个 afaict 是正确的：

echo "NPMRC=\""$(cat ./.npmrc)"\"" -> NPMRC="_auth=...."

寻找其他人可能已经找到的解决方案

我正在尝试指定一个构建请求，并将其source指定为repoSource：

但是，当我尝试使用 gcloud 提交时，出现错误：

在“编写自定义构建请求”中它说：

当您使用 gcloud 命令行工具提交构建请求时，如果您将源指定为命令行参数，则源字段可能不是必需的。您还可以在构建请求文件中指定源。有关更多信息，请参阅 gcloud 文档。

注意：构建资源文档中描述的 storageSource 和 repoSource 字段与源字段不同。storageSource 指示 Container Builder 在 Cloud Storage 存储桶中查找源文件，repoSource 是指包含源文件的 Cloud Source Repository。

那么，如何使用 gcloud 指定 repoSource 呢？我只看到记录了 gs:// url 前缀。

我正在使用一些自定义库，这些库托管在私有 pypi 服务器上（在 Google Compute Engine 实例中运行）。

我想在将应用程序部署到 Google App Engine 时包含这些库，并且想知道是否可以仅向 Google Cloud Platform 构建服务器开放私有 pypi 防火墙。

我是否有一种简单的方法来设置防火墙规则以授予 Google Container Registry 构建服务器访问我的 GCE 支持的 pypi 服务器的权限？

我在 GCE 上有一个 Kubernetes 部署，我想根据在 Google Container Registry 中创建的新图像自动更新它（最好是通过构建触发器）。有没有办法做到这一点？

提前致谢。

-标记

I am trying to use Google Cloud Container Builder to automate the building of my containers using GCP Build Triggers

My code is in Go, and I have a vendor folder in my project root which contains all of my Go dependencies (I use govendor). However, this vendor folder is NOT checked in to source control.

I have a cloudbuild.yaml file where I first build my Go source into a main executable, and then build a Docker image using this executable. Container Builder ensures these build steps have access to my master branch.

The problem is that the Go compilation step fails, because the vendor folder is not checked in to source control, so none of my dependencies are available for any build step.

Is there a way to create a build step that uses govendor to install all dependencies in the vendor folder? If so, how? Or is the only option to check in my vendor directory into source control (which seems unnecessary to me)?

我正在使用gcr.io/cloud-builders/bazel在谷歌容器构建上构建我的图像。

从日志来看，似乎大部分时间都在为 bazel 设置工作区。这个工作空间不会因构建而改变，因此我认为可以预先计算并存储在新图像中。

如何在 Google Cloud Platform 上加速这些 bazel 构建？

编辑：添加 cloudbuild 文件

cloudbuild.yaml：

我们正在将我们的容器构建流程迁移到 Google Container Builder。我们有多个使用 Node 或 Scala 的 repo。

至于实际的容器构建器功能，是否可以缓存两个构建之间的依赖关系（例如：node_modules、.ivy、...）。每次下载所有内容都非常耗时（金钱）。

我知道可以构建一个包含所有内容的自定义 docker 映像，但我们更愿意避免这种解决方案。

例如，我们可以为此目的挂载一个持久卷，就像我们过去对 DroneIO 所做的那样？或者甚至更好地像 Bitbucket Pipelines 那样自动？

谢谢

背景

相关问题：Google Container Builder：如何在构建步骤中安装 govendor 依赖项？

我正在尝试使用 Google Cloud Container Builder 使用 Build Triggers 自动构建我的 Docker 容器。

我的代码在 Go 中，vendor我的项目根目录中有一个文件夹（签入到 Git），其中包含我所有的 Go 依赖项。

我的项目有四个需要 Docker 化的二进制文件，结构如下：

每个程序的 Dockerfile 都很简单：

我设置了一个构建触发器来跟踪我的master分支。触发器运行以下构建请求 ( cloudbuild.yaml)，它利用了开源 Docker 构建步骤：

总结一下，我目前的构建过程如下：

1. 编辑代码。
2. 使用 . 构建每个 Go 可执行文件go build。可执行文件名为main，并与 . 一起保存在programX/main/目录中main.go。
3. 提交并推送代码（因为mainGit 跟踪可执行文件）到我的主分支。
4. mainBuild Trigger 使用步骤 1 中构建的文件制作了四个 Docker 镜像。

目标

我想从我的构建过程中删除第 1 步，这样我就不再需要在本地编译我的可执行文件，也不需要main在 Git 中跟踪我的可执行文件。

总之，这是我的理想过程：

1. 编辑代码，提交，推送到远程。
2. Build Trigger 编译所有四个程序，构建所有四个图像。
3. 放松 ：）

尝试的解决方案

我使用了开源的Go 构建步骤，如下：

cloudbuild.yaml： （更新）

在尝试了在env字段中设置 PROJECT_ROOT 和 GOPATH 的各种组合后build-programX，我的项目中使用的每个包都收到相同的错误（文件路径不同）：

它甚至没有寻找供应商目录？

接下来是什么？

我的猜测是以下情况之一是正确的：

1. 我没有在构建请求文件中正确指定GOPATH/ 。PROJECT_ROOT但如果是这样，正确的设置是什么？
2. 我的项目结构不正确。
3. 我想做的是不可能的:(*
4. 我需要以某种方式进行自定义构建步骤。
5. 使用的 Go 版本很旧 - 但我该如何检查呢？

我无法在网上找到我想要实现的目标的示例，而且我发现 GCP 关于这个主题的文档非常缺乏。

任何帮助将不胜感激！

我正在使用容器注册表构建器。它似乎运作良好。但是，我在一个意想不到的地方超时。超时处于Preparing上传图片阶段。

Pushing gcr.io/my-project/nimbl/foo The push refers to a repository [gcr.io/my-project/nimbl/foo] c0657b8960f1: Preparing 298d55719be3: Preparing 2c92aca44757: Preparing 456bc265a0bd: Preparing a787b259a3da: Preparing 9f23e5ebcfc2: Preparing dab134dd71e8: Preparing 9911896abb59: Preparing e4a87d9fa1bb: Preparing 5881b25780f5: Preparing da4d37ad6531: Preparing 004e69f3a081: Preparing 164d3ebb8cbe: Preparing 9f23e5ebcfc2: Waiting dab134dd71e8: Waiting 9911896abb59: Waiting e4a87d9fa1bb: Waiting 5881b25780f5: Waiting da4d37ad6531: Waiting 004e69f3a081: Waiting 164d3ebb8cbe: Waiting a787b259a3da: Pushed 298d55719be3: Pushed 456bc265a0bd: Pushed c0657b8960f1: Pushed dab134dd71e8: Pushed 9f23e5ebcfc2: Pushed 9911896abb59: Pushed 5881b25780f5: Pushed da4d37ad6531: Pushed 004e69f3a081: Pushed 164d3ebb8cbe: Pushed

Your build timed out. Use the [--timeout=DURATION] flag to change the timeout threshold. ERROR: (gcloud.container.builds.submit) build e21dc778-8f29-49e9-a17c-a9d52a5cc982 completed with status "TIMEOUT"

我试过增加超时但没有成功。它似乎永远不会离开准备阶段。

我们有一个 Spring Boot 应用程序（多个微服务），使用 Google Container Builder 打包并发布到注册表。我们的cloudbuild.yaml样子是这样的：

推送到 GitHub 上的存储库时由触发器调用。

如果我在本地运行它：

container-builder-local --dryrun=false .

生成的图像运行良好，例如：

docker run -e "SPRING_PROFILES_ACTIVE=development" -p 9000:9000 gcr.io/.../api-auth:latest

但是，当使用 Container Builder 在云中构建映像时，应用程序无法运行并失败并出现以前从未发生过的错误。

即使被拉动：

gcloud docker -- pull gcr.io/.../api-auth:latest

并在本地运行，新错误会阻止应用程序加载：

这只发生在镜像通过 Cloud Container Builder 时——既不是本地的，也不是本地的 gradle 构建。

这可能是云中的问题，还是我错过了一些微不足道的事情？

我也在GitHub 上提交了一个问题，但由于它是一个更广泛的问题以及应用程序的 Spring Boot 特性，我想我会在这里询问它是否响起任何铃声。