Only this pageAll pages
Powered by GitBook
1 of 15

اردو (Urdu)

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

ٹیرافارم (Terraform)

بنیادی خیال

یہ سیکشن ان اہم بنیادی خیالات کی وضاحت کرتا ہے جو کتاب میں استعمال کیے جاتے ہیں

ریسورس (Resource)

ریسورس (Resource) aws_vpc, aws_db_instanceوغیرہ ہوتے ہیں۔ ایک ریسورس کسی provider سے تعلق رکھتا ہے، arguments قبول کرتا ہے، خصوصیات آؤٹ پٹ(outputs) کرتا ہے، اور اس کا ایک lifecycle ہوتا ہے۔ ایک ریسورس کو بنایا، حاصل کیا، اپ ڈیٹ کیا اور ختم کیا جا سکتاہے

ریسورس کے ماڈیول (Resource module)

انفراسٹرکچر ماڈیول (Infrastructure module)

ایک انفراسٹرکچر ماڈیول، ریسورس ماڈیولز کا ایک مجموعہ ہے، جو منطقی طور پر منسلک نہیں ہو سکتے، لیکن موجودہ صورتحال/پروجیکٹ/سیٹ اپ میں ایک ہی مقصد پورا کرتے ہیں۔ یہ provider کے لیے ترتیب کو متعین کرتا ہے، جو ڈاون اسٹریم ریسورس ماڈیولز اور ریسورس کو پاس کر دیا جاتا ہے۔ یہ عام طور پر ایک منطقی سیپریٹر (مثال کے طور پر، AWS Region, Google Project) کے ساتھ کام کرنے کے لیے محدود ہوتا ہے۔

ترکیب (Composition)

ترکیب انفراسٹرکچر ماڈیولز کا ایک مجموعہ ہے، جو کئی منطقی طور پر الگ علاقوں (مثال کے طور پر،Regions AWS ، متعدد AWS اکاؤنٹس) میں پھیلا ہو سکتا ہے۔ ترکیب کو پوری تنظیم یا پروجیکٹ کے لیے درکار مکمل انفراسٹرکچر کی وضاحت کے لیے استعمال کیا جاتا ہے۔

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

ڈیٹا سورس (Data source)

ڈیٹا سورس (Data source) ایک ریڈ-اونلی read-only آپریشن انجام دیتا ہے اور provider کی ترتیب پر منحصر ہے، یہ ایک ریسورس ماڈیول اور ایک انفراسٹرکچر ماڈیول میں استعمال ہوتاہے۔

ڈیٹا سورس terraform_remote_state اعلیٰ سطحی ماڈیولز اور ترکیبوں کے لیے گلو کے طور پر کام کرتا ہے۔

ریموٹ حالت (Remote state)

فراہم کنندہ، فراہم کرنے والا، وغیرہ (Provider, provisioner, etc)

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

یہ کیوں اتنا مشکل ہے؟ (?Why so difficult)

مالیکیولز (ریسورس ماڈیولز اور انفراسٹرکچر ماڈیولز) میں ڈیٹا تک رسائی ماڈیولز کے آؤٹ پٹس اور data sources کا استعمال کرکے کی جاتی ہے۔

اوپر بیان کردہ چیزوں کو pseudo-ریلیشنز کرنے میں رکھیں تو یہ کچھ اس طرح نظر آ سکتا ہے:

composition-1 {
  infrastructure-module-1 {
    data-source-1 => d1

    resource-module-1 {
      data-source-2 => d2
      resource-1 (d1, d2)
      resource-2 (d2)
    }

    resource-module-2 {
      data-source-3 => d3
      resource-3 (d1, d3)
      resource-4 (d3)
    }
  }
}

ٹیرافارم (Terraform) کی دستاویزات تمام پہلوؤں کو تفصیل سے بیان کرتی ہیں۔ اس سیکشن کے باقی حصوں کو سمجھنے کے لیے

ریسورس کے ماڈیول( Resource module) منسلک ریسورسز Resources کا ایک مجموعہ ہوتاہے جو مل کر مشترکہ کارروائی انجام دیتے ہیں (مثال کے طور پر، VPC، subnets ، NAT gateway وغیرہ بناتا ہے)۔ یہ provider کی ترتیب پر منحصر ہے، جس کی وضاحت اس میں کی جا سکتی ہے، یا اعلیٰ سطح کے ڈھانچے میں (مثال کے طور پر، انفراسٹرکچر (module) میں)

مثال کے طور پر، ماڈیول میں اور جیسے ریسورس ماڈیولز استعمال ہوتے ہیں تاکہ پر کو چلانے کے لئے ضروری انفراسٹرکچر کو بنایا جا سکے۔

دوسری مثال ماڈیول کی ہے جہاں کی طرف سے مختلف ماڈیولز کا اشتراک ہوتا ہے تاکہ انفراسٹرکچر کو منظم کیا جا سکے اور Docker کے ریسورس کا استعمال کیا جا سکتا ہے تاکہ ایک ہی سیٹ میں images Docker کو تخلیق، منتقلی، اور تنصیب کیا جا سکے ۔

کسی بیرونی پروگرام کو ڈیٹا سورس کے طور پر کام کرنے کی اجازت دیتا ہے، جو ٹیرافارم Terraform ترتیب میں کہیں اور استعمال کے لیے غیر معمولی ڈیٹا کو بے نقاب کرتا ہے۔ ماڈیول سے ایک مثال یہاں ہے جہاں فائل کا نام ایک بیرونی Python اسکرپٹ کو کال کرکے کمپیوٹ کیا جاتا ہے۔

ہتپ ڈیٹا سورس دیئے گئے URL پر HTTP GET کی درخواست کرتا ہے اور ردعمل کے بارے میں معلومات حاصل کرتا ہے جو اکثر endpoints سے معلومات حاصل کرنے کے لیے مفید ہوتا ہے جہاں Terraform provider موجود نہیں ہوتا ہے۔

