Terraform نقصان

اچو ته ڪجھ نقصانن کي نمايان ڪريون، جن ۾ لوپس سان لاڳاپيل آھن، جيڪڏھن بيان ۽ ڊيپلائيشن ٽيڪنڪ، ۽ گڏوگڏ وڌيڪ عام مسئلا جيڪي عام طور تي Terraform کي متاثر ڪن ٿا:

• ڳڻپ ۽ for_each پيٽرولر جون حدون آهن؛
• صفر بند وقت جي مقرري کي محدود ڪريو؛
• جيتوڻيڪ هڪ سٺو منصوبو ناڪام ٿي سگهي ٿو؛
• refactoring ان جا نقصان ٿي سگهي ٿو.
• ملتوي هم آهنگي مسلسل آهي ... ملتوي سان.

ڳڻپ ۽ for_each پيٽرولر جون حدون آهن

هن باب ۾ مثال ڳڻپ جي پيٽرولر جو وسيع استعمال ڪن ٿا ۽ لوپس ۽ مشروط منطق ۾ هر هڪ اظهار لاءِ. اهي سٺو ڪم ڪن ٿا، پر انهن وٽ ٻه اهم حدون آهن جيڪي توهان کي ڄاڻڻ جي ضرورت آهي.

• ڳڻڻ ۽ لاءِ_هر ڪنهن به آئوٽ ريسورس متغير جو حوالو نٿو ڏئي سگهي.
• شمار ۽ for_each ماڊل ترتيبن ۾ استعمال نٿو ڪري سگھجي.

شمار ۽ for_each ڪنهن به وسيلن جي ٻاھرين متغير جو حوالو نٿو ڏئي سگھي

تصور ڪريو توهان کي ڪيترن ئي EC2 سرورز کي ترتيب ڏيڻ جي ضرورت آهي ۽ ڪجهه سببن لاء توهان ASG استعمال ڪرڻ نٿا چاهيو. توھان جو ڪوڊ ھن طرح ٿي سگھي ٿو:

resource "aws_instance" "example_1" {
   count             = 3
   ami                = "ami-0c55b159cbfafe1f0"
   instance_type = "t2.micro"
}

اچو ته انهن کي هڪ هڪ ڪري ڏسو.

جيئن ته ڳڻپيوڪر پيٽرولر هڪ جامد قدر تي مقرر ڪيو ويو آهي، هي ڪوڊ بغير ڪنهن مسئلن جي ڪم ڪندو: جڏهن توهان لاڳو ڪريو حڪم هلائيندا، اهو ٽي EC2 سرور ٺاهيندو. پر ڇا جيڪڏھن توھان چاھيو ٿا ھڪڙي سرور کي ھر دستيابي علائقي (AZ) ۾ پنھنجي موجوده AWS علائقي ۾؟ توهان ڪري سگهو ٿا توهان جو ڪوڊ لوڊ ڪري زونن جي هڪ فهرست aws_availability_zones ڊيٽا ماخذ کان ۽ پوءِ هر هڪ ذريعي لوپ ڪريو ۽ ان ۾ هڪ EC2 سرور ٺاهيو ڳڻپ پيراميٽر ۽ صف انڊيڪس رسائي استعمال ڪندي:

resource "aws_instance" "example_2" {
   count                   = length(data.aws_availability_zones.all.names)
   availability_zone   = data.aws_availability_zones.all.names[count.index]
   ami                     = "ami-0c55b159cbfafe1f0"
   instance_type       = "t2.micro"
}

data "aws_availability_zones" "all" {}

هي ڪوڊ به ٺيڪ ڪم ڪندو، ڇاڪاڻ ته ڳڻپ جي پيٽرولر بغير ڪنهن مسئلي جي ڊيٽا ذريعن جو حوالو ڏئي سگهي ٿو. پر ڇا ٿيندو جيڪڏهن سرورن جو تعداد جيڪو توهان کي ٺاهڻ جي ضرورت آهي ڪجهه وسيلن جي پيداوار تي منحصر آهي؟ هن کي ظاهر ڪرڻ لاء، آسان طريقو استعمال ڪرڻ آهي random_integer وسيلو، جيڪو، جيئن نالو مشورو ڏئي ٿو، هڪ بي ترتيب عددي واپسي:

resource "random_integer" "num_instances" {
  min = 1
  max = 3
}

