Terraform-provider-local: grpc: mensaje recibido más grande que max

Después de algunas investigaciones y discusiones en hashicorp/terraform#21709, moví esto aquí para representar un cambio para agregar un límite de tamaño de archivo a este proveedor (más pequeño que el límite de 4 MB impuesto por Terraform Core para que los usuarios nunca encuentren ese error genérico incluso cuando sobrecarga del protocolo de conteo) y para documentar ese límite tanto para la fuente de datos local_file local_file .

¿Esto sigue abierto? Me gustaría recoger esto si es así.
¿Podría aclarar/confirmar la solicitud?

1. Agregue un límite de tamaño de archivo de 4 mb en el proveedor local a través de un validador
2. Actualizar documentos para reflejar el límite de tamaño

Hola

¿Planea solucionar este problema? ¿Si es así cuando?

¿Esto sigue abierto? Me gustaría recoger esto si es así.
¿Podría aclarar/confirmar la solicitud?

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

2. Update docs to reflect the size limit

Creo que la mejor solución será admitir archivos> 4Mb

Sí, este problema aún persiste.

Sí, me encontré con este problema hoy en la fuente de datos local_file que apunta a un posible archivo de almacenamiento de AWS Lambda.

Hola, hay algun avance en este tema o estaba aparcado? Esto puede convertirse en un problema mayor si usamos un archivo de plantilla de Kubernetes y debemos almacenar el archivo en el disco. Dado que los archivos Kubernetes Yaml pueden volverse bastante grandes.
Mi solución es dividir el archivo en 2. El tamaño inicial del archivo era de 2 Mb, ahora tengo 2 archivos de un poco menos de 1 Mb cada uno y funciona.
Gracias

Me encontré con esto usando el 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)

¿Hay algún acuerdo sobre cómo podemos avanzar?
Los archivos de más de 4 MB solo funcionaban anteriormente debido a la falta de controles de seguridad (consulte https://github.com/hashicorp/terraform/issues/21709#issuecomment-501497885), por lo que el error es válido y no parece cambiar el límite. en terraform core será una opción (Re: "no es un error, es una característica").

Posiblemente podríamos manejarlo localmente dividiendo los archivos en fragmentos de 4 MB dentro del proveedor, pero no estoy seguro de si eso crearía sus propios problemas. Puedo continuar con eso, pero antes de perder el tiempo, ¿sería aceptable @apparentlymart ?

Usando Terraform 0.12.23 y proveedor de aws 2.61.0, obteniendo el mismo error Error: rpc error: code = ResourceExhausted desc = grpc: received message larger than max (18182422 vs. 4194304)

Parece que el paquete principal se ha actualizado para permitir 64 MB: https://github.com/hashicorp/terraform/pull/20906#

Y de acuerdo con los límites lambda , se pueden cargar archivos de 50 MB.

¿No sería mejor configurar el control de seguridad en 50 MB?

Solo como información para cualquiera que tenga este problema.

Si coloca su archivo zip en un cubo s3, no debería enfrentar este problema. Pero recuerde usar la función aws_s3_bucket_object.lambda_zip.content_base64 en lugar de la función filebase64 (ruta), entonces no tendrá este problema (o al menos esa fue la solución para mí).

Otra opción es usar una fuente de datos externa.

por ejemplo, dado un nombre de archivo con la variable deployment_package , genere el hash base64 con lo siguiente:

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

y usarlo como tal:

source_code_hash = data.external.deployment_package.result.filebase64sha256

que debería darte

+ source_code_hash = "ZjRkOTM4MzBlMDk4ODVkNWZmMDIyMTAwMmNkMDhmMTJhYTUxMDUzZmIzOThkMmE4ODQyOTc2MjcwNThmZmE3Nwo="

+1 este problema, nos está causando mucho dolor ya que intencionalmente queremos alinear archivos más grandes en la terraformación.

Veo que https://github.com/hashicorp/terraform/pull/20906 se fusionó hace más de un año, pero el síntoma descrito anteriormente aún persiste.

¿Se puede aumentar el límite para la transferencia de grpc en todo el proyecto para permitir que el servicio descendente que puede aceptar tales cargas útiles funcione correctamente sin soluciones alternativas?

Todavía sucede con Terraform 0.12.24. ¿Alguna solución para corregir el error de límite de GRPC?

Esto todavía sucede con Terraform 0.13.5, cuando se usa body con un API Gateway (v2) , usando la versión 3.14.1 del proveedor de AWS.

Para agregar más claridad, estoy usando la función file en mi caso:

body = file(var.body)

El archivo en cuestión tiene un tamaño de 1,5 MB.

Si elimino la declaración body , Terraform se ejecuta correctamente.

Actualizar

He usado jq para comprimir y reducir el tamaño del cuerpo a ~500 KB, y no hubo ningún error. Parece que el umbral podría ser inferior a 4 MB, ¿quizás 1 MB?

Todavía tengo este problema con
Terraform v0.12.29
proveedor.archivo v2.0.0
proveedor.aws v3.15.0
proveedor.plantilla v2.2.0

Necesita filebase64 para soportar archivos > 4mb porque usarlo en combinación con archive_file es la única forma de hacerlo idempotente.
Usando un archivo local_file entre frenos 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
  }
}

