کم از کم ان کنونشنز پر عمل نہ کرنے کی کوئی وجہ نہیں ہونی چاہیے۔
یہ احتیاط کریں کہ حقیقی کلاؤڈ ریسورس کو مخصوص ناموں میں پابندیوں کی عادت ہوتی ہے۔ کچھ ریسورس میں ڈیشز شامل نہیں ہوسکتے ہیں، کچھ کو کیمل کیس کی ضرورت ہوتی ہے۔ اس کتاب میں روایات ٹیرافارم ناموں کو اشارہ کرتی ہیں۔
ہر جگہ - (ڈیش) کی بجائے _ (انڈرسکور) کا استعمال کریں (ریسورس کے ناموں، ڈیٹا سورس کے ناموں، وہرہبلیس کے ناموں، outputs وغیرہ میں)
بہتر ہے کہ چھوٹے حرف اور اعداد کا استعمال کریں (حتی کہ یو ٹی ایف-8 کا استعمال ہو)۔
ریسورس(Resource) کے نام میں ریسورس (Resource) کی قسم کو دوہرانے سے بچیں (جزوی طور پر نہیں، مکمل طور پر نہیں)
اگر کوئی زیادہ وضاحتی اور عام نام دستیاب نہیں ہے، یا اگر ریسورس کا ماڈیول اس قسم کا ایک واحد ریسورس تخلیق کرتا ہے، تو ریسورس کا نام اس طرح رکھا جانا چاہیے۔ (مثال کے طور پر، AWS VPC ماڈیول میں aws_nat_gateway کی قسم کا ایک واحد ریسورس ہے اور aws_route_table کی قسم کے متعدد ریسورس ہیں، اس لیے aws_nat_gateway کا نام اس طرح رکھا جانا چاہیے اور aws_route_table کے پاس زیادہ وضاحتی نام ہونے چاہئیں - جیسے private
، public
، ڈیٹا بیس)۔
ناموں کے لیے ہمیشہ واحد اسم استعمال کریں
دلائل کو بیان کرتےوقت اور ان جگہوں پر - استعمال کریں جہاںvalue کسی انسان کے سامنے آئے گی (مثال کے طور پر، RDS مثال کے DNS نام کے اندر)۔
ریسورس یا ڈیٹا سورس بلاک کے اندر پہلی دلیل کے طور پر سب سے اوپرcount
/ for_each
دلیل شامل کریں اور اس کے بعد نئی لائن کے ذریعے الگ کریں۔
اگرresource اجازت دے تو، حقیقی دلیل کے طور tags
دلیل شامل کریں، اس کے بعد depends_on اور lifecycle،اور اگر ضروری ہو۔ ان سب کو ایک خالی لائن سے الگ کیا جانا چاہیے۔
"جب ارگومنٹ count / for_each
میں values استعمال کر رہے ہیں تو length
یا دیگر اعبار کی بجائے بولین values کو ترجیح دیں۔"
resource
کی کوڈ مثالیںcount / for_each
کا استعمالtags
کی جگہcount
میں شرائط ریسورس کے ماڈیولز میں چیزوں کو دوبارہ نہ بنائیں: وہرہبلیس (Variables) کے لیے نام، تفصیل، اور پہلے سے طے شدہ value استعمال کریں جیسا کہ ریسورس کے لیے "Argument Reference" سیکشن میں بیان کیا گیا ہے جس کے ساتھ آپ کام کر رہے ہیں۔
وہرہبلیس (Variables) میں توثیق کے لیے تعاون کافی محدود ہے (مثال کے طور پر آپ دوسرے وہرہبلیس (Variables) تک رسائی حاصل نہیں کر سکتے یا تلاش نہیں کر سکتے)۔ اس کے مطابق منصوبہ بندی کریں کیونکہ بہت سے معاملات میں یہ خصوصیت بیکار ہے۔
جب قسم list(...) یا map(...) ہو تو وہرہبلیس (Variables) کے نام میں جمع فارم استعمال کریں۔
وہرہبلیس (Variables) بلاک میں کلیدیں اس طرح ترتیب دیں: تفصیل، قسم، پہلے سے طے شدہ، توثیق۔
ہمیشہ تمام وہرہبلیس (Variables) پر تفصیل شامل کریں یہاں تک کہ اگر آپ کو لگتا ہے کہ یہ واضح ہے (آپ کو مستقبل میں اس کی ضرورت ہوگی)۔
جب تک کہ آپ کو ہر کلید پر سخت پابندیوں کی ضرورت نہ ہو، مخصوص قسم جیسے object() کے مقابلے میں سادہ اقسام (number، string، list(...)، map(...)، any) استعمال کرنے کو ترجیح دیں۔
اگر map کے تمام عناصر ایک ہی قسم کے ہیں (مثال کے طور پر string
) یا اس میں تبدیل کیے جا سکتے ہیں (مثال کے طور پر number
کی قسم کو string
میں تبدیل کیا جا سکتا ہے) تو map(map(string))
جیسے مخصوص اقسام کا استعمال کریں۔
ایک خاص گہرائی سے شروع ہونے والی قسم کی جانچنا کو غیر فعال کرنے کے لیے یا جب متعدد اقسام کی حمایت کی جانی چاہیے تو any
کا استعمال کریں۔
والیو Value{}
کبھی کبھی map ہوتی ہے لیکن کبھی کبھی ایک object ہوتی ہے۔ map بنانے کے لیے tomap(...)
استعمال کریں کیونکہ کوئیobject بنانے کا کوئی طریقہ نہیں ہے۔
آؤٹ پٹسOutputs کو اس کے دائرہ کار سے باہر مستقل اور قابل فہم بنائیں (جب کوئی صارف کسی ماڈیول کا استعمال کر رہا ہو تو یہ واضح ہونا چاہیے کہ یہ کس قسم اور والیو Value کی خصوصیت واپس کرتا ہے)۔
آؤٹ پٹ کا نام اس میں موجود پراپرٹی کو بیان کرنا چاہیے اور عام طور پر آپ کی خواہش سے کم آزاد شکل کا ہونا چاہیے۔
آؤٹ پٹ کے نام کے لیے اچھی ساخت {name}_{type}_{attribute}
کی طرح نظر آتی ہے، جہاں:
نام {name}
ریسورس یا ڈیٹا کے سورسہ کے نام کے بغیر provider کے سابقہ کے بغیر استعمال کریں aws_subnet
کے لیے {name}
subnet
ہے، aws_vpc
کے لیے یہ vpc
ہے۔
ٹائپ{type}
ریسورسسورسہ کی قسم ہے۔
{attribute} آؤٹ پٹ کے واپس کرنے کی ایک صفت ہے
"اگرآؤٹ پٹ وسیع تعریفی تفصیلات، انٹرپولیشن فنکشنز، اور مختلف ریسورس کی value واپس دے رہا ہے، تو {name}
اور {type}
کو جتنا ممکن ہو، عام اور عمومی رکھنا چاہئے (this
کا پریفکس نہیں ہونا چاہئے). مثال دیکھیں."
اگر واپس آنے والی value فہرست ہے تو اس کا جمع کا نام ہونا چاہیے۔ مثال دیکھیں۔
ہمیشہ تمام آؤٹ پٹس کے لیے تفصیل description
شامل کریں یہاں تک کہ اگر آپ کو لگتا ہے کہ یہ واضح ہے۔
حساس دلیل کو ترتیب دینے سے گریز کریں۔جب تک آپ تمام ماڈیولز میں تمام جگہوں پر اس آؤٹ پٹ کے استعمال کو مکمل طور پر کنٹرول نہیں کرتے،
ٹیرافارم (Terraform) کی شروعات سے دستیاب try()
کو (جو بعد از Terraform 0.13 کے ورژنز کے لئے چھوڑ دی گئی)element(concat(...))
(قدیم طریقہ کار) کے بجائے ترجیح دیں"
output
کوڈ کی مثالیں زیادہ سے زیادہ ایک سیکورٹی گروپ کی ID واپس کریں:
جب ایک ہی قسم کے متعدد ریسورسز ہوں، توthis
آؤٹ پٹ کے نام سے حذف کر دینے چاہیے:
اگر واپس آنے والی value فہرست ہے تو جمع کا نام استعمال کریں۔