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

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

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

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

دستاویزات

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

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

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

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

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

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

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

حوالہ جات

3. Blog post by :

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

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

مواد یہاں ہے۔https://github.com/antonbabenko/terraform-best-practices-workshop

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

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

• 2 AWS اکاؤنٹس

• 2 ریجن

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

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

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

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

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

کتاب کی ابتدا 2018 میں اسپین کے خوبصورت شہر مدريد میں ہوئی تھی، اور یہ کتاب مفت میں یہاں سے ڈاؤن لوڈ کی جا سکتی ہے ۔ https://www.terraform-best-practices.com/.

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

**سرپرستان(**Sponsors)

Please if you want to become a sponsor.

ترجمہ

اگر آپ اس کتاب کو دوسری زبانوں میں ترجمہ کرنے میں مدد کرنا چاہتے ہیں تو ۔

شراکت

میں ہمیشہ اس کتاب کے بارے میں ردعمل حاصل کرنا اور اسے اپ ڈیٹ کرنا چاہتا ہوں کیونکہ کمیونٹی بڑھتی ہے اور نئے خیالات کو نافذ کیا جاتا ہے اور وقت کے ساتھ ساتھ تصدیق کی جاتی ہے

اگر آپ مخصوص موضوعات میں دلچسپی رکھتے ہیں، تو براہ کرم ایک مسئلہ کھولیں ()، یا اس مسئلے کو تھمبز اپ (thumb up) کریں جسے آپ شامل کرنا چاہتے ہیں۔ اگر آپ محسوس کرتے ہیں کہ آپ کے پاس مواد ہے اور آپ حصہ ڈالنا چاہتے ہیں، تو ایک مسودہ لکھیں اور ایک پل ریکویسٹ (pull request) جمع کروائیں (اس وقت اچھا متن لکھنے کے بارے میں فکر نہ کریں!)

مصنفین

اس کتاب کی دیکھ بھال کی طرف سے مختلف معاونین اور ترجمہ کاروں کی مدد سے کی جاتی ہے

لائسنس

یہ کام Apache 2 لائسنس کے تحت لائسنس یافتہ ہے۔ مکمل تفصیلات کے لیے LICENSE فائل دیکھیں۔\

اس مواد کے مصنفین اور شراکت دار یہاں پائی جانے والی معلومات کی صحت کی ضمانت نہیں دے سکتے۔ براہ کرم یقینی بنائیں کہ آپ سمجھتے ہیں کہ یہاں فراہم کردہ معلومات آزادانہ طور پر فراہم کی جا رہی ہے، اور آپ اور اس مواد یا منصوبے سے وابستہ کسی بھی شخص کے درمیان کسی بھی قسم کا معاہدہ یا کنٹریکٹ نہیں بنایا گیا ہے۔ مصنفین اور شراکت دار اس مواد میں موجود معلومات میں کسی غلطی یا کمی کی وجہ سے ہونے والے کسی نقصان، نقصان، یا خرابی کے لیے کسی فریق کے سامنے کوئی ذمہ داری نہیں لیتے ہیں، خواہ وہ غلطیاں یا کمیاں غفلت، حادثہ، یا کسی اور وجہ سے ہو ں۔ کاپی رائٹ © 2018-2023 Anton Babenko

ٹیرافارم (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-ریلیشنز کرنے میں رکھیں تو یہ کچھ اس طرح نظر آ سکتا ہے:

- تیرا فارم کے ساتھ بہت فعالیت کرنے والے اور آپ کو بہت کچھ بتا سکنے والے افراد کی فہرست (اگر آپ ان سے پوچھیں تو)۔

- ہاشیکورپ کے تیرا فارم پر مواد کی مرتب شدہ فہرست۔

متفقہ اصول

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) تک رسائی حاصل نہیں کر سکتے یا تلاش نہیں کر سکتے)۔ اس کے مطابق منصوبہ بندی کریں کیونکہ بہت سے معاملات میں یہ خصوصیت بیکار ہے۔

آؤٹ پٹس (Outputs)

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

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

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

   1. نام {name}

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

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

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

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

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

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

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

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

ماخذ: 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" کو "آف دی شیلف انفراسٹرکچر ماڈل" کے طور پر ترجمہ کیا ہے کیونکہ یہ اصطلاح اردو میں زیادہ عام ہے۔

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

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

ریسورس کے درمیان واضح تعلقات کو بیان کرنے کے لئے 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 کو چھوڑا جا سکتا ہے۔