مستقبل کے لیے Terraform میں بنیادی ڈھانچے کی تفصیل۔ انتون بابینکو (2018)

بہت سے لوگ اپنے روزمرہ کے کام میں Terraform کو جانتے اور استعمال کرتے ہیں، لیکن اس کے لیے بہترین طریقہ کار ابھی تک تشکیل نہیں دیا گیا ہے۔ ہر ٹیم کو اپنے طریقے اور طریقے ایجاد کرنے ہوتے ہیں۔

آپ کا بنیادی ڈھانچہ تقریباً یقینی طور پر سادہ سے شروع ہوتا ہے: چند وسائل + چند ڈویلپرز۔ وقت کے ساتھ، یہ ہر طرح کی سمتوں میں بڑھتا ہے۔ کیا آپ وسائل کو Terraform ماڈیولز میں گروپ کرنے، کوڈ کو فولڈرز میں ترتیب دینے کے طریقے تلاش کرتے ہیں، اور کیا غلط ہو سکتا ہے؟ (مشہور آخری الفاظ)

وقت گزرتا ہے اور آپ کو لگتا ہے کہ آپ کا بنیادی ڈھانچہ آپ کا نیا پالتو جانور ہے، لیکن کیوں؟ آپ بنیادی ڈھانچے میں ناقابل فہم تبدیلیوں کے بارے میں فکر مند ہیں، آپ بنیادی ڈھانچے اور کوڈ کو چھونے سے ڈرتے ہیں - نتیجے کے طور پر، آپ نئی فعالیت میں تاخیر کرتے ہیں یا معیار کو کم کرتے ہیں...

Github پر AWS کے لیے Terraform کمیونٹی ماڈیولز کے مجموعے کا انتظام کرنے اور پیداوار میں Terraform کی طویل مدتی دیکھ بھال کے تین سال بعد، Anton Babenko اپنا تجربہ بتانے کے لیے تیار ہے: TF ماڈیول کیسے لکھیں تاکہ مستقبل میں تکلیف نہ ہو۔

بات کے اختتام تک، شرکاء Terraform میں وسائل کے انتظام کے اصولوں، Terraform میں ماڈیولز کے ساتھ منسلک بہترین طریقوں، اور بنیادی ڈھانچے کے انتظام سے منسلک کچھ مسلسل انضمام کے اصولوں سے زیادہ واقف ہوں گے۔

ڈس کلیمر: میں نوٹ کرتا ہوں کہ یہ رپورٹ نومبر 2018 کی ہے—2 سال گزر چکے ہیں۔ رپورٹ میں زیر بحث Terraform 0.11 کا ورژن مزید تعاون یافتہ نہیں ہے۔ گزشتہ 2 سالوں کے دوران 2 نئی ریلیز جاری کی گئی ہیں جن میں بہت سی جدتیں، بہتری اور تبدیلیاں شامل ہیں۔ براہ کرم اس پر توجہ دیں اور دستاویزات کی جانچ کریں۔

حوالہ جات:

• terraform-community-modules + terraform-aws-modules
• antonbabenko/pre-commit-terraform - آٹو فارمیٹنگ کوڈ اور دستاویزات
• antonbabenko/terrapin - ٹیرافارم ماڈیولز کا جنریٹر (WIP)
• antonbabenko/modules.tf-lambda - بصری خاکوں سے ٹیرافارم کوڈ جنریٹر (WIP)
• www.terraform-best-practices.com
• medium.com/@anton.babenko (نئی پوسٹس میری ذاتی ویب سائٹ www.antonbabenko.com/ پر ہیں)
• @antonbabenko - ٹویٹر، اور مختلف سلیکس کا ایک گروپ

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

میں Terraform پر کام کرتا ہوں اور 2015 سے Terraform اور Amazon سے متعلق اوپن سورس پروجیکٹس کی ایک بڑی تعداد میں ایک فعال شریک اور تعاون کنندہ رہا ہوں۔

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

میں Terraform کے ساتھ کام کرنے کی پیچیدگیوں اور تفصیلات کے بارے میں بات کروں گا۔ لیکن یہ واقعی ہائی لوڈ کا موضوع نہیں ہے۔ اور اب آپ سمجھ جائیں گے کہ ایسا کیوں ہے۔

وقت گزرنے کے ساتھ، میں نے Terraform ماڈیول لکھنا شروع کیا۔ صارفین نے سوالات لکھے، میں نے انہیں دوبارہ لکھا۔ پھر میں نے پری کمٹ ہک وغیرہ کا استعمال کرتے ہوئے کوڈ کو فارمیٹ کرنے کے لیے مختلف یوٹیلیٹیز لکھیں۔

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

میں یوکرین سے ہوں۔ میں کئی سالوں سے ناروے میں مقیم ہوں۔

نیز، اس رپورٹ کے لیے ان لوگوں سے معلومات اکٹھی کی گئی ہیں جو میرا نام جانتے ہیں اور مجھے سوشل نیٹ ورکس پر ڈھونڈتے ہیں۔ میرا تقریباً ہمیشہ ایک ہی عرفی نام ہوتا ہے۔

https://github.com/terraform-aws-modules
https://registry.terraform.io/namespaces/terraform-aws-modules

جیسا کہ میں نے ذکر کیا، میں Terraform AWS ماڈیولز کا مین مینٹینر ہوں، جو GitHub پر سب سے بڑے ریپوزٹریوں میں سے ایک ہے جہاں ہم سب سے عام کاموں کے لیے ماڈیولز کی میزبانی کرتے ہیں: VPC، Autoscaling، RDS۔

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

Terraform 2014 میں ایک افادیت کے طور پر نمودار ہوا جس نے آپ کو بنیادی ڈھانچے کو کوڈ کے طور پر لکھنے، منصوبہ بندی کرنے اور ان کا نظم کرنے کی اجازت دی۔ یہاں کلیدی تصور "بطور کوڈ بنیادی ڈھانچہ" ہے۔

تمام دستاویزات، جیسا کہ میں نے کہا، میں لکھا ہوا ہے۔ terraform.io. مجھے امید ہے کہ زیادہ تر لوگ اس سائٹ کے بارے میں جانتے ہیں اور دستاویزات کو پڑھ چکے ہیں۔ اگر ایسا ہے، تو آپ صحیح جگہ پر ہیں۔

یہ ایک باقاعدہ Terraform کنفیگریشن فائل کی طرح نظر آتی ہے، جہاں ہم پہلے کچھ متغیرات کی وضاحت کرتے ہیں۔

اس معاملے میں ہم "aws_region" کی وضاحت کرتے ہیں۔

