ٹیرافارم سے S3 مقامی ریاست لاکنگ میں کیسے منتقل کیا جائے۔

اگر آپ تھوڑی دیر سے AWS پر Terraform چلا رہے ہیں، تو آپ شاید سیٹ اپ جانتے ہوں گے: اسٹیٹ کو اسٹور کرنے کے لیے ایک S3 بالٹی، اسٹیٹ لاک کرنے کے لیے ایک DynamoDB ٹیبل، اور ان کو ایک ساتھ باندھنے کے لیے چند IAM پالیسیاں۔ یہ کام کرتا ہے۔ یہ سالوں تک کام کرتا رہا۔

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

اصل قیمت پیچیدگی ہے۔ کسی بھی نئے AWS ماحول کے لیے دونوں وسائل کی فراہمی کی ضرورت ہوتی ہے اس سے پہلے کہ Terraform دوسرے کا انتظام کر سکے۔ پہلی بار ٹیرافارم بیک اینڈ قائم کرنے والے کسی بھی انجینئر کو یہ سمجھنا چاہیے کہ دو بالکل مختلف AWS سروسز ریاست کو ذخیرہ کرنے اور اس کی حفاظت کے لیے منطقی طور پر ذمہ دار کیوں ہیں۔ اور تالا بند ہونے والے ہر واقعے میں کسی کو ٹیم کو غیر مسدود کرنے کے لیے DynamoDB سے ریکارڈ کو دستی طور پر حذف کرنے کی ضرورت ہوتی ہے۔

نومبر 2024 میں، AWS نے اعلان کیا کہ S3 اب Terraform اسٹیٹ فائلوں کے لیے مقامی آبجیکٹ لاکنگ کو سپورٹ کرتا ہے۔ DynamoDB کو اب اسٹیٹ لاکنگ کی ضرورت نہیں ہے۔. Terraform 1.10 نے اس خصوصیت کے لیے تعاون شامل کیا اور اب عام طور پر دستیاب ہے۔

اس ٹیوٹوریل میں آپ سیکھیں گے:

• S3 ڈیفالٹ لاک کیا ہیں اور وہ کیسے کام کرتے ہیں؟

• اگر آپ ایک نیا پروجیکٹ شروع کر رہے ہیں، تو اسے شروع سے کیسے ترتیب دیا جائے۔

• موجودہ S3 + DynamoDB سیٹ اپ کو S3 مقامی لاکنگ میں محفوظ طریقے سے کیسے منتقل کیا جائے۔

• یہ کیسے چیک کریں کہ آیا لاک کام کر رہا ہے اور کنارے کے کیسز کو ہینڈل کریں۔

آپ کو منظم کرنے کے لیے ایک کم AWS وسائل کے ساتھ ایک آسان، صاف ستھرا Terraform بیک اینڈ حاصل ہوتا ہے۔

انڈیکس

ٹیرافارم اسٹیٹ لاکنگ کیا ہے؟

نئے طریقوں کو دیکھنے سے پہلے، یہ سمجھنا مددگار ہے کہ اسٹیٹ لاکنگ کس مسئلے کو حل کرتی ہے۔

Terraform آپ کو وہ سب کچھ بتاتا ہے جو آپ انفراسٹرکچر کے بارے میں جانتے ہیں۔ ریاستی فائل – ایک JSON دستاویز جو اصل AWS وسائل سے ترتیب کو نقشہ بناتی ہے۔ جب آپ بھاگتے ہیں terraform applyTerraform اس فائل کو پڑھتا ہے، موجودہ حالت اور ترتیب کے درمیان فرق کا حساب لگاتا ہے، اور کوئی ضروری تبدیلیاں کرتا ہے۔

مسئلہ اس وقت پیدا ہوتا ہے جب دو انجینئرز یا دو CI/CD پائپ لائنیں چل رہی ہوں اور ایک ہی وقت میں تبدیلیاں لاگو کرنے کی کوشش کر رہی ہوں۔ اگر دونوں ایک ہی وقت میں اسٹیٹ فائل کو پڑھتے ہیں، تو آزادانہ طور پر تبدیلیوں کی گنتی کریں، اور دونوں واپس لکھنے کی کوشش کریں، دوڑ کی حالت. دوسری تحریر پہلی تحریر سے ہونے والی تبدیلیوں کو اوور رائٹ کرتی ہے اور ریاست اب حقیقت سے ہم آہنگ نہیں ہے۔ یہ ایک سنگین مسئلہ ہے جس کی وجہ سے وسائل کا پتہ نہیں چل سکتا، دوگنا ہو سکتا ہے یا غیر متوقع طور پر تباہ ہو سکتا ہے۔

ریاستی تالا ہم اس مسئلے کو ایک لاک بنا کر حل کرتے ہیں جب کوئی ایسا آپریشن شروع ہوتا ہے جو حالت میں ترمیم کر سکتا ہے۔ اگر ایک تالا پہلے سے موجود ہے، تو ٹیرافارم آگے بڑھنے سے انکار کر دیتا ہے اور یہ بتاتا ہے کہ تالا کس کے پاس ہے اور کب اسے حاصل کیا گیا تھا۔ ایک وقت میں صرف ایک ٹاسک لاک کو روک سکتا ہے۔ کام مکمل ہونے پر اسے غیر مقفل کردیا جائے گا۔