انفراسٹرکچر ماڈیولز اور ترتیبوں کو اپنی کو ایک remote جگہ میں جمع رکھنی چاہئے جہاں دوسرے لوگوں کی طرف سے اسے ایک کنٹرول طریقے سے استعمال کیا جا سکتا ہے (مثلاً، specify ACL, versioning, logging)۔

انفرادی ریسورس بنیادی ڈھانچے میں ایٹموں کی طرح ہوتے ہیں، جب کہ ریسورس ماڈیولز مالیکیولز (ایٹموں پر مشتمل) ہوتے ہیں۔ ماڈیول سب سے چھوٹی ورژن والی اور شیئر کرنے والی اکائی ہے۔ اس میں دلائل کی ایک درست فہرست ہے، جو اس طرح کی اکائی کے لیے مطلوبہ کام کرنے کے لیے بنیادی منطق کو استعمال کرتی ہے۔ مثال کے طور پر، ماڈیول ان پٹ کی بنیاد پر aws_security_group اور aws_security_group_rule ریسورس بناتا ہے۔ یہ ریسورس ماڈیول انفراسٹرکچر ماڈیول بنانے کے لیے دیگر ماڈیولز کے ساتھ مل کر استعمال کیا جا سکتا ہے۔

ترکیبات کے درمیان رسائی اکثر ریموٹ سٹیٹ data sources کا استعمال کرکے کی جاتی ہے۔

اسے غور سے پڑھیں۔
AWS VPC Terraform module
terraform-aws-atlantis
terraform-aws-vpc
terraform-aws-security- group
AWS Fargate
Atlantis
terraform-aws-cloudquery
terraform-aws-modules
بیرونی ڈیٹا
terraform-aws-lambda
http
Terraform state
terraform-aws-security-group
پیکجوں کے درمیان ڈیٹا شیئر کرنے کے کئی طریقے ہیں۔

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

  • شروع کرنے اور جیسے جیسے آپ آگے بڑھیں ترمیم کرنے کے لیے بہترین ہے۔

  • چھوٹے پیمانے کے انفراسٹرکچر کے ماڈیولز کے لیے بہترین ہے۔

  • چھوٹی تعداد میں resources کے لیے اچھا ہے (20-30 سے کم)

تمام ریسورسز کے لئے ایک state فائل ٹیرافارم Terraform سے کام کرنے کے طریقے کو دھیما بنا سکتا ہ اگر ریسورسز کی تعداد بڑھ رہی ہو ( ریسورسز کی تعداد کو محدود کرنے کے لئے ایک ارغومنٹ -target کا استعمال کرنے کو مد نظر میں رکھیں)

کوڈ کی ساخت

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

مجھے اپنے ٹیرافارم Terraform کنفیگریشنز کو کیسے ترتیب دینا چاہیے؟

یہ ان سوالات میں سے ایک ہے جہاں بہت سارے حل موجود ہیں اور عالمی مشورہ دینا بہت مشکل ہے، اس لیے آئیے اس سے شروع کریں کہ ہم کیا کر رہے ہیں۔

  • آپ کے پروجیکٹ کی پیچیدگی کیا ہے؟

    • متعلقہ ریسورسز کی تعداد

    • ٹیرافارم providers کی تعداد (نیچے "logical providers" کے بارے میں نوٹ دیکھیں)

  • آپ کا انفراسٹرکچر کتنا اور کب تبدیل ہوتا ہے؟

    • ایک مہینے/ہفتے/دن میں ایک بار سے

    • مسلسل (ہر بار جب ایک نیا کمٹ commitہوتا ہے)

  • کوڈ کی تبدیلی کے آغاز کنندگان؟ کیا آپ CI سرور کو ایک نیا آرٹی فیکٹ بنائے جانے پر repository کو اپ ڈیٹ کرنے دیتے ہیں؟

    • صرف ڈویلپرز انفراسٹرکچر repository میں پش کر سکتے ہیں

    • ہر کوئی PR کھول کر کسی بھی چیز میں تبدیلی کی تجویز پیش کر سکتا ہے (CI سرور پر چلنے والے خودکار کردہ کاموں سمیت)

  • آپ کس ڈپلائیمنٹ پلیٹ فارم یا ڈپلائیمنٹ سروس کا استعمال کرتے ہیں؟

    • ان چیزوں AWS CodeDeploy، Kubernetes، یا OpenShift کو تھوڑا مختلف طریقہ کار کی ضرورت ہے

  • انوائرنمنٹ environments کیسے گروپ کیے جاتے ہیں؟

    • انوائرنمنٹ environments، علاقے، پروجیکٹ کے لحاظ سے

ٹیرافارم (Terraform) کنفیگریشنز کی ساخت کے ساتھ شروع کرنا

جب آپ شروع کر رہے ہوں یا مثال کا کوڈ لکھ رہے ہوں تو تمام کوڈ main.tf میں رکھنا ایک اچھا خیال ہے۔ تمام دوسرے معاملات میں آپ کے پاس منطقی طور پر اس طرح سے تقسیم کی گئی کئی فائلیں ہونگی:

  • main.tf - تمام ریسورسز بنانے کے لیے ماڈیولز، لوکلز اور ڈیٹا سورکس کو کال کریں۔ main.tf

  • variables.tf - میں استعمال ہونے والے وہرہبلیس کے اعلانات پر مشتمل ہے۔ main.tf

  • outputs.tf -میں بنائے گئے ریسورسز سے آؤٹ پٹ پر مشتمل ہے۔ main.tf

  • versions.tf - کے لیے ورژن کی ضروریات پر مشتمل ہے۔ Terraform اور providers

ٹیرافارم (Terraform) کنفیگریشن کی ساخت کے بارے میں کیسے سوچنا ہے؟

