ٹیرافارم کے نقصانات

آئیے چند خامیوں پر روشنی ڈالتے ہیں، بشمول لوپس سے متعلق، اگر بیانات اور تعیناتی تکنیک، نیز مزید عمومی مسائل جو عام طور پر Terraform کو متاثر کرتے ہیں:

• شمار اور for_each پیرامیٹرز کی حدود ہیں۔
• صفر ڈاؤن ٹائم تعیناتیوں کو محدود کریں؛
• ایک اچھا منصوبہ بھی ناکام ہو سکتا ہے۔
• ریفیکٹرنگ میں اس کے نقصانات ہو سکتے ہیں۔
• موخر ہم آہنگی التوا کے ساتھ مطابقت رکھتی ہے۔

شمار اور for_each پیرامیٹرز کی حدود ہیں۔

اس باب میں مثالیں گنتی کے پیرامیٹر اور لوپس اور مشروط منطق میں for_each اظہار کا وسیع استعمال کرتی ہیں۔ وہ اچھی کارکردگی کا مظاہرہ کرتے ہیں، لیکن ان کی دو اہم حدود ہیں جن سے آپ کو آگاہ ہونے کی ضرورت ہے۔

• Count اور for_each کسی بھی ریسورس آؤٹ پٹ متغیر کا حوالہ نہیں دے سکتا۔
• شمار اور for_each کو ماڈیول کنفیگریشن میں استعمال نہیں کیا جا سکتا۔

count اور for_each کسی بھی ریسورس آؤٹ پٹ متغیر کا حوالہ نہیں دے سکتا

تصور کریں کہ آپ کو کئی EC2 سرورز تعینات کرنے کی ضرورت ہے اور کسی وجہ سے آپ ASG استعمال نہیں کرنا چاہتے۔ آپ کا کوڈ اس طرح ہو سکتا ہے:

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

آئیے ان کو ایک ایک کرکے دیکھتے ہیں۔

چونکہ کاؤنٹ پیرامیٹر ایک مستحکم قدر پر سیٹ ہے، یہ کوڈ بغیر کسی پریشانی کے کام کرے گا: جب آپ اپلائی کمانڈ چلاتے ہیں، تو یہ تین EC2 سرورز بنائے گا۔ لیکن کیا ہوگا اگر آپ اپنے موجودہ AWS علاقے کے اندر ہر ایک Availability Zone (AZ) میں ایک سرور تعینات کرنا چاہتے ہیں؟ آپ اپنے کوڈ کو 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 مستقبل میں اس صلاحیت کو شامل کرنے کا ارادہ رکھتا ہے، لہذا اس بات پر منحصر ہے کہ آپ اس کتاب کو کب پڑھتے ہیں، یہ پہلے سے دستیاب ہو سکتی ہے۔ یقینی طور پر جاننے کے لیے، ٹیرافارم چینج لاگ کو یہاں پڑھیں.

زیرو ڈاؤن ٹائم تعیناتیوں کی حدود

ASG کے ساتھ مل کر create_before_destroy بلاک کا استعمال صفر-ڈاؤن ٹائم تعیناتیوں کو بنانے کے لیے ایک بہترین حل ہے، سوائے ایک انتباہ کے: آٹو اسکیلنگ کے قواعد تعاون یافتہ نہیں ہیں۔ یا زیادہ واضح طور پر، یہ ہر تعیناتی پر ASG سائز کو min_size پر دوبارہ سیٹ کرتا ہے، جو کہ ایک مسئلہ ہو سکتا ہے اگر آپ چلنے والے سرورز کی تعداد بڑھانے کے لیے آٹو اسکیلنگ کے اصول استعمال کر رہے ہوں۔

مثال کے طور پر، ویب سرور-کلسٹر ماڈیول میں aws_autoscaling_schedule وسائل کا ایک جوڑا ہوتا ہے، جو صبح 9 بجے کلسٹر میں سرورز کی تعداد کو دو سے دس تک بڑھا دیتا ہے۔ اگر آپ صبح 11 بجے تعینات کرتے ہیں، تو نیا ASG دس کے بجائے صرف دو سرورز کے ساتھ بوٹ ہو جائے گا اور اگلے دن صبح 9 بجے تک اسی طرح رہے گا۔

اس پابندی کو کئی طریقوں سے روکا جا سکتا ہے۔