Terraform Run A                 State File / Lock                Terraform Run B
(User 1)                         (S3/DynamoDB)                   (User 2)

   |                                   |                            |
   |------- 1. Acquire Lock ---------->|                            |
   |                                   |                            |
   |<------ 2. Lock Granted -----------|                            |
   |                                   |                            |
   |                                   |------- 3. Acquire Lock --->|
   |            [PROCESSING]           |                            |
   |      (Modifying Infrastructure)   |<------ 4. Lock Denied -----|
   |                                   |        (Wait / Retry)      |
   |                                   |                            |
   |------- 5. Release Lock ---------->|                            |
   |                                   |                            |
   |           [COMPLETED]             |<------ 6. Lock Granted ----|
   |                                   |                            |
   |                                   |       [PROCESSING]         |
   |                                   | (Modifying Infrastructure) |              
   |                                   |                            |

S3 ڈیفالٹ اسٹیٹ لاکنگ کیا ہے؟

پہلے، Terraform کے S3 بیک اینڈ نے DynamoDB ٹیبلز کو لاکنگ میکانزم کے طور پر استعمال کیا تھا۔ جب کسی تالے کی ضرورت ہوتی ہے، تو Terraform DynamoDB کو یہ استعمال کرتے ہوئے ایک ریکارڈ لکھتا ہے: LockID بنیادی کلید۔ DynamoDB کی مشروط تحریروں نے اس بات کو یقینی بنایا کہ صرف ایک عمل اس ریکارڈ کو بنا سکتا ہے، جو کہ لاک ایٹمیسیٹی کا نفاذ ہے۔

S3 ڈیفالٹ لاکنگ کا استعمال کریں۔ S3 آبجیکٹ لاک اس کے بجائے. S3 آبجیکٹ لاکنگ ایک S3 خصوصیت ہے جو اصل میں ایک بار لکھیں، کئی (WORM) کی تعمیل کی ضروریات کو پورا کرنے کے لیے ڈیزائن کی گئی ہیں۔ AWS نے Terraform میں اسٹیٹ لاکنگ ورک فلو کو سپورٹ کرنے کے لیے اس فیچر کو بڑھایا ہے۔

اگر S3 مقامی لاکنگ آپ کے Terraform بیک اینڈ پر فعال ہے:

1. ٹیرافارم ریاستیں۔ .tfstate S3 میں اشیاء (پہلے کی طرح)

2. تالا حاصل کرنے کے لیے، Terraform استعمال کرتا ہے: S3 میں مشروط تحریری آپریشنز - خاص طور پر if-none-match مشروط ہیڈر جو ایٹمی طور پر ایک لاک فائل بناتا ہے۔

3. اگر لاک فائل پہلے سے موجود ہے، تو S3 لکھنے سے انکار کر دے گا اور Terraform اطلاع دے گا کہ لاک ہو گیا ہے۔

4. جب کام مکمل ہو جاتا ہے، Terraform لاک فائل کو حذف کر کے لاک کو جاری کرتا ہے۔

DynamoDB کے ساتھ بنیادی فرق یہ ہے کہ تالا لگانے کا پورا طریقہ کار S3 کے اندر ہے۔ کوئی دوسری خدمت نہیں ہے۔ کوئی دوسرا IAM اجازت سیٹ نہیں ہے۔ رزق کا کوئی دوسرا ذریعہ نہیں ہے۔

میمو: اس خصوصیت کے لیے Terraform کا ایک ورژن درکار ہے۔ 1.10.0 یا اس سے زیادہ S3 بالٹی آبجیکٹ لاک فعال ہے۔. بالٹی بناتے وقت آبجیکٹ لاکنگ کا فعال ہونا ضروری ہے۔ آپ اسے کنسول یا CLI کے ذریعے موجودہ بالٹی پر فعال نہیں کر سکتے ہیں۔ تاہم، موجودہ بالٹیوں کے لیے ایک معاون کام ہے، جس کا ہم حصہ 2 میں احاطہ کریں گے۔

S3 مقامی لاکنگ اور S3 + DynamoDB نقطہ نظر کا موازنہ

طرف	S3 + DynamoDB (وراثت)	S3 ڈیفالٹ لاکنگ (نیا)
AWS خدمات درکار ہیں۔	S3 + DynamoDB	صرف S3
IAM کی اجازت درکار ہے۔	S3 + DynamoDB اجازتیں۔	صرف S3 اجازتیں۔
ٹیرافارم ورژن	کوئی بھی	1.10.0 یا اس سے زیادہ
سیٹ اپ کی پیچیدگی	2 وسائل، 2 IAM اسکوپس	ایک وسائل
فکسڈ لاک آؤٹ حل	DynamoDB ریکارڈز کو حذف کرنا	S3 لاک فائل کو حذف کریں۔
خرچ	S3 اسٹوریج + DynamoDB آن ڈیمانڈ	صرف S3 اسٹوریج
آبجیکٹ لاکنگ کی ضروریات	ضرورت نہیں	S3 بالٹی کے لیے درکار ہے۔
تالا لگانے کا طریقہ کار	DynamoDB مشروط لکھتا ہے۔	S3 مشروط تحریر (if-none-match)
ریاستی ورژن	S3 ورژن (تجویز کردہ)	S3 ورژن (مکمل حفاظت کے لیے درکار)

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

شرطیں

شروع کرنے سے پہلے، یقینی بنائیں کہ آپ کے پاس درج ذیل ہیں:

• ٹیرافارم 1.10.0 اور اس سے زیادہ انسٹال اپنا ورژن چیک کریں:

terraform version

اگر آپ کو اپ گریڈ کرنے کی ضرورت ہے، تو براہ کرم آفیشل اپ گریڈ گائیڈ پر عمل کریں۔

