ٹیرافارم (Terraform) کی دستاویزات تمام پہلوؤں کو تفصیل سے بیان کرتی ہیں۔ اس سیکشن کے باقی حصوں کو سمجھنے کے لیے اسے غور سے پڑھیں۔

یہ سیکشن ان اہم بنیادی خیالات کی وضاحت کرتا ہے جو کتاب میں استعمال کیے جاتے ہیں

ریسورس (Resource)

ریسورس (Resource) aws_vpc, aws_db_instanceوغیرہ ہوتے ہیں۔ ایک ریسورس کسی provider سے تعلق رکھتا ہے، arguments قبول کرتا ہے، خصوصیات آؤٹ پٹ(outputs) کرتا ہے، اور اس کا ایک lifecycle ہوتا ہے۔ ایک ریسورس کو بنایا، حاصل کیا، اپ ڈیٹ کیا اور ختم کیا جا سکتاہے

ریسورس کے ماڈیول (Resource module)

ریسورس کے ماڈیول( Resource module) منسلک ریسورسز Resources کا ایک مجموعہ ہوتاہے جو مل کر مشترکہ کارروائی انجام دیتے ہیں (مثال کے طور پر، VPC، subnets ، NAT gateway وغیرہ بناتا ہے)۔ یہ provider کی ترتیب پر منحصر ہے، جس کی وضاحت اس میں کی جا سکتی ہے، یا اعلیٰ سطح کے ڈھانچے میں (مثال کے طور پر، انفراسٹرکچر (module) میں)

انفراسٹرکچر ماڈیول (Infrastructure module)

ایک انفراسٹرکچر ماڈیول، ریسورس ماڈیولز کا ایک مجموعہ ہے، جو منطقی طور پر منسلک نہیں ہو سکتے، لیکن موجودہ صورتحال/پروجیکٹ/سیٹ اپ میں ایک ہی مقصد پورا کرتے ہیں۔ یہ provider کے لیے ترتیب کو متعین کرتا ہے، جو ڈاون اسٹریم ریسورس ماڈیولز اور ریسورس کو پاس کر دیا جاتا ہے۔ یہ عام طور پر ایک منطقی سیپریٹر (مثال کے طور پر، AWS Region, Google Project) کے ساتھ کام کرنے کے لیے محدود ہوتا ہے۔

مثال کے طور پر، ماڈیول میں اور جیسے ریسورس ماڈیولز استعمال ہوتے ہیں تاکہ پر کو چلانے کے لئے ضروری انفراسٹرکچر کو بنایا جا سکے۔

دوسری مثال ماڈیول کی ہے جہاں کی طرف سے مختلف ماڈیولز کا اشتراک ہوتا ہے تاکہ انفراسٹرکچر کو منظم کیا جا سکے اور Docker کے ریسورس کا استعمال کیا جا سکتا ہے تاکہ ایک ہی سیٹ میں images Docker کو تخلیق، منتقلی، اور تنصیب کیا جا سکے ۔

ترکیب (Composition)

ترکیب انفراسٹرکچر ماڈیولز کا ایک مجموعہ ہے، جو کئی منطقی طور پر الگ علاقوں (مثال کے طور پر،Regions AWS ، متعدد AWS اکاؤنٹس) میں پھیلا ہو سکتا ہے۔ ترکیب کو پوری تنظیم یا پروجیکٹ کے لیے درکار مکمل انفراسٹرکچر کی وضاحت کے لیے استعمال کیا جاتا ہے۔

ترکیب میں انفراسٹرکچر ماڈیولز ہوتے ہیں، جن میں ریسورس ماڈیولز ہوتے ہیں، جو انفرادی ریسورس کو بناتے ہیں۔

ڈیٹا سورس (Data source)

ڈیٹا سورس (Data source) ایک ریڈ-اونلی read-only آپریشن انجام دیتا ہے اور provider کی ترتیب پر منحصر ہے، یہ ایک ریسورس ماڈیول اور ایک انفراسٹرکچر ماڈیول میں استعمال ہوتاہے۔

ڈیٹا سورس terraform_remote_state اعلیٰ سطحی ماڈیولز اور ترکیبوں کے لیے گلو کے طور پر کام کرتا ہے۔

کسی بیرونی پروگرام کو ڈیٹا سورس کے طور پر کام کرنے کی اجازت دیتا ہے، جو ٹیرافارم Terraform ترتیب میں کہیں اور استعمال کے لیے غیر معمولی ڈیٹا کو بے نقاب کرتا ہے۔ ماڈیول سے ایک مثال یہاں ہے جہاں فائل کا نام ایک بیرونی Python اسکرپٹ کو کال کرکے کمپیوٹ کیا جاتا ہے۔

