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

مجھے اپنے ٹیرافارم 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

• outputs.tf -میں بنائے گئے ریسورسز سے آؤٹ پٹ پر مشتمل ہے۔ main.tf

• versions.tf - کے لیے ورژن کی ضروریات پر مشتمل ہے۔ Terraform اور providers

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

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

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

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

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

  • اگر آپ کا پورا انفراسٹرکچر ایک ہی کمپوزیشن میں ہے تو اس میں کچھ وقت لگ سکتا ہے

• کم ریسورس کے ساتھ بلاسٹ رداس (سیکیورٹی کی خلاف ورزی کی صورت میں) چھوٹا ہوتا ہے

  • الگ الگ کمپوزیشن میں رکھ کر غیر متعلق ریسورس کو ایک دوسرے سے الگ تھلگ کرنا اگر کچھ غلط ہوتا ہے تو اس سے خطرہ کم کرتا ہے۔

• اپنا پراجیکٹ ریموٹ سٹیٹ استعمال کرکے شروع کریں کیونکہ:

  • آپ کا لیپ ٹاپ آپ کے انفراسٹرکچر کے کوڈکے لیے کوئی مقام نہیں ہے۔

  • فائلtfstate کو gitمیں رکھنا نہ مناسب ہے

  • بعد میں جب انفراسٹرکچر کی تہیں متعدد سمتوں (انحصار یا ریسورس کی تعداد) میں بڑھنا شروع ہو جائیں تو چیزوں کو قابو میں رکھنا آسان ہو گا

• مستقل ساخت اور نامزدگی کے طریقے کا مشق کریں:

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

  • Terraform اسٹیٹ فائل میں ریسورس کو منتقل کرنا ممکن ہے لیکن اگر آپ کے پاس مستقل ساخت اور نامزدگی کا طریقہ نہ ہو تو یہ کرنا مشکل ہو سکتا ہے۔

• ماڈیولزresource کو جتنا ممکن ہو سادہ رکھیں۔

• ان values کو ہارڈکوڈ نہ کریں جو variables کے طور پر پاس کی جا سکیں یا ڈیٹا sources کا استعمال کرتے ہوئے دریافت کی جا سکیں۔

• کمپوزیشن کے اندر انفراسٹرکچر ماڈیولز کے درمیان گلو کے طور پر خاص طور پر ڈیٹا ذرائع اور terraform_remote_state استعمال کریں۔

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

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

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

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

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

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

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

4. جب Terraform کو Ansible کے بعد اپنایا جاتا ہے، یا جب Ansible UI کو فعال طور پر استعمال کیا جاتا ہے۔

5. کبھی کبھی یہ Kubernetes اور Crossplane ecosystem نظام کو استعمال کرنے اور اپنے Terraform کنفیگریشنز کی مطلوبہ حالت کو حاصل کرنے کے لیے ایک reconciliation loop فیچر استعمال کرتا ہے۔ مزید معلومات کے لیے Crossplane vs Terraform ویڈیو دیکھیں۔

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

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

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

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

• 2 AWS اکاؤنٹس

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

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

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

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