هي ڪوڊ 1 ۽ 3 جي وچ ۾ هڪ بي ترتيب نمبر ٺاهي ٿو. اچو ته ڏسون ته ڇا ٿيندو جيڪڏهن اسان هن وسيلن جي آئوٽ پٽ کي aws_instance وسيلن جي ڳڻپ جي پيٽرولر ۾ استعمال ڪرڻ جي ڪوشش ڪندا آهيون:

resource "aws_instance" "example_3" {
   count             = random_integer.num_instances.result
   ami                = "ami-0c55b159cbfafe1f0"
   instance_type = "t2.micro"
}

جيڪڏهن توهان هن ڪوڊ تي ٽرافارم پلان هلائيندا آهيو، توهان کي هيٺ ڏنل غلطي ملندي:

Error: Invalid count argument

   on main.tf line 30, in resource "aws_instance" "example_3":
   30: count = random_integer.num_instances.result

The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this, use the -target argument to first apply only the resources that the count depends on.

Terraform جي ضرورت آهي ته ڳڻپ ۽ for_each رٿابندي جي مرحلي دوران حساب ڪيو وڃي، ان کان اڳ جو ڪو به وسيلا ٺاهيا وڃن يا تبديل ڪيا وڃن. هن جو مطلب اهو آهي ته شمار ۽ for_each لفظي، متغير، ڊيٽا ذريعن، ۽ حتي وسيلن جي فهرستن ڏانهن اشارو ڪري سگھن ٿا (جيستائين انهن جي ڊيگهه شيڊولنگ جي وقت تي طئي ٿي سگهي ٿي)، پر نه حسابي وسيلن جي پيداوار جي متغيرن ڏانهن.

شمار ۽ for_each ماڊل ترتيبن ۾ استعمال نٿو ڪري سگھجي

ڪنهن ڏينهن توهان کي آزمائيو ويندو ته توهان جي ماڊل جي ترتيب ۾ ڳڻپ پيٽرولر شامل ڪريو:

module "count_example" {
     source = "../../../../modules/services/webserver-cluster"

     count = 3

     cluster_name = "terraform-up-and-running-example"
     server_port = 8080
     instance_type = "t2.micro"
}

ھي ڪوڊ ھڪڙي ماڊل اندر ڳڻپ کي استعمال ڪرڻ جي ڪوشش ڪري ٿو ويب سرور-ڪلستر وسيلن جي ٽي ڪاپيون ٺاھيو. يا ٿي سگھي ٿو توھان چاھيو ٿا ڪنيڪٽ ڪرڻ واري ماڊل کي اختياري بنياد تي ڪجھ بولين جي حالت جي بنياد تي ان جي ڳڻپ جي پيٽرولر کي 0 تي سيٽ ڪندي. اھو ٿي سگھي ٿو مناسب ڪوڊ وانگر، پر توھان کي ھي نقص ملندو جڏھن ٽرافارم پلان ھلائيندي:

Error: Reserved argument name in module block

   on main.tf line 13, in module "count_example":
   13: count = 3

The name "count" is reserved for use in a future version of Terraform.