• AWS CLI ان اسناد کے ساتھ انسٹال اور کنفیگر کیا گیا ہے جن کو S3 بالٹی بنانے اور ان کا نظم کرنے کی اجازت ہے۔

aws --version
aws sts get-caller-identity   # confirm you're authenticated

• IAM اجازتیں۔ درج ذیل S3 آپریشنز کریں:

  • s3:CreateBucket

  • s3:PutBucketVersioning

  • s3:PutBucketEncryption

  • s3:PutObjectLegalHold

  • s3:PutObjectRetention

  • s3:GetObject

  • s3:PutObject

  • s3:DeleteObject

  • s3:ListBucket

• کے لیے نقل مکانی کا راستہ: موجودہ Terraform پروجیکٹس اور S3 بالٹیز اور DynamoDB ٹیبلز تک رسائی حاصل کریں جو فی الحال زیر استعمال ہیں۔

حصہ 1: شروع سے سیٹ اپ - شروع سے S3 ڈیفالٹ تالے کو کیسے ترتیب دیا جائے

اگر آپ نیا ٹیرافارم پروجیکٹ شروع کر رہے ہیں اور شروع سے S3 ڈیفالٹ لاکنگ استعمال کرنا چاہتے ہیں تو اس سیکشن کو فالو کریں۔

مرحلہ 1: ورژننگ اور خفیہ کاری کے ساتھ ایک S3 بالٹی بنائیں

اعتراض تالا بالٹی بناتے وقت اسے فعال کرنا ضروری ہے۔. اسے بعد میں معیاری کنسول کے بہاؤ کے ذریعے شامل نہیں کیا جا سکتا۔ AWS CLI کا استعمال کرتے ہوئے ایک بالٹی بنائیں جس میں آبجیکٹ لاکنگ فعال ہو۔

aws s3api create-bucket 
  --bucket your-project-terraform-state 
  --region us-east-1 
  --object-lock-enabled-for-bucket

میمو: دوسرے علاقوں کے لیے us-east-1درج ذیل شامل کریں: --create-bucket-configuration پرچم

aws s3api create-bucket 
  --bucket your-project-terraform-state 
  --region eu-west-1 
  --create-bucket-configuration LocationConstraint=eu-west-1 
  --object-lock-enabled-for-bucket

اب اپنی بالٹی پر ورژننگ کو فعال کریں۔ آبجیکٹ لاکنگ کے ساتھ ساتھ ورژننگ بھی ضروری ہے، اگر کچھ غلط ہو جائے تو Terraform کو پچھلے اسٹیٹ ورژن کو بازیافت کرنے کی اجازت دیتا ہے۔

aws s3api put-bucket-versioning 
  --bucket your-project-terraform-state 
  --versioning-configuration Status=Enabled

سرور سائڈ انکرپشن کو فعال کریں تاکہ اسٹیٹ فائلز کو آرام سے انکرپٹ کیا جائے۔

aws s3api put-bucket-encryption 
  --bucket your-project-terraform-state 
  --server-side-encryption-configuration '{
    "Rules": [
      {
        "ApplyServerSideEncryptionByDefault": {
          "SSEAlgorithm": "AES256"
        },
        "BucketKeyEnabled": true
      }
    ]
  }'

بالٹی تک تمام عوامی رسائی کو مسدود کریں۔ Terraform اسٹیٹ فائلوں میں وسائل کی IDs، IP پتے، اور ممکنہ طور پر حساس اقدار شامل ہیں۔ عوامی طور پر قابل رسائی نہیں ہونا چاہئے۔

aws s3api put-public-access-block 
  --bucket your-project-terraform-state 
  --public-access-block-configuration 
    "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

اپنی بالٹی کنفیگریشن چیک کریں۔

# Confirm Object Lock is enabled
aws s3api get-object-lock-configuration 
  --bucket your-project-terraform-state
 
# Confirm versioning is enabled
aws s3api get-bucket-versioning 
  --bucket your-project-terraform-state
 
# Confirm encryption is configured
aws s3api get-bucket-encryption 
  --bucket your-project-terraform-state

آبجیکٹ لاک چیک کے لیے متوقع آؤٹ پٹ:

{
    "ObjectLockConfiguration": {
        "ObjectLockEnabled": "Enabled"
    }
}

مرحلہ 2: ڈیفالٹ لاکنگ کے ساتھ ٹیرافارم بیک اینڈ کو کنفیگر کریں۔

آپ کے Terraform پروجیکٹ میں backend.tf فائل:

terraform {
  backend "s3" {
    bucket = "your-project-terraform-state"
    key    = "production/terraform.tfstate"
    region = "us-east-1"
 
    # Enable S3 native state locking
    # Requires Terraform 1.10.0+ and a bucket with Object Lock enabled
    use_lockfile = true
 
    # Encryption at rest
    encrypt = true
  }
}

موجودہ ترتیب سے سب سے بڑا فرق ہے۔ use_lockfile = true پیرامیٹرز کیا نوٹس غیر حاضر: نہیں dynamodb_table تنازعہ کوئی DynamoDB ٹیبل نہیں ہے۔ کوئی دوسری خدمت نہیں ہے۔

یہاں پرانی اور نئی ترتیبوں کا براہ راست موازنہ ہے:

پچھلی ترتیب (S3 + DynamoDB):

terraform {
  backend "s3" {
    bucket         = "your-project-terraform-state"
    key            = "production/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-state-lock"   # this goes away
  }
}

نئی ترتیب (S3 ڈیفالٹ لاکنگ):