ہتپ ڈیٹا سورس دیئے گئے URL پر HTTP GET کی درخواست کرتا ہے اور ردعمل کے بارے میں معلومات حاصل کرتا ہے جو اکثر endpoints سے معلومات حاصل کرنے کے لیے مفید ہوتا ہے جہاں Terraform provider موجود نہیں ہوتا ہے۔

ریموٹ حالت (Remote state)

انفراسٹرکچر ماڈیولز اور ترتیبوں کو اپنی کو ایک remote جگہ میں جمع رکھنی چاہئے جہاں دوسرے لوگوں کی طرف سے اسے ایک کنٹرول طریقے سے استعمال کیا جا سکتا ہے (مثلاً، specify ACL, versioning, logging)۔

فراہم کنندہ، فراہم کرنے والا، وغیرہ (Provider, provisioner, etc)

پروودرس Providers، پرووسونیرس provisioners، اور کچھ دوسرے مصطلحات کو آفیشل دستاویز میں بہت اچھی طرح وضاحت کی گئی ہے اور یہاں پر اسے دہرانے کا کوئی موقع نہیں ہے۔ میرے خیال میں، ان کا زیادہ Terraform modules لکھنے سے کچھ تعلق نہیں ہے۔

یہ کیوں اتنا مشکل ہے؟ (?Why so difficult)

انفرادی ریسورس بنیادی ڈھانچے میں ایٹموں کی طرح ہوتے ہیں، جب کہ ریسورس ماڈیولز مالیکیولز (ایٹموں پر مشتمل) ہوتے ہیں۔ ماڈیول سب سے چھوٹی ورژن والی اور شیئر کرنے والی اکائی ہے۔ اس میں دلائل کی ایک درست فہرست ہے، جو اس طرح کی اکائی کے لیے مطلوبہ کام کرنے کے لیے بنیادی منطق کو استعمال کرتی ہے۔ مثال کے طور پر، ماڈیول ان پٹ کی بنیاد پر aws_security_group اور aws_security_group_rule ریسورس بناتا ہے۔ یہ ریسورس ماڈیول انفراسٹرکچر ماڈیول بنانے کے لیے دیگر ماڈیولز کے ساتھ مل کر استعمال کیا جا سکتا ہے۔

مالیکیولز (ریسورس ماڈیولز اور انفراسٹرکچر ماڈیولز) میں ڈیٹا تک رسائی ماڈیولز کے آؤٹ پٹس اور data sources کا استعمال کرکے کی جاتی ہے۔

ترکیبات کے درمیان رسائی اکثر ریموٹ سٹیٹ data sources کا استعمال کرکے کی جاتی ہے۔

اوپر بیان کردہ چیزوں کو pseudo-ریلیشنز کرنے میں رکھیں تو یہ کچھ اس طرح نظر آ سکتا ہے:

ٹیرافارم () ایک طاقتور (اگرچہ اب تک کا سب سے طاقتورٹول نہیں ہے) اور سب سے زیادہ استعمال ہونے والے ٹولز میں سے ایک ہے جو انفراسٹرکچر کو کوڈ (infrastructure as code) کے طور پر منظم کرتا ہے۔ اور یہ ڈویلپرز کو بہت سے کام کرنے کی اجازت دیتا ہے . انہیں ایسی چیزوں کو کرنے سے نہیں روکتا جن کی حمایت یا انضمام کرنا مشکل ہو گا۔

میں یہ جانتا ہوں،اس کتاب میں بیان کردہ کچھ معلومات بہترین طریقوں کی طرح نہیں ہو سکتی ہیں۔ اور قارئین کو یہ الگ کرنے میں مدد کرنے کے لیے کہ کیا قائم کردہ بہترین طریقے ہیں اور کیا صرف چیزوں کو کرنے کا ایک اور طریقہ ہے، میں کبھی کبھی بہترین طریقوں سے متعلق ہر ذیلی سیکشن پر پختگی کی سطح کو واضح کرنے کے لیے اشارے اور آئیکون (icons) استعمال کرتا ہو ں۔

کتاب کی ابتدا 2018 میں اسپین کے خوبصورت شہر مدريد میں ہوئی تھی، اور یہ کتاب مفت میں یہاں سے ڈاؤن لوڈ کی جا سکتی ہے ۔ .

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