پھر ہم بیان کرتے ہیں کہ ہم کون سے وسائل پیدا کرنا چاہتے ہیں۔

ہم انحصار اور فراہم کنندگان کو لوڈ کرنے کے لیے کچھ کمانڈز چلاتے ہیں، خاص طور پر "terraform init"۔

اور ہم "terraform apply" کمانڈ چلاتے ہیں تاکہ یہ چیک کیا جا سکے کہ آیا مخصوص کنفیگریشن ہمارے بنائے گئے وسائل سے میل کھاتی ہے۔ چونکہ ہم نے پہلے کچھ بھی نہیں بنایا ہے، اس لیے Terraform ہمیں ان وسائل کو تخلیق کرنے کا اشارہ کرتا ہے۔

ہم اس کی تصدیق کرتے ہیں۔ اس طرح ہم ایک بالٹی بناتے ہیں جسے seasnail کہتے ہیں۔

اسی طرح کی کئی افادیتیں بھی ہیں۔ آپ میں سے بہت سے لوگ جو Amazon استعمال کرتے ہیں AWS CloudFormation یا Google Cloud Deployment Manager یا Azure Resource Manager کو جانتے ہیں۔ ان میں سے ہر ایک عوامی کلاؤڈ فراہم کنندگان میں سے ہر ایک کے اندر وسائل کے انتظام کے لیے کسی نہ کسی طرح کا اپنا عمل درآمد کرتا ہے۔ Terraform خاص طور پر مفید ہے کیونکہ یہ آپ کو 100 سے زیادہ فراہم کنندگان کا انتظام کرنے کی اجازت دیتا ہے۔ (مزید تفصیلات یہاں)

وہ اہداف جن کو Terraform نے شروع سے ہی حاصل کیا ہے:

• Terraform وسائل کا ایک ہی نظارہ فراہم کرتا ہے۔
• آپ کو تمام جدید پلیٹ فارمز کو سپورٹ کرنے کی اجازت دیتا ہے۔
• اور Terraform کو شروع سے ہی ایک افادیت کے طور پر ڈیزائن کیا گیا تھا جو آپ کو بنیادی ڈھانچے کو محفوظ طریقے سے اور پیش گوئی کے ساتھ تبدیل کرنے کی اجازت دیتا ہے۔

2014 میں، لفظ "پیش گوئی" اس تناظر میں بہت غیر معمولی لگ رہا تھا۔

Terraform ایک عالمگیر افادیت ہے۔ اگر آپ کے پاس API ہے، تو آپ ہر چیز کو کنٹرول کر سکتے ہیں:

• آپ 120 سے زیادہ فراہم کنندگان کا استعمال ہر چیز کا نظم کرنے کے لیے کر سکتے ہیں۔
• مثال کے طور پر، آپ GitHub ذخیروں تک رسائی کو بیان کرنے کے لیے Terraform استعمال کر سکتے ہیں۔
• آپ جیرا میں کیڑے بھی بنا اور بند کر سکتے ہیں۔
• آپ نیو ریلیک میٹرکس کا نظم کر سکتے ہیں۔
• اگر آپ واقعی چاہتے ہیں تو آپ ڈراپ باکس میں فائلیں بھی بنا سکتے ہیں۔

یہ سب Terraform فراہم کنندگان کا استعمال کرتے ہوئے حاصل کیا گیا ہے، جن کے پاس ایک کھلا API ہے جسے Go میں بیان کیا جا سکتا ہے۔

ہم کہتے ہیں کہ ہم نے Terraform کا استعمال شروع کیا، سائٹ پر کچھ دستاویزات پڑھیں، کچھ ویڈیو دیکھی، اور main.tf لکھنا شروع کیا، جیسا کہ میں نے پچھلی سلائیڈوں پر دکھایا تھا۔

اور سب کچھ بہت اچھا ہے، آپ کے پاس ایک فائل ہے جو VPC بناتی ہے۔

اگر آپ VPC بنانا چاہتے ہیں، تو آپ تقریباً ان 12 لائنوں کی وضاحت کرتے ہیں۔ بیان کریں کہ آپ کس علاقے میں بنانا چاہتے ہیں، IP پتوں کا کون سا cidr_block استعمال کرنا ہے۔ بس۔

قدرتی طور پر، منصوبہ آہستہ آہستہ بڑھ جائے گا.

اور آپ وہاں بہت ساری نئی چیزیں شامل کر رہے ہوں گے: وسائل، ڈیٹا کے ذرائع، آپ نئے فراہم کنندگان کے ساتھ ضم ہو رہے ہوں گے، اچانک آپ اپنے GitHub اکاؤنٹ میں صارفین کو منظم کرنے کے لیے Terraform استعمال کرنا چاہیں گے، وغیرہ۔ آپ استعمال کرنا چاہیں گے۔ مختلف DNS فراہم کرنے والے، ہر چیز کو عبور کریں۔ Terraform اسے آسان بناتا ہے۔

آئیے درج ذیل مثال کو دیکھتے ہیں۔

آپ آہستہ آہستہ انٹرنیٹ_گیٹ وے شامل کرتے ہیں کیونکہ آپ چاہتے ہیں کہ آپ کے VPC سے وسائل انٹرنیٹ تک رسائی حاصل کریں۔ یہ ایک اچھا خیال ہے۔

نتیجہ یہ ہے main.tf:

یہ main.tf کا سب سے اوپر حصہ ہے۔

یہ main.tf کا نچلا حصہ ہے۔

پھر آپ سب نیٹ شامل کریں۔ جب تک آپ NAT گیٹ ویز، روٹس، روٹنگ ٹیبلز اور دوسرے سب نیٹس کا ایک گروپ شامل کرنا چاہتے ہیں، آپ کے پاس 38 لائنیں نہیں ہوں گی، بلکہ تقریباً 200-300 لائنیں ہوں گی۔

یعنی آپ کی main.tf فائل آہستہ آہستہ بڑھ رہی ہے۔ اور اکثر لوگ سب کچھ ایک فائل میں ڈال دیتے ہیں۔ main.tf میں 10-20 Kb ظاہر ہوتا ہے۔ تصور کریں کہ 10-20 Kb متن کا مواد ہے۔ اور ہر چیز ہر چیز سے جڑی ہوئی ہے۔ اس کے ساتھ کام کرنا آہستہ آہستہ مشکل ہوتا جا رہا ہے۔ 10-20 Kb ایک اچھا صارف کیس ہے، کبھی کبھی زیادہ۔ اور لوگ ہمیشہ یہ نہیں سوچتے کہ یہ برا ہے۔

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

• کوڈ بڑھ رہا ہے۔
• وسائل کے درمیان انحصار بھی بڑھ رہا ہے۔

اور ہمیں ایک بہت بڑی ضرورت ہے۔ ہم سمجھتے ہیں کہ ہم مزید اس طرح نہیں رہ سکتے۔ ہمارا ضابطہ بہت بڑا ہوتا جا رہا ہے۔ 10-20 Kb، یقینا، بہت وسیع نہیں ہے، لیکن ہم صرف نیٹ ورک اسٹیک کے بارے میں بات کر رہے ہیں، یعنی آپ نے صرف نیٹ ورک کے وسائل شامل کیے ہیں۔ ہم ایپلیکیشن لوڈ بیلنسر، تعیناتی ES کلسٹر، Kubernetes وغیرہ کے بارے میں بات نہیں کر رہے ہیں، جہاں 100 Kb آسانی سے بنایا جا سکتا ہے۔ اگر آپ یہ سب لکھتے ہیں، تو آپ بہت جلد جان لیں گے کہ Terraform Terraform ماڈیول فراہم کرتا ہے۔

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

لہذا ہم یہ سمجھنے کی کوشش کر رہے ہیں کہ ہم اپنے 10-20-30 Kb کوڈ کو کیسے بہتر بنائیں گے۔ ہم آہستہ آہستہ سمجھ رہے ہیں کہ ہمیں کچھ ماڈیولز استعمال کرنے کی ضرورت ہے۔

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

وسائل کے ماڈیول کی ایک مثال۔

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

ہم بتاتے ہیں کہ ہم کون سا ورژن ڈاؤن لوڈ کرنا چاہتے ہیں۔

ہم وہاں دلائل کا ایک گروپ پاس کرتے ہیں۔ بس۔ جب ہم اس ماڈیول کو استعمال کرتے ہیں تو ہمیں صرف اتنا ہی جاننے کی ضرورت ہے۔

بہت سے لوگ سوچتے ہیں کہ اگر وہ تازہ ترین ورژن استعمال کرتے ہیں، تو سب کچھ مستحکم ہو جائے گا. لیکن نہیں. بنیادی ڈھانچے کا ورژن ہونا ضروری ہے؛ ہمیں واضح طور پر جواب دینا چاہیے کہ یہ یا وہ جزو کس ورژن میں تعینات کیا گیا تھا۔

یہاں وہ کوڈ ہے جو اس ماڈیول کے اندر ہے۔ سیکیورٹی گروپ ماڈیول۔ یہاں طومار 640 ویں لائن پر جاتا ہے۔ ہر ممکن ترتیب میں Amazon میں ایک سیکورٹی-کروپ ریسورس بنانا ایک بہت ہی غیر معمولی کام ہے۔ صرف ایک سیکیورٹی گروپ بنانا اور اسے بتانا کافی نہیں ہے کہ اسے کون سے اصول بھیجے جائیں۔ یہ بہت آسان ہوگا۔ ایمیزون کے اندر ایک ملین مختلف پابندیاں ہیں۔ مثال کے طور پر، اگر آپ استعمال کرتے ہیں VPC اختتامی نقطہ، سابقہ ​​فہرست، مختلف APIs اور اس سب کو ہر چیز کے ساتھ جوڑنے کی کوشش کرتا ہے، پھر Terraform آپ کو ایسا کرنے کی اجازت نہیں دیتا ہے۔ اور ایمیزون API بھی اس کی اجازت نہیں دیتا ہے۔ لہذا، ہمیں اس تمام خوفناک منطق کو ایک ماڈیول میں چھپانے کی ضرورت ہے اور صارف کوڈ دینے کی ضرورت ہے جو بالکل ایسا ہی نظر آتا ہے۔

صارف کو یہ جاننے کی ضرورت نہیں ہے کہ اسے اندر کیسے بنایا گیا ہے۔

دوسری قسم کے ماڈیولز، جو وسائل کے ماڈیولز پر مشتمل ہوتے ہیں، پہلے سے ہی ان مسائل کو حل کرتے ہیں جو آپ کے کاروبار پر زیادہ لاگو ہوتے ہیں۔ اکثر یہ ایک ایسی جگہ ہوتی ہے جو Terraform کے لیے ایک توسیع ہوتی ہے اور کمپنی کے معیارات کے لیے ٹیگز کے لیے کچھ سخت اقدار متعین کرتی ہے۔ آپ وہاں وہ فعالیت بھی شامل کر سکتے ہیں جسے Terraform فی الحال آپ کو استعمال کرنے کی اجازت نہیں دیتا ہے۔ یہ ابھی ہے۔ اب ورژن 0.11، جو ماضی کی بات بننے والا ہے۔ لیکن پھر بھی، پری پروسیسرز، jsonnet، cookiecutter اور دیگر چیزوں کا ایک گروپ وہ معاون طریقہ کار ہے جو مکمل کام کے لیے استعمال کیا جانا چاہیے۔

آگے میں اس کی کچھ مثالیں دکھاؤں گا۔

بنیادی ڈھانچے کے ماڈیول کو بالکل اسی طرح کہا جاتا ہے۔

ماخذ کی نشاندہی کی گئی ہے جہاں سے مواد کو ڈاؤن لوڈ کرنا ہے۔

قدروں کا ایک گروپ اس ماڈیول میں داخل اور منتقل ہوتا ہے۔

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

ماڈیولز کی دو قسمیں ہیں۔ یہ سمجھنا ضروری ہے کیونکہ میں نے اس رپورٹ میں جو معلومات گروپ کی ہیں ان میں سے زیادہ تر دستاویزات میں نہیں لکھی گئی ہیں۔

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

آئیے آگے ان ماڈیولز کو کیسے لکھنا ہے اس پر ایک نظر ڈالتے ہیں۔ پھر ہم دیکھیں گے کہ انہیں کیسے کال کرنا ہے اور کوڈ کے ساتھ کیسے کام کرنا ہے۔

Terraform رجسٹری - https://registry.terraform.io/

ٹپ #0 یہ ہے کہ وسائل کے ماڈیول نہ لکھیں۔ ان میں سے زیادہ تر ماڈیول پہلے ہی آپ کے لیے لکھے گئے ہیں۔ جیسا کہ میں نے کہا، وہ اوپن سورس ہیں، ان میں آپ کی کوئی بھی کاروباری منطق نہیں ہے، ان میں IP ایڈریس، پاس ورڈز وغیرہ کے لیے ہارڈ کوڈ شدہ اقدار نہیں ہیں۔ ماڈیول بہت لچکدار ہے۔ اور غالباً یہ پہلے ہی لکھا جا چکا ہے۔ ایمیزون سے وسائل کے لیے بہت سے ماڈیولز ہیں۔ تقریباً 650۔ اور ان میں سے اکثر اچھے معیار کے ہیں۔

اس مثال میں، کوئی آپ کے پاس آیا اور کہا، "میں ڈیٹا بیس کا انتظام کرنے کے قابل ہونا چاہتا ہوں۔ ایک ماڈیول بنائیں تاکہ میں ڈیٹا بیس بنا سکوں۔" اس شخص کو ایمیزون یا ٹیرافارم میں سے کسی ایک کے نفاذ کی تفصیلات معلوم نہیں ہیں۔ وہ آسانی سے کہتا ہے: "میں MSSQL کا انتظام کرنا چاہتا ہوں۔" یعنی، ہمارا مطلب ہے کہ یہ ہمارے ماڈیول کو کال کرے گا، وہاں انجن کی قسم کو پاس کرے گا، اور ٹائم زون کی نشاندہی کرے گا۔

اور کسی شخص کو یہ نہیں معلوم ہونا چاہیے کہ ہم اس ماڈیول کے اندر دو مختلف وسائل بنائیں گے: ایک MSSQL کے لیے، دوسرا ہر چیز کے لیے، صرف اس لیے کہ Terraform 0.11 میں آپ ٹائم زون کی اقدار کو اختیاری کے طور پر بیان نہیں کر سکتے۔

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

یہ دوسری دلیل ہے، جو کافی اہم ہے اگر آپ تھوڑی دیر سے Terraform استعمال کر رہے ہیں۔ آپ کے پاس ایک ذخیرہ ہے جس میں آپ اپنی کمپنی کے لیے اپنے تمام Terraform ماڈیولز رکھتے ہیں۔ اور یہ بالکل معمول کی بات ہے کہ وقت گزرنے کے ساتھ ساتھ یہ پروجیکٹ ایک یا دو میگا بائٹس کے سائز کا ہو جائے گا۔ یہ ٹھیک ہے.

لیکن مسئلہ یہ ہے کہ Terraform ان ماڈیولز کو کس طرح کال کرتا ہے۔ مثال کے طور پر، اگر آپ ہر ایک صارف کو بنانے کے لیے ایک ماڈیول کو کال کرتے ہیں، تو Terraform پہلے پورے ذخیرہ کو لوڈ کرے گا اور پھر اس فولڈر میں جائے گا جہاں وہ مخصوص ماڈیول واقع ہے۔ اس طرح آپ ہر بار ایک میگا بائٹ ڈاؤن لوڈ کریں گے۔ اگر آپ 100 یا 200 صارفین کو منظم کرتے ہیں، تو آپ 100 یا 200 میگا بائٹس ڈاؤن لوڈ کریں گے، اور پھر اس فولڈر میں جائیں گے۔ لہذا قدرتی طور پر جب بھی آپ "Terraform init" کو مارتے ہیں تو آپ بہت ساری چیزیں ڈاؤن لوڈ نہیں کرنا چاہتے ہیں۔

https://github.com/mbtproject/mbt

اس مسئلے کے دو حل ہیں۔ سب سے پہلے رشتہ دار راستے استعمال کرنا ہے۔ اس طرح آپ کوڈ میں بتاتے ہیں کہ فولڈر مقامی (./) ہے۔ اور کچھ بھی لانچ کرنے سے پہلے، آپ مقامی طور پر اس ذخیرے کا گٹ کلون کرتے ہیں۔ اس طرح آپ اسے ایک بار کریں۔

یقیناً بہت سے نشیب و فراز ہیں۔ مثال کے طور پر، آپ ورژننگ استعمال نہیں کر سکتے۔ اور کبھی کبھی اس کے ساتھ رہنا مشکل ہو جاتا ہے۔

دوسرا حل۔ اگر آپ کے پاس بہت سارے ذیلی ماڈلز ہیں اور آپ کے پاس پہلے سے ہی کسی قسم کی پائپ لائن قائم ہے، تو وہاں MBT پروجیکٹ ہے، جو آپ کو ایک monorepository سے بہت سے مختلف پیکجوں کو جمع کرنے اور انہیں S3 پر اپ لوڈ کرنے کی اجازت دیتا ہے۔ یہ بہت اچھا طریقہ ہے۔ اس طرح، iam-user-1.0.0.zip فائل کا وزن صرف 1 Kb ہوگا، کیونکہ اس وسائل کو بنانے کا کوڈ بہت چھوٹا ہے۔ اور یہ بہت تیزی سے کام کرے گا۔

آئیے اس بارے میں بات کرتے ہیں کہ ماڈیولز میں کیا استعمال نہیں کیا جا سکتا۔

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

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

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

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

سب سے عام مثال، جس کی نشاندہی سرکاری دستاویزات میں بھی کی گئی ہے، یہ ہے کہ اگر آپ aws_instance لکھتے ہیں اور دلائل کا ایک گروپ بتاتے ہیں، تو اس میں کوئی حرج نہیں ہے اگر آپ وہاں پروویژنر "لوکل-ایگزیک" کی وضاحت کرتے ہیں اور اپنا جوابی عمل چلاتے ہیں۔ پلے بک

درحقیقت، ہاں، اس میں کوئی حرج نہیں ہے۔ لیکن لفظی طور پر جلد ہی آپ کو احساس ہو جائے گا کہ یہ لوکل-exec چیز موجود نہیں ہے، مثال کے طور پر launch_configuration میں۔

اور جب آپ لانچ_کنفیگریشن استعمال کرتے ہیں، اور آپ ایک مثال سے آٹو اسکیلنگ گروپ بنانا چاہتے ہیں، تو لانچ_کنفیگریشن میں "پروویژنر" کا کوئی تصور نہیں ہے۔ "صارف کا ڈیٹا" کا تصور موجود ہے۔

لہذا، ایک زیادہ عالمگیر حل صارف کے ڈیٹا کو استعمال کرنا ہے۔ اور یہ یا تو مثال پر ہی لانچ کیا جائے گا، جب مثال آن ہو، یا اسی صارف ڈیٹا میں، جب آٹو اسکیلنگ گروپ اس لانچ_کنفیگریشن کو استعمال کرے۔

اگر آپ اب بھی پروویژنر کو چلانا چاہتے ہیں، کیونکہ یہ ایک گلوئینگ جزو ہے، جب ایک وسیلہ بن جاتا ہے، اس وقت آپ کو اپنے پروویژنر کو چلانے کی ضرورت ہوتی ہے، آپ کا کمانڈ۔ ایسے بہت سے حالات ہیں۔

اور اس کے لیے سب سے درست وسیلہ null_resource کہلاتا ہے۔ Null_resource ایک ڈمی وسیلہ ہے جو حقیقت میں کبھی نہیں بنایا جاتا۔ یہ کسی چیز کو نہیں چھوتا ہے، کوئی API نہیں، کوئی آٹو اسکیلنگ نہیں ہے۔ لیکن یہ آپ کو کنٹرول کرنے کی اجازت دیتا ہے کہ کمانڈ کو کب چلانا ہے۔ اس صورت میں، کمانڈ تخلیق کے دوران چلائی جاتی ہے۔

لنک http://bit.ly/common-traits-in-terraform-modules

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

اگر آپ کچھ لکھنا چاہتے ہیں تاکہ لوگ اسے استعمال کریں تو میں ان علامات پر عمل کرنے کا مشورہ دیتا ہوں۔

یہ ہیں:

• دستاویزات اور مثالیں۔
• مکمل فعالیت۔
• معقول ڈیفالٹس۔
• کوڈ صاف کریں۔
• ٹیسٹ۔

ٹیسٹ ایک مختلف صورت حال ہیں کیونکہ انہیں لکھنا کافی مشکل ہے۔ میں دستاویزات اور مثالوں پر زیادہ یقین رکھتا ہوں۔

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

یہ دستاویزات کا سرمئی حصہ ہے۔ اب آپ سوچ رہے ہوں گے: "کچھ غیر واضح ہے۔ یقین نہیں آرہا"۔ لیکن ہم چھ ماہ میں دیکھیں گے۔

اب بات کرتے ہیں کہ ان ماڈیولز کو کیسے کال کریں۔

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

دو انتہا ہیں۔ پہلی انتہا سب ایک میں ہے۔ ہمارے پاس ایک ماسٹر فائل ہے۔ فی الحال، یہ Terraform ویب سائٹ پر سرکاری طور پر بہترین عمل تھا۔

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

بہت زیادہ وقت ہے، مثال کے طور پر، 5 منٹ۔ کچھ لوگوں کے لیے یہ کافی وقت ہے۔ میں نے ایسے معاملات دیکھے ہیں جہاں 15 منٹ لگے۔ AWS API نے یہ جاننے کی کوشش میں 15 منٹ گزارے کہ ہر وسائل کی حالت کے ساتھ کیا ہو رہا ہے۔ یہ بہت بڑا علاقہ ہے۔

اور، قدرتی طور پر، ایک متعلقہ مسئلہ اس وقت ظاہر ہوگا جب آپ ایک جگہ کچھ تبدیل کرنا چاہتے ہیں، پھر آپ 15 منٹ انتظار کرتے ہیں، اور یہ آپ کو کچھ تبدیلیوں کا کینوس فراہم کرتا ہے۔ آپ نے تھوک دیا، "ہاں" لکھا، اور کچھ غلط ہو گیا۔ یہ ایک بہت حقیقی مثال ہے۔ Terraform آپ کو مسائل سے بچانے کی کوشش نہیں کرتا ہے۔ یعنی جو چاہو لکھو۔ مسائل ہوں گے - آپ کے مسائل۔ جبکہ Terraform 0.11 کسی بھی طرح سے آپ کی مدد کرنے کی کوشش نہیں کر رہا ہے۔ 0.12 میں کچھ دلچسپ مقامات ہیں جو آپ کو یہ کہنے کی اجازت دیتے ہیں: "واسیا، آپ واقعی یہ چاہتے ہیں، کیا آپ اپنے ہوش میں آ سکتے ہیں؟"

دوسرا طریقہ یہ ہے کہ اس علاقے کو کم کیا جائے، یعنی ایک جگہ سے آنے والی کالیں دوسری جگہ سے کم منسلک ہوسکتی ہیں۔

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

یہ سب ایک جگہ پر کون رہتا ہے؟ ایک، دو، تین لوگ، یعنی کوئی اسے استعمال کر رہا ہے۔

اور کون ایک خاص جزو، ایک بلاک یا ایک انفراسٹرکچر ماڈیول کہتا ہے؟ پانچ سات لوگ۔ یہ ٹھنڈا ہے۔

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

اگر اسٹیک VPC میں کچھ بدل گیا ہے اور آپ ان تبدیلیوں کو EC2 پر لاگو کرنا چاہتے ہیں، یعنی آپ آٹو اسکیلنگ گروپ کو اپ ڈیٹ کرنا چاہتے ہیں کیونکہ آپ کے پاس ایک نیا سب نیٹ ہے، تو میں اس قسم کو انحصار آرکیسٹریشن کہتا ہوں۔ کچھ حل ہیں: کون کیا استعمال کرتا ہے؟

میں تجویز کرسکتا ہوں کہ اس کے کیا حل ہیں۔ آپ جادو کرنے کے لیے Terraform کا استعمال کر سکتے ہیں، یا آپ Terraform کو استعمال کرنے کے لیے makefiles استعمال کر سکتے ہیں۔ اور دیکھیں کہ کیا وہاں کچھ تبدیل ہوا ہے، آپ اسے یہاں لانچ کر سکتے ہیں۔

آپ کو یہ فیصلہ کیسا لگا؟ کیا کسی کو یقین ہے کہ یہ ایک ٹھنڈا حل ہے؟ میں ایک مسکراہٹ دیکھ رہا ہوں، بظاہر شکوک و شبہات پیدا ہو گئے ہیں۔

یقینا، گھر پر اس کی کوشش نہ کریں. ٹیرافارم کو کبھی بھی ٹیرافارم سے چلانے کے لیے ڈیزائن نہیں کیا گیا تھا۔

ایک رپورٹ میں انہوں نے مجھے بتایا: "نہیں، یہ کام نہیں کرے گا۔" نقطہ یہ ہے کہ یہ کام نہیں کرنا چاہئے۔ اگرچہ یہ بہت متاثر کن لگتا ہے جب آپ ٹیرافارم سے ٹیرافارم شروع کر سکتے ہیں، اور پھر ٹیرافارم، آپ کو ایسا نہیں کرنا چاہیے۔ Terraform ہمیشہ بہت آسانی سے شروع ہونا چاہئے.

https://github.com/gruntwork-io/terragrunt/

اگر آپ کو کال آرکیسٹریشن کی ضرورت ہے جب ایک جگہ کچھ بدل گیا ہو، تو وہاں ٹیراگرنٹ ہے۔

Terragrunt ایک افادیت ہے، Terraform میں ایک اضافہ، جو آپ کو بنیادی ڈھانچے کے ماڈیولز پر کالوں کو مربوط اور آرکیسٹریٹ کرنے کی اجازت دیتا ہے۔

ایک عام Terraform کنفیگریشن فائل اس طرح نظر آتی ہے۔

آپ بتاتے ہیں کہ آپ کس مخصوص ماڈیول کو کال کرنا چاہتے ہیں۔

ماڈیول میں کیا انحصار ہے؟

اور یہ ماڈیول کن دلائل کو قبول کرتا ہے۔ ٹیراگرنٹ کے بارے میں جاننے کے لیے بس اتنا ہی ہے۔

دستاویزات موجود ہیں، اور GitHub پر 1 ستارے ہیں۔ لیکن زیادہ تر معاملات میں یہ وہی ہے جو آپ کو جاننے کی ضرورت ہے۔ اور یہ ان کمپنیوں میں لاگو کرنا بہت آسان ہے جو ابھی Terraform کے ساتھ کام کرنا شروع کر رہی ہیں۔

تو آرکیسٹریشن ٹیراگرنٹ ہے۔ اور بھی آپشنز ہیں۔

اب بات کرتے ہیں کہ کوڈ کے ساتھ کیسے کام کیا جائے۔

اگر آپ کو اپنے کوڈ میں نئی ​​خصوصیات شامل کرنے کی ضرورت ہے، تو زیادہ تر معاملات میں یہ آسان ہے۔ آپ ایک نیا وسیلہ لکھ رہے ہیں، سب کچھ آسان ہے۔

اگر آپ کے پاس کچھ وسائل ہیں جو آپ نے پہلے سے بنائے ہیں، مثال کے طور پر، آپ نے AWS اکاؤنٹ کھولنے کے بعد Terraform کے بارے میں سیکھا اور آپ کے پاس پہلے سے موجود وسائل کو استعمال کرنا چاہتے ہیں، تو مناسب ہو گا کہ آپ اپنے ماڈیول کو اس طرح بڑھا دیں، تاکہ یہ موجودہ وسائل کے استعمال کی حمایت کرتا ہے۔

اور بلاک ریسورس کا استعمال کرتے ہوئے نئے وسائل کی تخلیق کی حمایت کی۔

آؤٹ پٹ پر ہم ہمیشہ آؤٹ پٹ آئی ڈی واپس کرتے ہیں اس پر منحصر ہے کہ کیا استعمال کیا گیا تھا۔

ٹیرافارم 0.11 میں دوسرا بہت اہم مسئلہ فہرستوں کے ساتھ کام کرنا ہے۔

مشکل یہ ہے کہ اگر ہمارے پاس صارفین کی ایسی فہرست موجود ہے۔

اور جب ہم ان صارفین کو بلاک ریسورس کا استعمال کرتے ہوئے بناتے ہیں، تب سب کچھ ٹھیک ہو جاتا ہے۔ ہم پوری فہرست میں سے ہر ایک کے لیے ایک فائل بناتے ہیں۔ سب کچھ ٹھیک ہے. اور پھر، مثال کے طور پر، user3، جو درمیان میں ہے، یہاں سے ہٹا دیا جائے، پھر اس کے بعد بنائے گئے تمام وسائل دوبارہ بنائے جائیں گے کیونکہ انڈیکس بدل جائے گا۔

ریاستی ماحول میں فہرستوں کے ساتھ کام کرنا۔ ریاستی ماحول کیا ہے؟ یہ وہ صورت حال ہے جہاں یہ وسیلہ بننے پر ایک نئی قدر پیدا ہوتی ہے۔ مثال کے طور پر، AWS Access Key یا AWS Secret Key، یعنی جب ہم صارف بناتے ہیں تو ہمیں ایک نئی رسائی یا خفیہ کلید موصول ہوتی ہے۔ اور جب بھی ہم کسی صارف کو حذف کرتے ہیں، اس صارف کے پاس ایک نئی کلید ہوگی۔ لیکن یہ فینگ شوئی نہیں ہے، کیونکہ صارف ہمارے ساتھ دوستی نہیں کرنا چاہے گا اگر ہم ہر بار جب کوئی ٹیم چھوڑتا ہے تو ہم اس کے لیے ایک نیا صارف بناتے ہیں۔

یہ ہے حل۔ یہ Jsonnet میں لکھا ہوا کوڈ ہے۔ Jsonnet گوگل کی طرف سے ایک ٹیمپلیٹنگ زبان ہے۔

یہ کمانڈ آپ کو اس ٹیمپلیٹ کو قبول کرنے کی اجازت دیتی ہے اور آؤٹ پٹ کے طور پر یہ ایک json فائل واپس کرتی ہے جو آپ کے ٹیمپلیٹ کے مطابق بنائی گئی ہے۔

ٹیمپلیٹ اس طرح لگتا ہے۔

Terraform آپ کو HCL اور Json دونوں کے ساتھ ایک ہی طریقے سے کام کرنے کی اجازت دیتا ہے، لہذا اگر آپ Json پیدا کرنے کی صلاحیت رکھتے ہیں، تو آپ اسے Terraform میں پھسل سکتے ہیں۔ .tf.json ایکسٹینشن والی فائل کامیابی کے ساتھ ڈاؤن لوڈ ہو جائے گی۔

اور پھر ہم اس کے ساتھ حسب معمول کام کرتے ہیں: terraform init، terramorm apply۔ اور ہم دو صارف بناتے ہیں۔

اب کوئی ٹیم چھوڑ کر چلا جائے تو ہمیں ڈر نہیں۔ ہم صرف json فائل میں ترمیم کریں گے۔ واسیا پپکن چلا گیا، پیٹیا پیاٹوککن رہ گیا۔ Petya Pyatochkin کو نئی چابی نہیں ملے گی۔

ٹیرافارم کو دوسرے ٹولز کے ساتھ مربوط کرنا ٹیرافارم کا کام نہیں ہے۔ Terraform کو وسائل پیدا کرنے کے پلیٹ فارم کے طور پر بنایا گیا تھا اور بس۔ اور جو کچھ بھی بعد میں آتا ہے وہ Terraform کی تشویش نہیں ہے۔ اور اسے وہاں باندھنے کی ضرورت نہیں ہے۔ جواب دینے والا ہے، جو آپ کی ہر ضرورت کو پورا کرتا ہے۔

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

پہلا راستہ۔ ہم ایک آؤٹ پٹ بناتے ہیں جہاں ہم یہ کمانڈ لکھتے ہیں۔

اور پھر ہم اس کمانڈ کو شیل ٹیرافارم آؤٹ پٹ سے کال کرتے ہیں اور وہ ویلیو بتاتے ہیں جو ہم چاہتے ہیں۔ اس طرح، کمانڈ کو تمام متبادل اقدار کے ساتھ عمل میں لایا جاتا ہے۔ یہ بہت آرام دہ ہے۔

دوسرا راستہ۔ یہ ہمارے بنیادی ڈھانچے میں ہونے والی تبدیلیوں کے لحاظ سے null_resource کا استعمال ہے۔ جیسے ہی کچھ وسائل کی ID میں تبدیلی آتی ہے ہم اسی مقامی exe کو کال کر سکتے ہیں۔

قدرتی طور پر، یہ سب کاغذ پر ہموار ہے، کیونکہ ایمیزون، دیگر تمام عوامی فراہم کنندگان کی طرح، اس کے اپنے کنارے کے معاملات کا ایک گروپ ہے۔

سب سے عام ایج کیس یہ ہے کہ جب آپ AWS اکاؤنٹ کھولتے ہیں، تو اس سے فرق پڑتا ہے کہ آپ کون سے علاقے استعمال کرتے ہیں۔ کیا یہ خصوصیت وہاں فعال ہے؛ ہوسکتا ہے کہ آپ نے اسے دسمبر 2013 کے بعد کھولا ہو۔ ہو سکتا ہے کہ آپ VPC وغیرہ میں ڈیفالٹ استعمال کر رہے ہوں۔ بہت سی پابندیاں ہیں۔ اور ایمیزون نے انہیں پوری دستاویزات میں بکھیر دیا۔

کچھ چیزیں ہیں جن سے بچنے کی میں تجویز کرتا ہوں۔

شروع کرنے کے لیے، Terraform پلان یا Terraform CLI کے اندر تمام غیر خفیہ دلائل سے بچیں۔ یہ سب یا تو tfvars فائل میں یا ماحولیاتی متغیر میں ڈالا جا سکتا ہے۔

لیکن آپ کو اس پورے جادوئی حکم کو حفظ کرنے کی ضرورت نہیں ہے۔ ٹیرافارم پلان - var اور آف ہم جاتے ہیں۔ پہلا متغیر var ہے، دوسرا متغیر var ہے، تیسرا، چوتھا۔ بنیادی ڈھانچے کا سب سے اہم اصول بطور کوڈ جو میں اکثر استعمال کرتا ہوں وہ یہ ہے کہ صرف کوڈ کو دیکھ کر، مجھے اس بات کی واضح سمجھ ہونی چاہیے کہ وہاں کیا تعینات ہے، کس حالت میں اور کن اقدار کے ساتھ۔ اور اس لیے مجھے دستاویزات کو پڑھنے یا واسیا سے پوچھنے کی ضرورت نہیں ہے کہ اس نے ہمارا کلسٹر بنانے کے لیے کون سے پیرامیٹرز استعمال کیے ہیں۔ مجھے صرف tfvars ایکسٹینشن کے ساتھ ایک فائل کھولنے کی ضرورت ہے، جو اکثر ماحول سے میل کھاتی ہے، اور وہاں موجود ہر چیز کو دیکھتی ہے۔

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

اس کے علاوہ، متوازی کو محدود کرنے اور بڑھانے کی ضرورت نہیں ہے۔ اگر میرے پاس 150 وسائل ہیں اور میں ایمیزون کے متوازی کو ڈیفالٹ 10 سے 100 تک بڑھانا چاہتا ہوں، تو غالباً کچھ غلط ہو جائے گا۔ یا یہ اب ٹھیک ہو سکتا ہے، لیکن جب ایمیزون کہتا ہے کہ آپ بہت زیادہ کالیں کر رہے ہیں، تو آپ کو پریشانی ہو گی۔

Terraform ان میں سے زیادہ تر مسائل کو دوبارہ شروع کرنے کی کوشش کرے گا، لیکن آپ تقریباً کچھ حاصل نہیں کر پائیں گے۔ Parallelism=1 استعمال کرنے کے لیے ایک اہم چیز ہے اگر آپ AWS API کے اندر یا Terraform فراہم کنندہ کے اندر کسی مسئلے سے ٹھوکر کھاتے ہیں۔ اور پھر آپ کو یہ بتانے کی ضرورت ہے: parallelism=1 اور انتظار کریں جب تک کہ Terraform ایک کال، پھر دوسری، پھر تیسری کال مکمل کر لے۔ وہ انہیں ایک ایک کرکے لانچ کرے گا۔

لوگ اکثر مجھ سے پوچھتے ہیں، "میرے خیال میں ٹیرافارم ورک اسپیسز بری کیوں ہیں؟" مجھے یقین ہے کہ بنیادی ڈھانچے کا اصول کوڈ کے طور پر یہ دیکھنا ہے کہ کون سا انفراسٹرکچر بنایا گیا ہے اور کن اقدار کے ساتھ۔

ورک اسپیسز صارفین نے نہیں بنائے تھے۔ اس کا مطلب یہ نہیں ہے کہ صارفین نے GitHub کے مسائل میں لکھا ہے کہ ہم Terraform ورک اسپیس کے بغیر نہیں رہ سکتے۔ نہیں اس طرح نہیں۔ ٹیرافارم انٹرپرائز ایک تجارتی حل ہے۔ HashiCorp سے Terraform نے فیصلہ کیا کہ ہمیں ورک اسپیس کی ضرورت ہے، لہذا ہم نے اسے فائل کر دیا۔ مجھے اسے الگ فولڈر میں رکھنا بہت آسان لگتا ہے۔ پھر کچھ اور فائلیں ہوں گی، لیکن یہ واضح ہو جائے گا.

کوڈ کے ساتھ کیسے کام کریں؟ درحقیقت فہرستوں کے ساتھ کام کرنا ہی تکلیف ہے۔ اور Terraform کو آسان بنائیں۔ یہ وہ چیز نہیں ہے جو آپ کے لیے سب کچھ اچھا کرے گی۔ وہاں دستاویزات میں لکھی ہوئی ہر چیز کو ہٹانے کی ضرورت نہیں ہے۔

رپورٹ کا موضوع "مستقبل کے لیے" لکھا گیا تھا۔ میں اس پر بہت مختصر بات کروں گا۔ مستقبل کے لیے، اس کا مطلب ہے کہ 0.12 جلد ہی جاری کیا جائے گا۔

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

لیکن! اگر آپ ریڈی میڈ ماڈیولز اور تھرڈ پارٹی سلوشنز کا استعمال کرتے ہوئے کم اور زیادہ آسانی سے لکھتے ہیں، تو آپ کو انتظار نہیں کرنا پڑے گا اور امید ہے کہ 0.12 آئے گا اور آپ کے لیے سب کچھ ٹھیک کر دے گا۔

رپورٹ کے لیے شکریہ! آپ نے بنیادی ڈھانچے کے بارے میں کوڈ کے طور پر بات کی اور لفظی طور پر ٹیسٹ کے بارے میں ایک لفظ کہا۔ کیا ماڈیولز میں ٹیسٹ کی ضرورت ہے؟ یہ کس کی ذمہ داری ہے؟ کیا مجھے اسے خود لکھنے کی ضرورت ہے یا یہ ماڈیولز کی ذمہ داری ہے؟

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

میں اس موضوع پر سرگرمی سے تحقیق کر رہا ہوں، یعنی آپ نے جو بنیادی ڈھانچہ لکھا ہے اس کی بنیاد پر خود بخود ٹیسٹ کیسے تیار کیے جائیں۔ یعنی اگر آپ نے یہ کوڈ لکھا ہے تو مجھے اسے چلانے کی ضرورت ہے، اس کی بنیاد پر میں ٹیسٹ بنا سکتا ہوں۔

ٹیرٹیسٹ اکثر ذکر کردہ لائبریریوں میں سے ایک ہے جو آپ کو Terraform کے لیے انٹیگریشن ٹیسٹ لکھنے کی اجازت دیتی ہے۔ یہ افادیت میں سے ایک ہے۔ میں DSL قسم کو ترجیح دیتا ہوں، مثال کے طور پر، rspec.

انتون، رپورٹ کے لیے شکریہ! میرا نام ویلری ہے۔ مجھے ایک چھوٹا سا فلسفیانہ سوال کرنے دو۔ وہاں، مشروط طور پر، فراہمی ہے، وہاں تعیناتی ہے۔ پروویژننگ میرا انفراسٹرکچر بناتی ہے، تعیناتی میں ہم اسے کسی کارآمد چیز سے بھرتے ہیں، مثال کے طور پر، سرورز، ایپلی کیشنز وغیرہ۔ اور یہ بات میرے ذہن میں ہے کہ Terraform فراہمی کے لیے زیادہ ہے، اور Ansible تعیناتی کے لیے زیادہ ہے، کیونکہ Ansible فزیکل انفراسٹرکچر کے لیے بھی ہے۔ آپ کو nginx، Postgres انسٹال کرنے کی اجازت دیتا ہے۔ لیکن ایک ہی وقت میں، ایسا لگتا ہے کہ جوابی فراہمی کی اجازت دیتا ہے، مثال کے طور پر، ایمیزون یا گوگل کے وسائل۔ لیکن Terraform آپ کو اس کے ماڈیولز کا استعمال کرتے ہوئے کچھ سافٹ ویئر تعینات کرنے کی بھی اجازت دیتا ہے۔ آپ کے نقطہ نظر سے، کیا کوئی ایسی سرحد ہے جو Terraform اور Ansible کے درمیان چلتی ہے، کہاں اور کیا استعمال کرنا بہتر ہے؟ یا، مثال کے طور پر، کیا آپ کو لگتا ہے کہ Ansible پہلے سے ہی کچرا ہے، آپ کو ہر چیز کے لیے Terraform استعمال کرنے کی کوشش کرنی چاہیے؟

اچھا سوال، ویلری. مجھے یقین ہے کہ 2014 کے بعد سے Terraform مقصد کے لحاظ سے تبدیل نہیں ہوا ہے۔ یہ بنیادی ڈھانچے کے لئے بنایا گیا تھا اور بنیادی ڈھانچے کے لئے مر گیا تھا۔ ہمارے پاس ابھی بھی کنفیگریشن مینجمنٹ کی ضرورت تھی اور ہو گی۔ چیلنج یہ ہے کہ لانچ_کنفیگریشن کے اندر صارف کا ڈیٹا موجود ہے۔ اور وہاں آپ Ansible وغیرہ کو کھینچتے ہیں۔ یہ معیاری امتیاز ہے جو مجھے سب سے زیادہ پسند ہے۔

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

ہیلو! رپورٹ کے لیے شکریہ! میرا نام میشا ہے، آر بی ایس کمپنی۔ وسائل بناتے وقت آپ پروویژنر کے ذریعے جوابی کال کرسکتے ہیں۔ Ansible کا ایک موضوع بھی ہے جسے ڈائنامک انوینٹری کہتے ہیں۔ اور آپ پہلے Terraform کو کال کرسکتے ہیں، اور پھر Ansible کو کال کرسکتے ہیں، جو ریاست سے وسائل لے کر اس پر عمل درآمد کرے گا۔ کیا بہتر ہے؟

لوگ دونوں کو مساوی کامیابی کے ساتھ استعمال کرتے ہیں۔ مجھے ایسا لگتا ہے کہ Ansible میں متحرک انوینٹری ایک آسان چیز ہے، اگر ہم آٹو اسکیلنگ گروپ کے بارے میں بات نہیں کر رہے ہیں۔ کیونکہ آٹو اسکیلنگ گروپ میں ہمارے پاس پہلے سے ہی ہماری اپنی ٹول کٹ ہے، جسے لانچ_کنفیگریشن کہتے ہیں۔ لانچ_کنفیگریشن میں ہم ہر وہ چیز ریکارڈ کرتے ہیں جس کو لانچ کرنے کی ضرورت ہوتی ہے جب ہم نیا وسیلہ بناتے ہیں۔ لہذا، ایمیزون کے ساتھ، متحرک انوینٹری کا استعمال کرتے ہوئے اور Terraform ts فائل کو پڑھنا، میری رائے میں، حد سے زیادہ ہے۔ اور اگر آپ دوسرے ٹولز استعمال کرتے ہیں جہاں "آٹو اسکیلنگ گروپ" کا کوئی تصور نہیں ہے، مثال کے طور پر، آپ DigitalOcean یا کوئی اور فراہم کنندہ استعمال کرتے ہیں جہاں کوئی آٹو اسکیلنگ گروپ نہیں ہے، تو وہاں آپ کو دستی طور پر API کو کھینچنا ہوگا، IP ایڈریسز تلاش کرنا ہوں گے، تخلیق کرنا ہوں گے۔ ایک متحرک انوینٹری فائل، اور Ansible پہلے ہی اس کے ذریعے گھومے گی۔ یعنی، ایمیزون کے لیے لانچ_کنفیگریشن ہے، اور باقی ہر چیز کے لیے ڈائنامک انوینٹری ہے۔

ماخذ: www.habr.com