# ٹیرافارم (Terraform) کے ساتھ بڑے سائز کا انفراسٹرکچر

**ماخذ:**<https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/large-terraform>

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

* 2 AWS اکاؤنٹس
* 2 ریجن
* 2 الگ انوائرنمنٹ (prod اور stage جو کچھ بھی شیئر نہیں کرتے)۔ ہر انوائرنمنٹ ایک الگ AWS اکاؤنٹ میں رہتا ہے اور 2 ریجن کے درمیان ریسورس کا احاطہ کرتا ہے
* ہر انوائرنمنٹ [Terraform Registry](https://registry.terraform.io/) سے ماخوذ آف دی شیلف انفراسٹرکچر ماڈل (`alb`) کے مختلف ورژن کا استعمال کرتا ہے۔
* ہر انوائرنمنٹ `modules/network` کے ایک ہی ورژن کے اندرونی ماڈل کا استعمال کرتا ہے کیونکہ یہ `local` **ڈائرکٹری سے ماخوذ ہے۔**

  <br>

{% hint style="info" %}
اس طرح کے بڑے پراجیکٹ میں Terragrunt کا استعمال کرنے کے فوائد واضح دکھتے ہیں۔[ تراگنٹ کے ساتھ کوڈ سکریپچر کے مثال دیکھیں۔](https://www.terraform-best-practices.com/ur/examples/terragrunt)
{% endhint %}

{% hint style="success" %}

* &#x20;ان پروجیکٹس کے لئے مثالی ہیں جہاں بنیادی طور پر ریسورس معلومات کو الگ کیا گیا ہے (الگ AWS اکاؤنٹس)
* یہ اچھا ہے جب الگ الگ AWS اکاؤنٹس کے درمیان آپس میں تبدیلی کی ضرورت نہ ہوتی ہے (ایک انوائرنمنٹ = ایک AWS اکاؤنٹ = ایک اسٹیٹ فائل)
* یہ اچھا ہے جب انوائرنمنٹ **کے درمیان تبدیلیوں کی ضرورت نہ ہوتی ہے**
* اچھا جب انفراسٹرکچر ریسورس ہر انوائرنمنٹ کے لیے مقصد پر مختلف ہوں اور انہیں عام نہیں بنایا جا سکتا (مثلاً، کچھ ریسورس ایک انوائرنمنٹ میں یا کچھ regions **میں موجود نہیں ہیں)**
  {% endhint %}

{% hint style="warning" %}
انوائرنمنٹ کو ایک دوسرے کے ساتھ up-to-date رکھنا مشکل تر ہوتا جائے گا۔ دہرائے جانے والے کاموں کے لیے انفراسٹرکچر ماڈلز (آف دی شیلف یا اندرونی) استعمال کرنے پر غور کریں۔
{% endhint %}