https://twitter.com/antonbabenko/lists/terraform-experts - تیرا فارم کے ساتھ بہت فعالیت کرنے والے اور آپ کو بہت کچھ بتا سکنے والے افراد کی فہرست (اگر آپ ان سے پوچھیں تو)۔

https://github.com/shuaibiyy/awesome-terraform - ہاشیکورپ کے تیرا فارم پر مواد کی مرتب شدہ فہرست۔

http://bit.ly/terraform-youtube - "آپ کی ہر ہفتہ کی تیرا فارم یوتوبے" ٹیوٹریم چینل آنٹن بابینکو کا۔ آنٹن بابینکو کے ساتھ لائیو اسٹریمز میں جائیں، Q&A، لائیو کوڈنگ، اور تیرا فارم کے ساتھ کچھ ہیکنگ۔

تیرا فارم ہفتہ وار نیوز لیٹر۔ تیرا فارم کی دنیا میں مختلف خبریں (منصوبے، اعلانات، بحث) Anton Babenko کے ذریعہ۔

ان لوگوں کے لیے ایک ورکشاپ بھی ہے جو اس گائیڈ میں بیان کردہ چیزوں پر عمل کرنا چاہتے ہیں۔

مواد یہاں ہے۔

ریسورس کے درمیان واضح تعلقات کو بیان کرنے کے لئے locals کا استعمال کریں۔

ٹیرافارم (Terraform)کو اشارہ دینے کا مددگار طریقہ کہ کچھریسورس کو اس سے پہلے حذف کر دینا چاہیے جب کہ ٹیرافارم کنفیگریشنز میں براہ راست انحصار نہ ہو۔

https://raw.githubusercontent.com/antonbabenko/terraform-best-practices/master/snippets/locals.tf

Terraform 0.12 - مطلوبہ بمقابلہ اختیاری دلائل

1. اگر var.website ایک خالی map نہیں ہے، تو ضروری ہے کہ argument index_document کو سیٹ کیا جائے۔

2. اختیاری argument error_document کو چھوڑا جا سکتا ہے۔

ماخذ: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/medium-terraform

یہ مثال ایک میڈیم سائز کے انفراسٹرکچر کے لیے ٹیرافارم Terraform کنفیگریشنز کو ساخت دینے طور پر استعمال کرتا ہے:

• 2 AWS اکاؤنٹس

• 2 الگ انوائرنمنٹ (prod اور stage جو کچھ بھی شیئر نہیں کرتے)۔ ہر انوائرنمنٹ ایک الگ AWS اکاؤنٹ میں رہتا ہے

• ہر انوائرنمنٹ سے ماخوذ آف دی شیلف انفراسٹرکچر ماڈل (alb) کے مختلف ورژن کا استعمال کرتا ہے۔

• ہر انوائرنمنٹ modules/network کے ایک ہی ورژن کے اندرونی ماڈل کا استعمال کرتا ہے کیونکہ یہ local ڈائرکٹری سے ماخوذ ہے۔

نوٹ: میں نے "off-the-shelf infrastructure module" کو "آف دی شیلف انفراسٹرکچر ماڈل" کے طور پر ترجمہ کیا ہے کیونکہ یہ اصطلاح اردو میں زیادہ عام ہے۔

ماخذ:

یہ مثال ایک بڑے سائز کے انفراسٹرکچر کے لیے ٹیرافارم کنفیگریشنز کو ساخت دینے کی طور پر استعمال کرتا ہے

• 2 AWS اکاؤنٹس

• 2 ریجن

کوڈ ساخت ٹیرافارم (Terraform)

یہاں کچھ ٹولز ہیں جن کے بارے میں آپ کو آگاہ ہونا چاہیے اور ٹیرافارم کے ساتھ کام کرتے وقت استعمال کرنے پر غور کرنا چاہیے

• Terragrunt - آرکیسٹریشن ٹول

• - کوڈ لنٹر

• - ورژن منیجر

• - پل پریس کی آٹومیشن

• - ٹیرافارم کی ساتھ استعمال کرنے والے کے لئے گٹ ہکس کا مجموعہ

• - پل کی درخواستوں میں ٹیرافارم کے لیے کلاؤڈ لاگت کا تخمینہ۔ ٹیراگرنٹ، اٹلانٹس اور پری کمٹ ٹیرافارم کے ساتھ بھی کام کرتا ہے۔

ماڈیولز کے ساتھ انحصار کی مشکل کا حل کیا ہوتا ہے؟