• aws_autoscaling_schedule میں ریکرنس پیرامیٹر کو 0 9 * * * ("صبح 9 بجے چلائیں") سے 0-59 9-17 * * * ("صبح 9 بجے سے شام 5 بجے تک ہر منٹ چلائیں") میں تبدیل کریں۔ اگر ASG کے پاس پہلے ہی دس سرورز ہیں، تو اس آٹو اسکیلنگ اصول کو دوبارہ چلانے سے کچھ بھی نہیں بدلے گا، جو ہم چاہتے ہیں۔ لیکن اگر ASG کو حال ہی میں تعینات کیا گیا ہے، تو یہ اصول یقینی بنائے گا کہ زیادہ سے زیادہ ایک منٹ میں اس کے سرورز کی تعداد دس تک پہنچ جائے گی۔ یہ مکمل طور پر خوبصورت انداز نہیں ہے، اور دس سے دو سرورز اور پیچھے سے بڑی چھلانگیں بھی صارفین کے لیے پریشانی کا باعث بن سکتی ہیں۔
• ایک حسب ضرورت اسکرپٹ بنائیں جو ASG میں فعال سرورز کی تعداد کا تعین کرنے کے لیے AWS API کا استعمال کرے، اسے ایک بیرونی ڈیٹا سورس کا استعمال کرتے ہوئے کال کریں (صفحہ 249 پر "بیرونی ڈیٹا ماخذ" دیکھیں)، اور ASG کے مطلوبہ_capacity پیرامیٹر کو واپس کی گئی قدر پر سیٹ کریں۔ اسکرپٹ. اس طرح، ہر نئی ASG مثال ہمیشہ موجودہ Terraform کوڈ کی ہی صلاحیت پر چلے گی اور اسے برقرار رکھنا مزید مشکل بنا دیتا ہے۔

بلاشبہ، Terraform مثالی طور پر صفر-ڈاؤن ٹائم تعیناتیوں کے لیے بلٹ ان سپورٹ حاصل کرے گا، لیکن مئی 2019 تک، HashiCorp ٹیم کے پاس اس فعالیت کو شامل کرنے کا کوئی منصوبہ نہیں تھا (تفصیلات - یہاں).

درست منصوبہ ناکامی سے نافذ ہو سکتا ہے۔

بعض اوقات پلان کمانڈ بالکل درست تعیناتی کا منصوبہ تیار کرتا ہے، لیکن اپلائی کمانڈ غلطی لوٹاتا ہے۔ مثال کے طور پر، اسی نام کے ساتھ aws_iam_user وسیلہ شامل کرنے کی کوشش کریں جسے آپ نے پہلے باب 2 میں تخلیق کردہ IAM صارف کے لیے استعمال کیا تھا۔

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 اسٹیٹ فائل میں بیان کیے گئے ہیں۔ اگر وسائل کسی اور طریقے سے بنائے جاتے ہیں (مثال کے طور پر، AWS کنسول میں دستی طور پر کلک کر کے)، وہ اسٹیٹ فائل میں ختم نہیں ہوں گے اور اس لیے پلان کمانڈ پر عمل کرتے وقت Terraform ان کو مدنظر نہیں رکھے گا۔ نتیجے کے طور پر، ایک منصوبہ جو پہلی نظر میں درست لگتا ہے، ناکام ہو جائے گا.

اس سے سیکھنے کے لیے دو سبق ہیں۔

