Terraform-provider-local: grpc : message reçu supérieur au maximum

Après quelques recherches et discussions dans hashicorp/terraform#21709, j'ai déplacé ceci ici pour représenter un changement pour ajouter une limite de taille de fichier à ce fournisseur (plus petite que la limite de 4 Mo imposée par Terraform Core afin que les utilisateurs ne rencontrent jamais cette erreur générique même lorsque compter la surcharge du protocole) et de documenter cette limite pour la source de données local_file et le type de ressource local_file .

Est-ce toujours ouvert ? J'aimerais le récupérer si c'est le cas.
Pourriez-vous clarifier/confirmer la demande ?

1. Ajouter une limite de taille de fichier de 4 Mo dans le fournisseur local via un validateur
2. Mettre à jour les documents pour refléter la limite de taille

Bonjour

Prévoyez-vous de résoudre ce problème ? Si oui, quand ?

Est-ce toujours ouvert ? J'aimerais le récupérer si c'est le cas.
Pourriez-vous clarifier/confirmer la demande ?

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

2. Update docs to reflect the size limit

Je pense que la meilleure solution sera de prendre en charge les fichiers> 4 Mo

Oui, ce problème persiste toujours.

Oui, j'ai rencontré ce problème aujourd'hui sur la source de données local_file pointant vers un éventuel fichier d'archive AWS Lambda.

Bonjour, y a-t-il des progrès sur ce problème ou était-il parqué ? Cela peut devenir un problème plus important si nous utilisons un fichier de modèle de Kubernetes et devons stocker le fichier sur le disque. Depuis kubernetes, les fichiers Yaml peuvent devenir assez volumineux.
mon travail consiste à diviser le fichier en 2. La taille initiale du fichier était de 2 Mo, maintenant j'ai 2 fichiers d'un peu moins de 1 Mo chacun et cela fonctionne.
Merci

J'ai rencontré cela en utilisant la ressource 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)

Y a-t-il un accord sur la façon dont nous pouvons aller de l'avant?
Les fichiers de plus de 4 Mo ne fonctionnaient auparavant qu'en raison d'un manque de contrôles de sécurité (voir https://github.com/hashicorp/terraform/issues/21709#issuecomment-501497885) donc l'erreur est valide et cela ne ressemble pas à changer la limite dans terraform core sera une option non plus (Re : "pas un bogue, c'est une fonctionnalité").

Nous pourrions éventuellement le gérer localement en divisant les fichiers en morceaux de 4 Mo au sein du fournisseur, mais je ne suis pas sûr que cela créerait ses propres problèmes. Je peux poursuivre cela, mais avant de perdre du temps, cela serait-il même acceptable @apparentlymart ?

En utilisant Terraform 0.12.23 et le fournisseur aws 2.61.0, obtenir la même erreur Error: rpc error: code = ResourceExhausted desc = grpc: received message larger than max (18182422 vs. 4194304)

Il semble que le package principal ait été mis à jour pour autoriser 64 Mo - https://github.com/hashicorp/terraform/pull/20906#

Et selon les limites lambda, les fichiers docs de 50 Mo peuvent être téléchargés.

Ne serait-il pas préférable de régler le contrôle de sécurité sur 50 Mo ?

Juste comme un FYI pour toute personne ayant ce problème.

Si vous placez votre fichier zip dans un compartiment s3, vous ne devriez pas rencontrer ce problème. Mais n'oubliez pas d'utiliser la fonction aws_s3_bucket_object.lambda_zip.content_base64 plutôt que la fonction filebase64(path), alors vous n'aurez pas ce problème (ou du moins c'était la solution pour moi).

Une autre option consiste à utiliser une source de données externe.

par exemple, étant donné un nom de fichier avec la variable deployment_package , générez le hachage base64 avec ce qui suit :

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

et l'utiliser comme tel:

source_code_hash = data.external.deployment_package.result.filebase64sha256

qui devrait te donner

+ source_code_hash = "ZjRkOTM4MzBlMDk4ODVkNWZmMDIyMTAwMmNkMDhmMTJhYTUxMDUzZmIzOThkMmE4ODQyOTc2MjcwNThmZmE3Nwo="

+1 ce problème, cela nous cause beaucoup de douleur car nous voulons intentionnellement intégrer des fichiers plus volumineux dans le terraform.

Je vois que https://github.com/hashicorp/terraform/pull/20906 a été fusionné il y a plus d'un an, mais le symptôme décrit ci-dessus persiste.

La limite de transfert grpc peut-elle être augmentée tout au long du projet pour permettre au service en aval qui peut accepter de telles charges utiles de fonctionner correctement sans solutions de contournement ?

Toujours en cours avec Terraform 0.12.24. Une solution de contournement pour corriger l'erreur de limite GRPC ?