کوڈ کی ساخت کے لیے عام سفارشات

  • چھوٹے ریسورس کے ساتھ کام کرنا آسان اور تیز ہے

    • کمانڈ terraform plan اور terraform applyدونوں ہی ریسورس کی حیثیت کو تصدیق کرنے کے لیے کلاؤڈ API کالز کرتے ہیں

    • اگر آپ کا پورا انفراسٹرکچر ایک ہی کمپوزیشن میں ہے تو اس میں کچھ وقت لگ سکتا ہے

  • کم ریسورس کے ساتھ بلاسٹ رداس (سیکیورٹی کی خلاف ورزی کی صورت میں) چھوٹا ہوتا ہے

    • الگ الگ کمپوزیشن میں رکھ کر غیر متعلق ریسورس کو ایک دوسرے سے الگ تھلگ کرنا اگر کچھ غلط ہوتا ہے تو اس سے خطرہ کم کرتا ہے۔

  • اپنا پراجیکٹ ریموٹ سٹیٹ استعمال کرکے شروع کریں کیونکہ:

    • آپ کا لیپ ٹاپ آپ کے انفراسٹرکچر کے کوڈکے لیے کوئی مقام نہیں ہے۔

    • فائلtfstate کو gitمیں رکھنا نہ مناسب ہے

    • بعد میں جب انفراسٹرکچر کی تہیں متعدد سمتوں (انحصار یا ریسورس کی تعداد) میں بڑھنا شروع ہو جائیں تو چیزوں کو قابو میں رکھنا آسان ہو گا

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

    • Terraform اسٹیٹ فائل میں ریسورس کو منتقل کرنا ممکن ہے لیکن اگر آپ کے پاس مستقل ساخت اور نامزدگی کا طریقہ نہ ہو تو یہ کرنا مشکل ہو سکتا ہے۔

  • ماڈیولزresource کو جتنا ممکن ہو سادہ رکھیں۔

  • ان values کو ہارڈکوڈ نہ کریں جو variables کے طور پر پاس کی جا سکیں یا ڈیٹا sources کا استعمال کرتے ہوئے دریافت کی جا سکیں۔

  • کمپوزیشن کے اندر انفراسٹرکچر ماڈیولز کے درمیان گلو کے طور پر خاص طور پر ڈیٹا ذرائع اور terraform_remote_state استعمال کریں۔

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

انفراسٹرکچر ماڈیولز اور کمپوزیشن کی ترتیب

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

ڈویلپرز کی طرف سے استعمال ہونے والے آرکسٹریشن حل کرنے کم از کم 5 مختلف گروپس ہیں:

  1. ڈویلپرز کو کام کرنے کے لیے صرف Terraform جاننے کی ضرورت ہے .Terraform only

  2. خالص آرکسٹریشن ٹول جسے پوری انفراسٹرکچر کو منظم کرنے اور انحصار کو سنبھالنے کے لیے.Terragrunt استعمال کیا جا سکتا ہے۔ Terragrunt انفراسٹرکچر ماڈیولز اور کمپوزیشن کے ساتھ نیٹیو طور پر کام کرتا ہے، اس لیے یہ کوڈ کی نقل کو کم کرتا ہے

  3. In-house scripts. اکثر یہ آرکسٹریشن کی طرف ایک نقطہ آغاز کے طور پر ہوتا ہے اوردریافت کرنے سے پہلے ہوتا ہے۔

  4. جب Terraform کو Ansible کے بعد اپنایا جاتا ہے، یا جب Ansible UI کو فعال طور پر استعمال کیا جاتا ہے۔

اس بات کو مدنظر رکھتے ہوئے، یہ کتاب ان دو Terraform اور Terragruntمنصوبہ کی ساختوں کا جائزہ لیتی ہ

اگلے باب میں Terraform یا Terragrunt کے لیے کوڈ کی ساختوں کی مثالیں دیکھیں۔

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

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

  • 2 AWS اکاؤنٹس

  • 2 الگ انوائرنمنٹ (prod اور stage جو کچھ بھی شیئر نہیں کرتے)۔ ہر انوائرنمنٹ ایک الگ AWS اکاؤنٹ میں رہتا ہے

  • ہر انوائرنمنٹ modules/network کے ایک ہی ورژن کے اندرونی ماڈل کا استعمال کرتا ہے کیونکہ یہ local ڈائرکٹری سے ماخوذ ہے۔

نوٹ: میں نے "off-the-shelf infrastructure module" کو "آف دی شیلف انفراسٹرکچر ماڈل" کے طور پر ترجمہ کیا ہے کیونکہ یہ اصطلاح اردو میں زیادہ عام ہے۔

  • ان منصوبوں کے لیے بہترین انفراسٹرکچر منطقی طور پر الگ کیا گیا ہے (الگ AWS اکاؤنٹس)

  • یہ اچھا ہے۔جب AWS اکاؤنٹس کے درمیان شیئر کیے جانے والے ریسورس کو تبدیل کرنے کی کوئی ضرورت نہ ہو (ایک انوائرنمنٹ = ایک AWS اکاؤنٹ = ایک state فائل)

  • یہ اچھا ہے۔ جب انوائرنمنٹ کے درمیان تبدیلیوں کی آرکاسٹریشن کی کوئی ضرورت نہ ہو

  • یہ اچھا ہے۔ جب انفراسٹرکچر ریسورس ہرانوائرنمنٹ کے لیے مختلف مقصد پر ہوں اور انہیں عام نہیں بنایا جا سکتا (مثلاً، کچھ ریسورس ایک انوائرنمنٹ میں یا کچھ regions میں موجود نہیں ہیں)

جیسے جیسے پروجیکٹ بڑھتا ہے، ان انوائرنمنٹ کو ایک دوسرے کے ساتھ up-to-date رکھنا مشکل تر ہوتا جائے گا۔ دہرائے جانے والے کاموں کے لیے انفراسٹرکچر ماڈلز (آف دی شیلف یا اندرونی) استعمال کرنے پر غور کریں۔

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

