ماخذ: 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 فائل)
یہ اچھا ہے۔ جب انوائرنمنٹ کے درمیان تبدیلیوں کی آرکاسٹریشن کی کوئی ضرورت نہ ہو
یہ اچھا ہے۔ جب انفراسٹرکچر ریسورس ہرانوائرنمنٹ کے لیے مختلف مقصد پر ہوں اور انہیں عام نہیں بنایا جا سکتا (مثلاً، کچھ ریسورس ایک انوائرنمنٹ میں یا کچھ regions میں موجود نہیں ہیں)
جیسے جیسے پروجیکٹ بڑھتا ہے، ان انوائرنمنٹ کو ایک دوسرے کے ساتھ up-to-date رکھنا مشکل تر ہوتا جائے گا۔ دہرائے جانے والے کاموں کے لیے انفراسٹرکچر ماڈلز (آف دی شیلف یا اندرونی) استعمال کرنے پر غور کریں۔
چند وسائل، کوئی بیرونی انحصار نہیں۔ واحد AWS اکاؤنٹ۔ واحد علاقہ۔ واحد انوائرنمنٹ۔
ہاں
بہت سے AWS اکاؤنٹس اور بہت سے انوائرنمنٹ، ٹیرافارم کا استعمال کرتے ہوئے آف دی شیلف انفراسٹرکچر ماڈیولز
ہاں
بہت سے AWS اکاؤنٹس، بہت سے علاقے، کاپی پیسٹ کم کرنے کی فوری ضرورت، حسب ضرورت انفراسٹرکچر ماڈیولز، کمپوزیشن کا بھاری استعمال۔ ٹیرافارم کا استعمال۔
زیر تکمیل
بہت بڑا
"مختلف Provider (AWS، GCP، Azure)۔ متعدد کلاؤڈ کی انجام دہی۔ ٹیرا فارم کا استعمال کیا جاتا ہے۔"
نہیں
درمیانہ
"مختلف AWS اکاؤنٹس اور انوائرنمنٹ، آف دی شیلف زیرِ بنائی انوائرنمنٹ ماڈیولز، ٹیراگرنٹ کا استعمال کرتے ہوئے ترتیب کا نمونہ۔"
نہیں
بڑا
بہت سے AWS اکاؤنٹس، بہت سے علاقے، کاپی پیسٹ کم کرنے کی فوری ضرورت، حسب ضرورت انفراسٹرکچر ماڈیولز، کمپوزیشن کا بھاری استعمال۔ Terragrunt ٹیراگرنٹ کا استعمال
نہیں
بہت بڑا
متعدد Provider (AWS، GCP، Azure)۔ ملٹی کلاؤڈ تعیناتیاں۔ Terragrunt ٹیراگرنٹ کا استعمال۔
نہیں
ماخذ: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/small-terraform
اس مثال میں وہ کوڈ شامل ہے جو ایک چھوٹے سائز کی ٹیرا فارم کنفیگریشن کی ساخت کی مثال کے طور پر دیا گیا ہے، جہاں کوئی بیرونی دپندنکئیس dependencies
استعمال نہیں کیا گیا ہے۔
شروع کرنے اور جیسے جیسے آپ آگے بڑھیں ترمیم کرنے کے لیے بہترین ہے۔
چھوٹے پیمانے کے انفراسٹرکچر کے ماڈیولز کے لیے بہترین ہے۔
چھوٹے اور لکیری انفراسٹرکچر ماڈیولز کے لیے اچھا ہے (مثال کے طور پر، terraform-aws-atlantis)
چھوٹی تعداد میں resources کے لیے اچھا ہے (20-30 سے کم)
تمام ریسورسز کے لئے ایک state فائل ٹیرافارم Terraform سے کام کرنے کے طریقے کو دھیما بنا سکتا ہ اگر ریسورسز کی تعداد بڑھ رہی ہو ( ریسورسز کی تعداد کو محدود کرنے کے لئے ایک ارغومنٹ -target کا استعمال کرنے کو مد نظر میں رکھیں)
ماخذ: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 رکھنا مشکل تر ہوتا جائے گا۔ دہرائے جانے والے کاموں کے لیے انفراسٹرکچر ماڈلز (آف دی شیلف یا اندرونی) استعمال کرنے پر غور کریں۔