Terraform-provider-local: grpc：收到的消息大于最大值

在 hashcorp/terraform#21709 中进行了一些调查和讨论后，我将其移至此处以表示向此提供程序添加文件大小限制的更改（小于 Terraform Core 施加的 4MB 限制，这样用户即使在计算协议开销）并记录local_file数据源和local_file资源类型的限制。

这还开吗？ 如果是这样，我想把它捡起来。
你能澄清/确认请求吗？

1. 通过验证器在本地提供程序中添加 4mb 的文件大小限制
2. 更新文档以反映大小限制

你好

你打算解决这个问题吗？ 如果是这样，什么时候？

这还开吗？ 如果是这样，我想把它捡起来。
你能澄清/确认请求吗？

1. Add file size limit of 4mb in the local provider through a validator

2. Update docs to reflect the size limit

我认为最好的解决方法是支持 >4Mb 的文件

是的，这个问题仍然存在。

是的，我今天在指向预期 AWS Lambda 存档文件的 local_file 数据源上遇到了这个问题。

你好，这个问题有什么进展还是被搁置了？ 如果我们使用来自 Kubernetes 的模板文件并且必须将文件存储到磁盘，这可能会成为一个更大的问题。 由于 kubernetes Yaml 文件会变得非常大。
我的解决方法是将文件拆分为 2。初始文件大小为 2Mb，现在我有 2 个文件，每个文件都小于 1Mb，它确实有效。
谢谢

通过使用aws_lambda_function资源遇到这个问题......

data "local_file" "lambda" {
  filename = "${path.module}/out.zip"
}

resource "aws_s3_bucket_object" "lambda" {
  bucket = var.lambda_bucket
  key    = "${local.name}.zip"
  source = data.local_file.lambda.filename
  etag = filemd5(data.local_file.lambda.filename)
}