چھوٹے اور لکیری انفراسٹرکچر ماڈیولز کے لیے اچھا ہے (مثال کے طور پر، )

منطقی providers مکمل طور پر Terraform کی منطق کے اندر کام کرتے ہیں اور اکثر کسی دوسری خدمت سے تعامل نہیں کرتے، اس لیے ہم ان کی پیچیدگی O(1) کے طور پر سوچ سکتے ہیں۔ سب سے عام منطقی providers میں , , , , شامل ہیں۔

terraform.tfvars کے علاوہ کہیں بھی استعمال نہیں کیا جانا چاہئے۔ .

براہ کرم یقینی بنائیں کہ آپ کلیدی تصورات - ، اور کو سمجھتے ہیں، کیونکہ وہ مندرجہ ذیل مثالوں میں استعمال ہوتے ہیں۔

مستقل ساخت اور کے طریقے کا مشق کریں:

کبھی کبھی یہ Kubernetes اور ecosystem نظام کو استعمال کرنے اور اپنے Terraform کنفیگریشنز کی مطلوبہ حالت کو حاصل کرنے کے لیے ایک reconciliation loop فیچر استعمال کرتا ہے۔ مزید معلومات کے لیے ویڈیو دیکھیں۔

ماخذ:

ہر انوائرنمنٹ سے ماخوذ آف دی شیلف انفراسٹرکچر ماڈل (alb) کے مختلف ورژن کا استعمال کرتا ہے۔

https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/small-terraform
terraform-aws-
atlantis
random
local
terraform
null
time
نامزدگی
Crossplane
Crossplane vs Terraform
https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/medium-terraform
Terraform Registry
composition
ریسورس ماڈیول
انفراسٹرکچر ماڈیول
کمپوزیشن

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

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

  • 2 AWS اکاؤنٹس

  • 2 ریجن

  • 2 الگ انوائرنمنٹ (prod اور stage جو کچھ بھی شیئر نہیں کرتے)۔ ہر انوائرنمنٹ ایک الگ AWS اکاؤنٹ میں رہتا ہے اور 2 ریجن کے درمیان ریسورس کا احاطہ کرتا ہے

  • ہر انوائرنمنٹ modules/network کے ایک ہی ورژن کے اندرونی ماڈل کا استعمال کرتا ہے کیونکہ یہ local ڈائرکٹری سے ماخوذ ہے۔

  • ان پروجیکٹس کے لئے مثالی ہیں جہاں بنیادی طور پر ریسورس معلومات کو الگ کیا گیا ہے (الگ AWS اکاؤنٹس)

  • یہ اچھا ہے جب الگ الگ AWS اکاؤنٹس کے درمیان آپس میں تبدیلی کی ضرورت نہ ہوتی ہے (ایک انوائرنمنٹ = ایک AWS اکاؤنٹ = ایک اسٹیٹ فائل)

  • یہ اچھا ہے جب انوائرنمنٹ کے درمیان تبدیلیوں کی ضرورت نہ ہوتی ہے

  • اچھا جب انفراسٹرکچر ریسورس ہر انوائرنمنٹ کے لیے مقصد پر مختلف ہوں اور انہیں عام نہیں بنایا جا سکتا (مثلاً، کچھ ریسورس ایک انوائرنمنٹ میں یا کچھ regions میں موجود نہیں ہیں)

انوائرنمنٹ کو ایک دوسرے کے ساتھ up-to-date رکھنا مشکل تر ہوتا جائے گا۔ دہرائے جانے والے کاموں کے لیے انفراسٹرکچر ماڈلز (آف دی شیلف یا اندرونی) استعمال کرنے پر غور کریں۔

ماخذ:

ہر انوائرنمنٹ سے ماخوذ آف دی شیلف انفراسٹرکچر ماڈل (alb) کے مختلف ورژن کا استعمال کرتا ہے۔

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

https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/large-terraform
Terraform Registry
تراگنٹ کے ساتھ کوڈ سکریپچر کے مثال دیکھیں۔

کُوڈ اسٹائلنگ

  • ٹیرافارم ماڈلز اور مثالیں میں فیچرز اور انہیں استعمال کرنے کے طریقے کی وضاحت کرنے والی دستاویزات ہونی چاہئیں۔

  • README.md فائلوں کے تمام لنکس مطلق ہونے چاہئیں تاکہ ٹیرافارم رجسٹری کی ویب سائٹ انہیں صحیح طریقے سے دکھا سکے۔

دستاویزات

خودکار طور پر تیار کردہ دستاویزات

ٹیرافارم کنفیگریشنز کے ساتھ pre-commit کا کوڈ فارمیٹ اور تصدیق کرنے کے ساتھ ساتھ دستاویزات کو اپ ڈیٹ کرنے کے لیے بھی استعمال کیا جا سکتا ہے۔

ٹیرافارم کی دستاویزات

@todo: release, GH actions ,دستاویز کے ماڈیول ورژن

حوالہ جات

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

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

ایک فریم ورک ہے جو کثیر زبانی پری کمٹ ہکس کو منظم اور برقرار رکھنے کے لیے استعمال ہوتا ہے۔ یہ پائتھن میں لکھا گیا ہے اور ایک طاقتور ٹول ہے جو کسی ڈویلپر کی مشین پر کوڈ کو git ریپوزٹری پر کمٹ کرنے سے پہلے خودکار طریقے سے کچھ کرنے کے لیے استعمال کیا جا سکتا ہے۔ عام طور پر، اسے linter اور کوڈ کو فارمیٹ کرنے کے لیے استعمال کیا جاتا ہے ( دیکھیں)۔

کو چیک کریں تاکہ اس سے آگاہی حاصل کی جا سکے، اور موجودہ ریپوزٹریاں (مثلاً، terraform-) جہاں یہ پہلے ہی استعمال ہو رہی ہیں۔