بدقسمتي سان، Terraform 0.12.6 جي طور تي، ڳڻپ يا for_each استعمال ڪندي ماڊل وسيلن ۾ سهڪار نه ڪيو ويو آهي. Terraform 0.12 رليز نوٽس (http://bit.ly/3257bv4) جي مطابق، HashiCorp مستقبل ۾ ھن صلاحيت کي شامل ڪرڻ جو ارادو رکي ٿو، تنھنڪري ان تي منحصر آھي جڏھن توھان ھي ڪتاب پڙھندا، اھو اڳ ۾ ئي دستياب ٿي سگھي ٿو. پڪ سان معلوم ڪرڻ لاء، پڙهو Terraform changelog هتي.

زيرو ڊائون ٽائم ڊيپلائيمينٽ جون حدون

ASG سان ميلاپ ۾ create_before_destroy بلاڪ کي استعمال ڪرڻ صفر-ڊائون ٽائم ڊيپلائيمينٽ ٺاهڻ لاءِ هڪ بهترين حل آهي، سواءِ هڪ خبردار جي: آٽو اسڪيلنگ ضابطا سپورٽ نه آهن. يا وڌيڪ صحيح ٿيڻ لاءِ، هي ASG سائيز کي ريٽ سيٽ ڪري ٿو min_size تي هر ڊيپلائيمينٽ تي، جيڪو مسئلو ٿي سگهي ٿو جيڪڏهن توهان استعمال ڪري رهيا آهيو آٽو اسڪيلنگ قاعدن کي هلائڻ لاءِ سرور جو تعداد وڌائڻ لاءِ.

مثال طور، ويب سرور-ڪلسٽر ماڊل ۾ aws_autoscaling_schedule وسيلن جو هڪ جوڙو شامل آهي، جيڪو 9 am تي ڪلستر ۾ سرورن جو تعداد وڌائي ٿو ٻن کان ڏهن تائين. جيڪڏهن توهان مقرر ڪريو ٿا، چئو، 11 وڳي، نئون ASG ڏهن بجاءِ صرف ٻن سرورن سان بوٽ ڪندو ۽ ٻئي ڏينهن صبح 9 وڳي تائين اهو ئي رهندو.

ھن حد کي ڪيترن ئي طريقن سان ختم ڪري سگھجي ٿو.

• recurrence parameter in aws_autoscaling_schedule 0 9 * * * ("هلائي 9 am") مان تبديل ڪريو 0-59 9-17 * * * ("هر منٽ 9 am کان 5 pm تائين"). جيڪڏهن ASG اڳ ۾ ئي ڏهه سرور آهن، هن آٽو اسڪيلنگ قاعدي کي ٻيهر هلائڻ ۾ ڪا به تبديلي نه ايندي، جيڪو اسان چاهيون ٿا. پر جيڪڏهن ASG صرف تازو ڪيو ويو آهي، اهو قاعدو يقيني بڻائيندو ته وڌ ۾ وڌ هڪ منٽ ۾ ان جي سرورن جو تعداد ڏهه تائين پهچي ويندو. هي هڪ مڪمل طور تي خوبصورت انداز نه آهي، ۽ ڏهن کان ٻه سرور ۽ پوئتي کان وڏي ٽپو پڻ صارفين لاء مسئلا پيدا ڪري سگهي ٿي.
• هڪ ڪسٽم اسڪرپٽ ٺاهيو جيڪو AWS API استعمال ڪري ٿو ASG ۾ فعال سرورن جو تعداد طئي ڪرڻ لاءِ، ان کي ڪال ڪريو خارجي ڊيٽا ماخذ کي استعمال ڪندي (ڏسو "بيروني ڊيٽا ماخذ" صفحي 249 تي)، ۽ ASG جي مطلوب_capacity پيٽرولر کي سيٽ ڪريو لکت. اهڙيءَ طرح، هر نئين ASG مثال هميشه ساڳي ظرفيت تي هلندي جيئن موجوده Terraform ڪوڊ ۽ ان کي برقرار رکڻ وڌيڪ مشڪل بڻائي ٿو.

يقينن، Terraform کي مثالي طور تي زيرو-ڊائون ٽائم ڊيپلائيمينٽس لاءِ بلٽ ان سپورٽ حاصل هوندي، پر مئي 2019 تائين، HashiCorp ٽيم وٽ هن ڪارڪردگي کي شامل ڪرڻ جو ڪو به منصوبو نه هو (تفصيل - هتي).

صحيح منصوبو ناڪامي سان لاڳو ٿي سگھي ٿو

ڪڏهن ڪڏهن پلان ڪمانڊ هڪ مڪمل طور تي صحيح ترتيب ڏيڻ وارو منصوبو پيدا ڪري ٿو، پر لاڳو حڪم هڪ غلطي واپس ڪري ٿو. ڪوشش ڪريو، مثال طور، aws_iam_user resource کي ساڳي نالي سان شامل ڪريو جيڪو توھان IAM استعمال ڪندڙ لاءِ استعمال ڪيو آھي توھان اڳ ۾ باب 2 ۾ ٺاھيو آھي:

resource "aws_iam_user" "existing_user" {
   # Подставьте сюда имя уже существующего пользователя IAM,
   # чтобы попрактиковаться в использовании команды terraform import
   name = "yevgeniy.brikman"
}

ھاڻي، جيڪڏھن توھان هلائيندا آھيو پلان ڪمانڊ، Terraform ھڪڙو مناسب ٺاھڻ وارو منصوبو ٺاھيندو:

Terraform will perform the following actions:

   # aws_iam_user.existing_user will be created
   + resource "aws_iam_user" "existing_user" {
         + arn                  = (known after apply)
         + force_destroy   = false
         + id                    = (known after apply)
         + name               = "yevgeniy.brikman"
         + path                 = "/"
         + unique_id         = (known after apply)
      }

Plan: 1 to add, 0 to change, 0 to destroy.

جيڪڏهن توهان لاڳو حڪم هلائيندا آهيو توهان کي هيٺ ڏنل غلطي ملندي:

Error: Error creating IAM User yevgeniy.brikman: EntityAlreadyExists:
User with name yevgeniy.brikman already exists.

   on main.tf line 10, in resource "aws_iam_user" "existing_user":
   10: resource "aws_iam_user" "existing_user" {

مسئلو، يقينا، اهو آهي ته هڪ IAM صارف انهي نالي سان اڳ ۾ ئي موجود آهي. ۽ اهو ٿي سگهي ٿو نه رڳو IAM استعمال ڪندڙن سان، پر تقريبن ڪنهن به وسيلن ڏانهن. اهو ممڪن آهي ته ڪو ماڻهو هن وسيلو کي دستي طور تي يا ڪمانڊ لائن استعمال ڪندي ٺاهيو، پر ٻئي طريقي سان، ملندڙ IDs تڪرارن جي ڪري ٿي. ھن نقص جون ڪيتريون ئي تبديليون آھن جيڪي اڪثر ڪري نئين ايندڙن کي Terraform ۾ حيران ڪري وٺن ٿيون.

اهم نقطو اهو آهي ته ٽرافارم پلان ڪمانڊ صرف انهن وسيلن کي مدنظر رکي ٿو جيڪي Terraform اسٽيٽ فائل ۾ بيان ڪيا ويا آهن. جيڪڏهن وسيلا ڪنهن ٻئي طريقي سان ٺاهيا ويا آهن (مثال طور، دستي طور تي AWS ڪنسول ۾ ڪلڪ ڪندي)، اهي رياستي فائل ۾ ختم نه ٿيندا ۽ تنهن ڪري Terraform انهن کي اڪائونٽ ۾ نه وٺندو جڏهن پلان ڪمانڊ تي عمل ڪندي. نتيجي طور، هڪ منصوبو جيڪو صحيح لڳي ٿو پهرين نظر ۾ ناڪام ٿي ويندو.

ان مان سکڻ جا ٻه سبق آهن.

• جيڪڏهن توهان اڳ ۾ ئي Terraform سان ڪم ڪرڻ شروع ڪيو آهي، ٻيو ڪجهه استعمال نه ڪريو. جيڪڏهن توهان جي انفراسٽرڪچر جو حصو Terraform استعمال ڪندي منظم ڪيو ويو آهي، توهان هاڻي ان کي دستي طور تبديل نه ڪري سگهو ٿا. ٻي صورت ۾، توهان نه رڳو خطرناڪ Terraform غلطين جو خطرو آهي، پر توهان پڻ IaC جي ڪيترن ئي فائدن کي رد ڪندا آهيو ڇو ته ڪوڊ هاڻي توهان جي انفراسٽرڪچر جي صحيح نمائندگي نه ڪندو.
• جيڪڏهن توهان وٽ اڳ ۾ ئي ڪجهه انفراسٽرڪچر آهي، درآمد حڪم استعمال ڪريو. جيڪڏهن توهان موجوده انفراسٽرڪچر سان Terraform استعمال ڪرڻ شروع ڪري رهيا آهيو، ته توهان ان کي رياستي فائل ۾ شامل ڪري سگهو ٿا terraform امپورٽ ڪمانڊ استعمال ڪندي. هن طريقي سان Terraform کي معلوم ٿيندو ته ڪهڙي بنيادي ڍانچي کي منظم ڪرڻ جي ضرورت آهي. درآمد جو حڪم ٻه دلائل وٺندو آهي. پهرين توهان جي ترتيب واري فائلن ۾ وسيلن جو پتو آهي. ھتي نحو ساڳيو آھي جيئن وسيلن جي لنڪ لاءِ: _. (جهڙوڪ aws_iam_user.existing_user). ٻيو دليل اهو آهي ته وسيلن جي ID درآمد ڪئي وڃي. اچو ته چوندا آهن وسيلن جي ID aws_iam_user صارف جو نالو آهي (مثال طور، yevgeniy.brikman)، ۽ وسيلن جي ID aws_instance آهي EC2 سرور ID (جهڙوڪ i-190e22e5). هڪ وسيلو ڪيئن درآمد ڪجي عام طور تي ان جي صفحي جي تري ۾ دستاويز ۾ اشارو ڪيو ويو آهي.

  هيٺ هڪ درآمدي حڪم آهي جيڪو aws_iam_user وسيلن کي هم وقت سازي ڪري ٿو جيڪو توهان پنهنجي Terraform ترتيب ۾ شامل ڪيو آهي IAM صارف سان گڏ باب 2 ۾ (توهان جو نالو yevgeniy.brikman جي بدران، يقينا):

  $ terraform import aws_iam_user.existing_user yevgeniy.brikman

  Terraform توهان جي IAM صارف کي ڳولڻ لاءِ AWS API کي سڏيندو ۽ ان جي وچ ۾ هڪ اسٽيٽ فائل ايسوسيئيشن ٺاهيندو ۽ توهان جي Terraform ترتيب ۾ aws_iam_user.existing_user وسيلن جي وچ ۾. هاڻي کان، جڏهن توهان پلان ڪمانڊ هلائيندا آهيو، Terraform کي خبر پوندي ته IAM صارف اڳ ۾ ئي موجود آهي ۽ ان کي ٻيهر ٺاهڻ جي ڪوشش نه ڪندو.

  اهو نوٽ ڪرڻ جي قابل آهي ته جيڪڏهن توهان وٽ اڳ ۾ ئي ڪيترائي وسيلا آهن جيڪي توهان ٽرافارم ۾ درآمد ڪرڻ چاهيو ٿا، دستي طور تي ڪوڊ لکڻ ۽ هر هڪ کي هڪ وقت ۾ درآمد ڪرڻ هڪ پريشاني ٿي سگهي ٿي. تنهن ڪري اهو هڪ اوزار ڳولڻ جي قابل آهي جهڙوڪ Terraforming (http://terraforming.dtan4.net/)، جيڪو خودڪار طريقي سان ڪوڊ ۽ اسٽيٽ کي توهان جي AWS اڪائونٽ مان درآمد ڪري سگهي ٿو.

  Refactoring ان جا نقصان ٿي سگهن ٿا

  Refactoring پروگرامنگ ۾ هڪ عام رواج آهي جتي توهان ڪوڊ جي اندروني ڍانچي کي تبديل ڪندا آهيو جڏهن ته خارجي رويي کي تبديل نه ڪيو ويندو آهي. اهو ڪوڊ کي صاف، صاف، ۽ برقرار رکڻ لاء آسان بڻائڻ آهي. Refactoring هڪ لازمي ٽيڪنڪ آهي جنهن کي باقاعده استعمال ڪيو وڃي. پر جڏھن اھو اچي ٿو Terraform يا ڪنھن ٻئي IaC ٽول تي، توھان کي ان بابت تمام گھڻو محتاط رھڻو پوندو ته توھان جو مطلب ڇا آھي ڪوڊ جي ”خارجي رويي“ مان، ٻي صورت ۾ غير متوقع مسئلا پيدا ٿيندا.

  مثال طور، هڪ عام قسم جي ريفيڪٽرنگ کي تبديل ڪري رهيو آهي متغيرن جي نالن کي وڌيڪ سمجھڻ وارن سان يا افعال. ڪيترن ئي IDEs کي ريفڪٽرنگ لاءِ بلٽ ان سپورٽ آهي ۽ خودڪار طريقي سان سڄي منصوبي ۾ متغير ۽ افعال جو نالو مٽائي سگھي ٿو. عام مقصد جي پروگرامنگ ٻولين ۾، هي هڪ ننڍڙو طريقو آهي جنهن بابت توهان شايد نه سوچيو، پر Terraform ۾ توهان کي ان سان انتهائي محتاط رهڻو پوندو، ٻي صورت ۾ توهان کي بند ٿيڻ جو تجربو ٿي سگهي ٿو.

  مثال طور، webserver-cluster module input variable cluster_name:

  variable "cluster_name" {
     description = "The name to use for all the cluster resources"
     type          = string
  }

  تصور ڪريو ته توھان ھي ماڊل استعمال ڪرڻ شروع ڪيو آھي ھڪڙي microservice کي ترتيب ڏيڻ لاءِ foo. بعد ۾، توھان چاھيو ٿا پنھنجي خدمت جو نالو تبديل ڪريو بار ڏانھن. اها تبديلي شايد معمولي لڳي، پر حقيقت ۾ اها خدمت ۾ خلل پيدا ڪري سگهي ٿي.

  حقيقت اها آهي ته ويب سرور-ڪلستر ماڊل استعمال ڪري ٿو cluster_name متغير ڪيترن ئي وسيلن ۾، جنهن ۾ ٻه سيڪيورٽي گروپن جو نالو پيٽرولر ۽ ALB شامل آهن:

  resource "aws_lb" "example" {
     name                    = var.cluster_name
     load_balancer_type = "application"
     subnets = data.aws_subnet_ids.default.ids
     security_groups      = [aws_security_group.alb.id]
  }

  جيڪڏھن توھان ھڪڙي وسيلن تي نالو پيٽرولر تبديل ڪريو ٿا، Terraform ان وسيلن جي پراڻي ورزن کي ختم ڪري ڇڏيندو ۽ ان جي جاء تي ھڪڙو نئون ٺاھيندو. پر جيڪڏهن اهو وسيلو هڪ ALB آهي، ان کي حذف ڪرڻ ۽ نئين نسخي کي ڊائون لوڊ ڪرڻ جي وچ ۾، توهان وٽ هڪ ميکانيزم نه هوندو جيڪو توهان جي ويب سرور ڏانهن ٽرئفڪ کي ريڊائريڪٽ ڪري. ساڳئي طرح، جيڪڏهن هڪ سيڪيورٽي گروپ کي ختم ڪيو ويو آهي، توهان جي سرورز ڪنهن به نيٽ ورڪ ٽرئفڪ کي رد ڪرڻ شروع ڪندا جيستائين هڪ نئون گروپ ٺاهيو وڃي.

  ٻي قسم جي ريفڪٽرنگ توهان کي دلچسپي رکي ٿي Terraform ID تبديل ڪندي. اچو ته وٺو aws_security_group resource webserver-cluster module ۾ مثال طور:

  resource "aws_security_group" "instance" {
    # (...)
  }

  هن وسيلن جي سڃاڻپ ڪندڙ کي مثال طور سڏيو ويندو آهي. تصور ڪريو ته ريفيڪٽرنگ دوران توھان ان کي تبديل ڪرڻ جو فيصلو ڪيو وڌيڪ سمجھڻ وارو (توهان جي راء ۾) نالو cluster_instance:

  resource "aws_security_group" "cluster_instance" {
     # (...)
  }

  آخر ڇا ٿيندو؟ اهو صحيح آهي: هڪ رڪاوٽ.

  Terraform هر وسيلن جي ID کي ڪلائوڊ فراهم ڪندڙ جي ID سان ملائي ٿو. مثال طور، iam_user AWS IAM صارف ID سان جڙيل آهي، ۽ aws_instance AWS EC2 سرور ID سان جڙيل آهي. جيڪڏهن توهان وسيلا ID تبديل ڪريو ٿا (مثال کان cluster_instance ڏانهن، جيئن ته معاملو aws_security_group سان آهي)، Terraform ڏانهن اهو ظاهر ٿيندو ڄڻ توهان پراڻي وسيلن کي ڊاهي ڇڏيو ۽ هڪ نئون شامل ڪيو. جيڪڏهن توهان انهن تبديلين کي لاڳو ڪندا، Terraform پراڻي سيڪيورٽي گروپ کي ختم ڪري ڇڏيندو ۽ هڪ نئون ٺاهيندو، جڏهن ته توهان جا سرور ڪنهن به نيٽ ورڪ ٽرئفڪ کي رد ڪرڻ شروع ڪندا.

  هتي چار اهم سبق آهن توهان کي هن بحث مان پري وڃڻ گهرجي.

  • هميشه منصوبي جو حڪم استعمال ڪريو. اهو انهن سڀني شين کي ظاهر ڪري سگهي ٿو. ان جي پيداوار جو احتياط سان جائزو وٺو ۽ حالتن تي ڌيان ڏيو جتي Terraform وسيلن کي ختم ڪرڻ جو منصوبو ڪري ٿو جيڪي گهڻو ڪري ڊاهي نه وڃن.
  • ختم ڪرڻ کان اڳ ٺاھيو. جيڪڏھن توھان چاھيو ٿا ھڪڙو وسيلو مٽائڻ، ان بابت احتياط سان سوچيو ته ڇا توھان کي اصل کي حذف ڪرڻ کان پھريان ھڪڙو متبادل بڻائڻ جي ضرورت آھي. جيڪڏهن جواب ها آهي، create_before_destroy مدد ڪري سگھي ٿو. ساڳيو نتيجو دستي طور تي حاصل ڪري سگھجي ٿو ٻن مرحلن کي انجام ڏيڻ سان: پھريائين ڪنفگريشن ۾ نئون وسيلو شامل ڪريو ۽ اپلائي ڪمانڊ کي ھلايو، ۽ پوءِ پراڻا وسيلا ختم ڪريو ڪنفگريشن مان ۽ استعمال ڪريو پھرين ڪمانڊ لاڳو ڪريو.
  • سڃاڻپ ڪندڙ کي تبديل ڪرڻ جي حالت کي تبديل ڪرڻ جي ضرورت آهي. جيڪڏهن توهان وسيلن سان لاڳاپيل ID کي تبديل ڪرڻ چاهيو ٿا (مثال طور aws_security_group جو نالو مٽايو مثال کان cluster_instance) بغير وسيلن کي حذف ڪرڻ ۽ ان جو نئون ورزن ٺاهڻ جي، توهان کي لازمي طور تي Terraform اسٽيٽ فائل کي اپڊيٽ ڪرڻ گهرجي. اهو ڪڏهن به دستي طور تي نه ڪريو - بدران terraform اسٽيٽ ڪمانڊ استعمال ڪريو. جڏهن سڃاڻپ ڪندڙ جو نالو مٽائي، توهان کي ٽرافارم اسٽيٽ ايم وي ڪمانڊ هلائڻ گهرجي، جنهن ۾ هيٺيون نحو آهي:

    terraform state mv <ORIGINAL_REFERENCE> <NEW_REFERENCE>

    ORIGINAL_REFERENCE هڪ اظهار آهي جيڪو ان جي موجوده شڪل ۾ وسيلن ڏانهن اشارو ڪري ٿو، ۽ NEW_REFERENCE اهو آهي جتي توهان ان کي منتقل ڪرڻ چاهيو ٿا. مثال طور، جڏهن aws_security_group گروپ جو نالو بدلايو مثال کان cluster_instance، توھان کي ھيٺ ڏنل حڪم هلائڻ جي ضرورت آھي:

    $ terraform state mv 
       aws_security_group.instance 
       aws_security_group.cluster_instance

    هي Terraform کي ٻڌائي ٿو ته رياست جيڪا اڳ ۾ aws_security_group.instance سان لاڳاپيل هئي هاڻي aws_security_group.cluster_instance سان لاڳاپيل هجڻ گهرجي. جيڪڏهن هن حڪم کي تبديل ڪرڻ ۽ هلائڻ کان پوء ٽرافارم پلان ڪا به تبديلي نه ڏيکاري، پوء توهان سڀ ڪجهه صحيح ڪيو.

  • ڪجھ سيٽنگون تبديل نه ٿيون ڪري سگھجن. ڪيترن ئي وسيلن جا پيرا ميٽر غير تبديل ٿيل آهن. جيڪڏھن توھان انھن کي تبديل ڪرڻ جي ڪوشش ڪندا، Terraform پراڻي وسيلن کي حذف ڪندو ۽ ان جي جاءِ تي ھڪڙو نئون ٺاھيندو. هر وسيلن جو صفحو عام طور تي ظاهر ڪندو ته ڇا ٿيندو جڏهن توهان هڪ خاص سيٽنگ تبديل ڪندا آهيو، تنهن ڪري دستاويز چيڪ ڪرڻ جي پڪ ڪريو. هميشه پلان ڪمانڊ استعمال ڪريو ۽ استعمال ڪرڻ تي غور ڪريو create_before_destroy حڪمت عملي.

  ڊفرل مستقل مزاجي سان مطابقت رکي ٿي... التوا سان

  ڪجهه ڪلائوڊ فراهم ڪندڙ APIs، جهڙوڪ AWS، غير مطابقت رکندڙ آهن ۽ دير سان مطابقت رکي ٿي. Asynchrony جو مطلب آهي ته انٽرفيس فوري طور تي جواب واپس ڪري سگهي ٿو بغير گهربل عمل جي مڪمل ٿيڻ جي انتظار جي. دير سان مطابقت جو مطلب اهو آهي ته تبديلين کي سڄي سسٽم ۾ پروپيگنڊا ڪرڻ لاء وقت وٺي سگھي ٿو. جڏهن ته اهو ٿي رهيو آهي، توهان جا جواب متضاد ۽ انحصار ٿي سگهن ٿا ته ڪهڙي ڊيٽا جو ماخذ ريپليڪا توهان جي API ڪالن جو جواب ڏئي رهيو آهي.

  تصور ڪريو، مثال طور، ته توهان AWS کي API ڪال ڪريو ٿا ان کي EC2 سرور ٺاهڻ لاءِ. API هڪ "ڪامياب" جواب ڏيندو (201 ٺاهيل) تقريبن فوري طور تي، سرور جي پاڻ کي پيدا ٿيڻ جو انتظار ڪرڻ کان سواء. جيڪڏهن توهان ان سان ڳنڍڻ جي ڪوشش ڪندا، اهو لڳ ڀڳ ضرور ناڪام ٿيندو ڇو ته ان موقعي تي AWS اڃا تائين وسيلن جي شروعات ڪري رهيو آهي يا، متبادل طور تي، سرور اڃا تائين بوٽ نه ڪيو آهي. ان کان علاوه، جيڪڏهن توهان هن سرور بابت معلومات حاصل ڪرڻ لاء هڪ ٻي ڪال ڪريو ٿا، توهان کي هڪ غلطي ملي سگهي ٿي (404 نه مليو). شيء اها آهي ته هن EC2 سرور بابت معلومات اڃا تائين پروپيگنڊا ٿي سگهي ٿي AWS ۾ ان کان اڳ جو اهو هر جڳهه تي دستياب ٿي وڃي، توهان کي ڪجهه سيڪنڊن جو انتظار ڪرڻو پوندو.

  جڏهن به توهان سست مطابقت سان هڪ غير مطابقت واري API استعمال ڪندا آهيو، توهان کي وقتي طور تي توهان جي درخواست کي ٻيهر ڪوشش ڪرڻ گهرجي جيستائين عمل مڪمل نه ٿئي ۽ سسٽم ذريعي پروپيگيٽ ٿئي. بدقسمتي سان، AWS SDK هن لاء ڪو به سٺو اوزار مهيا نٿو ڪري، ۽ Terraform پروجيڪٽ 6813 (https://github.com/hashicorp/terraform/issues/6813) وانگر ڪيترن ئي مسئلن جو شڪار ٿيندو هو.

  $ terraform apply
  aws_subnet.private-persistence.2: InvalidSubnetID.NotFound:
  The subnet ID 'subnet-xxxxxxx' does not exist

  ٻين لفظن ۾، توهان هڪ وسيلو ٺاهيو (جهڙوڪ هڪ سب نيٽ) ۽ پوءِ ان جي باري ۾ ڪجهه معلومات حاصل ڪرڻ جي ڪوشش ڪريو (جهڙوڪ نئين ٺاهيل سب نيٽ جي ID)، ۽ Terraform ان کي ڳولي نه ٿو سگهي. انهن مان گھڻا بگ (بشمول 6813) مقرر ڪيا ويا آهن، پر اهي اڃا به وقت بوقت پيدا ٿيندا آهن، خاص طور تي جڏهن Terraform نئين وسيلن جي قسم لاءِ سپورٽ شامل ڪري. اهو پريشان ڪندڙ آهي، پر اڪثر ڪيسن ۾ ڪنهن به نقصان جو سبب ناهي. جڏهن توهان ٽيرافارم کي ٻيهر لاڳو ڪريو ٿا، هر شي کي ڪم ڪرڻ گهرجي، ڇاڪاڻ ته هن وقت تائين معلومات اڳ ۾ ئي سڄي سسٽم ۾ پکڙيل هوندي.

  هي اقتباس Evgeniy Brikman جي ڪتاب مان پيش ڪيو ويو آهي "ٽرافارم: بنيادي ڍانچي تي ڪوڊ سطح".

جو ذريعو: www.habr.com