Cela se produit toujours avec Terraform 0.13.5, lors de l'utilisation body avec une API Gateway (v2) , en utilisant la version 3.14.1 du fournisseur AWS.

Pour plus de clarté, j'utilise la fonction file dans mon cas :

body = file(var.body)

Le fichier en question a une taille de 1,5 Mo.

Si je supprime la déclaration body , Terraform s'exécute avec succès.

Mettre à jour

J'ai utilisé jq pour compresser et réduire la taille du corps à ~ 500 Ko, et il n'y a pas eu d'erreur. Il semble que le seuil soit inférieur à 4 Mo, 1 Mo, peut-être ?

J'ai toujours ce problème avec
Terraforme v0.12.29
fournisseur.archive v2.0.0
fournisseur.aws v3.15.0
fournisseur.template v2.2.0

Besoin filebase64 pour prendre en charge le fichier> 4 Mo car l'utiliser en combinaison avec archive_file est le seul moyen de le rendre idempotent.
L'utilisation d'un local_file entre les freins qui ....

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

J'ai également ce problème en essayant de déployer une fonction Rust sur IBM Cloud. De la même manière que @atamgp , j'ai un data "archive_file" qui échoue avec

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

Mais même si cela réussissait (ou si le fichier .zip était créé manuellement), le resource "ibm_function_action" échouerait toujours avec

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

Face au même problème avec la carte de configuration 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

J'ai rencontré le même problème - il semble qu'il y ait une limitation du nombre de caractères dans le code de ressource.

L'utilisation du fichier téléchargé dans le compartiment (sans le compresser) a résolu mon problème - je suppose que ce qui a aidé est le fait que .body de s3 est généralement un flux, opposé à .rendered (que j'utilisais auparavant), qui génère plus de caractères dans la source de ressources.

Cela se produit toujours avec Terraform 0.13.5, lors de l'utilisation body avec une API Gateway (v2) , en utilisant la version 3.14.1 du fournisseur AWS.

Pour plus de clarté, j'utilise la fonction file dans mon cas :

body = file(var.body)

Le fichier en question a une taille de 1,5 Mo.

Si je supprime la déclaration body , Terraform s'exécute avec succès.

Mettre à jour

J'ai utilisé jq pour compresser et réduire la taille du corps à ~ 500 Ko, et il n'y a pas eu d'erreur. Il semble que le seuil soit inférieur à 4 Mo, 1 Mo, peut-être ?

@finferflu - ont trouvé la même chose, nous nous heurtions à cela avec un fichier openapi json de 1,5 Mo. J'avais l'impression que ce n'était pas le véritable descripteur de fichier sur le JSON qui en était la cause, mais le "corps" de l'API REST contient maintenant ce qui est ensuite inclus dans l'état - et il y a probablement beaucoup de caractères d'échappement et d'autres éléments dans l'état - de sorte que le fichier d'état dépasse 4 Mo. Pour éviter un fichier local pour le swagger, nous avons téléchargé sur S3 et utilisé un objet de données s3 dans TF et le même problème s'est produit - donc un indicateur fort pour le supporter.

Toujours avoir ce problème avec v0.15.4 et terraform cloud. Nous avons importé une infrastructure lors de l'utilisation de terraform cloud, puis avons essayé un plan, mais nous ne pouvons pas obtenir le fichier d'état :

╷
│ Erreur : erreur de plug-in
│
│ avec okta_group.user_type_non_service_accounts,
│ sur la ligne 174 de groups.tf, dans la ressource "okta_group" "user_type_non_service_accounts":
│ 174 : ressource "okta_group" "user_type_non_service_accounts" {
│
│ Le plugin a renvoyé une erreur inattendue du plugin.(*GRPCProvider).UpgradeResourceState : erreur rpc : code = ResourceExhausted desc = grpc : message reçu supérieur au maximum (6280527 contre 4194304)

Mon fichier fait environ 2,4 Mo et je suis confronté à ce problème encore aujourd'hui.

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

des solutions de contournement pour cela s'il vous plaît?

Nous avons rencontré cette erreur lors de l'utilisation de fichiers JSON swagger et de la passerelle API.
Nous avons temporairement résolu ce problème en compressant le fichier swagger JSON pour réduire les fichiers, ce qui était suffisant. la taille de swagger est passée de 1,4 Mo à 950 Ko.

Ce n'est pas une véritable solution de contournement, mais cela aide peut-être quelqu'un qui est également proche de la limite.
Étrangement, l'erreur persistait même si nous n'utilisions aucune donnée/ressource local.template_file ou local.file (nous avons utilisé la fonction templatefile à la place).

Cela peut-il attirer plus d'attention s'il vous plaît?