Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
ٹیرافارم کوڈ کی ساخت سے متعلق سوالات کمیونٹی میں اب تک سب سے زیادہ آتے ہیں۔ ہر کوئی کسی نہ کسی نقطہ پر پروجیکٹ کے لئے بہترین کوڈ کی ساخت کے بارے میں سوچتا ہے۔
یہ ان سوالات میں سے ایک ہے جہاں بہت سارے حل موجود ہیں اور عالمی مشورہ دینا بہت مشکل ہے، اس لیے آئیے اس سے شروع کریں کہ ہم کیا کر رہے ہیں۔
آپ کے پروجیکٹ کی پیچیدگی کیا ہے؟
متعلقہ ریسورسز کی تعداد
ٹیرافارم 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.tfvars
کے علاوہ کہیں بھی استعمال نہیں کیا جانا چاہئے۔ composition.
براہ کرم یقینی بنائیں کہ آپ کلیدی تصورات - ریسورس ماڈیول، انفراسٹرکچر ماڈیول اور کمپوزیشن کو سمجھتے ہیں، کیونکہ وہ مندرجہ ذیل مثالوں میں استعمال ہوتے ہیں۔
چھوٹے ریسورس کے ساتھ کام کرنا آسان اور تیز ہے
کمانڈ 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 کو فعال طور پر استعمال کیا جاتا ہے۔
کبھی کبھی یہ 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" کو "آف دی شیلف انفراسٹرکچر ماڈل" کے طور پر ترجمہ کیا ہے کیونکہ یہ اصطلاح اردو میں زیادہ عام ہے۔
ان منصوبوں کے لیے بہترین انفراسٹرکچر منطقی طور پر الگ کیا گیا ہے (الگ AWS اکاؤنٹس)
یہ اچھا ہے۔جب AWS اکاؤنٹس کے درمیان شیئر کیے جانے والے ریسورس کو تبدیل کرنے کی کوئی ضرورت نہ ہو (ایک انوائرنمنٹ = ایک AWS اکاؤنٹ = ایک state فائل)