resource "aws_lambda_function" "login_api" {
  function_name    = local.name
  role             = aws_iam_role.lambda_role.arn
  handler          = "lambda.handler"
  s3_bucket        = aws_s3_bucket_object.lambda.bucket
  s3_key           = aws_s3_bucket_object.lambda.key
  source_code_hash = filebase64sha256(data.local_file.lambda.filename)

是否有任何关于我们如何前进的协议？
由于缺乏安全检查，超过 4mb 的文件以前只能工作（请参阅 https://github.com/hashicorp/terraform/issues/21709#issuecomment-501497885），因此错误是有效的，听起来不像更改限制在 terraform core 中也将是一个选项（回复：“不是错误，它是一个功能”）。

我们可以通过在提供程序中将文件拆分为 4mb 块来在本地处理它，但我不确定这是否会产生它自己的问题。 我可以追求这一点，但在我浪费时间之前，这是否可以接受@apparentlymart ？

使用 Terraform 0.12.23 和 aws provider 2.61.0，得到相同的错误Error: rpc error: code = ResourceExhausted desc = grpc: received message larger than max (18182422 vs. 4194304)

看起来核心包已更新为允许 64MB - https://github.com/hashicorp/terraform/pull/20906#

并且根据lambda 限制文档，可以上传 50MB 文件。

将安全检查设置为 50MB 不是最好的吗？

对于遇到此问题的任何人，仅供参考。

如果您将 zip 文件放在 s3 存储桶中，则不会遇到此问题。 但是请记住使用aws_s3_bucket_object.lambda_zip.content_base64而不是 filebase64(path) 函数，那么您将不会遇到此问题（或者至少这对我来说是解决方法）。

另一种选择是使用外部数据源。

例如，给定带有变量deployment_package的文件名，生成具有以下内容的 base64 哈希：

data "external" "deployment_package" {
  program = ["/bin/bash", "-c", <<EOS
#!/bin/bash
set -e
SHA=$(openssl dgst -sha256 ${var.deployment_package} | cut -d' ' -f2 | base64)
jq -n --arg sha "$SHA" '{"filebase64sha256": $sha }'
EOS
  ]
}

并这样使用它：

source_code_hash = data.external.deployment_package.result.filebase64sha256

这应该给你

+ source_code_hash = "ZjRkOTM4MzBlMDk4ODVkNWZmMDIyMTAwMmNkMDhmMTJhYTUxMDUzZmIzOThkMmE4ODQyOTc2MjcwNThmZmE3Nwo="

+1 这个问题，它给我们带来了很大的痛苦，因为我们有意将更大的文件内联到 terraform 中。

我看到https://github.com/hashicorp/terraform/pull/20906已经在一年多前合并了，但是上面描述的症状仍然存在。

是否可以在整个项目中增加 grpc 传输的限制，以允许可以接受此类有效负载的下游服务在没有变通方法的情况下正常工作？

Terraform 0.12.24 仍在发生。 修复 GRPC 限制错误的任何解决方法？

Terraform 0.13.5 仍然会发生这种情况，当使用body和API Gateway (v2)时，使用 AWS 提供商的 3.14.1 版本。

为了更清楚，我在我的例子中使用了file函数：

body = file(var.body)

有问题的文件大小为 1.5MB。

如果我删除body声明，Terraform 会成功运行。

更新

我已经使用jq来压缩并将正文的大小减小到 ~500KB，并且没有错误。 看起来阈值可能低于 4MB、1MB，也许？

我仍然有这个问题
Terraform v0.12.29
provider.archive v2.0.0
provider.aws v3.15.0
provider.template v2.2.0

需要filebase64来支持大于 4mb 的文件，因为将它与archive_file结合使用是使其具有幂等性的唯一方法。
在刹车之间使用 local_file ......

data "archive_file" "this" {
  type        = "zip"
  output_path = "${path.module}/test.zip"

  source {
    filename = "test.crt"
    content  = file("${path.module}/archive/test.crt")
  }

  source {
    filename = "binary-file"
    content  = filebase64("${path.module}/archive/binary-file")
  }

  source {
    filename = "config.yml"
    content  = data.template_file.this.rendered
  }
}

我在尝试将 Rust 功能部署到 IBM Cloud 时也遇到了这个问题。 与@atamgp类似，我有一个data "archive_file"失败了

grpc: received message larger than max (11484267 vs. 4194304)

但是即使这成功了（或者.zip文件是手动创建的）， resource "ibm_function_action"仍然会失败

grpc: received message larger than max (7074738 vs. 4194304)

Terraform v0.14.3
+ provider registry.terraform.io/hashicorp/archive v2.0.0
+ provider registry.terraform.io/hashicorp/local v2.0.0
+ provider registry.terraform.io/ibm-cloud/ibm v1.12.0

Kubernetes 配置映射面临同样的问题

resource "kubernetes_config_map" "nginx" {
  metadata {
    name      = "geoip"
    namespace = "ingress"
  }

  binary_data = {
    "GeoLite2-Country.mmdb" = filebase64("${path.module}/config/GeoLite2-Country.mmdb")
  }
}

Acquiring state lock. This may take a few moments...

Error: rpc error: code = ResourceExhausted desc = grpc: received message larger than max (5248767 vs. 4194304)

Terraform v0.14.4
+ provider registry.terraform.io/hashicorp/kubernetes v1.13.3

我遇到了同样的问题 - 资源代码中的字符数似乎有限制。

使用上传到存储桶的文件（不压缩它）解决了我的问题 - 我假设有帮助的事实是，来自 s3 的 .body 通常是一个流，与 .rendered （我之前使用过）相反，它生成资源来源中的更多字符。

Terraform 0.13.5 仍然会发生这种情况，当使用body和API Gateway (v2)时，使用 AWS 提供商的 3.14.1 版本。

为了更清楚，我在我的例子中使用了file函数：

body = file(var.body)

有问题的文件大小为 1.5MB。

如果我删除body声明，Terraform 会成功运行。

更新

我已经使用jq来压缩并将正文的大小减小到 ~500KB，并且没有错误。 看起来阈值可能低于 4MB、1MB，也许？

@finferflu - 发现了同样的事情，我们遇到了一个 1.5mb 的 openapi json 文件。 我的印象是，导致这种情况的不是 JSON 上的实际文件句柄，而是 REST API 的“主体”现在包含它，然后包含在状态中 - 并且可能有很多转义字符和状态中的其他项目 - 所以状态文件超过 4mb。 为了避免招摇的本地文件，我们上传到 S3 并在 TF 中使用了一个 s3 数据对象，并且发生了同样的问题 - 所以一个强有力的指标来支持这一点。

v0.15.4 和 terraform cloud 仍然存在这个问题。 我们在使用 terraform cloud 时导入了一些基础设施，然后尝试了一个计划，但无法将状态文件取出：

╷
│ 错误：插件错误
│
│ 使用 okta_group.user_type_non_service_accounts，
│ 在 groups.tf 第 174 行，在资源“okta_group”“user_type_non_service_accounts”中：
│ 174：资源“okta_group”“user_type_non_service_accounts”{
│
│ 插件从插件返回了一个意外错误。(*GRPCProvider).UpgradeResourceState: rpc error: code = ResourceExhausted desc = grpc: received message greater than max (6280527 vs. 4194304)

我的文件大约 2.4 MB，即使在今天我也面临这个问题。

resource "local_file" "parse-template" {
  content =  templatefile(local.template-name, {
    var1 = value1
    var2 = value2
  }) 
  filename = "${local.script-name}"
}

请问有什么解决方法吗？

我们在使用 swagger JSON 文件和 API 网关时遇到了这个错误。
我们通过压缩 JSON swagger 文件来临时解决此问题，以缩小文件，这已经足够了。 swagger 大小从 1.4Mb 变为 950Kb。

这不是一个真正的解决方法，但也许它可以帮助那些也接近极限的人。
奇怪的是，即使我们没有使用任何 local.template_file 或 local.file 数据/资源（我们使用了 templatefile 函数），错误仍然存​​在。

请问这能引起更多关注吗？