مواد اور زیریں ماڈیول کی ورژنز کو وضاحت سے ذکر کرنا چاہئیں۔ Providers کو ماڈیول کے باہر تشکیل دینا چاہئیں، مگر صرف ترتیب میں providers اور ٹیرا فارم کی ورژنز کو بھی بند کرسکتے ہیں۔

کوئی ماسٹر ڈیپنڈنسی منجمنٹ ٹول نہیں ہے۔، مگر انحصار کو کم پریشانی والی بنانے کے لئے کچھ مشورے ہیں۔ مثال کے طور پر، کو ڈیپنڈنسی اپ ڈیٹس کو خود بخود کرنے کے لئے استعمال کیا جا سکتا ہے۔ Dependabot آپ کی ڈیپنڈنسیوں کو محفوظ اور up-to-date رکھنے کے لئے pull requests کھولتا ہے۔ Dependabot ٹیرا فارم کنفیگریشن کو بھی معاونیت پہنچاتا ہے۔

• ٹیرافارم ماڈلز اور مثالیں میں فیچرز اور انہیں استعمال کرنے کے طریقے کی وضاحت کرنے والی دستاویزات ہونی چاہئیں۔

• README.md فائلوں کے تمام لنکس مطلق ہونے چاہئیں تاکہ ٹیرافارم رجسٹری کی ویب سائٹ انہیں صحیح طریقے سے دکھا سکے۔

• دستاویزات میں mermaid کے ساتھ بنائے گئے ڈایاگرام اور cloudcraft.co کے ساتھ بنائے گئے بلیو پرنٹس شامل ہو سکتے ہیں۔

• استعمال کریں تاکہ یہ یقینی بنایا جا سکے کہ کوڈ درست ہے، صحیح طریقے سے فارمیٹ کیا گیا ہے، اور خود بخود دستاویز کیا گیا ہے اس سے پہلے کہ اسے git میں پش کیا جائے اور انسانوں کے ذریعہ جائزہ لیا جائے۔

دستاویزات

خودکار طور پر تیار کردہ دستاویزات

ایک فریم ورک ہے جو کثیر زبانی پری کمٹ ہکس کو منظم اور برقرار رکھنے کے لیے استعمال ہوتا ہے۔ یہ پائتھن میں لکھا گیا ہے اور ایک طاقتور ٹول ہے جو کسی ڈویلپر کی مشین پر کوڈ کو git ریپوزٹری پر کمٹ کرنے سے پہلے خودکار طریقے سے کچھ کرنے کے لیے استعمال کیا جا سکتا ہے۔ عام طور پر، اسے linter اور کوڈ کو فارمیٹ کرنے کے لیے استعمال کیا جاتا ہے ( دیکھیں)۔

ٹیرافارم کنفیگریشنز کے ساتھ pre-commit کا کوڈ فارمیٹ اور تصدیق کرنے کے ساتھ ساتھ دستاویزات کو اپ ڈیٹ کرنے کے لیے بھی استعمال کیا جا سکتا ہے۔

کو چیک کریں تاکہ اس سے آگاہی حاصل کی جا سکے، اور موجودہ ریپوزٹریاں (مثلاً، terraform-) جہاں یہ پہلے ہی استعمال ہو رہی ہیں۔

ٹیرافارم کی دستاویزات

ایک ایسا ٹول ہے جو ٹیرافارم ماڈلز سے مختلف آؤٹ پٹ فارمیٹس میں دستاویزات تیار کرتا ہے۔ آپ اسے دستی طور پر (pre-commit hooks کے بغیر) چلا سکتے ہیں، یا کے ساتھ استعمال کر سکتے ہیں تاکہ دستاویزات خود بخود اپ ڈیٹ ہو جائیں۔

@todo: release, GH actions ,دستاویز کے ماڈیول ورژن

حوالہ جات

3. Blog post by :

ٹیرافارم کوڈ کی ساخت سے متعلق سوالات کمیونٹی میں اب تک سب سے زیادہ آتے ہیں۔ ہر کوئی کسی نہ کسی نقطہ پر پروجیکٹ کے لئے بہترین کوڈ کی ساخت کے بارے میں سوچتا ہے۔

مجھے اپنے ٹیرافارم Terraform کنفیگریشنز کو کیسے ترتیب دینا چاہیے؟

یہ ان سوالات میں سے ایک ہے جہاں بہت سارے حل موجود ہیں اور عالمی مشورہ دینا بہت مشکل ہے، اس لیے آئیے اس سے شروع کریں کہ ہم کیا کر رہے ہیں۔