ایک ایسا ٹول ہے جو ٹیرافارم ماڈلز سے مختلف آؤٹ پٹ فارمیٹس میں دستاویزات تیار کرتا ہے۔ آپ اسے دستی طور پر (pre-commit hooks کے بغیر) چلا سکتے ہیں، یا کے ساتھ استعمال کر سکتے ہیں تاکہ دستاویزات خود بخود اپ ڈیٹ ہو جائیں۔

Blog post by :

mermaid
cloudcraft.co
ٹیرافارم پری-کمیٹ ہکس
پری کمٹ
سپورٹڈ hooks
پری کمٹ ٹیرافارم
aws-vpc
ٹیرافارم کی دستاویزات
pre-commit-terraform hooks
pre-commit framework homepage
Collection of git hooks for Terraform to be used with pre-commit framework
Dean Wilson
pre-commit hooks and terraform - a safety net for your repositories

ٹیراگرنٹ (Terragrunt)

حوالہ جات

عمومی سوالات

(عام ٹیرافارم مسائل)

یہاں کچھ ٹولز ہیں جن کے بارے میں آپ کو آگاہ ہونا چاہیے اور ٹیرافارم کے ساتھ کام کرتے وقت استعمال کرنے پر غور کرنا چاہیے

ماڈیولز کے ساتھ انحصار کی مشکل کا حل کیا ہوتا ہے؟

مواد اور زیریں ماڈیول کی ورژنز کو وضاحت سے ذکر کرنا چاہئیں۔ Providers کو ماڈیول کے باہر تشکیل دینا چاہئیں، مگر صرف ترتیب میں providers اور ٹیرا فارم کی ورژنز کو بھی بند کرسکتے ہیں۔

کوڈ کی ساخت کی مثالیں

کوڈ ساخت ٹیرافارم (Terraform)

یہ مثالیںprovider AWS دکھاتی ہیں لیکن ان مثالوں میں دکھائے گئے اکثر اصول دوسرے عوامی کلاؤڈ providers اور ساتھ ہی دیگر قسم کے providers (DNS، DB، مانیٹرنگ، وغیرہ) پر بھی لاگو کیے جا سکتے ہیں۔

کوڈ ساخت ٹیراگرنٹ (Terragrunt)

قسم
تفصیل
تیاری

درمیانہ

"مختلف AWS اکاؤنٹس اور انوائرنمنٹ، آف دی شیلف زیرِ بنائی انوائرنمنٹ ماڈیولز، ٹیراگرنٹ کا استعمال کرتے ہوئے ترتیب کا نمونہ۔"

نہیں

بڑا

بہت سے AWS اکاؤنٹس، بہت سے علاقے، کاپی پیسٹ کم کرنے کی فوری ضرورت، حسب ضرورت انفراسٹرکچر ماڈیولز، کمپوزیشن کا بھاری استعمال۔ Terragrunt ٹیراگرنٹ کا استعمال

نہیں

بہت بڑا

متعدد Provider (AWS، GCP، Azure)۔ ملٹی کلاؤڈ تعیناتیاں۔ Terragrunt ٹیراگرنٹ کا استعمال۔

نہیں

نامزدگی کے اصول

متفقہ اصول

کم از کم ان کنونشنز پر عمل نہ کرنے کی کوئی وجہ نہیں ہونی چاہیے۔

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

  1. ہر جگہ - (ڈیش) کی بجائے _ (انڈرسکور) کا استعمال کریں (ریسورس کے ناموں، ڈیٹا سورس کے ناموں، وہرہبلیس کے ناموں، outputs وغیرہ میں)

  2. بہتر ہے کہ چھوٹے حرف اور اعداد کا استعمال کریں (حتی کہ یو ٹی ایف-8 کا استعمال ہو)۔

ریسورس (Resource) اور ڈیٹا سورس(data source) کے دلائل

  1. ریسورس(Resource) کے نام میں ریسورس (Resource) کی قسم کو دوہرانے سے بچیں (جزوی طور پر نہیں، مکمل طور پر نہیں)

`resource "aws_route_table" "public" {}`
`resource "aws_route_table" "public_route_table" {}`
`resource "aws_route_table" "public_aws_route_table" {}`
  1. اگر کوئی زیادہ وضاحتی اور عام نام دستیاب نہیں ہے، یا اگر ریسورس کا ماڈیول اس قسم کا ایک واحد ریسورس تخلیق کرتا ہے، تو ریسورس کا نام اس طرح رکھا جانا چاہیے۔ (مثال کے طور پر، AWS VPC ماڈیول میں aws_nat_gateway کی قسم کا ایک واحد ریسورس ہے اور aws_route_table کی قسم کے متعدد ریسورس ہیں، اس لیے aws_nat_gateway کا نام اس طرح رکھا جانا چاہیے اور aws_route_table کے پاس زیادہ وضاحتی نام ہونے چاہئیں - جیسے private، public، ڈیٹا بیس)۔

  2. ناموں کے لیے ہمیشہ واحد اسم استعمال کریں

  3. دلائل کو بیان کرتےوقت اور ان جگہوں پر - استعمال کریں جہاںvalue کسی انسان کے سامنے آئے گی (مثال کے طور پر، RDS مثال کے DNS نام کے اندر)۔

  4. ریسورس یا ڈیٹا سورس بلاک کے اندر پہلی دلیل کے طور پر سب سے اوپرcount / for_each دلیل شامل کریں اور اس کے بعد نئی لائن کے ذریعے الگ کریں۔

  5. اگرresource اجازت دے تو، حقیقی دلیل کے طور tags دلیل شامل کریں، اس کے بعد depends_on اور lifecycle،اور اگر ضروری ہو۔ ان سب کو ایک خالی لائن سے الگ کیا جانا چاہیے۔

  6. "جب ارگومنٹ count / for_each میں values استعمال کر رہے ہیں تو length یا دیگر اعبار کی بجائے بولین values کو ترجیح دیں۔"