terraform {
  backend "s3" {
    bucket       = "your-project-terraform-state"
    key          = "production/terraform.tfstate"
    region       = "us-east-1"
    encrypt      = true
    use_lockfile = true   # this replaces dynamodb_table
  }
}

مرحلہ 3: دوبارہ ترتیب دیں اور تصدیق کریں۔

چلائیں terraform init پسدید شروع کرنے کے لیے:

terraform init

متوقع پیداوار:

Initializing the backend...
 
Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.
 
Initializing provider plugins...
 
Terraform has been successfully initialized!

اپنے منصوبے پر عمل کریں تاکہ یہ یقینی بنایا جا سکے کہ ہر چیز شروع سے آخر تک ٹھیک طریقے سے کام کرتی ہے۔

terraform plan

اگر کوئی لاک فعال ہے، تو ایک مختصر وقفہ ہوگا جب کہ Terraform کسی بھی پلان کے آؤٹ پٹ کے ظاہر ہونے سے پہلے تالا حاصل کر لیتا ہے۔ اگر آپ اپنی S3 بالٹی کو دیکھتے ہیں، تو آپ لاکنگ کی معلومات بھی دیکھ سکتے ہیں۔ .tflock فائل آپریشن کے دوران اسٹیٹس فائل کے ساتھ عارضی طور پر ظاہر ہوتی ہے اور مکمل ہونے پر غائب ہوجاتی ہے۔

حصہ 2: ہجرت - S3 + DynamoDB سے S3 مقامی لاکنگ میں کیسے جائیں

اس سیکشن پر عمل کریں اگر آپ کے پاس ہے: موجودہ Terraform ترتیبات میں اسٹیٹ لاکنگ کے لیے S3 بالٹیاں اور DynamoDB ٹیبل استعمال کر رہا ہوں اور S3 مقامی لاکنگ میں منتقل ہونا چاہتا ہوں۔

اہم: ہجرت کے لیے مینٹیننس ونڈو کی ضرورت ہوتی ہے، یا کم از کم ایک مدت جس میں Terraform جابز نہیں چل رہی ہوتیں۔ ہم اپنی بیک اینڈ کنفیگریشن تبدیل کر رہے ہیں۔ دوسرے لفظوں میں ٹیم کے تمام ارکان اور CI/CD پائپ لائنوں کو چلنے سے روک دیا جانا چاہیے۔ terraform plan یا terraform apply ہجرت کرنا. نقل مکانی میں 10 منٹ سے بھی کم وقت لگتا ہے۔

مرحلہ 1: اپنی موجودہ ترتیبات کو چیک کریں۔

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

# Confirm your state file is in S3
aws s3 ls s3://your-existing-bucket/path/to/terraform.tfstate
 
# Confirm the DynamoDB table exists
aws dynamodb describe-table 
  --table-name your-dynamodb-lock-table 
  --query 'Table.TableStatus'

موجودہ حالت چیک کریں۔ backend.tf درست اقدار کو نوٹ کریں۔

# Your current backend.tf - note these values before changing anything
terraform {
  backend "s3" {
    bucket         = "your-existing-bucket"       # note this
    key            = "path/to/terraform.tfstate"   # note this
    region         = "us-east-1"                   # note this
    encrypt        = true
    dynamodb_table = "your-dynamodb-lock-table"    # this will be removed
  }
}

اس بات کو یقینی بنانے کے لیے کہ آپ کی موجودہ حالت صاف ہے اور کوئی غیر متوقع تبدیلیاں زیر التواء نہیں ہیں ایک حتمی منصوبہ پر عمل کریں۔

terraform plan

اگر آپ کو اپنے پلان میں کوئی تبدیلی نظر نہیں آتی ہے تو آگے بڑھنا محفوظ ہے۔

مرحلہ 2: اپنی موجودہ S3 بالٹی پر آبجیکٹ لاکنگ کو فعال کریں۔

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

تاہم، AWS سپورٹ کی درخواستوں یا براہ راست API کالز کے ذریعے موجودہ بالٹیوں پر آبجیکٹ لاکنگ کو فعال کرنے کا ایک طریقہ فراہم کرتا ہے جو معیاری کنسول UI میں ظاہر نہیں ہوتے ہیں۔ AWS نے سرکاری طور پر ٹیرافارم مائیگریشن استعمال کیس کے لیے اس راستے کو دستاویز کیا ہے۔

درج ذیل AWS CLI کمانڈ کو چلا کر آبجیکٹ لاکنگ کو فعال کریں: موجودہ بالٹی:

aws s3api put-object-lock-configuration 
  --bucket your-existing-bucket 
  --object-lock-configuration '{"ObjectLockEnabled": "Enabled"}'

میمو: یہ کمانڈ آبجیکٹ لاکنگ کو چالو کرتی ہے۔ پہلے سے طے شدہ برقراری کے بغیر گورننس موڈاس کا مطلب ہے تمام اشیاء کے لیے ڈیفالٹ ریٹینشن پیریڈ سیٹ کیے بغیر لاکنگ فیچر کو فعال کرنا۔ یہ بالکل وہی ہے جو Terraform کی ڈیفالٹ لاکنگ کی ضرورت ہے۔ یعنی مستقل اشیاء کو محفوظ کرنے کے بجائے لاک فائلوں کو بنانے اور حذف کرنے کی صلاحیت۔

اب چیک کریں کہ آیا آبجیکٹ لاکنگ فعال ہے۔

aws s3api get-object-lock-configuration 
  --bucket your-existing-bucket

