_この問題は、もともと@tebrielによってhashicorp / terraform# 21709として開かれました。 プロバイダーの分割の結果として、ここに移行されました。 問題の元の本文は以下のとおりです。_
Terraform v0.12.2
+ provider.archive v1.2.1
+ provider.aws v2.14.0
+ provider.local v1.2.2
+ provider.template v2.1.1
// 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)
私の中規模プロジェクトのテラフォーム計画。
make内で実行されていますが、make外でも同じプロファイルを持っています。 これは0.11.14でも問題なく適用されます。
hashicorp / terraform#21709で調査と議論を行った後、このプロバイダーにファイルサイズの制限を追加するための変更を表すためにこれをここに移動しました(Terraform Coreによって課される4MBの制限よりも小さいため、ユーザーがその一般的なエラーに遭遇することはありません。プロトコルオーバーヘッドのカウント)およびlocal_file
データソースとlocal_file
リソースタイプの両方の制限を文書化します。
これはまだ開いていますか? もしそうなら、これを拾いたいです。
リクエストを明確化/確認していただけますか?
こんにちは
この問題を修正する予定はありますか? もしそうなら、いつ?
これはまだ開いていますか? もしそうなら、これを拾いたいです。
リクエストを明確化/確認していただけますか?1. Add file size limit of 4mb in the local provider through a validator 2. Update docs to reflect the size limit
最善の解決策は、4Mbを超えるファイルをサポートすることだと思います
はい、この問題はまだ解決していません。
はい、今日、将来のAWSLambdaアーカイブファイルを指すlocal_fileデータソースでこの問題に遭遇しました。
こんにちは、この問題について何か進展はありますか、それとも駐車されましたか? Kubernetesのテンプレートファイルを使用し、ファイルをディスクに保存する必要がある場合、これはより大きな問題になる可能性があります。 kubernetesのYamlファイルはかなり大きくなる可能性があるため。
私の回避策は、ファイルを2つに分割することです。初期のファイルサイズは2Mbでしたが、現在はそれぞれ1Mbより少し小さい2つのファイルがあり、機能します。
ありがとう
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 MBを超えるファイルは、安全性チェックがないために以前は機能していました(https://github.com/hashicorp/terraform/issues/21709#issuecomment-501497885を参照)。そのため、エラーは有効であり、制限を変更するようには聞こえません。テラフォームコアでもオプションになります(Re:「バグではなく、機能です」)。
プロバイダー内でファイルを4MBのチャンクに分割することでローカルで処理できる可能性がありますが、それによって独自の問題が発生するかどうかはわかりません。 私はそれを追求することができますが、時間を無駄にする前に、それは@apparentlymartでも受け入れられますか?
Terraform 0.12.23とawsプロバイダー2.61.0を使用して、同じエラーを取得Error: rpc error: code = ResourceExhausted desc = grpc: received message larger than max (18182422 vs. 4194304)
コアパッケージが64MBを許可するように更新されたようです-https ://github.com/hashicorp/terraform/pull/20906#
また、ラムダ制限ドキュメントによると、50MBのファイルをアップロードできます。
安全チェックを50MBに設定するのが最善ではないでしょうか?
この問題を抱えている人のためのFYIと同じように。
zipファイルをs3バケットに入れる場合、この問題に直面することはありません。 ただし、filebase64(path)関数ではなくaws_s3_bucket_object.lambda_zip.content_base64
を使用することを忘れないでください。そうすれば、この問題は発生しません(または、少なくともそれが私の修正でした)。
別のオプションは、外部データソースを使用することです。
たとえば、変数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が1年以上前にマージされたようですが、上記の症状はまだ続いています。
grpc転送の制限をプロジェクト全体で増やして、そのようなペイロードを受け入れることができるダウンストリームサービスが回避策なしで適切に機能できるようにすることはできますか?
Terraform0.12.24でもまだ発生しています。 GRPC制限エラーを修正するための回避策はありますか?
これは、AWSプロバイダーのバージョン3.14.1を使用してAPI Gateway(v2)でbody
を使用している場合、Terraform0.13.5でも引き続き発生します。
さらに明確にするために、私の場合はfile
関数を使用しています。
body = file(var.body)
問題のファイルのサイズは1.5MBです。
body
宣言を削除すると、Terraformは正常に実行されます。
jq
を使用して、本体のサイズを約500KBに圧縮および縮小しましたが、エラーは発生しませんでした。 しきい値が4MB、1MBよりも低い可能性があるようです。
私はまだこの問題を抱えています
Terraform v0.12.29
Provider.archive v2.0.0
Provider.aws v3.15.0
Provider.template v2.2.0
$ archive_file
と組み合わせて使用することがべき等にする唯一の方法であるため、4MBを超えるファイルをサポートするにfilebase64
が必要です。
ブレーキの間に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関数をIBMCloudにデプロイしようとすると、この問題も発生します。 @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
同じ問題が発生しました。リソースコードに含まれる文字数に制限があるようです。
バケットにアップロードされたファイルを(圧縮せずに)使用すると、問題が修正されました-s3の.bodyは通常、.rendered(以前使用していた)とは対照的に、ストリームであるという事実が助けになったと思います。リソースソースの文字数が増えました。
これは、AWSプロバイダーのバージョン3.14.1を使用してAPI Gateway(v2)で
body
を使用している場合、Terraform0.13.5でも引き続き発生します。さらに明確にするために、私の場合は
file
関数を使用しています。body = file(var.body)
問題のファイルのサイズは1.5MBです。
body
宣言を削除すると、Terraformは正常に実行されます。アップデート
jq
を使用して、本体のサイズを約500KBに圧縮および縮小しましたが、エラーは発生しませんでした。 しきい値が4MB、1MBよりも低い可能性があるようです。
@finferflu-同じことを発見しました。1.5MBのopenapijsonファイルでこれに遭遇していました。 これを引き起こしているのはJSONの実際のファイルハンドルではないという印象を受けましたが、REST APIの「本体」にはこれが含まれ、状態に含まれるようになりました。おそらく多くのエスケープ文字と状態内の他のアイテム-したがって、statefileは4mbを超えます。 Swaggerのローカルファイルを回避するために、S3にアップロードしてTFでs3データオブジェクトを使用しましたが、同じ問題が発生しました。これをサポートする強力な指標です。
v0.15.4とテラフォームクラウドでもこの問題が発生します。 テラフォームクラウドを使用しているときにインフラストラクチャをインポートしてから計画を試しましたが、状態ファイルを取得できませんでした。
╷
│エラー:プラグインエラー
│
│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エラー:コード= ResourceExhausted desc = grpc:最大より大きいメッセージを受信しました(6280527対4194304)
私のファイルは約2.4MBで、今日でもこの問題に直面しています。
resource "local_file" "parse-template" {
content = templatefile(local.template-name, {
var1 = value1
var2 = value2
})
filename = "${local.script-name}"
}
このための回避策はありますか?
SwaggerJSONファイルとAPIゲートウェイを使用しているときにこのエラーが発生しました。
JSON swaggerファイルを圧縮してファイルを縮小することで、この問題を一時的に修正しました。これで十分でした。 闊歩のサイズは1.4Mbから950Kbになりました。
これは実際の回避策ではありませんが、制限に近い人にも役立つ可能性があります。
不思議なことに、local.template_fileまたはlocal.file data / resourceを使用しなかったにもかかわらず(代わりにtemplatefile関数を使用した)、エラーが持続しました。
これはもっと注目を集めることができますか?
最も参考になるコメント
これはもっと注目を集めることができますか?