Terraform-provider-local: grpc: empfangene Nachricht größer als max

Nach einigen Untersuchungen und Diskussionen in hashicorp/terraform#21709 habe ich dies hierher verschoben, um eine Änderung darzustellen, um diesem Anbieter eine Dateigrößenbeschränkung hinzuzufügen (kleiner als die von Terraform Core auferlegte 4-MB-Grenze, damit Benutzer diesen allgemeinen Fehler niemals treffen, selbst wenn Zählen des Protokoll-Overheads) und diese Grenze sowohl für die Datenquelle local_file als auch für den Ressourcentyp local_file zu dokumentieren.

Ist das noch offen? Ich würde das gerne holen, wenn ja.
Können Sie die Anfrage präzisieren/bestätigen?

1. Fügen Sie die Dateigrößenbeschränkung von 4 MB im lokalen Anbieter über einen Validator hinzu
2. Aktualisieren Sie die Dokumente, um die Größenbeschränkung widerzuspiegeln

Hallo

Planen Sie, dieses Problem zu beheben? Wenn ja, wann?

Ist das noch offen? Ich würde das gerne holen, wenn ja.
Können Sie die Anfrage präzisieren/bestätigen?

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

2. Update docs to reflect the size limit

Ich denke, die beste Lösung wird darin bestehen, Dateien >4 MB zu unterstützen

Ja, dieses Problem besteht weiterhin.

Ja, ich bin heute auf dieses Problem in der Datenquelle local_file gestoßen, die auf eine potenzielle AWS Lambda-Archivdatei verweist.

Hallo, gibt es Fortschritte bei diesem Problem oder wurde es geparkt? Dies kann zu einem größeren Problem werden, wenn wir eine Vorlagendatei von Kubernetes verwenden und die Datei auf der Festplatte speichern müssen. Seit Kubernetes können Yaml-Dateien ziemlich groß werden.
Meine Arbeit besteht darin, die Datei in 2 Teile aufzuteilen. Die ursprüngliche Dateigröße war 2 MB, jetzt habe ich 2 Dateien mit jeweils etwas weniger als 1 MB und es funktioniert.
Danke

Durch die Verwendung der Ressource aws_lambda_function darauf gestoßen...

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)