También tengo este problema al intentar implementar una función de Rust en IBM Cloud. De manera similar a @atamgp , tengo un data "archive_file" que falla con

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

Pero incluso si esto tiene éxito (o el archivo .zip se crea manualmente), el resource "ibm_function_action" aún fallaría con

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

Enfrentó el mismo problema con el mapa de configuración de 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

Me encontré con el mismo problema: parece que hay una limitación en la cantidad de caracteres que hay en el código de recursos.

El uso del archivo cargado en el depósito (sin comprimirlo) solucionó mi problema; supongo que lo que ayudó es el hecho de que .body de s3 suele ser una transmisión, a diferencia de .rendered (que estaba usando antes), que genera más caracteres en la fuente de recursos.

Esto todavía sucede con Terraform 0.13.5, cuando se usa body con un API Gateway (v2) , usando la versión 3.14.1 del proveedor de AWS.

Para agregar más claridad, estoy usando la función file en mi caso:

body = file(var.body)

El archivo en cuestión tiene un tamaño de 1,5 MB.

Si elimino la declaración body , Terraform se ejecuta correctamente.

Actualizar

He usado jq para comprimir y reducir el tamaño del cuerpo a ~500 KB, y no hubo ningún error. Parece que el umbral podría ser inferior a 4 MB, ¿quizás 1 MB?

@finferflu : encontré lo mismo, nos encontramos con esto con un archivo openapi json de 1.5mb. Tenía la impresión de que no era el identificador de archivo real en el JSON lo que estaba causando esto, pero el "cuerpo" de la API REST ahora contiene esto, que luego se incluye en el estado, y probablemente haya muchos caracteres de escape y otros elementos en el estado, por lo que el archivo de estado supera los 4mb. Para evitar un archivo local para el swagger, lo subimos a S3 y usamos un objeto de datos s3 en TF y ocurrió el mismo problema, por lo que es un indicador fuerte para respaldar esto.

Todavía tengo este problema con v0.15.4 y terraform cloud. Importamos algo de infraestructura mientras usábamos terraform cloud y luego probamos un plan, pero no podemos sacar el archivo de estado:

╷
│ Error: Error de complemento
│
│ con okta_group.user_type_non_service_accounts,
│ en la línea 174 de groups.tf, en el recurso "okta_group" "user_type_non_service_accounts":
│ 174: recurso "okta_group" "user_type_non_service_accounts" {
│
│ El complemento devolvió un error inesperado del complemento.(*GRPCProvider).UpgradeResourceState: rpc error: code = ResourceExhausted desc = grpc: mensaje recibido mayor que max (6280527 vs. 4194304)

Mi archivo tiene alrededor de 2,4 MB y me enfrento a este problema incluso hoy.

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

alguna solución para esto por favor?

Nos encontramos con este error al usar archivos Swagger JSON y puerta de enlace API.
Solucionamos este problema temporalmente comprimiendo el archivo swagger de JSON para reducir los archivos, lo cual fue suficiente. el tamaño de swagger pasó de 1,4 Mb a 950 Kb.

No es una solución real, pero tal vez ayude a alguien que también está cerca del límite.
Extrañamente, el error siguió persistiendo a pesar de que no usamos ningún archivo/recurso local.template_file o local.file (usamos la función templatefile en su lugar).

¿Puede esto llamar más la atención, por favor?