Terraform-provider-local: grpc: mensagem recebida maior que max

Após alguma investigação e discussão em hashicorp/terraform#21709, movi isso aqui para representar uma mudança para adicionar um limite de tamanho de arquivo a este provedor (menor que o limite de 4 MB imposto pelo Terraform Core para que os usuários nunca encontrem esse erro genérico mesmo quando contando a sobrecarga do protocolo) e documentar esse limite para a fonte de dados local_file e o tipo de recurso local_file .

Isso ainda está aberto? Eu gostaria de pegar isso se for o caso.
Poderia esclarecer/confirmar o pedido?

1. Adicionar limite de tamanho de arquivo de 4mb no provedor local por meio de um validador
2. Atualizar documentos para refletir o limite de tamanho

Olá

Você planeja corrigir esse problema? Se assim for, quando?

Isso ainda está aberto? Eu gostaria de pegar isso se for o caso.
Poderia esclarecer/confirmar o pedido?

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

2. Update docs to reflect the size limit

Acho que a melhor correção será suportar arquivos > 4Mb

Sim, esse problema ainda persiste.

Sim, encontrei esse problema hoje na fonte de dados local_file apontando para um possível arquivo morto do AWS Lambda.

Olá, há algum progresso nesta questão ou foi estacionado? Isso pode se tornar um problema maior se usarmos o arquivo de modelo do Kubernetes e precisarmos armazenar o arquivo em disco. Como os arquivos Yaml do kubernetes podem se tornar muito grandes.
meu trabalho é dividir o arquivo em 2. O tamanho inicial do arquivo era de 2Mb, agora tenho 2 arquivos de um pouco menos de 1Mb cada e funciona.
Obrigado

Encontrei isso usando o recurso 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)

Existe algum acordo sobre como podemos avançar?
Arquivos com mais de 4 MB só funcionavam anteriormente devido à falta de verificações de segurança (consulte https://github.com/hashicorp/terraform/issues/21709#issuecomment-501497885) então o erro é válido e não parece alterar o limite no núcleo do terraform também será uma opção (Re: “não é um bug, é um recurso”).

Nós poderíamos lidar com isso localmente dividindo arquivos em pedaços de 4 MB dentro do provedor, mas não tenho certeza se isso criaria seus próprios problemas. Eu posso buscar isso, mas antes que eu perca tempo, isso seria aceitável @apparentlymart ?

Usando o Terraform 0.12.23 e o provedor aws 2.61.0, obtendo o mesmo erro Error: rpc error: code = ResourceExhausted desc = grpc: received message larger than max (18182422 vs. 4194304)

Parece que o pacote principal foi atualizado para permitir 64 MB - https://github.com/hashicorp/terraform/pull/20906#

E de acordo com os limites de documentos lambda, arquivos de 50 MB podem ser carregados.

Não seria melhor definir a verificação de segurança para 50 MB?

Apenas como um FYI para quem tem esse problema.

Se você colocar seu arquivo zip em um bucket s3, não deverá enfrentar esse problema. Mas lembre-se de usar a função aws_s3_bucket_object.lambda_zip.content_base64 em vez da função filebase64(path), então você não terá esse problema (ou pelo menos essa foi a correção para mim).

Outra opção é usar uma fonte de dados externa.

por exemplo, dado um nome de arquivo com a variável deployment_package , gere o hash base64 com o seguinte:

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
  ]
}

e use-o como tal:

source_code_hash = data.external.deployment_package.result.filebase64sha256

que deve te dar

+ source_code_hash = "ZjRkOTM4MzBlMDk4ODVkNWZmMDIyMTAwMmNkMDhmMTJhYTUxMDUzZmIzOThkMmE4ODQyOTc2MjcwNThmZmE3Nwo="

+1 esse problema, está nos causando muita dor, pois queremos intencionalmente inserir arquivos maiores no terraform.

Vejo que https://github.com/hashicorp/terraform/pull/20906 foi mesclado há mais de um ano, mas o sintoma descrito acima ainda persiste.

O limite de transferência de grpc pode ser aumentado em todo o projeto para permitir que o serviço downstream que pode aceitar essas cargas úteis funcione corretamente sem soluções alternativas?

Ainda acontecendo com o Terraform 0.12.24. Qualquer solução alternativa para corrigir o erro de limite GRPC?