Gibt es eine Einigung darüber, wie wir vorankommen können?
Dateien über 4 MB funktionierten zuvor nur aufgrund fehlender Sicherheitsüberprüfungen (siehe https://github.com/hashicorp/terraform/issues/21709#issuecomment-501497885), sodass der Fehler gültig ist und nicht nach einer Änderung des Limits klingt in Terraform Core wird auch eine Option sein (Re: „kein Fehler, es ist ein Feature“).

Wir könnten es möglicherweise lokal handhaben, indem wir Dateien innerhalb des Anbieters in 4-MB-Blöcke aufteilen, aber ich bin mir nicht sicher, ob dies zu eigenen Problemen führen würde. Ich kann dem nachgehen, aber bevor ich Zeit verschwende, wäre das überhaupt akzeptabel @apparentlymart ?

Bei Verwendung von Terraform 0.12.23 und AWS-Anbieter 2.61.0 wird derselbe Fehler Error: rpc error: code = ResourceExhausted desc = grpc: received message larger than max (18182422 vs. 4194304) angezeigt

Es sieht so aus, als ob das Kernpaket aktualisiert wurde, um 64 MB zuzulassen – https://github.com/hashicorp/terraform/pull/20906#

Und gemäß den Lambda-Grenzwerten können 50-MB-Dateien hochgeladen werden.

Wäre es nicht am besten, den Sicherheitscheck auf 50 MB einzustellen?

Nur als FYI für alle, die dieses Problem haben.

Wenn Sie Ihre ZIP-Datei in einen S3-Bucket legen, sollten Sie dieses Problem nicht haben. Denken Sie jedoch daran, die Funktion aws_s3_bucket_object.lambda_zip.content_base64 anstelle der Funktion filebase64(path) zu verwenden, dann haben Sie dieses Problem nicht (oder zumindest war das die Lösung für mich).

Eine weitere Option ist die Verwendung einer externen Datenquelle.

Generieren Sie beispielsweise bei einem Dateinamen mit der Variablen deployment_package den base64-Hash mit dem Folgenden:

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

und verwende es so:

source_code_hash = data.external.deployment_package.result.filebase64sha256

was dir geben soll

+ source_code_hash = "ZjRkOTM4MzBlMDk4ODVkNWZmMDIyMTAwMmNkMDhmMTJhYTUxMDUzZmIzOThkMmE4ODQyOTc2MjcwNThmZmE3Nwo="

+1 dieses Problem, es bereitet uns große Schmerzen, da wir absichtlich größere Dateien in das Terraform einfügen möchten.

Ich sehe, dass https://github.com/hashicorp/terraform/pull/20906 vor über einem Jahr zusammengeführt wurde, aber das oben beschriebene Symptom besteht immer noch.

Kann das Limit für die grpc-Übertragung im gesamten Projekt erhöht werden, damit nachgelagerte Dienste, die solche Nutzlasten akzeptieren können, ohne Problemumgehungen ordnungsgemäß funktionieren?

Passiert immer noch mit Terraform 0.12.24. Gibt es eine Problemumgehung, um den GRPC-Limit-Fehler zu beheben?

Dies passiert immer noch mit Terraform 0.13.5, wenn body mit einem API Gateway (v2) verwendet wird, mit Version 3.14.1 des AWS-Anbieters.

Um mehr Klarheit zu schaffen, verwende ich in meinem Fall die Funktion file :

body = file(var.body)

Die betreffende Datei hat eine Größe von 1,5 MB.

Wenn ich die Deklaration body entferne, wird Terraform erfolgreich ausgeführt.

Aktualisieren

Ich habe jq verwendet, um die Größe des Körpers zu komprimieren und auf ~500 KB zu reduzieren, und es gab keinen Fehler. Es sieht so aus, als wäre der Schwellenwert niedriger als 4 MB, vielleicht 1 MB?

Ich habe immer noch dieses Problem mit
Terraform v0.12.29
provider.archive v2.0.0
provider.aws v3.15.0
Anbieter.Vorlage v2.2.0

Benötigen Sie filebase64 , um Dateien > 4 MB zu unterstützen, da die Verwendung in Kombination mit archive_file die einzige Möglichkeit ist, sie idempotent zu machen.
Die Verwendung einer local_file dazwischen bremst das....

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

Ich habe dieses Problem auch beim Versuch, eine Rust-Funktion in IBM Cloud bereitzustellen. Ähnlich wie bei @atamgp habe ich ein data "archive_file" , das fehlschlägt

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

Aber selbst wenn dies erfolgreich war (oder die .zip -Datei manuell erstellt wurde), würde die resource "ibm_function_action" immer noch mit fehlschlagen

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

Hatte das gleiche Problem mit der Kubernetes-Konfigurationskarte

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

Ich bin auf dasselbe Problem gestoßen - es sieht so aus, als ob es eine Beschränkung gibt, wie viele Zeichen im Ressourcencode enthalten sind.

Die Verwendung einer in den Bucket hochgeladenen Datei (ohne sie zu komprimieren) hat mein Problem behoben. Ich gehe davon aus, dass die Tatsache geholfen hat, dass .body von s3 normalerweise ein Stream ist, im Gegensatz zu .rendered (das ich zuvor verwendet habe), der generiert mehr Zeichen in der Ressourcenquelle.

Dies passiert immer noch mit Terraform 0.13.5, wenn body mit einem API Gateway (v2) verwendet wird, mit Version 3.14.1 des AWS-Anbieters.

Um mehr Klarheit zu schaffen, verwende ich in meinem Fall die Funktion file :

body = file(var.body)

Die betreffende Datei hat eine Größe von 1,5 MB.

Wenn ich die Deklaration body entferne, wird Terraform erfolgreich ausgeführt.

Aktualisieren

Ich habe jq verwendet, um die Größe des Körpers zu komprimieren und auf ~500 KB zu reduzieren, und es gab keinen Fehler. Es sieht so aus, als wäre der Schwellenwert niedriger als 4 MB, vielleicht 1 MB?

@finferflu - habe dasselbe festgestellt, wir sind mit einer 1,5-MB-openapi-json-Datei darauf gestoßen. Ich hatte den Eindruck, dass es nicht das eigentliche Dateihandle auf dem JSON war, das dies verursacht hat, aber der "Body" der REST-API enthält dies jetzt, was dann in den Status aufgenommen wird - und es gibt wahrscheinlich viele Escape-Zeichen und andere Elemente im Zustand - die Zustandsdatei überschreitet also 4 MB. Um eine lokale Datei für den Swagger zu vermeiden, haben wir auf S3 hochgeladen und ein s3-Datenobjekt in TF verwendet, und das gleiche Problem trat auf – also ein starker Indikator, der dies unterstützt.

Dieses Problem tritt immer noch mit v0.15.4 und Terraform Cloud auf. Wir haben eine Infrastruktur importiert, während wir die Terraform-Cloud verwendet haben, und dann einen Plan ausprobiert, können aber die Statusdatei nicht herausbekommen:

§
│ Fehler: Plugin-Fehler
│
│ mit okta_group.user_type_non_service_accounts,
│ auf groups.tf Zeile 174, in Ressource „okta_group“ „user_type_non_service_accounts“:
│ 174: Ressource „okta_group“ „user_type_non_service_accounts“ {
│
│ Das Plugin hat einen unerwarteten Fehler vom Plugin zurückgegeben.(*GRPCProvider).UpgradeResourceState: rpc error: code = ResourceExhausted desc = grpc: empfangene Nachricht größer als max. (6280527 vs. 4194304)

Meine Datei ist ungefähr 2,4 MB groß und ich stehe noch heute vor diesem Problem.

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

Irgendwelche Problemumgehungen dafür bitte?

Wir sind auf diesen Fehler gestoßen, als wir Swagger-JSON-Dateien und das API-Gateway verwendet haben.
Wir haben dieses Problem vorübergehend behoben, indem wir die JSON-Swagger-Datei komprimiert haben, um die Dateien zu verkleinern, was ausreichend war. Die Swagger-Größe stieg von 1,4 MB auf 950 KB.

Es ist kein wirklicher Workaround, aber vielleicht hilft es jemandem, der auch nahe am Limit ist.
Seltsamerweise blieb der Fehler bestehen, obwohl wir keine local.template_file- oder local.file-Daten/Ressourcen verwendet haben (wir haben stattdessen die Funktion templatefile verwendet).

Kann das bitte mehr Aufmerksamkeit bekommen?