• آپ کے پروجیکٹ کی پیچیدگی کیا ہے؟

  • متعلقہ ریسورسز کی تعداد

  • ٹیرافارم providers کی تعداد (نیچے "logical providers" کے بارے میں نوٹ دیکھیں)

• آپ کا انفراسٹرکچر کتنا اور کب تبدیل ہوتا ہے؟

  • ایک مہینے/ہفتے/دن میں ایک بار سے

  • مسلسل (ہر بار جب ایک نیا کمٹ commitہوتا ہے)

• کوڈ کی تبدیلی کے آغاز کنندگان؟ کیا آپ CI سرور کو ایک نیا آرٹی فیکٹ بنائے جانے پر repository کو اپ ڈیٹ کرنے دیتے ہیں؟

  • صرف ڈویلپرز انفراسٹرکچر repository میں پش کر سکتے ہیں

  • ہر کوئی PR کھول کر کسی بھی چیز میں تبدیلی کی تجویز پیش کر سکتا ہے (CI سرور پر چلنے والے خودکار کردہ کاموں سمیت)

• آپ کس ڈپلائیمنٹ پلیٹ فارم یا ڈپلائیمنٹ سروس کا استعمال کرتے ہیں؟

  • ان چیزوں AWS CodeDeploy، Kubernetes، یا OpenShift کو تھوڑا مختلف طریقہ کار کی ضرورت ہے

• انوائرنمنٹ environments کیسے گروپ کیے جاتے ہیں؟

  • انوائرنمنٹ environments، علاقے، پروجیکٹ کے لحاظ سے

ٹیرافارم (Terraform) کنفیگریشنز کی ساخت کے ساتھ شروع کرنا

جب آپ شروع کر رہے ہوں یا مثال کا کوڈ لکھ رہے ہوں تو تمام کوڈ main.tf میں رکھنا ایک اچھا خیال ہے۔ تمام دوسرے معاملات میں آپ کے پاس منطقی طور پر اس طرح سے تقسیم کی گئی کئی فائلیں ہونگی:

• main.tf - تمام ریسورسز بنانے کے لیے ماڈیولز، لوکلز اور ڈیٹا سورکس کو کال کریں۔ main.tf

• variables.tf - میں استعمال ہونے والے وہرہبلیس کے اعلانات پر مشتمل ہے۔ main.tf

terraform.tfvars کے علاوہ کہیں بھی استعمال نہیں کیا جانا چاہئے۔ .

ٹیرافارم (Terraform) کنفیگریشن کی ساخت کے بارے میں کیسے سوچنا ہے؟

کوڈ کی ساخت کے لیے عام سفارشات

• چھوٹے ریسورس کے ساتھ کام کرنا آسان اور تیز ہے

  • کمانڈ terraform plan اور terraform applyدونوں ہی ریسورس کی حیثیت کو تصدیق کرنے کے لیے کلاؤڈ API کالز کرتے ہیں

اس کتاب میں، مثال کے طور پر منصوبوں کو پیچیدگی کے لحاظ سے گروپ کیا گیا ہے - چھوٹے سے لے کر بہت بڑے انفراسٹرکچر تک۔ یہ علیحدگی سخت نہیں ہے، اس لیے دوسری ساختوں کو بھی چیک کریں۔

انفراسٹرکچر ماڈیولز اور کمپوزیشن کی ترتیب

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

ڈویلپرز کی طرف سے استعمال ہونے والے آرکسٹریشن حل کرنے کم از کم 5 مختلف گروپس ہیں:

1. ڈویلپرز کو کام کرنے کے لیے صرف Terraform جاننے کی ضرورت ہے .Terraform only

2. خالص آرکسٹریشن ٹول جسے پوری انفراسٹرکچر کو منظم کرنے اور انحصار کو سنبھالنے کے لیے.Terragrunt استعمال کیا جا سکتا ہے۔ Terragrunt انفراسٹرکچر ماڈیولز اور کمپوزیشن کے ساتھ نیٹیو طور پر کام کرتا ہے، اس لیے یہ کوڈ کی نقل کو کم کرتا ہے

3. In-house scripts. اکثر یہ آرکسٹریشن کی طرف ایک نقطہ آغاز کے طور پر ہوتا ہے اوردریافت کرنے سے پہلے ہوتا ہے۔