Isso ainda está acontecendo com o Terraform 0.13.5, ao usar body com um API Gateway (v2) , usando a versão 3.14.1 do provedor AWS.

Para adicionar mais clareza, estou usando a função file no meu caso:

body = file(var.body)

O arquivo em questão tem 1,5 MB de tamanho.

Se eu remover a declaração body , o Terraform será executado com sucesso.

Atualizar

Eu usei jq para comprimir e reduzir o tamanho do corpo para ~500KB, e não houve erro. Parece que o limite pode ser inferior a 4 MB, 1 MB, talvez?

ainda tenho esse problema com
Terraform v0.12.29
provedor.arquivo v2.0.0
provedor.aws v3.15.0
provedor.modelo v2.2.0

Precisa de filebase64 para suportar arquivo > 4mb porque usá-lo em combinação com archive_file é a única maneira de torná-lo idempotente.
Usando um local_file entre freios que ....

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
  }
}

Também tenho esse problema ao tentar implementar uma função Rust no IBM Cloud. Da mesma forma que @atamgp , eu tenho um data "archive_file" que falha com

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

Mas mesmo se isso fosse bem-sucedido (ou o arquivo .zip fosse criado manualmente), o resource "ibm_function_action" ainda falharia com

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

Enfrentei o mesmo problema com o mapa de configuração do 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

Eu encontrei o mesmo problema - parece que há limitação de quantos caracteres estão no código do recurso.

Usar o arquivo carregado no bucket (sem compactá-lo) corrigiu meu problema - suponho que o que ajudou é o fato de que .body de s3 geralmente é um fluxo, oposto a .rendered (que eu estava usando antes), que gera mais caracteres na fonte de recursos.

Isso ainda está acontecendo com o Terraform 0.13.5, ao usar body com um API Gateway (v2) , usando a versão 3.14.1 do provedor AWS.

Para adicionar mais clareza, estou usando a função file no meu caso:

body = file(var.body)

O arquivo em questão tem 1,5 MB de tamanho.

Se eu remover a declaração body , o Terraform será executado com sucesso.

Atualizar

Eu usei jq para comprimir e reduzir o tamanho do corpo para ~500KB, e não houve erro. Parece que o limite pode ser inferior a 4 MB, 1 MB, talvez?

@finferflu - encontramos a mesma coisa, estávamos nos deparando com um arquivo json openapi de 1,5 MB. Fiquei com a impressão de que não era o identificador de arquivo real no JSON que estava causando isso, mas o "corpo" da API REST agora contém isso que é incluído no estado - e provavelmente há muitos caracteres de escape e outros itens no estado - então o arquivo de estado excede 4mb. Para evitar um arquivo local para o swagger, fizemos upload para o S3 e usamos um objeto de dados s3 no TF e ocorreu o mesmo problema - portanto, um forte indicador para dar suporte a isso.

Ainda recebendo este problema com v0.15.4 e nuvem terraform. Importamos alguma infraestrutura enquanto usamos o terraform cloud e tentamos um plano, mas não conseguimos obter o arquivo de estado:

╷
│ Erro: erro de plug-in
│
│ com okta_group.user_type_non_service_accounts,
│ na linha 174 do groups.tf, no recurso "okta_group" "user_type_non_service_accounts":
│ 174: recurso "okta_group" "user_type_non_service_accounts" {
│
│ O plugin retornou um erro inesperado do plugin.(*GRPCProvider).UpgradeResourceState: rpc error: code = ResourceExhausted desc = grpc: mensagem recebida maior que max (6280527 vs. 4194304)

Meu arquivo tem cerca de 2,4 MB e estou enfrentando esse problema até hoje.

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

alguma solução para isso por favor?

Encontramos esse erro ao usar arquivos JSON swagger e gateway de API.
Corrigimos temporariamente esse problema compactando o arquivo JSON swagger para reduzir os arquivos, o que era suficiente. o tamanho do swagger passou de 1,4Mb para 950Kb.

Não é uma solução real, mas talvez ajude alguém que também esteja perto do limite.
Estranhamente, o erro continuou persistindo mesmo que não tivéssemos usado nenhum local.template_file ou local.file data/resource (usamos a função templatefile em vez disso).

Isso pode chamar mais atenção, por favor?