مرحبا،
أنا أستخدم terraform v0.10.8 وموفر aws 1.1.0 وأحصل على الخطأ التالي عند تحديث قواعد دخول مجموعة الأمان بإضافة حقل الوصف.
أنا قادر على تحديث SG ، لكنني بحاجة إلى إزالة جميع القواعد يدويًا. ثم يعمل terraform ويقوم بتحديث SG. عندما أحاول تحديث SG مرة أخرى ، يحدث الخطأ.
لا يحدث هذا الخطأ إذا لم يكن لدى SG أي قواعد مع حقل الوصف.
سطر أوامر terraform
تطبيق $ terraform -target
=== ناتج التضاريس
خطأ: خطأ في تطبيق الخطة:
حدث خطأ واحد (أخطاء):
aws_security_group.client-demo-sg-devops: حدث خطأ واحد (أخطاء):
aws_security_group. * *: خطأ في إبطال قواعد دخول مجموعة الأمان: InvalidPermission.NotFound: القاعدة المحددة غير موجودة في مجموعة الأمان هذه.
كود الحالة: 400 ، معرف الطلب: 2bfe24f7-a980-4bbc-a58d-54e5935f57a6
لا يتراجع Terraform تلقائيًا في مواجهة الأخطاء.
بدلاً من ذلك ، تم تحديث ملف حالة Terraform جزئيًا بـ
أي موارد أنجزت بنجاح. الرجاء معالجة الخطأ
أعلاه ثم قدم طلبًا مرة أخرى لتغيير بنيتك الأساسية بشكل تدريجي.
عجيب.
تم إجراء المزيد من التغييرات ، وهناك SG تم تحديثه بشكل جيد ، مع تضمين الوصف.
يحتوي SG الثاني هذا على نفس عدد قواعد الدخول الخاصة بالقواعد التي تحصل على خطأ ولا يخطئ عند تحديثه.
إجراء المزيد من الاختبارات.
يبدو أنه مرتبط بطول محتوى حقل الوصف.
إذا كان محتوى حقل الوصف لجميع قواعد الدخول في SG هو نفسه ، فلن يحدث الخطأ.
يحتمل أن تكون مرتبطة؟ # 1959
لا ، ليس هذا هو الطول.
نعم ، # 1959 قد تكون ذات صلة.
من الجولة الثانية لتطبيق terraform ، دون تغييرات ، والحصول على خطأ ، لاحظ أنه يقارن القواعد بالقاعدة الأخيرة لمجموعة الأمان.
شكر،
@ تاكيدا - جواو صيد جيد
نفس المشكلة من ذوي الخبرة هنا.
اختبرت للتو AWS Provider 1.2 وما زالت المشكلة قائمة.
أي تعديل حدث في هذه القضية؟ أنا أيضا أواجه هذه المشكلة في تطبيقي.
تم إصلاحه في # 1959 وتم إصداره كجزء من الإصدار 1.3.1
نفس المشكلة هنا. في انتظار اختبار v1.3.1.
أعتقد أن هذه المشكلة لا تزال موجودة. لقد قمت بإنشاء مجموعات أمان جديدة مع terraform وعندما أعيد تشغيل التطبيق ، يشكو terraform مع
* module.webui.aws_security_group.web: 1 error(s) occurred:
* aws_security_group.web: Error revoking security group ingress rules: InvalidPermission.NotFound: The specified rule does not exist in this security group.
status code: 400, request id: 20c88505-d009-42ba-bc30-c0444cef2e94
عند تعيين علامة التتبع والنظر إلى استدعاء aws ، فإن terraform يمرر الوصف الخاطئ إلى aws:
Action=RevokeSecurityGroupIngress&GroupId=sg-b25012c7&IpPermissions.1.FromPort=3389&IpPermissions.1.IpProtocol=tcp&IpPermissions.1.IpRanges.1.CidrIp=172.16.0.0%2F16&IpPermissions.1.IpRanges.1.Description=RDP&IpPermissions.1.ToPort=3389&Version=2016-11-15
يحاول terraform إزالة القاعدة لـ CIDR 172.16.0.0/16 ووصف RDP ، لكن وصف كتلة CIDR هذه هو في الواقع RDP من مساحات العمل . توجد قاعدة لكتلة CIDR منفصلة وصفها هو RDP
إليك مقتطف من مجموعة الأمان الخاصة بي:
ingress {
description = "RDP"
from_port = 3389
to_port = 3389
protocol = "tcp"
cidr_blocks = ["10.0.0.0/8"]
}
ingress {
description = "RDP from Workspaces"
from_port = 3389
to_port = 3389
protocol = "tcp"
cidr_blocks = ["${var.workspaces_cidr_blocks}"]
}
من الناتج terraform plan
، أرى أن terraform تعتقد أنها بحاجة إلى حذف قاعدة RDP وإنشاء قاعدة لـ RDP For Workspaces ، لكنها لا تفعل ذلك.
ingress.1615219479.cidr_blocks.#: "1" => "0"
ingress.1615219479.cidr_blocks.0: "172.16.0.0/16" => ""
ingress.1615219479.description: "RDP" => ""
ingress.1615219479.from_port: "3389" => "0"
ingress.1615219479.ipv6_cidr_blocks.#: "0" => "0"
ingress.1615219479.protocol: "tcp" => ""
ingress.1615219479.security_groups.#: "0" => "0"
ingress.1615219479.self: "false" => "false"
ingress.1615219479.to_port: "3389" => "0"
ingress.2147368551.cidr_blocks.#: "0" => "1"
ingress.2147368551.cidr_blocks.0: "" => "172.16.0.0/16"
ingress.2147368551.description: "" => "RDP from Workspaces"
ingress.2147368551.from_port: "" => "3389"
ingress.2147368551.ipv6_cidr_blocks.#: "0" => "0"
ingress.2147368551.protocol: "" => "tcp"
ingress.2147368551.security_groups.#: "0" => "0"
ingress.2147368551.self: "" => "false"
ingress.2147368551.to_port: "" => "3389"
إصدار Terraform:
""
Terraform v0.11.1
لا تزال هناك مشكلة.
أنا أستخدم أيضًا Provider.aws v1.5.0 ومن المستحيل تشغيل تطبيق ما لم تقم بإزالة حقل الوصف يدويًا (ومن حالات التضاريس).
أرى هذه المشكلة أيضًا. إذا قمت بحذف الوصف الموجود في وحدة التحكم ، فقم بحذف حقل الوصف في حالة tf ، فسيتم تشغيل تطبيق terraform. ولكن إذا حاولت تشغيل التطبيق مرة أخرى دون تغيير أي شيء ، فسوف يفشل.
reznet tnx
تحدث هذه المشكلة فقط عند استخدام كتل ingress {}
أو egress {}
من مورد aws_security_group
.
يعمل الإعلان المنفصل عن المجموعة والقواعد كما هو متوقع وهو أكثر طريقة مفضلة للقيام بذلك.
resource "aws_security_group" "test" {
name = "test-rules"
description = "test"
}
resource "aws_security_group_rule" "test_rule1" {
type = "ingress"
description = "RDP"
from_port = "3389"
to_port = "3389"
protocol = "tcp"
cidr_blocks = ["10.0.0.0/8"]
security_group_id = "${aws_security_group.test.id}"
}
resource "aws_security_group_rule" "test_rule2" {
type = "ingress"
description = "RDP from Workspaces"
from_port = "3389"
to_port = "3389"
protocol = "tcp"
cidr_blocks = ["170.0.0.0/8"]
security_group_id = "${aws_security_group.test.id}"
}
هل يمكننا ذكر embedded blocks
في عنوان الإصدار؟ لجعلها أكثر واقعية؟
radeksimko wdyt؟
نفس المشكلة هنا.
رؤية هذا أيضا.
tf v.0.11.2
aws.provider 1.2.0 ولكنه تم إصلاحه باستخدام aws-Provider 1.6.0
تم العثور على مصدر المشكلة - بنية البيانات التي تم إرجاعها بواسطة ResourceAwsSecurityGroupIPPermGather ()
ضع في اعتبارك التالي مورد TF:
resource "aws_security_group" "test" {
name = "test"
ingress {
description = "RDP 11111"
from_port = 3389
to_port = 3389
protocol = "tcp"
cidr_blocks = ["1.1.1.1/32"]
}
ingress {
description = "RDP 22222"
from_port = 3389
to_port = 3389
protocol = "tcp"
cidr_blocks = ["2.2.2.2/32"]
}
}
مقارنة الهياكل المحلية / البعيدة (مطوية)
محلي:
[]interface {}{
map[string]interface {}{
"protocol":"tcp",
"ipv6_cidr_blocks":[]interface {}{},
"self":false,
"description":"RDP 11111",
"from_port":3389,
"cidr_blocks":[]interface {}{"1.1.1.1/32"},
"security_groups":*Set(map[string]interface {}(nil)),
"to_port":3389
},
map[string]interface {}{
"self":false,
"description":"RDP 22222",
"to_port":3389,
"protocol":"tcp",
"security_groups":*Set(map[string]interface {}(nil)),
"from_port":3389,
"cidr_blocks":[]interface {}{"2.2.2.2/32"},
"ipv6_cidr_blocks":[]interface {}{}
}
}
التحكم عن بعد:
[]map[string]interface {}{
map[string]interface {}{
"description":"RDP 22222",
"from_port":3389,
"to_port":3389,
"protocol":"tcp",
"cidr_blocks":[]string{"1.1.1.1/32", "2.2.2.2/32"}
}
}
لذا ، تحتوي البنية البعيدة على عنصر واحد فقط مع description
منفصل من cidr_blocks
، ولهذا السبب لا يمكن تعيينها بشكل صحيح إلى البنية المحلية.
سأعمل على الإصلاح في الأيام القادمة.
ما هو أفضل حل لهذا في الوقت الحالي؟
kenske ، استخدم aws_security_group_rule
إنه أكثر تعقيدًا قليلاً مما اعتقدته من قبل. تحتاجradeksimkoNinir المشورة اور.
هيكل بيانات cidr_blocks
، ipv6_cidr_blocks
، prefix_list_ids
& security_groups
كتل من resource_aws_security_group.go يجب أن تتم ترقية من []string
إلى []map[string]string
للاحتفاظ بالوصف مع قيمة الكتلة أو شريحة من النوع الداخلي الجديد (أفضل هذا):
type sgItem struct {
Value string
Description string
}
wdyt؟ تينكس
أي تحديثات؟
@ kenske لقد jaymecd لأننا نستخدم موجود في التعريف. لا أعتقد أن هذا ممكن مع aws_security_group_rule
أو ، إذا كان الأمر كذلك ، فلن أتمكن من العثور على طريقة لمسح القواعد التي أضافها شخص ما يدويًا عبر وحدة التحكم / واجهة برمجة تطبيقات AWS.
لقد احتجت إلى تمكين التصحيح / التتبع لمعرفة ما تم استدعاؤه بالضبط (والفشل) عبر RevokeSecurityGroupIngress ، ثم قمت يدويًا بتعيين الوصف على تلك القواعد في AWS ، لذا في المرة التالية التي حاول فيها terraform apply
إزالتها ، ينجح. بعد ذلك ، وبدون حقول وصف منافسة ، كان كل terraform plan
من تلك النقطة فصاعدًا نظيفًا.
ScottSorrentino كان الأمر مؤلمًا نوعًا ما ، لكنني اتبعت اقتراح
نظرًا لأن حالة العمل الخاصة بالقواعد المضمنة تبدو مفقودة ، فإليك بالتفصيل.
الإعلانات ذات النمط المضمن هي طريقة لقول هذه القواعد فقط ، حيث يشير نمط المورد المنفصل إلى هذه القواعد على الأقل . من وجهة نظر الامتثال ، فإن هذه القواعد هي آلية إنفاذ السياسة ، حيث تضمن هذه القواعد على الأقل وجود الوظائف المعتمدة. هذا له تأثيرات كبيرة جدًا عندما يحين وقت التدقيق.
عندما يسألنا المدققون:
يرجى وصف كيفية تطبيق قواعد جدار الحماية من خلال التحكم في التغيير.
يسمح لنا استخدام النمط المضمن بتجنب الاضطرار إلى بناء نظام معقد لاستيعاب حدث CloudTrail والارتباط بنظام طلب التغيير الخاص بنا لإظهار أنه يتم تنفيذ التغييرات المعتمدة فقط وأن التغيير الانجراف يتم اكتشافه والانزعاج منه ، إذا لم يتم منعه تمامًا . بدلاً من ذلك ، يمكننا أن نمنحهم سجل الالتزام الخاص بإعادة الشراء الخاصة بنا. يفهم المدققون تدفقات الموافقة على git-repos و merge-request. لقد قالوا من حيث الجوهر:
يا! مثل Puppet ، ولكن لتعريفات مجموعة الأمان!
وهذا يجعل العملية برمتها أسهل بكثير . هذا هو واحد من أكبر القيمة المضافة التي تقدمها لنا Terraform في بنيتنا التحتية.
لقد واجهت هذه المشكلة اليوم أيضًا.
ومع ذلك ، في حالتي حيث لدي قاعدة مثل ما يلي
resource "aws_security_group_rule" "DEFAULT_DO_NOT_USE-1" {
type = "ingress"
from_port = 0
to_port = 0
protocol = "-1"
self = "true"
description = "Allow all incoming traffic from withing this security group"
security_group_id = "${aws_security_group.DEFAULT_DO_NOT_USE.id}"
}
لا يمكنني استخدام aws_security_group_rule
كما هو مقترح أعلاه من قبل jaymecd حيث سينتهي بي الأمر إلى إصابة خطأ مختلف موضح في # 1920
أي حل آخر؟
أهلا مرة أخرى،
بعد الكثير من اللعب المؤلم مع هذا ، استنتجت أن المشكلة تكمن في استخدام حقل description
إما لقاعدة الدخول أو الخروج والتقديم مرة أخرى بعد المرة الأولى. أدناه أكتب الخطوات التي أوصلتني إلى هذا الاستنتاج.
لدي تصريح المورد أدناه (تم التعليق على الملاحظة description
باستثناء الإدخال الأول):
resource "aws_security_group" "bastion_priv_SG-master" {
name = "bastion_priv_SG-master"
description = "Security group for bastion host"
vpc_id = "${aws_vpc.us_n_virg_VPC-master-10_100_0_0-16.id}"
# incoming
ingress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["xx.xx.xx.xx/32"]
description = "Allow all incoming traffic from xx.xx.xx.xx/32"
}
ingress {
from_port = 0
to_port = 0
protocol = "-1"
self = "true"
#description = "Allow all incoming traffic from within this SG"
}
ingress {
from_port = 9100
to_port = 9100
protocol = "tcp"
security_groups = ["${data.aws_security_group.app_priv_SG_QAMonitor.id}"]
#description = "Allow all incoming traffic from app_priv_SG_QAMonitor SG"
}
# outgoing
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
#description = "Allow all outgoing traffic from this SG to the Internet"
}
tags {
Name = "bastion_priv_SG-master"
}
}
تطبيق أن المرة الأولى تعمل بشكل جيد وأرى التغييرات المتوقعة في مجموعة الأمان. تقوم عملية الاستصلاح بشكل غريب بحذف قاعدة الدخول الأولى وإعادة إنشائها. لكنها تطبق بنجاح. فيما يلي نتيجة الإجراء التطبيقي:
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
~ update in-place
Terraform will perform the following actions:
~ aws_security_group.bastion_priv_SG-master
ingress.1242592041.cidr_blocks.#: "1" => "0"
ingress.1242592041.cidr_blocks.0: "xx.xx.xx.xx/32" => ""
ingress.1242592041.description: "" => ""
ingress.1242592041.from_port: "0" => "0"
ingress.1242592041.ipv6_cidr_blocks.#: "0" => "0"
ingress.1242592041.protocol: "-1" => ""
ingress.1242592041.security_groups.#: "0" => "0"
ingress.1242592041.self: "false" => "false"
ingress.1242592041.to_port: "0" => "0"
ingress.1698735776.cidr_blocks.#: "0" => "0"
ingress.1698735776.description: "" => ""
ingress.1698735776.from_port: "9100" => "9100"
ingress.1698735776.ipv6_cidr_blocks.#: "0" => "0"
ingress.1698735776.protocol: "tcp" => "tcp"
ingress.1698735776.security_groups.#: "1" => "1"
ingress.1698735776.security_groups.3308286315: "sg-5477a429" => "sg-5477a429"
ingress.1698735776.self: "false" => "false"
ingress.1698735776.to_port: "9100" => "9100"
ingress.502957524.cidr_blocks.#: "0" => "1"
ingress.502957524.cidr_blocks.0: "" => "xx.xx.xx.xx/32"
ingress.502957524.description: "" => "Allow all incoming traffic from xx.xx.xx.xx/32"
ingress.502957524.from_port: "" => "0"
ingress.502957524.ipv6_cidr_blocks.#: "0" => "0"
ingress.502957524.protocol: "" => "-1"
ingress.502957524.security_groups.#: "0" => "0"
ingress.502957524.self: "" => "false"
ingress.502957524.to_port: "" => "0"
ingress.753360330.cidr_blocks.#: "0" => "0"
ingress.753360330.description: "" => ""
ingress.753360330.from_port: "0" => "0"
ingress.753360330.ipv6_cidr_blocks.#: "0" => "0"
ingress.753360330.protocol: "-1" => "-1"
ingress.753360330.security_groups.#: "0" => "0"
ingress.753360330.self: "true" => "true"
ingress.753360330.to_port: "0" => "0"
Plan: 0 to add, 1 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
aws_security_group.bastion_priv_SG-master: Modifying... (ID: sg-4183373a)
ingress.1242592041.cidr_blocks.#: "1" => "0"
ingress.1242592041.cidr_blocks.0: "xx.xx.xx.xx/32" => ""
ingress.1242592041.description: "" => ""
ingress.1242592041.from_port: "0" => "0"
ingress.1242592041.ipv6_cidr_blocks.#: "0" => "0"
ingress.1242592041.protocol: "-1" => ""
ingress.1242592041.security_groups.#: "0" => "0"
ingress.1242592041.self: "false" => "false"
ingress.1242592041.to_port: "0" => "0"
ingress.1698735776.cidr_blocks.#: "0" => "0"
ingress.1698735776.description: "" => ""
ingress.1698735776.from_port: "9100" => "9100"
ingress.1698735776.ipv6_cidr_blocks.#: "0" => "0"
ingress.1698735776.protocol: "tcp" => "tcp"
ingress.1698735776.security_groups.#: "1" => "1"
ingress.1698735776.security_groups.3308286315: "sg-5477a429" => "sg-5477a429"
ingress.1698735776.self: "false" => "false"
ingress.1698735776.to_port: "9100" => "9100"
ingress.502957524.cidr_blocks.#: "0" => "1"
ingress.502957524.cidr_blocks.0: "" => "xx.xx.xx.xx/32"
ingress.502957524.description: "" => "Allow all incoming traffic from xx.xx.xx.xx/32"
ingress.502957524.from_port: "" => "0"
ingress.502957524.ipv6_cidr_blocks.#: "0" => "0"
ingress.502957524.protocol: "" => "-1"
ingress.502957524.security_groups.#: "0" => "0"
ingress.502957524.self: "" => "false"
ingress.502957524.to_port: "" => "0"
ingress.753360330.cidr_blocks.#: "0" => "0"
ingress.753360330.description: "" => ""
ingress.753360330.from_port: "0" => "0"
ingress.753360330.ipv6_cidr_blocks.#: "0" => "0"
ingress.753360330.protocol: "-1" => "-1"
ingress.753360330.security_groups.#: "0" => "0"
ingress.753360330.self: "true" => "true"
ingress.753360330.to_port: "0" => "0"
aws_security_group.bastion_priv_SG-master: Modifications complete after 2s (ID: sg-4183373a)
Apply complete! Resources: 0 added, 1 changed, 0 destroyed.
الآن ، إذا تقدمت بطلب مرة أخرى دون تغيير أي شيء في الموارد ، فسيفشل:
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
~ update in-place
Terraform will perform the following actions:
~ aws_security_group.bastion_priv_SG-master
ingress.1698735776.cidr_blocks.#: "0" => "0"
ingress.1698735776.description: "" => ""
ingress.1698735776.from_port: "9100" => "9100"
ingress.1698735776.ipv6_cidr_blocks.#: "0" => "0"
ingress.1698735776.protocol: "tcp" => "tcp"
ingress.1698735776.security_groups.#: "1" => "1"
ingress.1698735776.security_groups.3308286315: "sg-5477a429" => "sg-5477a429"
ingress.1698735776.self: "false" => "false"
ingress.1698735776.to_port: "9100" => "9100"
ingress.2396394866.cidr_blocks.#: "0" => "0"
ingress.2396394866.description: "Allow all incoming traffic from xx.xx.xx.xx/32" => ""
ingress.2396394866.from_port: "0" => "0"
ingress.2396394866.ipv6_cidr_blocks.#: "0" => "0"
ingress.2396394866.protocol: "-1" => ""
ingress.2396394866.security_groups.#: "0" => "0"
ingress.2396394866.self: "true" => "false"
ingress.2396394866.to_port: "0" => "0"
ingress.502957524.cidr_blocks.#: "1" => "1"
ingress.502957524.cidr_blocks.0: "xx.xx.xx.xx/32" => "xx.xx.xx.xx/32"
ingress.502957524.description: "Allow all incoming traffic from xx.xx.xx.xx/32" => "Allow all incoming traffic from xx.xx.xx.xx/32"
ingress.502957524.from_port: "0" => "0"
ingress.502957524.ipv6_cidr_blocks.#: "0" => "0"
ingress.502957524.protocol: "-1" => "-1"
ingress.502957524.security_groups.#: "0" => "0"
ingress.502957524.self: "false" => "false"
ingress.502957524.to_port: "0" => "0"
ingress.753360330.cidr_blocks.#: "0" => "0"
ingress.753360330.description: "" => ""
ingress.753360330.from_port: "" => "0"
ingress.753360330.ipv6_cidr_blocks.#: "0" => "0"
ingress.753360330.protocol: "" => "-1"
ingress.753360330.security_groups.#: "0" => "0"
ingress.753360330.self: "" => "true"
ingress.753360330.to_port: "" => "0"
Plan: 0 to add, 1 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
aws_security_group.bastion_priv_SG-master: Modifying... (ID: sg-4183373a)
ingress.1698735776.cidr_blocks.#: "0" => "0"
ingress.1698735776.description: "" => ""
ingress.1698735776.from_port: "9100" => "9100"
ingress.1698735776.ipv6_cidr_blocks.#: "0" => "0"
ingress.1698735776.protocol: "tcp" => "tcp"
ingress.1698735776.security_groups.#: "1" => "1"
ingress.1698735776.security_groups.3308286315: "sg-5477a429" => "sg-5477a429"
ingress.1698735776.self: "false" => "false"
ingress.1698735776.to_port: "9100" => "9100"
ingress.2396394866.cidr_blocks.#: "0" => "0"
ingress.2396394866.description: "Allow all incoming traffic from xx.xx.xx.xx/32" => ""
ingress.2396394866.from_port: "0" => "0"
ingress.2396394866.ipv6_cidr_blocks.#: "0" => "0"
ingress.2396394866.protocol: "-1" => ""
ingress.2396394866.security_groups.#: "0" => "0"
ingress.2396394866.self: "true" => "false"
ingress.2396394866.to_port: "0" => "0"
ingress.502957524.cidr_blocks.#: "1" => "1"
ingress.502957524.cidr_blocks.0: "xx.xx.xx.xx/32" => "xx.xx.xx.xx/32"
ingress.502957524.description: "Allow all incoming traffic from xx.xx.xx.xx/32" => "Allow all incoming traffic from xx.xx.xx.xx/32"
ingress.502957524.from_port: "0" => "0"
ingress.502957524.ipv6_cidr_blocks.#: "0" => "0"
ingress.502957524.protocol: "-1" => "-1"
ingress.502957524.security_groups.#: "0" => "0"
ingress.502957524.self: "false" => "false"
ingress.502957524.to_port: "0" => "0"
ingress.753360330.cidr_blocks.#: "0" => "0"
ingress.753360330.description: "" => ""
ingress.753360330.from_port: "" => "0"
ingress.753360330.ipv6_cidr_blocks.#: "0" => "0"
ingress.753360330.protocol: "" => "-1"
ingress.753360330.security_groups.#: "0" => "0"
ingress.753360330.self: "" => "true"
ingress.753360330.to_port: "" => "0"
Error: Error applying plan:
1 error(s) occurred:
* aws_security_group.bastion_priv_SG-master: 1 error(s) occurred:
* aws_security_group.bastion_priv_SG-master: Error revoking security group ingress rules: InvalidPermission.NotFound: The specified rule does not exist in th
status code: 400, request id: 98d8fa95-0aa2-40b8-851d-0a10bb25572b
Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.
اين الموضوع ..؟
في نتيجة إجراء التطبيق الثاني أعلاه ، لاحظ قاعدة الدخول بالرقم 2396394866
يرى Terraform ، بطريقة ما ومن مكان ما ، قاعدة دخول تحاول الحذف ولا توجد في أي مكان في ملف حالتي أو مجموعة الأمان الخاصة بي في AWS. ولهذا السبب تشتكي من عدم وجود قاعدة دخول مجموعة الأمان.
لماذا وكيف يرى Terraform شيئًا غير موجود في .tf أو ملف الحالة هو السؤال.
وهذا لا يكفي ، لا يمكنني الخروج من هذا الموقف حتى لو قمت بالتعليق على الوصف من قاعدة الدخول. ستظل تفشل مع نفس الخطأ. وأظن أن هذا لأن ملف الحالة الآن في حالة غير متسقة لأنه لا يتراجع.
لا بد لي من حذف مورد مجموعة الأمان يدويًا من ملف الحالة ، وإجراء التحديث ، واستيراده مرة أخرى ، ثم إنشاء قواعد الدخول والخروج واحدة تلو الأخرى بدون الوصف.
لا يمكنني تحديد مكان الخطأ هنا ، لكنني أقترح على أي شخص آخر عدم تقديم وصف لقواعد الدخول والخروج المتداخلة إذا كنت لا تريد الدخول في هذا الموقف.
أنا أقوم بتشغيل Terraform v0.11.5
شكر،
حصلت على بعض هذه الليلة. حتى لو علقت على الوصف ، فإنه لا يزال يتسبب في الخطأ. فقط بعد حذف الخط تمامًا ، بدأت الأشياء في العمل كما هو متوقع.
Terraform v0.11.5
+ Provider.aws v1.13.0
أعاد الخطأ تقديمه مرة أخرى في
""
Terraform v0.11.5
الموفر "aws" (1.13.0)
هل تم إصلاح الخلل بالفعل؟ ما زلت أرى ذلك أيضًا ، على الرغم من أنني لا أستطيع معرفة كيفية تحديث موفر AWS الخاص بي (أنا على 1.6 وتشغيل terraform init
لا يفعل شيئًا لتغيير ذلك).
ibrahima ما زال لم يرَ أي تحديثات حول الخطأ.
بالنسبة للإصدار المقدم ، حاول حذف الملف المشابه لـ .terraform/plugins/linux_amd64/terraform-provider-aws_v1.14.1_x4
وهو ما أملكه ثم قم بتشغيل init
مرة أخرى. سيؤدي هذا إلى تحديث إصدار الموفر.
حسنًا ، لقد اكتشفت ذلك بالفعل بعد نشر التعليق (نوعًا ما بديهيًا ، لأن الرسالة terraform init
تقول أنه تم تثبيت أحدث إصدار ، ولكن حسنًا). والآن أعاني بالفعل من عدد أكبر من الأخطاء وليس أقل:
لتحديث الموفر ، عليك تشغيل terraform init -upgrade
.
تعاني من هذا أيضًا.
Terraform v0.11.5
+ provider.archive v1.0.3
+ provider.aws v1.11.0
أردت فقط ملاحظة أن هذا يحدث أيضًا لمورد aws_default_security_group
، حيث لا يعد استخدام موارد aws_security_group_rule
الفردية خيارًا
أواجه مشكلة مماثلة عند تحديث قواعد مجموعة الأمان ، ولا علاقة لها بالوصف ، ويبدو أن ملف حالة tf يصبح غير متزامن مع قواعد مجموعة الأمان في وقت التطبيق ، يقوم أولاً بإزالة / تعديل قاعدة الأمان ثم يحاول لإضافة خصائص جديدة.
$ terraform -version
Terraform v0.11.7
لا يزال هذا موجودًا ، لقد قمت بحذف جميع الأوصاف يدويًا في نظام AWS وإعادة تشغيل البرنامج النصي للتهيئة.
Caspain لدي نفس المشكلة اليوم. نجح حذف الأوصاف والتقديم مرة أخرى بشكل جيد
مرحبًا يا رفاق 👋 عذرًا ، لقد كانت هذه مشكلة طويلة الأمد مع مزود AWS. يجب أن يتم تضمين الإصلاح الخاص بذلك في رقم 4416 الذي سيتم إصداره مع الإصدار 1.19.0 من مزود AWS ، على الأرجح في منتصف الأسبوع المقبل.
صرخات إلى loivis (و svanharmelen الذي قدم في وقت سابق ، من المحتمل أن يكون العلاقات العامة الصحيحة ، والذي كان يجب أن
نظرًا لوجود العديد من المشكلات المختلفة المحيطة بهذا الخطأ ، سأقوم بإغلاق هذه المشكلة (من بين جميع المشكلات الأخرى) لتشجيع أي مشكلات / مناقشة عالقة ليتم وصفها بالكامل في العدد (المشكلات) الجديدة للتوحيد. شكرا لتفهمك.
التعليق الأكثر فائدة
حصلت على بعض هذه الليلة. حتى لو علقت على الوصف ، فإنه لا يزال يتسبب في الخطأ. فقط بعد حذف الخط تمامًا ، بدأت الأشياء في العمل كما هو متوقع.
Terraform v0.11.5
+ Provider.aws v1.13.0