• اگر آپ نے پہلے ہی Terraform کے ساتھ کام کرنا شروع کر دیا ہے، تو کوئی اور چیز استعمال نہ کریں۔ اگر آپ کے بنیادی ڈھانچے کے کچھ حصے کا انتظام Terraform کے ذریعے کیا جاتا ہے، تو آپ اسے دستی طور پر مزید تبدیل نہیں کر سکتے۔ بصورت دیگر، آپ کو نہ صرف عجیب Terraform غلطیوں کا خطرہ ہے، بلکہ آپ IaC کے بہت سے فوائد کی نفی بھی کرتے ہیں کیونکہ کوڈ اب آپ کے بنیادی ڈھانچے کی درست نمائندگی نہیں کرے گا۔
• اگر آپ کے پاس پہلے سے ہی کچھ انفراسٹرکچر ہے تو امپورٹ کمانڈ استعمال کریں۔ اگر آپ موجودہ انفراسٹرکچر کے ساتھ ٹیرافارم استعمال کرنا شروع کر رہے ہیں، تو آپ اسے ٹیرافارم امپورٹ کمانڈ کا استعمال کرکے اسٹیٹ فائل میں شامل کر سکتے ہیں۔ اس طرح Terraform کو معلوم ہو جائے گا کہ کس بنیادی ڈھانچے کو منظم کرنے کی ضرورت ہے۔ درآمد کمانڈ دو دلائل لیتا ہے. پہلا آپ کی کنفیگریشن فائلوں میں ریسورس ایڈریس ہے۔ یہاں نحو وہی ہے جو وسائل کے لنکس کے لیے ہے: _۔ (جیسے aws_iam_user.existing_user)۔ دوسری دلیل امپورٹ کیے جانے والے وسائل کی ID ہے۔ آئیے کہتے ہیں کہ ریسورس ID aws_iam_user صارف کا نام ہے (مثال کے طور پر، yevgeniy.brikman)، اور ریسورس ID aws_instance EC2 سرور ID ہے (جیسے i-190e22e5)۔ کسی وسیلہ کو درآمد کرنے کا طریقہ عام طور پر اس کے صفحہ کے نیچے موجود دستاویزات میں بتایا جاتا ہے۔

  ذیل میں ایک امپورٹ کمانڈ ہے جو aws_iam_user ریسورس کو سنکرونائز کرتی ہے جسے آپ نے باب 2 میں IAM صارف کے ساتھ اپنی Terraform کنفیگریشن میں شامل کیا ہے (یقیناً آپ کے نام کو yevgeniy.brikman کے لیے تبدیل کرنا):

  $ terraform import aws_iam_user.existing_user yevgeniy.brikman

  Terraform آپ کے IAM صارف کو تلاش کرنے کے لیے AWS API کو کال کرے گا اور آپ کی Terraform کنفیگریشن میں اس اور aws_iam_user.existing_user وسائل کے درمیان اسٹیٹ فائل ایسوسی ایشن بنائے گا۔ اب سے، جب آپ پلان کمانڈ چلاتے ہیں، تو Terraform کو معلوم ہو جائے گا کہ IAM صارف پہلے سے موجود ہے اور اسے دوبارہ بنانے کی کوشش نہیں کرے گا۔

  یہ بات قابل غور ہے کہ اگر آپ کے پاس پہلے سے ہی بہت سارے وسائل ہیں جنہیں آپ Terraform میں درآمد کرنا چاہتے ہیں، تو دستی طور پر کوڈ لکھنا اور ایک وقت میں ہر ایک کو درآمد کرنا ایک پریشانی کا باعث ہو سکتا ہے۔ لہذا یہ Terraforming (http://terraforming.dtan4.net/) جیسے ٹول کو دیکھنے کے قابل ہے، جو آپ کے AWS اکاؤنٹ سے خود بخود کوڈ اور اسٹیٹ کو درآمد کر سکتا ہے۔

  ریفیکٹرنگ میں اس کے نقصانات ہو سکتے ہیں۔

  ریفیکٹرنگ۔ پروگرامنگ میں ایک عام عمل ہے جہاں آپ کوڈ کے اندرونی ڈھانچے کو تبدیل کرتے ہیں جبکہ بیرونی رویے کو کوئی تبدیلی نہیں کرتے۔ یہ کوڈ کو صاف، صاف اور برقرار رکھنے میں آسان بنانا ہے۔ ریفیکٹرنگ ایک ناگزیر تکنیک ہے جسے باقاعدگی سے استعمال کیا جانا چاہیے۔ لیکن جب بات Terraform یا کسی دوسرے IaC ٹول کی ہو، تو آپ کو اس بارے میں انتہائی محتاط رہنا ہوگا کہ کوڈ کے ایک ٹکڑے کے "بیرونی رویے" سے آپ کا کیا مطلب ہے، بصورت دیگر غیر متوقع مسائل پیدا ہوں گے۔

  مثال کے طور پر، ری فیکٹرنگ کی ایک عام قسم متغیرات یا افعال کے ناموں کو زیادہ قابل فہم ناموں سے بدل رہی ہے۔ بہت سے IDEs کو ری فیکٹرنگ کے لیے بلٹ ان سپورٹ حاصل ہے اور وہ خود بخود پورے پروجیکٹ میں متغیرات اور افعال کا نام بدل سکتے ہیں۔ عام مقصد کی پروگرامنگ زبانوں میں، یہ ایک معمولی طریقہ ہے جس کے بارے میں آپ سوچ بھی نہیں سکتے، لیکن Terraform میں آپ کو اس کے ساتھ انتہائی محتاط رہنا ہوگا، ورنہ آپ کو بندش کا سامنا کرنا پڑ سکتا ہے۔

  مثال کے طور پر، webserver-cluster ماڈیول میں ایک ان پٹ متغیر ہے cluster_name:

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

  تصور کریں کہ آپ نے اس ماڈیول کا استعمال فوو نامی مائیکرو سروس کو تعینات کرنے کے لیے شروع کیا ہے۔ بعد میں، آپ اپنی سروس کا نام تبدیل کرکے بار کرنا چاہتے ہیں۔ یہ تبدیلی معمولی لگتی ہے، لیکن حقیقت میں یہ سروس میں خلل ڈال سکتی ہے۔

  حقیقت یہ ہے کہ ویب سرور-کلسٹر ماڈیول متعدد وسائل میں 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 "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 سے وابستہ ہے۔ اگر آپ ریسورس آئی ڈی کو تبدیل کرتے ہیں (مثال سے کلسٹر_انسٹینس میں، جیسا کہ aws_security_group کا معاملہ ہے)، Terraform میں ایسا ظاہر ہوگا جیسے آپ نے پرانا وسیلہ حذف کر دیا ہے اور ایک نیا شامل کیا ہے۔ اگر آپ ان تبدیلیوں کو لاگو کرتے ہیں، تو Terraform پرانے سیکیورٹی گروپ کو حذف کر دے گا اور ایک نیا بنا دے گا، جب کہ آپ کے سرور کسی بھی نیٹ ورک ٹریفک کو مسترد کرنا شروع کر دیں گے۔

  یہاں چار اہم اسباق ہیں جو آپ کو اس بحث سے دور کرنے چاہئیں۔

  • ہمیشہ پلان کمانڈ استعمال کریں۔ یہ ان تمام چھینٹوں کو ظاہر کر سکتا ہے۔ اس کے آؤٹ پٹ کا بغور جائزہ لیں اور ان حالات پر توجہ دیں جہاں Terraform ایسے وسائل کو حذف کرنے کا ارادہ رکھتا ہے جنہیں زیادہ تر حذف نہیں کیا جانا چاہیے۔
  • حذف کرنے سے پہلے تخلیق کریں۔ اگر آپ کسی وسیلہ کو تبدیل کرنا چاہتے ہیں تو اس بارے میں احتیاط سے سوچیں کہ آیا آپ کو اصل کو حذف کرنے سے پہلے متبادل بنانے کی ضرورت ہے۔ اگر جواب ہاں میں ہے تو create_before_destroy مدد کر سکتا ہے۔ یہی نتیجہ دستی طور پر دو مراحل کو انجام دے کر حاصل کیا جا سکتا ہے: پہلے کنفیگریشن میں ایک نیا وسیلہ شامل کریں اور اپلائی کمانڈ چلائیں، اور پھر پرانے وسیلہ کو کنفیگریشن سے ہٹا دیں اور اپلائی کمانڈ کو دوبارہ استعمال کریں۔
  • شناخت کنندگان کو تبدیل کرنے کے لیے حالت کو تبدیل کرنے کی ضرورت ہے۔ اگر آپ کسی وسائل سے وابستہ ID کو تبدیل کرنا چاہتے ہیں (مثال کے طور پر، aws_security_group کا نام تبدیل کریں instance سے cluster_instance)، وسائل کو حذف کیے بغیر اور اس کا نیا ورژن بنائے، آپ کو اسی کے مطابق Terraform اسٹیٹ فائل کو اپ ڈیٹ کرنا ہوگا۔ یہ کبھی بھی دستی طور پر نہ کریں - اس کے بجائے ٹیرافارم اسٹیٹ کمانڈ استعمال کریں۔ شناخت کنندگان کا نام تبدیل کرتے وقت، آپ کو terraform state mv کمانڈ چلانی چاہیے، جس میں درج ذیل نحو ہے:

    terraform state mv <ORIGINAL_REFERENCE> <NEW_REFERENCE>

    ORIGINAL_REFERENCE ایک ایسا اظہار ہے جو اس کی موجودہ شکل میں وسائل کا حوالہ دیتا ہے، اور NEW_REFERENCE وہ جگہ ہے جہاں آپ اسے منتقل کرنا چاہتے ہیں۔ مثال کے طور پر، aws_security_group گروپ کو مثال سے کلسٹر_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