ریسورسresource کی کوڈ مثالیں

count / for_each کا استعمال

main.tf
resource "aws_route_table" "public" {
  count = 2

  vpc_id = "vpc-12345678"
  # ... remaining arguments omitted
}

resource "aws_route_table" "private" {
  for_each = toset(["one", "two"])

  vpc_id = "vpc-12345678"
  # ... remaining arguments omitted
}
main.tf
resource "aws_route_table" "public" {
  vpc_id = "vpc-12345678"
  count  = 2

  # ... remaining arguments omitted
}

ٹیگزtags کی جگہ

main.tf
resource "aws_nat_gateway" "this" {
  count = 2

  allocation_id = "..."
  subnet_id     = "..."

  tags = {
    Name = "..."
  }

  depends_on = [aws_internet_gateway.this]

  lifecycle {
    create_before_destroy = true
  }
}   
main.tf
resource "aws_nat_gateway" "this" {
  count = 2

  tags = "..."

  depends_on = [aws_internet_gateway.this]

  lifecycle {
    create_before_destroy = true
  }

  allocation_id = "..."
  subnet_id     = "..."
}

کونٹcount میں شرائط

outputs.tf
resource "aws_nat_gateway" "that" {    # Best
  count = var.create_public_subnets ? 1 : 0
}

resource "aws_nat_gateway" "this" {    # Good
  count = length(var.public_subnets) > 0 ? 1 : 0
}

وہرہبلیس (Variables)

  1. ریسورس کے ماڈیولز میں چیزوں کو دوبارہ نہ بنائیں: وہرہبلیس (Variables) کے لیے نام، تفصیل، اور پہلے سے طے شدہ value استعمال کریں جیسا کہ ریسورس کے لیے "Argument Reference" سیکشن میں بیان کیا گیا ہے جس کے ساتھ آپ کام کر رہے ہیں۔

  2. وہرہبلیس (Variables) میں توثیق کے لیے تعاون کافی محدود ہے (مثال کے طور پر آپ دوسرے وہرہبلیس (Variables) تک رسائی حاصل نہیں کر سکتے یا تلاش نہیں کر سکتے)۔ اس کے مطابق منصوبہ بندی کریں کیونکہ بہت سے معاملات میں یہ خصوصیت بیکار ہے۔

  3. جب قسم list(...) یا map(...) ہو تو وہرہبلیس (Variables) کے نام میں جمع فارم استعمال کریں۔

  4. وہرہبلیس (Variables) بلاک میں کلیدیں اس طرح ترتیب دیں: تفصیل، قسم، پہلے سے طے شدہ، توثیق۔

  5. ہمیشہ تمام وہرہبلیس (Variables) پر تفصیل شامل کریں یہاں تک کہ اگر آپ کو لگتا ہے کہ یہ واضح ہے (آپ کو مستقبل میں اس کی ضرورت ہوگی)۔

  6. جب تک کہ آپ کو ہر کلید پر سخت پابندیوں کی ضرورت نہ ہو، مخصوص قسم جیسے object() کے مقابلے میں سادہ اقسام (number، string، list(...)، map(...)، any) استعمال کرنے کو ترجیح دیں۔

  7. اگر map کے تمام عناصر ایک ہی قسم کے ہیں (مثال کے طور پر string) یا اس میں تبدیل کیے جا سکتے ہیں (مثال کے طور پر number کی قسم کو string میں تبدیل کیا جا سکتا ہے) تو map(map(string)) جیسے مخصوص اقسام کا استعمال کریں۔

  8. ایک خاص گہرائی سے شروع ہونے والی قسم کی جانچنا کو غیر فعال کرنے کے لیے یا جب متعدد اقسام کی حمایت کی جانی چاہیے تو any کا استعمال کریں۔

  9. والیو Value{} کبھی کبھی map ہوتی ہے لیکن کبھی کبھی ایک object ہوتی ہے۔ map بنانے کے لیے tomap(...) استعمال کریں کیونکہ کوئیobject بنانے کا کوئی طریقہ نہیں ہے۔

آؤٹ پٹس (Outputs)

آؤٹ پٹسOutputs کو اس کے دائرہ کار سے باہر مستقل اور قابل فہم بنائیں (جب کوئی صارف کسی ماڈیول کا استعمال کر رہا ہو تو یہ واضح ہونا چاہیے کہ یہ کس قسم اور والیو Value کی خصوصیت واپس کرتا ہے)۔

  1. آؤٹ پٹ کا نام اس میں موجود پراپرٹی کو بیان کرنا چاہیے اور عام طور پر آپ کی خواہش سے کم آزاد شکل کا ہونا چاہیے۔

  2. آؤٹ پٹ کے نام کے لیے اچھی ساخت {name}_{type}_{attribute} کی طرح نظر آتی ہے، جہاں:

    1. نام {name}ریسورس یا ڈیٹا کے سورسہ کے نام کے بغیر provider کے سابقہ کے بغیر استعمال کریں aws_subnet کے لیے {name} subnetہے، aws_vpc کے لیے یہ vpc ہے۔

    2. ٹائپ{type} ریسورسسورسہ کی قسم ہے۔

    3. {attribute} آؤٹ پٹ کے واپس کرنے کی ایک صفت ہے

  3. ہمیشہ تمام آؤٹ پٹس کے لیے تفصیل description شامل کریں یہاں تک کہ اگر آپ کو لگتا ہے کہ یہ واضح ہے۔

  4. حساس دلیل کو ترتیب دینے سے گریز کریں۔جب تک آپ تمام ماڈیولز میں تمام جگہوں پر اس آؤٹ پٹ کے استعمال کو مکمل طور پر کنٹرول نہیں کرتے،

  5. ٹیرافارم (Terraform) کی شروعات سے دستیاب try() کو (جو بعد از Terraform 0.13 کے ورژنز کے لئے چھوڑ دی گئی)element(concat(...)) (قدیم طریقہ کار) کے بجائے ترجیح دیں"

آؤٹ پٹoutput کوڈ کی مثالیں

زیادہ سے زیادہ ایک سیکورٹی گروپ کی ID واپس کریں:

outputs.tf
output "security_group_id" {
  description = "The ID of the security group"
  value       = try(aws_security_group.this[0].id, aws_security_group.name_prefix[0].id, "")
}

جب ایک ہی قسم کے متعدد ریسورسز ہوں، توthis آؤٹ پٹ کے نام سے حذف کر دینے چاہیے:

outputs.tf
output "this_security_group_id" {
  description = "The ID of the security group"
  value       = element(concat(coalescelist(aws_security_group.this.*.id, aws_security_group.web.*.id), [""]), 0)
}

اگر واپس آنے والی value فہرست ہے تو جمع کا نام استعمال کریں۔

outputs.tf
output "rds_cluster_instance_endpoints" {
  description = "A list of all cluster instance endpoints"
  value       = aws_rds_cluster_instance.this.*.endpoint
}

ورکشاپ

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

خوش آمدید

یہ دستاویز ایک کوشش ہے کہ منظم طریقے سے ٹیرافارم (Terraform) کا استعمال کرتے ہوئے بہترین طریقوں کو بیان کیا جائے اور ٹیرافارم کے صارفین کو پیش آنے والے اکثر مسائل کے لیے سفارشات فراہم کی جائیں۔

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

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

**سرپرستان(**Sponsors)

—

ترجمہ

شراکت

میں ہمیشہ اس کتاب کے بارے میں ردعمل حاصل کرنا اور اسے اپ ڈیٹ کرنا چاہتا ہوں کیونکہ کمیونٹی بڑھتی ہے اور نئے خیالات کو نافذ کیا جاتا ہے اور وقت کے ساتھ ساتھ تصدیق کی جاتی ہے

مصنفین

لائسنس

یہ کام Apache 2 لائسنس کے تحت لائسنس یافتہ ہے۔ مکمل تفصیلات کے لیے LICENSE فائل دیکھیں۔\

اس مواد کے مصنفین اور شراکت دار یہاں پائی جانے والی معلومات کی صحت کی ضمانت نہیں دے سکتے۔ براہ کرم یقینی بنائیں کہ آپ سمجھتے ہیں کہ یہاں فراہم کردہ معلومات آزادانہ طور پر فراہم کی جا رہی ہے، اور آپ اور اس مواد یا منصوبے سے وابستہ کسی بھی شخص کے درمیان کسی بھی قسم کا معاہدہ یا کنٹریکٹ نہیں بنایا گیا ہے۔ مصنفین اور شراکت دار اس مواد میں موجود معلومات میں کسی غلطی یا کمی کی وجہ سے ہونے والے کسی نقصان، نقصان، یا خرابی کے لیے کسی فریق کے سامنے کوئی ذمہ داری نہیں لیتے ہیں، خواہ وہ غلطیاں یا کمیاں غفلت، حادثہ، یا کسی اور وجہ سے ہو ں۔ کاپی رائٹ © 2018-2023 Anton Babenko

ٹیرافارم (Terraform)کنفیگریشنز لکھنا

ریسورس کے درمیان واضح تعلقات کو بیان کرنے کے لئے locals کا استعمال کریں۔

ٹیرافارم (Terraform)کو اشارہ دینے کا مددگار طریقہ کہ کچھریسورس کو اس سے پہلے حذف کر دینا چاہیے جب کہ ٹیرافارم کنفیگریشنز میں براہ راست انحصار نہ ہو۔

Terraform 0.12 - مطلوبہ بمقابلہ اختیاری دلائل

  1. اگر var.website ایک خالی map نہیں ہے، تو ضروری ہے کہ argument index_document کو سیٹ کیا جائے۔

  2. اختیاری argument error_document کو چھوڑا جا سکتا ہے۔

تیرا فارم Terraform کمیونٹی سے متعلق عظیم مواد بنانے اور اوپن سورس منصوبے کو منظم کرنے والے بہت سارے لوگ ہیں، لیکنمیں ان لنکس کو یہاں درج فہرستوں کو کاپی کیے بغیر حاصل کرنے کے لیے بہترین ڈھانچے کے بارے میں سوچ بھی نہیں سکتا

- تیرا فارم کے ساتھ بہت فعالیت کرنے والے اور آپ کو بہت کچھ بتا سکنے والے افراد کی فہرست (اگر آپ ان سے پوچھیں تو)۔

- ہاشیکورپ کے تیرا فارم پر مواد کی مرتب شدہ فہرست۔

- "آپ کی ہر ہفتہ کی تیرا فارم یوتوبے" ٹیوٹریم چینل آنٹن بابینکو کا۔ آنٹن بابینکو کے ساتھ لائیو اسٹریمز میں جائیں، Q&A، لائیو کوڈنگ، اور تیرا فارم کے ساتھ کچھ ہیکنگ۔

تیرا فارم ہفتہ وار نیوز لیٹر۔ تیرا فارم کی دنیا میں مختلف خبریں (منصوبے، اعلانات، بحث) Anton Babenko کے ذریعہ۔

- آرکیسٹریشن ٹول

- کوڈ لنٹر

- ورژن منیجر

- پل پریس کی آٹومیشن

- ٹیرافارم کی ساتھ استعمال کرنے والے کے لئے گٹ ہکس کا مجموعہ

- پل کی درخواستوں میں ٹیرافارم کے لیے کلاؤڈ لاگت کا تخمینہ۔ ٹیراگرنٹ، اٹلانٹس اور پری کمٹ ٹیرافارم کے ساتھ بھی کام کرتا ہے۔