متوقع پیداوار:

{
    "ObjectLockConfiguration": {
        "ObjectLockEnabled": "Enabled"
    }
}

یہ بھی یقینی بنائیں کہ ورژننگ پہلے سے ہی فعال ہے (اگر آپ پروڈکشن ٹیرافارم سیٹ اپ چلا رہے ہیں، تو اسے فعال ہونا چاہیے)۔

aws s3api get-bucket-versioning 
  --bucket your-existing-bucket

متوقع پیداوار:

{
    "Status": "Enabled"
}

اگر ورژننگ فعال نہیں ہے، تو جاری رکھنے سے پہلے اسے فعال کریں۔

aws s3api put-bucket-versioning 
  --bucket your-existing-bucket 
  --versioning-configuration Status=Enabled

مرحلہ 3: Terraform بیک اینڈ کنفیگریشن کو اپ ڈیٹ کریں۔

براہ کرم اپ ڈیٹ کریں۔ backend.tf ہٹانے کے لیے dynamodb_table دلائل اور اضافے use_lockfile = true:

terraform {
  backend "s3" {
    bucket = "your-existing-bucket"
    key    = "path/to/terraform.tfstate"
    region = "us-east-1"
    encrypt = true
 
    # Add this:
    use_lockfile = true
 
    # Remove this line entirely:
    # dynamodb_table = "your-dynamodb-lock-table"
  }
}

اپ ڈیٹ backend.tf یہ اس طرح ہونا چاہئے:

terraform {
  backend "s3" {
    bucket       = "your-existing-bucket"
    key          = "path/to/terraform.tfstate"
    region       = "us-east-1"
    encrypt      = true
    use_lockfile = true
  }
}

مرحلہ 4: ٹیرافارم کو دوبارہ شروع کریں۔

چلائیں terraform init اور -reconfigure پرچم یہ جھنڈا Terraform کو بتاتا ہے کہ بیک اینڈ کنفیگریشن کو جان بوجھ کر تبدیل کیا گیا ہے اور اسے ریاست کی کاپی کرنے کا اشارہ کرنے کے بجائے اسے دوبارہ شروع کرنے کی ہدایت کرتا ہے (ریاست پہلے سے ہی اسی بالٹی میں ہے)۔

terraform init -reconfigure

متوقع پیداوار:

Initializing the backend...
 
Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.
 
Initializing provider plugins...
- Reusing previous version of hashicorp/aws from the dependency lock file
 
Terraform has been successfully initialized!

اگر آپ کو یہاں کوئی غلطی نظر آتی ہے: سب سے عام وجہ یہ ہے کہ بالٹی پر آبجیکٹ لاکنگ کو کامیابی سے فعال نہیں کیا گیا ہے۔ جاری رکھنے سے پہلے مرحلہ 2 میں تصدیق کو دوبارہ چلائیں۔

مرحلہ 5: منتقلی کی تصدیق کریں۔

یہ یقینی بنانے کے لیے اپنا پلان چلائیں کہ Terraform آپ کی نئی بیک اینڈ کنفیگریشن کے ساتھ صحیح طریقے سے کام کرے۔

terraform plan

منصوبہ ہونا چاہئے:

• کامیابی سے مکمل

• وہی نتائج دکھائیں جو آپ نے مرحلہ 1 میں لاگو کیا تھا (کوئی تبدیلی یا پہلے جیسی تبدیلیاں نہیں)

• اپنے آؤٹ پٹ میں کہیں بھی DynamoDB کا ذکر نہ کریں۔

اس بات کی تصدیق کرنے کے لیے کہ لاک دراصل DynamoDB کے بجائے S3 استعمال کر رہا ہے، دوسرا ٹرمینل کھولیں اور پہلا ٹرمینل چلنے کے دوران اپنا پلان چلائیں۔ دوسرے ٹرمینل میں، آپ کو ایک لاکنگ ایرر آؤٹ پٹ نظر آئے گا جس میں S3 کا ذکر ہوگا نہ کہ DynamoDB کا۔

╷
│ Error: Error acquiring the state lock
│
│Error message: operation error S3: PutObject, https response       error StatusCode: 409,
│ RequestID: ..., api error Conflict: Object lock already exists for this key.
│
│ Lock Info:
│   ID:        a1b2c3d4-e5f6-7890-abcd-ef1234567890
│   Path:      your-existing-bucket/path/to/terraform.tfstate.tflock
│   Operation: OperationTypePlan
│   Who:       user@hostname
│   Version:   1.10.0
│   Created:   2026-05-06 14:22:01 UTC
│   Info:
╵

کہ Path فیلڈ شو .tfstate.tflockیہ S3 بالٹی میں فائل ہے، DynamoDB ریکارڈ نہیں۔ یہ اس بات کی تصدیق کرتا ہے کہ لاکنگ کو اب مکمل طور پر S3 کے ذریعے سنبھال لیا گیا ہے۔

مرحلہ 6: اپنے DynamoDB ٹیبل کو صاف کریں۔

ایک بار جب آپ نے تصدیق کر لی کہ منتقلی صحیح طریقے سے کام کر رہی ہے اور آپ کی ٹیم نے اسے کم از کم ایک بار کامیابی سے چلایا ہے۔ plan اور apply جیسا کہ آپ نئے بیک اینڈ کا استعمال کرتے ہوئے سائیکل سے گزرتے ہیں، آپ اپنے DynamoDB ٹیبلز کو ہٹا سکتے ہیں۔

