Terraform-provider-local: grpc: تلقي رسالة أكبر من الحد الأقصى

تم إنشاؤها على ١٣ يونيو ٢٠١٩  ·  24تعليقات  ·  مصدر: hashicorp/terraform-provider-local

_تم فتح هذا الإصدار في الأصل بواسطة tebriel كـ hashicorp / terraform # 21709. تم ترحيله هنا كنتيجة لتقسيم الموفر . النص الأصلي للمشكلة أدناه.


نسخة Terraform

Terraform v0.12.2
+ provider.archive v1.2.1
+ provider.aws v2.14.0
+ provider.local v1.2.2
+ provider.template v2.1.1

ملفات تكوين Terraform

// Nothing exceptionally important at this time

إخراج التصحيح


https://gist.github.com/tebriel/08f699ce69555a2670884343f9609feb

إخراج الأعطال


لا تحطم

سلوك متوقع


كان يجب أن يكون قد أكمل الخطة

السلوك الفعلي

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

خطوات التكاثر


خطة terraform في مشروعي المتوسط ​​الحجم.

سياق إضافي


يعمل داخل الماركة ، لكن له نفس الملف الشخصي خارج الماركة. هذا ينطبق على الغرامة في 0.11.14.

مراجع

enhancement

التعليق الأكثر فائدة

هل يمكن أن يحظى هذا بمزيد من الاهتمام من فضلك؟

ال 24 كومينتر

بعد إجراء بعض التحقيقات والمناقشات في hashicorp / terraform # 21709 ، قمت بنقل هذا هنا لتمثيل تغيير لإضافة حد لحجم الملف إلى هذا المزود (أصغر من حد 4 ميغابايت الذي تفرضه Terraform Core حتى لا يصطدم المستخدمون بهذا الخطأ العام أبدًا حتى عندما حساب النفقات العامة للبروتوكول) ولتوثيق هذا الحد لكل من مصدر البيانات local_file local_file ونوع المورد $ # $ 1 $ # $.

هل هذا لا يزال مفتوحا؟ أود التقاط هذا إذا كان الأمر كذلك.
هل يمكنك توضيح / تأكيد الطلب؟

  1. أضف حد حجم ملف يبلغ 4 ميغا بايت في الموفر المحلي من خلال مدقق
  2. قم بتحديث المستندات لتعكس حد الحجم

أهلا

هل تخطط لإصلاح هذه المشكلة؟ إذا كان الأمر كذلك ، فمتى؟

هل هذا لا يزال مفتوحا؟ أود التقاط هذا إذا كان الأمر كذلك.
هل يمكنك توضيح / تأكيد الطلب؟

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

2. Update docs to reflect the size limit

أعتقد أن أفضل إصلاح سيكون لدعم الملفات> 4 ميجا بايت

نعم ، لا تزال هذه المشكلة قائمة.

نعم ، واجهت هذه المشكلة اليوم في مصدر بيانات local_file الذي يشير إلى ملف أرشيف AWS Lambda محتمل.

مرحبًا ، هل هناك أي تقدم في هذه القضية أم أنها متوقفة؟ يمكن أن تصبح هذه مشكلة أكبر إذا استخدمنا ملف نموذج من Kubernetes ويجب أن نخزن الملف على القرص. نظرًا لأن ملفات kubernetes Yaml يمكن أن تصبح كبيرة جدًا.
عملي هو تقسيم الملف إلى 2. كان حجم الملف الأولي 2 ميجا بايت ، والآن لدي ملفان يقل كل منهما قليلاً عن 1 ميجا بايت وهو يعمل.
شكرا

ركض في هذا باستخدام مورد 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)

هل هناك اتفاق حول كيفية المضي قدما؟
تعمل الملفات التي يزيد حجمها عن 4 ميغا بايت في السابق فقط بسبب نقص فحوصات السلامة (راجع https://github.com/hashicorp/terraform/issues/21709#issuecomment-501497885) لذا فإن الخطأ صالح ولا يبدو أنه تغيير الحد في terraform core سيكون خيارًا أيضًا (Re: "ليس خطأ ، إنه ميزة").

يمكننا التعامل معها محليًا عن طريق تقسيم الملفات إلى أجزاء بحجم 4 ميغا بايت داخل الموفر ، لكنني لست متأكدًا مما إذا كان ذلك سيؤدي إلى مشكلات خاصة به. يمكنني متابعة ذلك ولكن قبل أن أضيع الوقت ، هل سيكون هذا مقبولًا حتى 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)

يبدو أنه تم تحديث الحزمة الأساسية للسماح بسعة 64 ميجا بايت - https://github.com/hashicorp/terraform/pull/20906#

ووفقًا لحدود lambda ، يمكن تحميل ملفات مستندات 50 ميجا بايت.

ألن يكون من الأفضل ضبط فحص الأمان على 50 ميغا بايت؟

فقط لمعلوماتك لأي شخص لديه هذه المشكلة.

إذا وضعت ملفك المضغوط في دلو s3 ، فلن تواجه هذه المشكلة. لكن تذكر استخدام aws_s3_bucket_object.lambda_zip.content_base64 بدلاً من وظيفة filebase64 (المسار) ، فلن تواجهك هذه المشكلة (أو على الأقل كان هذا هو الحل بالنسبة لي).

