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

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

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

مجھے اپنے ٹیرافارم 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 کنفیگریشنز کو ساخت دینے طور پر استعمال کرتا ہے:

• 2 AWS اکاؤنٹس

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

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

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

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

ماخذ: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/small-terraform اس مثال میں وہ کوڈ شامل ہے جو ایک چھوٹے سائز کی ٹیرا فارم کنفیگریشن کی ساخت کی مثال کے طور پر دیا گیا ہے، جہاں کوئی بیرونی دپندنکئیس dependenciesاستعمال نہیں کیا گیا ہے۔

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

• 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 ,دستاویز کے ماڈیول ورژن

حوالہ جات

1. pre-commit framework homepage

2. Collection of git hooks for Terraform to be used with pre-commit framework

3. Blog post by Dean Wilson: pre-commit hooks and terraform - a safety net for your repositories

متفقہ اصول

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 کا استعمال

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
}

resource "aws_route_table" "public" {
  vpc_id = "vpc-12345678"
  count  = 2

  # ... remaining arguments omitted
}

ٹیگزtags کی جگہ

resource "aws_nat_gateway" "this" {
  count = 2

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

  tags = {
    Name = "..."
  }

  depends_on = [aws_internet_gateway.this]

  lifecycle {
    create_before_destroy = true
  }
}   

resource "aws_nat_gateway" "this" {
  count = 2

  tags = "..."

  depends_on = [aws_internet_gateway.this]

  lifecycle {
    create_before_destroy = true
  }

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

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

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} آؤٹ پٹ کے واپس کرنے کی ایک صفت ہے

   4. See examples.

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

4. اگر واپس آنے والی value فہرست ہے تو اس کا جمع کا نام ہونا چاہیے۔ مثال دیکھیں۔

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

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

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

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

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

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 آؤٹ پٹ کے نام سے حذف کر دینے چاہیے:

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 فہرست ہے تو جمع کا نام استعمال کریں۔

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

ماخذ: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 - آرکیسٹریشن ٹول

• tflint - کوڈ لنٹر

• tfenv - ورژن منیجر

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

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

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

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

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

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

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

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

ریسورس (Resource)

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

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

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

انفراسٹرکچر ماڈیول (Infrastructure 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 کو تخلیق، منتقلی، اور تنصیب کیا جا سکے ۔

ترکیب (Composition)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ترکیبات کے درمیان رسائی اکثر ریموٹ سٹیٹ 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)
    }
  }
}

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

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

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

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

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

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

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

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

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

Please if you want to become a sponsor.

ترجمہ

شراکت

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

مصنفین

لائسنس

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

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