اپنے DynamoDB ٹیبل کو حذف کرنے سے پہلے کم از کم 24 سے 48 گھنٹے انتظار کریں۔ اگر آپ کے پاس CI/CD پائپ لائن ہے یا آپ کے متعدد ٹیم ممبران ہیں۔ اس سے آپ کو کسی بھی پائپ لائن کو پکڑنے کا وقت ملتا ہے جو نئی بیک اینڈ کنفیگریشن کے ساتھ اپ ڈیٹ نہیں ہوئی ہیں۔

جب آپ تیار ہوں، DynamoDB ٹیبل کو حذف کریں۔

aws dynamodb delete-table 
  --table-name your-dynamodb-lock-table

حذف کرنے کی تصدیق کریں۔

aws dynamodb describe-table 
  --table-name your-dynamodb-lock-table

متوقع پیداوار:

An error occurred (ResourceNotFoundException) when calling the DescribeTable operation:
Requested resource not found

یہ خرابی اس بات کی تصدیق کرتی ہے کہ ٹیبل غائب ہو گیا ہے۔ ہجرت مکمل ہو چکی ہے۔

اگر آپ نے اپنے DynamoDB ٹیبل کو Terraform (تجویز کردہ پیٹرن) کا استعمال کرتے ہوئے فراہم کیا ہے، تو Terraform کنفیگریشن سے وسائل کو ہٹائیں اور چلائیں: terraform apply براہ راست CLI استعمال کرنے کے بجائے Terraform کے ذریعے حذف کریں۔ یہ اسے صاف رکھے گا۔

# Remove this entire block from your Terraform configuration:
resource "aws_dynamodb_table" "terraform_state_lock" {
  name         = "terraform-state-lock"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"
 
  attribute {
    name = "LockID"
    type = "S"
  }
}

بلاک کو ہٹانے کے بعد، چلائیں:

terraform apply

Terraform پتہ لگاتا ہے کہ DynamoDB ٹیبل ریسورس کو کنفیگریشن سے ہٹا دیا گیا ہے اور ٹیبل کو حذف کر دیا ہے۔

یہ کیسے چیک کریں کہ آیا لاک کام کر رہا ہے۔

ایک نیا سیٹ اپ یا منتقلی مکمل کرنے کے بعد، اس طریقہ کار کو آزادانہ طور پر تصدیق کرنے کے لیے استعمال کریں کہ آپ کے تالے صحیح طریقے سے کام کر رہے ہیں۔

طریقہ 1: آپریشن کے دوران لاک فائلوں کا مشاہدہ کریں۔

ایک ٹرمینل سے وسائل سے بھرپور کنفیگریشنز کے لیے طویل مدتی منصوبے شروع کریں۔

terraform plan

جب یہ چل رہا ہو، دوسرے ٹرمینل میں S3 پر لاک فائل کو چیک کریں۔

aws s3 ls s3://your-bucket/path/to/ | grep tflock

آپ اس طرح کی فائلیں دیکھیں گے:

2026-05-06 14:22:01        512 terraform.tfstate.tflock

ایک بار جب آپ کا منصوبہ مکمل ہوجائے تو، وہی کمانڈ دوبارہ چلائیں۔ کہ .tflock فائل غائب ہونی چاہئے۔

طریقہ 2: لاک فائل کے مواد کو پڑھیں

جب آپ کا منصوبہ چل رہا ہو، لاک فائل کو ڈاؤن لوڈ کریں اور اس کے مواد کی تصدیق کے لیے پڑھیں۔

aws s3 cp 
  s3://your-bucket/path/to/terraform.tfstate.tflock 
  /tmp/current.lock && cat /tmp/current.lock

متوقع آؤٹ پٹ (پڑھنے کی اہلیت کے لیے فارمیٹ کیا گیا):

{
  "ID": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "Operation": "OperationTypePlan",
  "Info": "",
  "Who": "tolani@dev-machine",
  "Version": "1.10.0",
  "Created": "2026-05-06T14:22:01.123456789Z",
  "Path": "your-bucket/path/to/terraform.tfstate"
}

یہ وہی تالا کی معلومات ہے جو Terraform ظاہر کرتا ہے جب ایک تالا لگایا جاتا ہے۔ اب یہ DynamoDB میں ریکارڈ نہیں ہے، بلکہ S3 میں JSON فائل ہے۔

پھنسے ہوئے تالے سے کیسے نمٹا جائے۔

DynamoDB بیک اینڈ میں، پھنسے ہوئے لاک کو حل کرنے کا مطلب ہے DynamoDB ٹیبل سے ریکارڈ کو حذف کرنا۔ S3 ڈیفالٹ لاکنگ کے ساتھ، .tflock S3 میں فائلیں۔

مندرجہ ذیل صورتوں میں تالا جام ہو سکتا ہے:

• کوئی راستہ نہیں terraform apply یا plan چلتے چلتے عمل کو ختم کر دیا گیا۔

• ٹیرافارم آپریشن کے دوران CI/CD پائپ لائن ایگزیکیوٹر کریش ہو گیا۔

• نیٹ ورک کی بندش کی وجہ سے غیر مقفل کرنا مکمل نہیں ہوا۔

یہ چیک کرنے کا طریقہ ہے کہ آیا آپ کا لاک لاک ہے:

aws s3 ls s3://your-bucket/path/to/ | grep tflock

اگر .tflock اگر فائل موجود ہے اور فی الحال کوئی Terraform جاب نہیں چل رہی ہے، تو یہ مقفل ہے۔