کوئی ماسٹر ڈیپنڈنسی منجمنٹ ٹول نہیں ہے۔، مگر انحصار کو کم پریشانی والی بنانے کے لئے کچھ مشورے ہیں۔ مثال کے طور پر، کو ڈیپنڈنسی اپ ڈیٹس کو خود بخود کرنے کے لئے استعمال کیا جا سکتا ہے۔ Dependabot آپ کی ڈیپنڈنسیوں کو محفوظ اور up-to-date رکھنے کے لئے pull requests کھولتا ہے۔ Dependabot ٹیرا فارم کنفیگریشن کو بھی معاونیت پہنچاتا ہے۔

قسم
تفصیل
تیاری

چند وسائل، کوئی بیرونی انحصار نہیں۔ واحد AWS اکاؤنٹ۔ واحد علاقہ۔ واحد انوائرنمنٹ۔

ہاں

بہت سے AWS اکاؤنٹس اور بہت سے انوائرنمنٹ، ٹیرافارم کا استعمال کرتے ہوئے آف دی شیلف انفراسٹرکچر ماڈیولز

ہاں

بہت سے AWS اکاؤنٹس، بہت سے علاقے، کاپی پیسٹ کم کرنے کی فوری ضرورت، حسب ضرورت انفراسٹرکچر ماڈیولز، کمپوزیشن کا بھاری استعمال۔ ٹیرافارم کا استعمال۔

زیر تکمیل

بہت بڑا

"مختلف Provider (AWS، GCP، Azure)۔ متعدد کلاؤڈ کی انجام دہی۔ ٹیرا فارم کا استعمال کیا جاتا ہے۔"

نہیں

.

"اگرآؤٹ پٹ وسیع تعریفی تفصیلات، انٹرپولیشن فنکشنز، اور مختلف ریسورس کی value واپس دے رہا ہے، تو {name} اور {type} کو جتنا ممکن ہو، عام اور عمومی رکھنا چاہئے (this کا پریفکس نہیں ہونا چاہئے). ."

اگر واپس آنے والی value فہرست ہے تو اس کا جمع کا نام ہونا چاہیے۔

مواد یہاں ہے۔

ٹیرافارم () ایک طاقتور (اگرچہ اب تک کا سب سے طاقتورٹول نہیں ہے) اور سب سے زیادہ استعمال ہونے والے ٹولز میں سے ایک ہے جو انفراسٹرکچر کو کوڈ (infrastructure as code) کے طور پر منظم کرتا ہے۔ اور یہ ڈویلپرز کو بہت سے کام کرنے کی اجازت دیتا ہے . انہیں ایسی چیزوں کو کرنے سے نہیں روکتا جن کی حمایت یا انضمام کرنا مشکل ہو گا۔

کتاب کی ابتدا 2018 میں اسپین کے خوبصورت شہر مدريد میں ہوئی تھی، اور یہ کتاب مفت میں یہاں سے ڈاؤن لوڈ کی جا سکتی ہے ۔ .

Please if you want to become a sponsor.

— Terraform Compliance Simplified. Make your Terraform modules compliance-ready.

اگر آپ اس کتاب کو دوسری زبانوں میں ترجمہ کرنے میں مدد کرنا چاہتے ہیں تو ۔

اگر آپ مخصوص موضوعات میں دلچسپی رکھتے ہیں، تو براہ کرم ایک مسئلہ کھولیں ()، یا اس مسئلے کو تھمبز اپ (thumb up) کریں جسے آپ شامل کرنا چاہتے ہیں۔ اگر آپ محسوس کرتے ہیں کہ آپ کے پاس مواد ہے اور آپ حصہ ڈالنا چاہتے ہیں، تو ایک مسودہ لکھیں اور ایک پل ریکویسٹ (pull request) جمع کروائیں (اس وقت اچھا متن لکھنے کے بارے میں فکر نہ کریں!)

اس کتاب کی دیکھ بھال کی طرف سے مختلف معاونین اور ترجمہ کاروں کی مدد سے کی جاتی ہے

awesome-terraform
https://twitter.com/antonbabenko/lists/terraform-experts
https://github.com/shuaibiyy/awesome-terraform
http://bit.ly/terraform-youtube
https://weekly.tf
Terragrunt
tflint
tfenv
Atlantis
pre-commit-terraform
پری-کمٹ فریم ورک
Infracost
Dependabot
https://github.com/antonbabenko/terraform-best-practices-workshop
Terraform
https://www.terraform-best-practices.com/
contact me
مجھ سے رابطہ کریں
open an issue
Anton Babenko
See examples
مثال دیکھیں
مثال دیکھیں۔
main.tf
variable "website" {
  type    = map(string)
  default = {}
}

resource "aws_s3_bucket" "this" {
  # omitted...

  dynamic "website" {
    for_each = length(keys(var.website)) == 0 ? [] : [var.website]

    content {
      index_document = website.value.index_document
      error_document = lookup(website.value, "error_document", null)
    }
  }
}
terraform.tfvars
website = {
  index_document = "index.html"
}
چھوٹا
درمیانہ
بڑا
Compliance.tf
https://raw.githubusercontent.com/antonbabenko/terraform-best-practices/master/snippets/locals.tf
العربية (Arabic)
Bosanski (Bosnian)
Português (Brazilian Portuguese)
English
Français (French)
ελληνικά (Greek)
עברית (Hebrew)
Türkçe (Turkish)
ქართული (Georgian)
Bahasa Indonesia (Indonesian)
हिंदी (Hindi)
Deutsch (German)
Simple infrastructure composition
日本語 (Japanese)
Italiano (Italian)
Polski (Polish)
ಕನ್ನಡ (Kannada)
한국어 (Korean)
简体中文 (Simplified Chinese)
Español (Spanish)
Română (Romanian)
Українська (Ukrainian)