هناك خيار آخر وهو استخدام مصدر بيانات خارجي.

على سبيل المثال ، عند إعطاء اسم ملف بالمتغير 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 هذه المشكلة ، إنها تسبب لنا الكثير من الألم لأننا نريد عن قصد تضمين ملفات أكبر حجمًا في التضاريس.

أرى أنه تم دمج https://github.com/hashicorp/terraform/pull/20906 منذ أكثر من عام ، لكن الأعراض الموضحة أعلاه لا تزال قائمة.

هل يمكن زيادة حد نقل grpc في جميع أنحاء المشروع للسماح للخدمة النهائية التي يمكنها قبول مثل هذه الأحمال للعمل بشكل صحيح دون حلول بديلة؟

لا يزال يحدث مع Terraform 0.12.24. أي حل بديل لإصلاح خطأ حد GRPC؟

لا يزال هذا يحدث مع Terraform 0.13.5 ، عند استخدام body مع بوابة API (الإصدار 2) ، باستخدام الإصدار 3.14.1 من موفر AWS.

لإضافة المزيد من الوضوح ، أستخدم الوظيفة file في حالتي:

body = file(var.body)

حجم الملف المعني 1.5 ميغابايت.

إذا قمت بإزالة تصريح body ، فسيتم تشغيل Terraform بنجاح.

تحديث

لقد استخدمت jq لضغط وتقليل حجم الجسم إلى 500 كيلوبايت تقريبًا ، ولم يكن هناك خطأ. يبدو أن العتبة قد تكون أقل من 4 ميغا بايت ، 1 ميغا بايت ، ربما؟

لا يزال لدي هذه المشكلة مع
Terraform v0.12.29
Provider.archive v2.0.0
Provider.aws v3.15.0
Provider.template v2.2.0

تحتاج filebase64 لدعم ملف> 4 ميجا بايت لأن استخدامه مع 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

لقد واجهت نفس المشكلة - يبدو أن هناك قيودًا على عدد الأحرف الموجودة في رمز المورد.

أدى استخدام الملف الذي تم تحميله إلى الحاوية (بدون ضغطه) إلى إصلاح مشكلتي - أفترض أن ما ساعدني هو حقيقة أن. المزيد من الشخصيات في مصدر الموارد.

لا يزال هذا يحدث مع Terraform 0.13.5 ، عند استخدام body مع بوابة API (الإصدار 2) ، باستخدام الإصدار 3.14.1 من موفر AWS.

لإضافة المزيد من الوضوح ، أستخدم الوظيفة file في حالتي:

body = file(var.body)

حجم الملف المعني 1.5 ميغابايت.

إذا قمت بإزالة تصريح body ، فسيتم تشغيل Terraform بنجاح.

تحديث

لقد استخدمت jq لضغط وتقليل حجم الجسم إلى 500 كيلوبايت تقريبًا ، ولم يكن هناك خطأ. يبدو أن العتبة قد تكون أقل من 4 ميغا بايت ، 1 ميغا بايت ، ربما؟

finferflu - لقد وجدنا نفس الشيء ، كنا نواجه هذا باستخدام ملف openapi json 1.5 ميغا بايت. كان لدي انطباع بأنه لم يكن مقبض الملف الفعلي على JSON هو الذي تسبب في ذلك ، ولكن "جسم" واجهة برمجة تطبيقات REST يحتوي الآن على هذا الذي تم تضمينه بعد ذلك في الحالة - ومن المحتمل أن يكون هناك الكثير من أحرف الهروب و عناصر أخرى في الحالة - لذلك يتجاوز حجم ملف الحالة 4 ميغابايت. لتجنب ملف محلي لـ swagger ، قمنا بتحميله إلى S3 واستخدمنا كائن بيانات s3 في TF وحدثت نفس المشكلة - لذلك مؤشر قوي لدعم ذلك.

لا تزال تواجه هذه المشكلة مع v0.15.4 و terraform cloud. قمنا باستيراد بعض البنية الأساسية أثناء استخدام سحابة terraform ثم جربنا خطة ، لكن لا يمكننا إخراج ملف الحالة:


│ خطأ: خطأ في البرنامج المساعد

│ مع 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: code = ResourceExhausted desc = grpc: تلقي رسالة أكبر من max (6280527 مقابل 4194304)

يبلغ حجم ملفي حوالي 2.4 ميغابايت وأنا أواجه هذه المشكلة حتى اليوم.

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

هل من حلول لهذا من فضلك؟

واجهنا هذا الخطأ عند استخدام ملفات swagger JSON وبوابة API.
لقد أصلحنا هذه المشكلة مؤقتًا عن طريق ضغط ملف JSON swagger لتقليص الملفات التي كانت كافية. ذهب حجم اختيال من 1.4 ميغا بايت إلى 950 كيلو بايت.

إنه ليس حلًا حقيقيًا ، ولكن ربما يساعد شخصًا قريبًا أيضًا من الحد الأقصى.
الغريب ، استمر الخطأ على الرغم من أننا لم نستخدم أي ملف / بيانات local.template_file أو local.file (استخدمنا وظيفة templatefile بدلاً من ذلك).

هل يمكن أن يحظى هذا بمزيد من الاهتمام من فضلك؟

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات