Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
چند وسائل، کوئی بیرونی انحصار نہیں۔ واحد AWS اکاؤنٹ۔ واحد علاقہ۔ واحد انوائرنمنٹ۔
ہاں
بہت سے AWS اکاؤنٹس اور بہت سے انوائرنمنٹ، ٹیرافارم کا استعمال کرتے ہوئے آف دی شیلف انفراسٹرکچر ماڈیولز
ہاں
بہت سے AWS اکاؤنٹس، بہت سے علاقے، کاپی پیسٹ کم کرنے کی فوری ضرورت، حسب ضرورت انفراسٹرکچر ماڈیولز، کمپوزیشن کا بھاری استعمال۔ ٹیرافارم کا استعمال۔
زیر تکمیل
بہت بڑا
"مختلف Provider (AWS، GCP، Azure)۔ متعدد کلاؤڈ کی انجام دہی۔ ٹیرا فارم کا استعمال کیا جاتا ہے۔"
نہیں
درمیانہ
"مختلف AWS اکاؤنٹس اور انوائرنمنٹ، آف دی شیلف زیرِ بنائی انوائرنمنٹ ماڈیولز، ٹیراگرنٹ کا استعمال کرتے ہوئے ترتیب کا نمونہ۔"
نہیں
بڑا
بہت سے AWS اکاؤنٹس، بہت سے علاقے، کاپی پیسٹ کم کرنے کی فوری ضرورت، حسب ضرورت انفراسٹرکچر ماڈیولز، کمپوزیشن کا بھاری استعمال۔ Terragrunt ٹیراگرنٹ کا استعمال
نہیں
بہت بڑا
متعدد Provider (AWS، GCP، Azure)۔ ملٹی کلاؤڈ تعیناتیاں۔ Terragrunt ٹیراگرنٹ کا استعمال۔
نہیں
ٹیرافارم کوڈ کی ساخت سے متعلق سوالات کمیونٹی میں اب تک سب سے زیادہ آتے ہیں۔ ہر کوئی کسی نہ کسی نقطہ پر پروجیکٹ کے لئے بہترین کوڈ کی ساخت کے بارے میں سوچتا ہے۔
یہ ان سوالات میں سے ایک ہے جہاں بہت سارے حل موجود ہیں اور عالمی مشورہ دینا بہت مشکل ہے، اس لیے آئیے اس سے شروع کریں کہ ہم کیا کر رہے ہیں۔
آپ کے پروجیکٹ کی پیچیدگی کیا ہے؟
متعلقہ ریسورسز کی تعداد
ٹیرافارم providers کی تعداد (نیچے "logical providers" کے بارے میں نوٹ دیکھیں)
آپ کا انفراسٹرکچر کتنا اور کب تبدیل ہوتا ہے؟
ایک مہینے/ہفتے/دن میں ایک بار سے
مسلسل (ہر بار جب ایک نیا کمٹ commitہوتا ہے)
کوڈ کی تبدیلی کے آغاز کنندگان؟ کیا آپ CI سرور کو ایک نیا آرٹی فیکٹ بنائے جانے پر repository کو اپ ڈیٹ کرنے دیتے ہیں؟
صرف ڈویلپرز انفراسٹرکچر repository میں پش کر سکتے ہیں
ہر کوئی PR کھول کر کسی بھی چیز میں تبدیلی کی تجویز پیش کر سکتا ہے (CI سرور پر چلنے والے خودکار کردہ کاموں سمیت)
آپ کس ڈپلائیمنٹ پلیٹ فارم یا ڈپلائیمنٹ سروس کا استعمال کرتے ہیں؟
ان چیزوں AWS CodeDeploy، Kubernetes، یا OpenShift کو تھوڑا مختلف طریقہ کار کی ضرورت ہے
انوائرنمنٹ environments کیسے گروپ کیے جاتے ہیں؟
انوائرنمنٹ environments، علاقے، پروجیکٹ کے لحاظ سے
جب آپ شروع کر رہے ہوں یا مثال کا کوڈ لکھ رہے ہوں تو تمام کوڈ main.tf میں رکھنا ایک اچھا خیال ہے۔ تمام دوسرے معاملات میں آپ کے پاس منطقی طور پر اس طرح سے تقسیم کی گئی کئی فائلیں ہونگی:
main.tf
- تمام ریسورسز بنانے کے لیے ماڈیولز، لوکلز اور ڈیٹا سورکس کو کال کریں۔ main.tf
variables.tf
- میں استعمال ہونے والے وہرہبلیس کے اعلانات پر مشتمل ہے۔ main.tf
outputs.tf
-میں بنائے گئے ریسورسز سے آؤٹ پٹ پر مشتمل ہے۔ main.tf
versions.tf
- کے لیے ورژن کی ضروریات پر مشتمل ہے۔ Terraform اور providers
چھوٹے ریسورس کے ساتھ کام کرنا آسان اور تیز ہے
کمانڈ terraform plan
اور terraform apply
دونوں ہی ریسورس کی حیثیت کو تصدیق کرنے کے لیے کلاؤڈ API کالز کرتے ہیں
اگر آپ کا پورا انفراسٹرکچر ایک ہی کمپوزیشن میں ہے تو اس میں کچھ وقت لگ سکتا ہے
کم ریسورس کے ساتھ بلاسٹ رداس (سیکیورٹی کی خلاف ورزی کی صورت میں) چھوٹا ہوتا ہے
الگ الگ کمپوزیشن میں رکھ کر غیر متعلق ریسورس کو ایک دوسرے سے الگ تھلگ کرنا اگر کچھ غلط ہوتا ہے تو اس سے خطرہ کم کرتا ہے۔
اپنا پراجیکٹ ریموٹ سٹیٹ استعمال کرکے شروع کریں کیونکہ:
آپ کا لیپ ٹاپ آپ کے انفراسٹرکچر کے کوڈکے لیے کوئی مقام نہیں ہے۔
فائلtfstate
کو gitمیں رکھنا نہ مناسب ہے
بعد میں جب انفراسٹرکچر کی تہیں متعدد سمتوں (انحصار یا ریسورس کی تعداد) میں بڑھنا شروع ہو جائیں تو چیزوں کو قابو میں رکھنا آسان ہو گا
پروسیجرول کوڈ کی طرح، Terraform کوڈ کو پہلے لوگوں کو پڑھنے کے لیے لکھا جانا چاہیے، مستقل مزاجی مدد کرے گی جب چھ ماہ بعد تبدیلیاں ہوں۔
Terraform اسٹیٹ فائل میں ریسورس کو منتقل کرنا ممکن ہے لیکن اگر آپ کے پاس مستقل ساخت اور نامزدگی کا طریقہ نہ ہو تو یہ کرنا مشکل ہو سکتا ہے۔
ماڈیولزresource کو جتنا ممکن ہو سادہ رکھیں۔
ان values کو ہارڈکوڈ نہ کریں جو variables کے طور پر پاس کی جا سکیں یا ڈیٹا sources کا استعمال کرتے ہوئے دریافت کی جا سکیں۔
کمپوزیشن کے اندر انفراسٹرکچر ماڈیولز کے درمیان گلو کے طور پر خاص طور پر ڈیٹا ذرائع اور terraform_remote_state
استعمال کریں۔
اس کتاب میں، مثال کے طور پر منصوبوں کو پیچیدگی کے لحاظ سے گروپ کیا گیا ہے - چھوٹے سے لے کر بہت بڑے انفراسٹرکچر تک۔ یہ علیحدگی سخت نہیں ہے، اس لیے دوسری ساختوں کو بھی چیک کریں۔
چھوٹی انفراسٹرکچر کا مطلب ہے کہ انحصار کی تعداد کم ہے اور ریسورس کم ہیں۔ جیسے جیسے پروجیکٹ بڑھتا ہے،ٹیرافارم Terraform کنفیگریشنز کی سلسلہ وار تخلیق کی ضرورت، مختلف انفراسٹرکچر ماڈیولز کو جوڑنا، اور کمپوزیشن کے اندر اقدار پاس کرنا واضح ہو جاتا ہے۔
ڈویلپرز کی طرف سے استعمال ہونے والے آرکسٹریشن حل کرنے کم از کم 5 مختلف گروپس ہیں:
ڈویلپرز کو کام کرنے کے لیے صرف Terraform جاننے کی ضرورت ہے .Terraform only
خالص آرکسٹریشن ٹول جسے پوری انفراسٹرکچر کو منظم کرنے اور انحصار کو سنبھالنے کے لیے.Terragrunt استعمال کیا جا سکتا ہے۔ Terragrunt انفراسٹرکچر ماڈیولز اور کمپوزیشن کے ساتھ نیٹیو طور پر کام کرتا ہے، اس لیے یہ کوڈ کی نقل کو کم کرتا ہے
In-house scripts. اکثر یہ آرکسٹریشن کی طرف ایک نقطہ آغاز کے طور پر ہوتا ہے اوردریافت کرنے سے پہلے ہوتا ہے۔
جب Terraform کو Ansible کے بعد اپنایا جاتا ہے، یا جب Ansible UI کو فعال طور پر استعمال کیا جاتا ہے۔
اس بات کو مدنظر رکھتے ہوئے، یہ کتاب ان دو Terraform اور Terragruntمنصوبہ کی ساختوں کا جائزہ لیتی ہ
اگلے باب میں Terraform یا Terragrunt کے لیے کوڈ کی ساختوں کی مثالیں دیکھیں۔
ماخذ:
یہ مثال ایک میڈیم سائز کے انفراسٹرکچر کے لیے ٹیرافارم Terraform کنفیگریشنز کو ساخت دینے طور پر استعمال کرتا ہے:
2 AWS اکاؤنٹس
2 الگ انوائرنمنٹ (prod اور stage جو کچھ بھی شیئر نہیں کرتے)۔ ہر انوائرنمنٹ ایک الگ AWS اکاؤنٹ میں رہتا ہے
ہر انوائرنمنٹ سے ماخوذ آف دی شیلف انفراسٹرکچر ماڈل (alb
) کے مختلف ورژن کا استعمال کرتا ہے۔
ہر انوائرنمنٹ modules/network
کے ایک ہی ورژن کے اندرونی ماڈل کا استعمال کرتا ہے کیونکہ یہ local
ڈائرکٹری سے ماخوذ ہے۔
نوٹ: میں نے "off-the-shelf infrastructure module" کو "آف دی شیلف انفراسٹرکچر ماڈل" کے طور پر ترجمہ کیا ہے کیونکہ یہ اصطلاح اردو میں زیادہ عام ہے۔
ان منصوبوں کے لیے بہترین انفراسٹرکچر منطقی طور پر الگ کیا گیا ہے (الگ AWS اکاؤنٹس)
یہ اچھا ہے۔جب AWS اکاؤنٹس کے درمیان شیئر کیے جانے والے ریسورس کو تبدیل کرنے کی کوئی ضرورت نہ ہو (ایک انوائرنمنٹ = ایک AWS اکاؤنٹ = ایک state فائل)
یہ اچھا ہے۔ جب انوائرنمنٹ کے درمیان تبدیلیوں کی آرکاسٹریشن کی کوئی ضرورت نہ ہو
یہ اچھا ہے۔ جب انفراسٹرکچر ریسورس ہرانوائرنمنٹ کے لیے مختلف مقصد پر ہوں اور انہیں عام نہیں بنایا جا سکتا (مثلاً، کچھ ریسورس ایک انوائرنمنٹ میں یا کچھ regions میں موجود نہیں ہیں)
جیسے جیسے پروجیکٹ بڑھتا ہے، ان انوائرنمنٹ کو ایک دوسرے کے ساتھ up-to-date رکھنا مشکل تر ہوتا جائے گا۔ دہرائے جانے والے کاموں کے لیے انفراسٹرکچر ماڈلز (آف دی شیلف یا اندرونی) استعمال کرنے پر غور کریں۔
منطقی providers مکمل طور پر Terraform کی منطق کے اندر کام کرتے ہیں اور اکثر کسی دوسری خدمت سے تعامل نہیں کرتے، اس لیے ہم ان کی پیچیدگی O(1) کے طور پر سوچ سکتے ہیں۔ سب سے عام منطقی providers میں , , , , شامل ہیں۔
terraform.tfvars
کے علاوہ کہیں بھی استعمال نہیں کیا جانا چاہئے۔ .
براہ کرم یقینی بنائیں کہ آپ کلیدی تصورات - ، اور کو سمجھتے ہیں، کیونکہ وہ مندرجہ ذیل مثالوں میں استعمال ہوتے ہیں۔
مستقل ساخت اور کے طریقے کا مشق کریں:
کبھی کبھی یہ Kubernetes اور ecosystem نظام کو استعمال کرنے اور اپنے Terraform کنفیگریشنز کی مطلوبہ حالت کو حاصل کرنے کے لیے ایک reconciliation loop فیچر استعمال کرتا ہے۔ مزید معلومات کے لیے ویڈیو دیکھیں۔
ماخذ: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/small-terraform
اس مثال میں وہ کوڈ شامل ہے جو ایک چھوٹے سائز کی ٹیرا فارم کنفیگریشن کی ساخت کی مثال کے طور پر دیا گیا ہے، جہاں کوئی بیرونی دپندنکئیس dependencies
استعمال نہیں کیا گیا ہے۔
شروع کرنے اور جیسے جیسے آپ آگے بڑھیں ترمیم کرنے کے لیے بہترین ہے۔
چھوٹے پیمانے کے انفراسٹرکچر کے ماڈیولز کے لیے بہترین ہے۔
چھوٹے اور لکیری انفراسٹرکچر ماڈیولز کے لیے اچھا ہے (مثال کے طور پر، terraform-aws-atlantis)
چھوٹی تعداد میں resources کے لیے اچھا ہے (20-30 سے کم)
تمام ریسورسز کے لئے ایک state فائل ٹیرافارم Terraform سے کام کرنے کے طریقے کو دھیما بنا سکتا ہ اگر ریسورسز کی تعداد بڑھ رہی ہو ( ریسورسز کی تعداد کو محدود کرنے کے لئے ایک ارغومنٹ -target کا استعمال کرنے کو مد نظر میں رکھیں)
ٹیرافارم ماڈلز اور مثالیں میں فیچرز اور انہیں استعمال کرنے کے طریقے کی وضاحت کرنے والی دستاویزات ہونی چاہئیں۔
README.md فائلوں کے تمام لنکس مطلق ہونے چاہئیں تاکہ ٹیرافارم رجسٹری کی ویب سائٹ انہیں صحیح طریقے سے دکھا سکے۔
دستاویزات میں mermaid کے ساتھ بنائے گئے ڈایاگرام اور cloudcraft.co کے ساتھ بنائے گئے بلیو پرنٹس شامل ہو سکتے ہیں۔
ٹیرافارم پری-کمیٹ ہکس استعمال کریں تاکہ یہ یقینی بنایا جا سکے کہ کوڈ درست ہے، صحیح طریقے سے فارمیٹ کیا گیا ہے، اور خود بخود دستاویز کیا گیا ہے اس سے پہلے کہ اسے git میں پش کیا جائے اور انسانوں کے ذریعہ جائزہ لیا جائے۔
پری کمٹ ایک فریم ورک ہے جو کثیر زبانی پری کمٹ ہکس کو منظم اور برقرار رکھنے کے لیے استعمال ہوتا ہے۔ یہ پائتھن میں لکھا گیا ہے اور ایک طاقتور ٹول ہے جو کسی ڈویلپر کی مشین پر کوڈ کو git ریپوزٹری پر کمٹ کرنے سے پہلے خودکار طریقے سے کچھ کرنے کے لیے استعمال کیا جا سکتا ہے۔ عام طور پر، اسے linter اور کوڈ کو فارمیٹ کرنے کے لیے استعمال کیا جاتا ہے (سپورٹڈ hooks دیکھیں)۔
ٹیرافارم کنفیگریشنز کے ساتھ pre-commit
کا کوڈ فارمیٹ اور تصدیق کرنے کے ساتھ ساتھ دستاویزات کو اپ ڈیٹ کرنے کے لیے بھی استعمال کیا جا سکتا ہے۔
پری کمٹ ٹیرافارم کو چیک کریں تاکہ اس سے آگاہی حاصل کی جا سکے، اور موجودہ ریپوزٹریاں (مثلاً، terraform-aws-vpc) جہاں یہ پہلے ہی استعمال ہو رہی ہیں۔
ٹیرافارم کی دستاویزات ایک ایسا ٹول ہے جو ٹیرافارم ماڈلز سے مختلف آؤٹ پٹ فارمیٹس میں دستاویزات تیار کرتا ہے۔ آپ اسے دستی طور پر (pre-commit hooks کے بغیر) چلا سکتے ہیں، یا pre-commit-terraform hooks کے ساتھ استعمال کر سکتے ہیں تاکہ دستاویزات خود بخود اپ ڈیٹ ہو جائیں۔
@todo: release, GH actions ,دستاویز کے ماڈیول ورژن
کم از کم ان کنونشنز پر عمل نہ کرنے کی کوئی وجہ نہیں ہونی چاہیے۔
یہ احتیاط کریں کہ حقیقی کلاؤڈ ریسورس کو مخصوص ناموں میں پابندیوں کی عادت ہوتی ہے۔ کچھ ریسورس میں ڈیشز شامل نہیں ہوسکتے ہیں، کچھ کو کیمل کیس کی ضرورت ہوتی ہے۔ اس کتاب میں روایات ٹیرافارم ناموں کو اشارہ کرتی ہیں۔
ہر جگہ - (ڈیش) کی بجائے _ (انڈرسکور) کا استعمال کریں (ریسورس کے ناموں، ڈیٹا سورس کے ناموں، وہرہبلیس کے ناموں، 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 فہرست ہے تو جمع کا نام استعمال کریں۔
ماخذ:https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/large-terraform
یہ مثال ایک بڑے سائز کے انفراسٹرکچر کے لیے ٹیرافارم کنفیگریشنز کو ساخت دینے کی طور پر استعمال کرتا ہے
2 AWS اکاؤنٹس
2 ریجن
2 الگ انوائرنمنٹ (prod اور stage جو کچھ بھی شیئر نہیں کرتے)۔ ہر انوائرنمنٹ ایک الگ AWS اکاؤنٹ میں رہتا ہے اور 2 ریجن کے درمیان ریسورس کا احاطہ کرتا ہے
ہر انوائرنمنٹ Terraform Registry سے ماخوذ آف دی شیلف انفراسٹرکچر ماڈل (alb
) کے مختلف ورژن کا استعمال کرتا ہے۔
ہر انوائرنمنٹ modules/network
کے ایک ہی ورژن کے اندرونی ماڈل کا استعمال کرتا ہے کیونکہ یہ local
ڈائرکٹری سے ماخوذ ہے۔
اس طرح کے بڑے پراجیکٹ میں Terragrunt کا استعمال کرنے کے فوائد واضح دکھتے ہیں۔ تراگنٹ کے ساتھ کوڈ سکریپچر کے مثال دیکھیں۔
ان پروجیکٹس کے لئے مثالی ہیں جہاں بنیادی طور پر ریسورس معلومات کو الگ کیا گیا ہے (الگ AWS اکاؤنٹس)
یہ اچھا ہے جب الگ الگ AWS اکاؤنٹس کے درمیان آپس میں تبدیلی کی ضرورت نہ ہوتی ہے (ایک انوائرنمنٹ = ایک AWS اکاؤنٹ = ایک اسٹیٹ فائل)
یہ اچھا ہے جب انوائرنمنٹ کے درمیان تبدیلیوں کی ضرورت نہ ہوتی ہے
اچھا جب انفراسٹرکچر ریسورس ہر انوائرنمنٹ کے لیے مقصد پر مختلف ہوں اور انہیں عام نہیں بنایا جا سکتا (مثلاً، کچھ ریسورس ایک انوائرنمنٹ میں یا کچھ regions میں موجود نہیں ہیں)
انوائرنمنٹ کو ایک دوسرے کے ساتھ up-to-date رکھنا مشکل تر ہوتا جائے گا۔ دہرائے جانے والے کاموں کے لیے انفراسٹرکچر ماڈلز (آف دی شیلف یا اندرونی) استعمال کرنے پر غور کریں۔
(عام ٹیرافارم مسائل)
Terragrunt - آرکیسٹریشن ٹول
tflint - کوڈ لنٹر
tfenv - ورژن منیجر
Atlantis - پل پریس کی آٹومیشن
pre-commit-terraform - ٹیرافارم کی ساتھ استعمال کرنے والے پری-کمٹ فریم ورک کے لئے گٹ ہکس کا مجموعہ
Infracost - پل کی درخواستوں میں ٹیرافارم کے لیے کلاؤڈ لاگت کا تخمینہ۔ ٹیراگرنٹ، اٹلانٹس اور پری کمٹ ٹیرافارم کے ساتھ بھی کام کرتا ہے۔
مواد اور زیریں ماڈیول کی ورژنز کو وضاحت سے ذکر کرنا چاہئیں۔ Providers کو ماڈیول کے باہر تشکیل دینا چاہئیں، مگر صرف ترتیب میں providers اور ٹیرا فارم کی ورژنز کو بھی بند کرسکتے ہیں۔
کوئی ماسٹر ڈیپنڈنسی منجمنٹ ٹول نہیں ہے۔، مگر انحصار کو کم پریشانی والی بنانے کے لئے کچھ مشورے ہیں۔ مثال کے طور پر، Dependabot کو ڈیپنڈنسی اپ ڈیٹس کو خود بخود کرنے کے لئے استعمال کیا جا سکتا ہے۔ Dependabot آپ کی ڈیپنڈنسیوں کو محفوظ اور up-to-date رکھنے کے لئے pull requests کھولتا ہے۔ Dependabot ٹیرا فارم کنفیگریشن کو بھی معاونیت پہنچاتا ہے۔
ٹیرافارم (Terraform) کی دستاویزات تمام پہلوؤں کو تفصیل سے بیان کرتی ہیں۔ اس سیکشن کے باقی حصوں کو سمجھنے کے لیے اسے غور سے پڑھیں۔
یہ سیکشن ان اہم بنیادی خیالات کی وضاحت کرتا ہے جو کتاب میں استعمال کیے جاتے ہیں
ریسورس (Resource) aws_vpc
, aws_db_instance
وغیرہ ہوتے ہیں۔ ایک ریسورس کسی provider سے تعلق رکھتا ہے، arguments قبول کرتا ہے، خصوصیات آؤٹ پٹ(outputs) کرتا ہے، اور اس کا ایک lifecycle ہوتا ہے۔ ایک ریسورس کو بنایا، حاصل کیا، اپ ڈیٹ کیا اور ختم کیا جا سکتاہے
ریسورس کے ماڈیول( Resource module) منسلک ریسورسز Resources
کا ایک مجموعہ ہوتاہے جو مل کر مشترکہ کارروائی انجام دیتے ہیں (مثال کے طور پر، AWS VPC Terraform module VPC، subnets ، NAT gateway وغیرہ بناتا ہے)۔ یہ provider کی ترتیب پر منحصر ہے، جس کی وضاحت اس میں کی جا سکتی ہے، یا اعلیٰ سطح کے ڈھانچے میں (مثال کے طور پر، انفراسٹرکچر (module) میں)
ایک انفراسٹرکچر ماڈیول، ریسورس ماڈیولز کا ایک مجموعہ ہے، جو منطقی طور پر منسلک نہیں ہو سکتے، لیکن موجودہ صورتحال/پروجیکٹ/سیٹ اپ میں ایک ہی مقصد پورا کرتے ہیں۔ یہ provider کے لیے ترتیب کو متعین کرتا ہے، جو ڈاون اسٹریم ریسورس ماڈیولز اور ریسورس کو پاس کر دیا جاتا ہے۔ یہ عام طور پر ایک منطقی سیپریٹر (مثال کے طور پر، AWS Region, Google Project) کے ساتھ کام کرنے کے لیے محدود ہوتا ہے۔
مثال کے طور پر، terraform-aws-atlantis ماڈیول میں terraform-aws-vpc اور terraform-aws-security- group جیسے ریسورس ماڈیولز استعمال ہوتے ہیں تاکہ AWS Fargate پر Atlantis کو چلانے کے لئے ضروری انفراسٹرکچر کو بنایا جا سکے۔
دوسری مثال terraform-aws-cloudquery ماڈیول کی ہے جہاں terraform-aws-modules کی طرف سے مختلف ماڈیولز کا اشتراک ہوتا ہے تاکہ انفراسٹرکچر کو منظم کیا جا سکے اور Docker کے ریسورس کا استعمال کیا جا سکتا ہے تاکہ ایک ہی سیٹ میں images Docker کو تخلیق، منتقلی، اور تنصیب کیا جا سکے ۔
ترکیب انفراسٹرکچر ماڈیولز کا ایک مجموعہ ہے، جو کئی منطقی طور پر الگ علاقوں (مثال کے طور پر،Regions AWS ، متعدد AWS اکاؤنٹس) میں پھیلا ہو سکتا ہے۔ ترکیب کو پوری تنظیم یا پروجیکٹ کے لیے درکار مکمل انفراسٹرکچر کی وضاحت کے لیے استعمال کیا جاتا ہے۔
ترکیب میں انفراسٹرکچر ماڈیولز ہوتے ہیں، جن میں ریسورس ماڈیولز ہوتے ہیں، جو انفرادی ریسورس کو بناتے ہیں۔
ڈیٹا سورس (Data source) ایک ریڈ-اونلی read-only
آپریشن انجام دیتا ہے اور provider کی ترتیب پر منحصر ہے، یہ ایک ریسورس ماڈیول اور ایک انفراسٹرکچر ماڈیول میں استعمال ہوتاہے۔
ڈیٹا سورس terraform_remote_state
اعلیٰ سطحی ماڈیولز اور ترکیبوں کے لیے گلو کے طور پر کام کرتا ہے۔
بیرونی ڈیٹا کسی بیرونی پروگرام کو ڈیٹا سورس کے طور پر کام کرنے کی اجازت دیتا ہے، جو ٹیرافارم Terraform ترتیب میں کہیں اور استعمال کے لیے غیر معمولی ڈیٹا کو بے نقاب کرتا ہے۔ terraform-aws-lambda ماڈیول سے ایک مثال یہاں ہے جہاں فائل کا نام ایک بیرونی Python اسکرپٹ کو کال کرکے کمپیوٹ کیا جاتا ہے۔
ہتپ http ڈیٹا سورس دیئے گئے URL پر HTTP GET کی درخواست کرتا ہے اور ردعمل کے بارے میں معلومات حاصل کرتا ہے جو اکثر endpoints سے معلومات حاصل کرنے کے لیے مفید ہوتا ہے جہاں Terraform provider موجود نہیں ہوتا ہے۔
انفراسٹرکچر ماڈیولز اور ترتیبوں کو اپنی Terraform state کو ایک remote جگہ میں جمع رکھنی چاہئے جہاں دوسرے لوگوں کی طرف سے اسے ایک کنٹرول طریقے سے استعمال کیا جا سکتا ہے (مثلاً، specify ACL, versioning, logging)۔
پروودرس Providers، پرووسونیرس provisioners، اور کچھ دوسرے مصطلحات کو آفیشل دستاویز میں بہت اچھی طرح وضاحت کی گئی ہے اور یہاں پر اسے دہرانے کا کوئی موقع نہیں ہے۔ میرے خیال میں، ان کا زیادہ Terraform modules لکھنے سے کچھ تعلق نہیں ہے۔
انفرادی ریسورس بنیادی ڈھانچے میں ایٹموں کی طرح ہوتے ہیں، جب کہ ریسورس ماڈیولز مالیکیولز (ایٹموں پر مشتمل) ہوتے ہیں۔ ماڈیول سب سے چھوٹی ورژن والی اور شیئر کرنے والی اکائی ہے۔ اس میں دلائل کی ایک درست فہرست ہے، جو اس طرح کی اکائی کے لیے مطلوبہ کام کرنے کے لیے بنیادی منطق کو استعمال کرتی ہے۔ مثال کے طور پر، terraform-aws-security-group ماڈیول ان پٹ کی بنیاد پر aws_security_group
اور aws_security_group_rule
ریسورس بناتا ہے۔ یہ ریسورس ماڈیول انفراسٹرکچر ماڈیول بنانے کے لیے دیگر ماڈیولز کے ساتھ مل کر استعمال کیا جا سکتا ہے۔
مالیکیولز (ریسورس ماڈیولز اور انفراسٹرکچر ماڈیولز) میں ڈیٹا تک رسائی ماڈیولز کے آؤٹ پٹس اور data sources کا استعمال کرکے کی جاتی ہے۔
ترکیبات کے درمیان رسائی اکثر ریموٹ سٹیٹ data sources کا استعمال کرکے کی جاتی ہے۔ پیکجوں کے درمیان ڈیٹا شیئر کرنے کے کئی طریقے ہیں۔
اوپر بیان کردہ چیزوں کو pseudo-ریلیشنز کرنے میں رکھیں تو یہ کچھ اس طرح نظر آ سکتا ہے:
تیرا فارم Terraform کمیونٹی سے متعلق عظیم مواد بنانے اور اوپن سورس منصوبے کو منظم کرنے والے بہت سارے لوگ ہیں، لیکنمیں ان لنکس کو یہاں درج فہرستوں کو کاپی کیے بغیر حاصل کرنے کے لیے بہترین ڈھانچے کے بارے میں سوچ بھی نہیں سکتا
- تیرا فارم کے ساتھ بہت فعالیت کرنے والے اور آپ کو بہت کچھ بتا سکنے والے افراد کی فہرست (اگر آپ ان سے پوچھیں تو)۔
- ہاشیکورپ کے تیرا فارم پر مواد کی مرتب شدہ فہرست۔
- "آپ کی ہر ہفتہ کی تیرا فارم یوتوبے" ٹیوٹریم چینل آنٹن بابینکو کا۔ آنٹن بابینکو کے ساتھ لائیو اسٹریمز میں جائیں، Q&A، لائیو کوڈنگ، اور تیرا فارم کے ساتھ کچھ ہیکنگ۔
تیرا فارم ہفتہ وار نیوز لیٹر۔ تیرا فارم کی دنیا میں مختلف خبریں (منصوبے، اعلانات، بحث) Anton Babenko کے ذریعہ۔
یہ دستاویز ایک کوشش ہے کہ منظم طریقے سے ٹیرافارم (Terraform) کا استعمال کرتے ہوئے بہترین طریقوں کو بیان کیا جائے اور ٹیرافارم کے صارفین کو پیش آنے والے اکثر مسائل کے لیے سفارشات فراہم کی جائیں۔
ٹیرافارم () ایک طاقتور (اگرچہ اب تک کا سب سے طاقتورٹول نہیں ہے) اور سب سے زیادہ استعمال ہونے والے ٹولز میں سے ایک ہے جو انفراسٹرکچر کو کوڈ (infrastructure as code) کے طور پر منظم کرتا ہے۔ اور یہ ڈویلپرز کو بہت سے کام کرنے کی اجازت دیتا ہے . انہیں ایسی چیزوں کو کرنے سے نہیں روکتا جن کی حمایت یا انضمام کرنا مشکل ہو گا۔
میں یہ جانتا ہوں،اس کتاب میں بیان کردہ کچھ معلومات بہترین طریقوں کی طرح نہیں ہو سکتی ہیں۔ اور قارئین کو یہ الگ کرنے میں مدد کرنے کے لیے کہ کیا قائم کردہ بہترین طریقے ہیں اور کیا صرف چیزوں کو کرنے کا ایک اور طریقہ ہے، میں کبھی کبھی بہترین طریقوں سے متعلق ہر ذیلی سیکشن پر پختگی کی سطح کو واضح کرنے کے لیے اشارے اور آئیکون (icons) استعمال کرتا ہو ں۔
کتاب کی ابتدا 2018 میں اسپین کے خوبصورت شہر مدريد میں ہوئی تھی، اور یہ کتاب مفت میں یہاں سے ڈاؤن لوڈ کی جا سکتی ہے ۔ .
چند سالوں بعد، اس میں مزید حقیقی بہترین طریقوں کے ساتھ اپ ڈیٹ کیا گیا ہے جو ٹیرافارم (Terraform) 1.0 کے ساتھ دستیاب ہیں۔ آخر کار، یہ کتاب ٹیرافارم (Terraform) کے صارفین کے لئے ببہترین طریقوں اور تجویزات کا حامل ہونی چاہئے۔
Please if you want to become a sponsor.
میں ہمیشہ اس کتاب کے بارے میں ردعمل حاصل کرنا اور اسے اپ ڈیٹ کرنا چاہتا ہوں کیونکہ کمیونٹی بڑھتی ہے اور نئے خیالات کو نافذ کیا جاتا ہے اور وقت کے ساتھ ساتھ تصدیق کی جاتی ہے
یہ کام Apache 2 لائسنس کے تحت لائسنس یافتہ ہے۔ مکمل تفصیلات کے لیے LICENSE فائل دیکھیں۔\
اس مواد کے مصنفین اور شراکت دار یہاں پائی جانے والی معلومات کی صحت کی ضمانت نہیں دے سکتے۔ براہ کرم یقینی بنائیں کہ آپ سمجھتے ہیں کہ یہاں فراہم کردہ معلومات آزادانہ طور پر فراہم کی جا رہی ہے، اور آپ اور اس مواد یا منصوبے سے وابستہ کسی بھی شخص کے درمیان کسی بھی قسم کا معاہدہ یا کنٹریکٹ نہیں بنایا گیا ہے۔ مصنفین اور شراکت دار اس مواد میں موجود معلومات میں کسی غلطی یا کمی کی وجہ سے ہونے والے کسی نقصان، نقصان، یا خرابی کے لیے کسی فریق کے سامنے کوئی ذمہ داری نہیں لیتے ہیں، خواہ وہ غلطیاں یا کمیاں غفلت، حادثہ، یا کسی اور وجہ سے ہو ں۔ کاپی رائٹ © 2018-2023 Anton Babenko
اگر آپ اس کتاب کو دوسری زبانوں میں ترجمہ کرنے میں مدد کرنا چاہتے ہیں تو ۔
اگر آپ مخصوص موضوعات میں دلچسپی رکھتے ہیں، تو براہ کرم ایک مسئلہ کھولیں ()، یا اس مسئلے کو تھمبز اپ (thumb up) کریں جسے آپ شامل کرنا چاہتے ہیں۔ اگر آپ محسوس کرتے ہیں کہ آپ کے پاس مواد ہے اور آپ حصہ ڈالنا چاہتے ہیں، تو ایک مسودہ لکھیں اور ایک پل ریکویسٹ (pull request) جمع کروائیں (اس وقت اچھا متن لکھنے کے بارے میں فکر نہ کریں!)
اس کتاب کی دیکھ بھال کی طرف سے مختلف معاونین اور ترجمہ کاروں کی مدد سے کی جاتی ہے