0

Cloud Build 的创建配额为 30。如果我们有超过 30 个 Cloud Functions，则可以轻松达到此配额。有没有办法部署人们使用的 30 多个云功能，最好是足够聪明，不会部署未经修改的云功能？

4

1 回答 1

2

在我们在 GCP 社区 slack 频道中的对话之后，这里有一个带有小示例的想法。该示例描述了一个云功能，但可以轻松扩展到任意一组云功能。

请记住-这不是我的发明-可以在互联网上找到很多示例。

CICD 在 Cloud Build 中使用 Terraform（简单地说 - 云构建 yaml 文件包含“terraform init”和“terraform apply”）。因此，推送（或拉取请求）会触发执行 Terraform 的 Cloud Build 作业。

在这个问题的范围内 - terraform 脚本应该有 4 个元素：

1/ 带有云功能代码的 zip 存档的名称 - 应该在 GCS 存储桶中：

locals {
  cf_zip_archive_name = "cf-some-prefix-${data.archive_file.cf_source_zip.output_sha}.zip"
}

2/ 一个压缩包：

data "archive_file" "cf_source_zip" {
  type        = "zip"
  source_dir  = "${path.module}/..<<path + directory to the CF code>>"
  output_path = "${path.module}/tmp/some-name.zip"
}

3/ 存储桶中的 GCS 对象（假设存储桶已经存在，或在此问题范围之外创建）：

resource "google_storage_bucket_object" "cf_source_zip" {
  name         = local.cf_zip_archive_name
  source       = data.archive_file.cf_source_zip.output_path
  content_type = "application/zip"
  bucket       = google_storage_bucket.cf_source_archive_bucket.name
}

4/ 云函数（仅显示 2 个参数）：

resource "google_cloudfunctions_function" "sf_integrations" {

  source_archive_bucket = google_storage_bucket.cf_source_archive_bucket.name
  source_archive_object = google_storage_bucket_object.cf_source_zip.name

}

它是如何一起工作的=>

触发 Terraform 时，会创建 zip 文件，以防云功能代码被修改。zip 文件的 SHA 哈希码不同（如果代码已被修改）。因此，具有 GCS 对象名称的局部变量获得不同的值。这意味着 zip 文件以新名称上传到 GCS 存储桶。由于源代码对象现在有了新名称source_archive_object = google_storage_bucket_object.cf_source_zip.name，terraform 发现必须重新部署云函数（因为状态文件具有存档对象的旧名称）。重新部署云功能。

另一方面，如果代码没有被修改——名字source_archive_object = google_storage_bucket_object.cf_source_zip.name没有被修改，那么 Terraform 不会部署任何东西。

显然，如果修改了其他参数 - 无论如何都会继续重新部署。

于 2021-07-22T16:52:26.163 回答