اس بات کو مدنظر رکھتے ہوئے، یہ کتاب ان دو Terraform اور Terragruntمنصوبہ کی ساختوں کا جائزہ لیتی ہ

اگلے باب میں Terraform یا Terragrunt کے لیے کوڈ کی ساختوں کی مثالیں دیکھیں۔

متفقہ اصول

1. ہر جگہ - (ڈیش) کی بجائے _ (انڈرسکور) کا استعمال کریں (ریسورس کے ناموں، ڈیٹا سورس کے ناموں، وہرہبلیس کے ناموں، outputs وغیرہ میں)

2. بہتر ہے کہ چھوٹے حرف اور اعداد کا استعمال کریں (حتی کہ یو ٹی ایف-8 کا استعمال ہو)۔

ریسورس (Resource) اور ڈیٹا سورس(data source) کے دلائل

1. ریسورس(Resource) کے نام میں ریسورس (Resource) کی قسم کو دوہرانے سے بچیں (جزوی طور پر نہیں، مکمل طور پر نہیں)

1. اگر کوئی زیادہ وضاحتی اور عام نام دستیاب نہیں ہے، یا اگر ریسورس کا ماڈیول اس قسم کا ایک واحد ریسورس تخلیق کرتا ہے، تو ریسورس کا نام اس طرح رکھا جانا چاہیے۔ (مثال کے طور پر، AWS VPC ماڈیول میں aws_nat_gateway کی قسم کا ایک واحد ریسورس ہے اور aws_route_table کی قسم کے متعدد ریسورس ہیں، اس لیے aws_nat_gateway کا نام اس طرح رکھا جانا چاہیے اور aws_route_table کے پاس زیادہ وضاحتی نام ہونے چاہئیں - جیسے private، public، ڈیٹا بیس)۔

2. ناموں کے لیے ہمیشہ واحد اسم استعمال کریں

ریسورسresource کی کوڈ مثالیں

count / for_each کا استعمال

ٹیگزtags کی جگہ

کونٹcount میں شرائط

وہرہبلیس (Variables)

1. ریسورس کے ماڈیولز میں چیزوں کو دوبارہ نہ بنائیں: وہرہبلیس (Variables) کے لیے نام، تفصیل، اور پہلے سے طے شدہ value استعمال کریں جیسا کہ ریسورس کے لیے "Argument Reference" سیکشن میں بیان کیا گیا ہے جس کے ساتھ آپ کام کر رہے ہیں۔

2. وہرہبلیس (Variables) میں توثیق کے لیے تعاون کافی محدود ہے (مثال کے طور پر آپ دوسرے وہرہبلیس (Variables) تک رسائی حاصل نہیں کر سکتے یا تلاش نہیں کر سکتے)۔ اس کے مطابق منصوبہ بندی کریں کیونکہ بہت سے معاملات میں یہ خصوصیت بیکار ہے۔

3. جب قسم list(...) یا map(...) ہو تو وہرہبلیس (Variables) کے نام میں جمع فارم استعمال کریں۔

آؤٹ پٹس (Outputs)

آؤٹ پٹسOutputs کو اس کے دائرہ کار سے باہر مستقل اور قابل فہم بنائیں (جب کوئی صارف کسی ماڈیول کا استعمال کر رہا ہو تو یہ واضح ہونا چاہیے کہ یہ کس قسم اور والیو Value کی خصوصیت واپس کرتا ہے)۔

1. آؤٹ پٹ کا نام اس میں موجود پراپرٹی کو بیان کرنا چاہیے اور عام طور پر آپ کی خواہش سے کم آزاد شکل کا ہونا چاہیے۔

2. آؤٹ پٹ کے نام کے لیے اچھی ساخت {name}_{type}_{attribute} کی طرح نظر آتی ہے، جہاں:

   1. نام {name}

آؤٹ پٹoutput کوڈ کی مثالیں

زیادہ سے زیادہ ایک سیکورٹی گروپ کی ID واپس کریں:

جب ایک ہی قسم کے متعدد ریسورسز ہوں، توthis آؤٹ پٹ کے نام سے حذف کر دینے چاہیے:

اگر واپس آنے والی value فہرست ہے تو جمع کا نام استعمال کریں۔

ماخذ: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/small-terraform اس مثال میں وہ کوڈ شامل ہے جو ایک چھوٹے سائز کی ٹیرا فارم کنفیگریشن کی ساخت کی مثال کے طور پر دیا گیا ہے، جہاں کوئی بیرونی دپندنکئیس dependenciesاستعمال نہیں کیا گیا ہے۔