تالا پڑھ کر آپ یہ جان سکتے ہیں کہ اسے کس نے رکھا ہے۔

aws s3 cp 
  s3://your-bucket/path/to/terraform.tfstate.tflock 
  /tmp/stuck.lock && cat /tmp/stuck.lock

یہ وہ ہے جو (Who فیلڈ) ایک کام انجام دے رہا تھا، یہ کون سا کام تھا (Operation فیلڈ)، حصول کا وقت (Created فیلڈ)۔

آپ Terraform کو اس طرح استعمال کرکے زبردستی انلاک کرسکتے ہیں:

terraform force-unlock LOCK-ID

تبدیلی LOCK-ID اور ID لاک فائل کے مواد کی قدر۔ مثال کے طور پر:

terraform force-unlock a1b2c3d4-e5f6-7890-abcd-ef1234567890

Terraform مندرجہ ذیل کو چیک کرتا ہے:

Do you really want to force-unlock?
  Terraform will remove the lock on the remote state.
  This will allow local Terraform commands to modify this state, even though it
  may be still be in use. Only 'yes' will be accepted to confirm.
 
  Enter a value: yes
 
Terraform state has been successfully unlocked!

ایک متبادل یہ ہے کہ لاک فائل کو براہ راست CLI کے ذریعے حذف کیا جائے۔ اگر terraform force-unlock اگر یہ کام نہیں کرتا ہے (مثال کے طور پر کیونکہ آپ CI ماحول میں چل رہے ہیں جہاں Terraform دستیاب نہیں ہے)، خود لاک فائل کو حذف کرنے کی کوشش کریں۔

aws s3 rm s3://your-bucket/path/to/terraform.tfstate.tflock

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

رول بیک پلان: اگر کچھ غلط ہو جاتا ہے۔

اگر آپ کو منتقلی کے بعد مسائل کا سامنا کرنا پڑتا ہے، تو آپ ان مراحل پر عمل کر کے اپنے S3 + DynamoDB سیٹ اپ پر واپس جا سکتے ہیں:

مرحلہ 1: تمام Terraform کاموں کو روک دیں۔ آپ کی ٹیم اور CI/CD پائپ لائن میں۔

مرحلہ 2: DynamoDB ٹیبل کو دوبارہ بنائیں اگر آپ اسے پہلے ہی حذف کر چکے ہیں:

aws dynamodb create-table 
  --table-name terraform-state-lock 
  --attribute-definitions AttributeName=LockID,AttributeType=S 
  --key-schema AttributeName=LockID,KeyType=HASH 
  --billing-mode PAY_PER_REQUEST

مرحلہ 3: واپس جائیں۔ backend.tf پچھلی ترتیب کے ساتھ:

terraform {
  backend "s3" {
    bucket         = "your-existing-bucket"
    key            = "path/to/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-state-lock"   # restored
    # Remove: use_lockfile = true
  }
}

مرحلہ 4: دوبارہ شروع کریں:

terraform init -reconfigure

مرحلہ 5: تصدیق کریں:

terraform plan

اسٹیٹ فائل کو منتقل نہیں کیا گیا ہے، لہذا رول بیک کے دوران کوئی ڈیٹا ضائع نہیں ہوتا ہے۔ صرف ایک تبدیلی ہے تالا لگانے کا طریقہ کار Terraform استعمال کرتا ہے۔

میمو: S3 بالٹی پر آبجیکٹ لاکنگ کو فعال کرنا رول بیکس کو نہیں روکتا ہے۔ آبجیکٹ لاکنگ اور DynamoDB لاکنگ ایک ساتھ رہ سکتے ہیں۔ آبجیکٹ لاکنگ بالٹی میں آسانی سے فعالیت کا اضافہ کرتا ہے۔ استعمال کریں dynamodb_table آپ کی بیک اینڈ کنفیگریشن میں، آپ Terraform کو DynamoDB استعمال کرنے کی ہدایت دیتے ہیں اس سے قطع نظر کہ آپ کی بالٹی پر آبجیکٹ لاکنگ فعال ہے یا نہیں۔

ریاستی بالٹیوں کے لیے سیکیورٹی کے بہترین طریقے

S3 مقامی تالے میں منتقل ہونا آپ کی ریاست کی بالٹی کی مجموعی حفاظتی ترتیب کا جائزہ لینے کا ایک اچھا موقع ہے۔ یہاں کچھ طرز عمل ہیں جن پر ہر پروڈکشن ٹیرافارم اسٹیٹ بالٹی کو لاگو کرنا چاہئے:

ورژننگ کو فعال کریں (ضروری)

S3 مقامی تالے کو محفوظ طریقے سے چلانے کے لیے ورژن بنانا ایک سخت ضرورت ہے۔ اگر آپ کی اسٹیٹ فائل غلطی سے اوور رائٹ یا خراب ہو گئی ہے، تو آپ پچھلے ورژن کو بحال کر سکتے ہیں۔

aws s3api put-bucket-versioning 
  --bucket your-state-bucket 
  --versioning-configuration Status=Enabled

تمام عوامی رسائی کو مسدود کریں (غیر گفت و شنید)

ریاستی فائلوں میں ریسورس ARNs، IP ایڈریسز ہوتے ہیں، اور یہ Terraform متغیرات سے گزری ہوئی اہم اقدار پر مشتمل ہو سکتی ہے۔ عوامی طور پر قابل رسائی نہیں ہونا چاہئے۔

aws s3api put-public-access-block 
  --bucket your-state-bucket 
  --public-access-block-configuration 
    "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

سرور سائڈ انکرپشن کو فعال کریں۔

باقی فائلوں کو ہمیشہ انکرپٹ کریں۔ AES256 کم از کم ہے۔ اگر آپ کی تنظیم کو KMS کلیدی انتظام کی ضرورت ہے:

aws s3api put-bucket-encryption 
  --bucket your-state-bucket 
  --server-side-encryption-configuration '{
    "Rules": [
      {
        "ApplyServerSideEncryptionByDefault": {
          "SSEAlgorithm": "aws:kms",
          "KMSMasterKeyID": "arn:aws:kms:us-east-1:123456789012:key/your-kms-key-id"
        },
        "BucketKeyEnabled": true
      }
    ]
  }'

کم سے کم مراعات یافتہ IAM اجازتوں کا اطلاق کریں۔

ریاستی بالٹی تک رسائی کے لیے Terraform جو کردار یا صارف استعمال کرتا ہے اس کے پاس صرف ضروری اجازتیں ہونی چاہئیں۔ S3 ڈیفالٹ لاکنگ کے لیے کم از کم IAM پالیسی ہے:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "TerraformStateAccess",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": [
        "arn:aws:s3:::your-state-bucket",
        "arn:aws:s3:::your-state-bucket/*"
      ]
    },
    {
      "Sid": "TerraformStateLocking",
      "Effect": "Allow",
      "Action": [
        "s3:GetObjectLegalHold",
        "s3:PutObjectLegalHold",
        "s3:GetObjectRetention",
        "s3:PutObjectRetention"
      ],
      "Resource": "arn:aws:s3:::your-state-bucket/*.tflock"
    }
  ]
}

یاد رکھیں کہ کیا غائب ہے۔ آپ کے پاس DynamoDB کی اجازت نہیں ہے۔ اس کے لیے پچھلے طریقوں سے صاف اور چھوٹے اجازتوں کا سیٹ درکار ہے۔

رسائی لاگنگ کو فعال کریں۔

CloudTrail یا S3 سرور تک رسائی کے لاگز میں اپنے ہیلتھ بالٹی تک تمام رسائی کو لاگ ان کریں۔ یہ ایک آڈٹ ٹریل فراہم کرتا ہے جب بھی اسٹیٹ کو پڑھا، لکھا یا لاک کیا جاتا ہے۔

aws s3api put-bucket-logging 
  --bucket your-state-bucket 
  --bucket-logging-status '{
    "LoggingEnabled": {
      "TargetBucket": "your-logging-bucket",
      "TargetPrefix": "terraform-state-access/"
    }
  }'

نتیجہ

AWS S3 ڈیفالٹ اسٹیٹ لاکنگ آپ کے Terraform بیک اینڈ سیٹ اپ میں DynamoDB ٹیبلز کی ضرورت کو ختم کر دیتی ہے۔ نتیجہ آسان انفراسٹرکچر، چھوٹی IAM اجازتیں، اور آپ کی ٹیم کے لیے آپ کے زیر انتظام ہر ماحول میں فراہمی، نگرانی اور ادائیگی کے لیے ایک کم سروس ہے۔

آپ نے جو کچھ حاصل کیا ہے اس کا خلاصہ یہ ہے:

• اب آپ سمجھ گئے ہیں کہ اسٹیٹ لاکنگ کیا ہے اور محفوظ Terraform آپریشنز کے لیے یہ کیوں ضروری ہے۔

• S3 مقامی لاکنگ کا روایتی S3 + DynamoDB اپروچ سے موازنہ کرنا

• صحیح بالٹی کنفیگریشن کے ساتھ S3 ڈیفالٹ لاکنگ کا استعمال کرتے ہوئے ایک نیا Terraform بیک اینڈ سیٹ کرنا

• ہمارے موجودہ بیک اینڈ کو S3 + DynamoDB سے S3 مقامی لاکنگ میں محفوظ طریقے سے منتقل کر دیا گیا۔

• آپ نے سیکھا کہ کس طرح تالے کی جانچ کرنا، پھنسے ہوئے تالے کو ہینڈل کرنا، اور اگر ضروری ہو تو رول بیک کرنا۔

• صحت کی بالٹیوں پر سیکیورٹی کے بہترین طریقوں کا اطلاق کریں۔

S3 مقامی لاکنگ کو استعمال کرنے کا یہ نمونہ AWS پر تمام نئے Terraform پروجیکٹس کے لیے تجویز کردہ طریقہ ہے۔ اگر آپ متعدد ٹیرافارم بیک اینڈز کے ساتھ ایک بڑے اثاثے کا انتظام کر رہے ہیں، تو اسکرپٹ یا ٹیرافارم ماڈیول کا استعمال کرتے ہوئے خودکار منتقلی پر غور کریں جو تمام ریاستی بالٹیوں پر پیٹرن کا اطلاق کرتا ہے۔

اگر آپ اسٹارٹ اپ کے لیے کلاؤڈ انفراسٹرکچر بنا رہے ہیں یا بہتر کر رہے ہیں اور پروڈکشن کے لیے تیار ٹیرافارم ماڈیولز، CI/CD پائپ لائن پیٹرن، اور انفراسٹرکچر رن بکس کا مکمل حوالہ چاہتے ہیں، تو چیک کریں: اسٹارٹ اپ DevOps فیلڈ گائیڈ. ہم آپ کے AWS انفراسٹرکچر کی پوری زندگی کا احاطہ کرتے ہیں، ابتدائی سیٹ اپ سے لے کر پیداواری اعتبار تک۔

حوالہ جات