Terraform AWS ट्यूटोरियल: EC2 पर एजेंट डिप्लॉयमेंट ऑटोमेशन

मैंने AWS कंसोल में अनगिनत घंटे क्लिक करते हुए बिताए हैं—हाथों-हाथ EC2 इंस्टैंस लॉन्च करना, सिक्योरिटी ग्रुप्स कॉन्फ़िगर करना, और अनिवार्य रूप से ऐसी गलतियाँ करना जिनकी डिबगिंग में घंटे लग जाते हैं। क्या यह परिचित लगता है? आप गलत उपलब्धता ज़ोन में इंस्टैंस बना देते हैं, किसी संसाधन को टैग करना भूल जाते हैं, या पिछले महीने जो कॉन्फ़िगरेशन बनाया था उसे फिर से बनाने में दोपहर गंवा देते हैं क्योंकि आपने चरणों का दस्तावेज़ीकरण नहीं किया था। 

मैन्युअल इन्फ्रास्ट्रक्चर प्रोविज़निंग सिर्फ़ उबाऊ नहीं है—यह त्रुटि-प्रवण, स्केलेबल नहीं, और ऑडिट करना लगभग असंभव है। यहीं Terraform सब कुछ बदल देता है। कल्पना कीजिए कि आप अपनी पूरी AWS इन्फ्रास्ट्रक्चर को टेक्स्ट फ़ाइलों में परिभाषित कर रहे हैं, जिन्हें आप वर्ज़न कंट्रोल में रख सकते हैं, रिव्यू कर सकते हैं, और ऑटोमैटिक रूप से डिप्लॉय कर सकते हैं। अब दर्जनों स्क्रीन पर क्लिक करने की ज़रूरत नहीं। और न ही टीम में "मेरी मशीन पर तो चल रहा था" जैसी बहसें।

इस ट्यूटोरियल में, मैं आपको Terraform का उपयोग करके AWS इन्फ्रास्ट्रक्चर ऑटोमेट करना सिखाऊँगा, एक वास्तविक उदाहरण पर ध्यान देते हुए: एक ऐसा EC2 इंस्टैंस प्रोविज़न करना जिसमें SSM (Systems Manager) एजेंट अपने-आप बूटस्ट्रैप्ड हो। अंत तक, आप Infrastructure as Code की बुनियादी बातों को समझेंगे और आपके पास काम करने वाला कोड होगा जिसे आप तुरंत अपने AWS अकाउंट पर डिप्लॉय कर सकते हैं।

यदि आप AWS में नए हैं, तो हमारे किसी कोर्स पर विचार करें, जैसे AWS Concepts, Introduction to AWS Boto in Python, या AWS Security and Cost Management. 

Terraform क्या है?

Terraform HashiCorp द्वारा बनाया गया एक ओपन‑सोर्स Infrastructure as Code (IaC) टूल है, जो आपको HashiCorp Configuration Language (HCL) का उपयोग करके क्लाउड संसाधनों को परिभाषित, प्रोविज़न और प्रबंधित करने देता है। 

क्लाउड कंसोल्स में क्लिक करने या इम्पेरेटिव bash स्क्रिप्ट लिखने के बजाय, आप कॉन्फ़िगरेशन फ़ाइलों में यह घोषित करते हैं कि आपको कौन-सी इन्फ्रास्ट्रक्चर चाहिए, और Terraform उसे लागू करने का सारा काम संभालता है। इम्पेरेटिव से डिक्लेरेटिव इन्फ्रास्ट्रक्चर की यह शिफ्ट क्लाउड संसाधनों के बारे में हमारी सोच को मौलिक रूप से बदल देती है। 

AWS EC2 इंस्टैंस लॉन्च करने के लिए इम्पेरेटिव बनाम डिक्लेरेटिव दृष्टिकोण

इम्पेरेटिव तरीकों में, आप चरण-दर-चरण निर्देश लिखते हैं: "पहले यह सिक्योरिटी ग्रुप बनाओ, फिर उसके बन जाने का इंतज़ार करो, फिर इस सिक्योरिटी ग्रुप के साथ यह इंस्टैंस लॉन्च करो, फिर यह वॉल्यूम अटैच करो, फिर ये टैग्स बनाओ।" हर चरण के क्रम और त्रुटि‑संभाल की ज़िम्मेदारी आप पर होती है। 

Terraform के डिक्लेरेटिव दृष्टिकोण में, आप बस अंतिम स्थिति परिभाषित करते हैं: "मुझे इन विशिष्टताओं वाला EC2 इंस्टैंस चाहिए, जो इस सिक्योरिटी ग्रुप से जुड़ा हो और इन टैग्स के साथ हो।" Terraform निर्भरताएँ विश्लेषित करता है, सही क्रम निर्धारित करता है और योजना निष्पादित करता है। यदि कुछ विफल होता है, तो Terraform को ठीक-ठीक पता होता है कि वह कहाँ तक पहुँचा था।

खासकर AWS के लिए Terraform क्यों चुनें? 

1. पहला, समुदाय का इकोसिस्टम बहुत बड़ा है—लगभग हर कल्पनीय AWS सेवा के लिए आपको मॉड्यूल्स, उदाहरण और समाधान मिलेंगे। 
2. दूसरा, Terraform प्रोवाइडर‑न्यूट्रल है। एक बार सीख लें, वही स्किल्स और पैटर्न AWS, Azure, GCP और अन्य प्लेटफ़ॉर्म पर काम करते हैं। वेंडर लॉक‑इन से बचें और वर्कफ़्लो सुसंगत रखें। 
3. तीसरा, Terraform की स्टेट मैनेजमेंट प्रणाली हर संसाधन को ट्रैक करती है, जिससे अपडेट और बदलाव पूर्वानुमेय बनते हैं। Terraform जानता है कि आपने क्या बनाया है और उसे सुरक्षित रूप से बदल या नष्ट कर सकता है।

हैंड्स‑ऑन कॉन्फ़िगरेशन में जाने से पहले, तीन प्रमुख अवधारणाएँ समझना ज़रूरी है जो Terraform की नींव बनाती हैं:

• Resources वे इन्फ्रास्ट्रक्चर घटक हैं जिन्हें आप बनाते हैं—EC2 इंस्टैंसेज़, S3 बकेट्स, सिक्योरिटी ग्रुप्स। 
• Providers वे प्लगइन्स हैं जो Terraform को विभिन्न प्लेटफ़ॉर्म्स के साथ इंटरेक्ट करने देते हैं; AWS प्रोवाइडर आपका HCL AWS API कॉल्स में अनुवाद करता है। 
• HCL वह मानव‑पठनीय सिंटैक्स है जिसका उपयोग आप इन्फ्रास्ट्रक्चर परिभाषित करने के लिए करेंगे—अभिव्यंजक और सरल, दोनों होने के लिए डिज़ाइन किया गया।

इन बुनियादों के साथ, अब अपना वातावरण वास्तविक इन्फ्रास्ट्रक्चर बनाने के लिए तैयार करते हैं। 

अपना Terraform AWS वातावरण सेट करना

कोई भी Terraform कोड लिखने से पहले, आपको CLI इंस्टॉल करना होगा और AWS क्रेडेंशियल्स कॉन्फ़िगर करने होंगे। मैं दोनों के बारे में बताता हूँ।

Terraform इंस्टॉल करें

Terraform इंस्टॉल करना आपके ऑपरेटिंग सिस्टम पर निर्भर करता है:

• macOS पर Homebrew का उपयोग करें: पहले brew tap hashicorp/tap से HashiCorp tap जोड़ें, फिर brew install hashicorp/tap/terraform से Terraform इंस्टॉल करें। 

• Windows पर, hashicorp.com से बाइनरी डाउनलोड करें और PATH में जोड़ें, या Chocolatey का उपयोग करें: choco install terraform. 

• Linux पर, उपयुक्त पैकेज डाउनलोड करें या अपने डिस्ट्रीब्यूशन के पैकेज मैनेजर का उपयोग करें। 

इंस्टॉल होने के बाद, terraform version चलाकर इंस्टॉलेशन जाँचें।

AWS क्रेडेंशियल्स कॉन्फ़िगर करें

AWS क्रेडेंशियल्स कॉन्फ़िगर करना के लिए एक AWS अकाउंट, एक एक्सेस की और IAM से एक सीक्रेट की की आवश्यकता होती है। कभी भी अपने रूट अकाउंट का उपयोग न करें। इसके बजाय, प्रोग्रामेटिक एक्सेस और उपयुक्त अनुमतियों (AdministratorAccess) के साथ एक IAM यूज़र बनाएँ। मानक तरीका ~/.aws/credentials पर AWS क्रेडेंशियल्स फ़ाइल का उपयोग करता है:

[default]
aws_access_key_id = YOUR_ACCESS_KEY
aws_secret_access_key = YOUR_SECRET_KEYसंचालित द्वारा

वैकल्पिक रूप से, वातावरण वेरिएबल्स सेट करें: AWS_ACCESS_KEY_ID और AWS_SECRET_ACCESS_KEY। प्रोडक्शन वातावरण के लिए, लंबे समय तक जीवित रहने वाले क्रेडेंशियल्स के बजाय EC2 इंस्टैंसेज़ या CI/CD सिस्टम्स से अटैच्ड IAM रोल्स का उपयोग करें।

यदि आप Amazon के इकोसिस्टम से अलग किसी विकल्प के बारे में सोच रहे हैं या बस "बिग थ्री" की तुलना का अच्छा अवलोकन चाहते हैं, तो यह AWS, Azure, और GCP Service Comparison for Data Science & AI पढ़ने की सलाह देता हूँ।

AWS पर Terraform के साथ EC2 एजेंट डिप्लॉय करना

बुनियाद तैयार है, तो कुछ वास्तविक बनाते हैं: एक EC2 इंस्टैंस जो स्टार्टअप पर अपने‑आप SSM एजेंट इंस्टॉल करता है।

प्रोजेक्ट स्ट्रक्चर सेट करना

Terraform प्रोजेक्ट्स एक स्पष्ट और संरचित दृष्टिकोण से लाभान्वित होते हैं। तीन फ़ाइलें बनाएँ: संसाधन परिभाषाओं के लिए main.tf, इनपुट्स के लिए variables.tf, और डिप्लॉयमेंट के बाद काम आने वाले मानों के लिए outputs.tf। यह विभाजन आपके कोड को व्यवस्थित और सुगम रखता है।

 aws-terraform
├── main.tf
├── output.tf
└── variables.tfसंचालित द्वारा

यह क्यों मायने रखता है: जैसे‑जैसे प्रोजेक्ट बढ़ता है, सब कुछ एक ही फ़ाइल में मिलाना असंभव हो जाता है। वेरिएबल्स आपको अलग‑अलग वातावरण (dev, staging, production) में वही कोड इनपुट बदलकर पुन: उपयोग करने देते हैं। आउटपुट्स वे मान प्रदान करते हैं जिनकी आपको ज़रूरत होगी, जैसे इंस्टैंस IDs या IP पते—AWS कंसोल में मैन्युअल खोज के बिना।

EC2 संसाधन कॉन्फ़िगरेशन लिखना

अब इन्फ्रास्ट्रक्चर बनाते हैं: SSM एजेंट प्री‑इंस्टॉल्ड वाला EC2 इंस्टैंस। main.tf फ़ाइल में निम्न कॉन्फ़िगरेशन जोड़ें:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

provider "aws" {
  region = "eu-central-1"
}

data "aws_ami" "amazon_linux" {
  most_recent = true
  
  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
  
  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
  
  owners = ["amazon"]
}

resource "aws_instance" "web_server" {
  ami           = data.aws_ami.amazon_linux.id
  instance_type = "t2.micro"
  
  iam_instance_profile = aws_iam_instance_profile.ssm_profile.name
  
  user_data = <<-EOF
              #!/bin/bash
              cd /tmp
              sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
              sudo systemctl enable amazon-ssm-agent
              sudo systemctl start amazon-ssm-agent
              EOF
  
  tags = {
    Name = "TerraformWebServer"
  }
}

resource "aws_iam_instance_profile" "ssm_profile" {
  name = "ec2-ssm-profile"
  role = aws_iam_role.ssm_role.name
}

resource "aws_iam_role" "ssm_role" {
  name = "ec2-ssm-role"
  
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = {
        Service = "ec2.amazonaws.com"
      }
    }]
  })
}

resource "aws_iam_role_policy_attachment" "ssm_policy" {
  role       = aws_iam_role.ssm_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}संचालित द्वारा

Terraform EC2 इंस्टैंस कॉन्फ़िगरेशन

data ब्लॉक AWS से सबसे हालिया Amazon Linux 2 AMI क्वेरी करता है। फ़िल्टर्स सही इमेज टाइप सुनिश्चित करते हैं, और owners = ["amazon"] यह सुनिश्चित करता है कि आप आधिकारिक Amazon AMIs का उपयोग कर रहे हैं। यह तरीका सभी रीज़न में बिना बदलाव के काम करता है—Terraform स्वचालित रूप से सही क्षेत्रीय AMI ढूँढ लेता है।

महत्त्वपूर्ण हिस्सा है user_data: एक शेल स्क्रिप्ट जो इंस्टैंस के पहले बूट पर चलती है। यह स्क्रिप्ट SSM एजेंट डाउनलोड और इंस्टॉल करती है, फिर उसे ऑटो‑स्टार्ट के लिए सक्षम करती है। IAM रोल SSM को इंस्टैंस मैनेज करने के लिए आवश्यक परमिशन्स देता है।

यही पैटर्न किसी भी एजेंट के लिए काम करता है। लॉग्स और मेट्रिक्स के लिए CloudWatch चाहिए? बस user_data स्क्रिप्ट को CloudWatch एजेंट इंस्टॉल करने के लिए संशोधित करें। सिद्धांत समान है: जो इंस्टॉल चाहिए उसे परिभाषित करें, और Terraform सुनिश्चित करेगा कि हर इंस्टैंस पर वह हो।

output.tf फ़ाइल के लिए, उदाहरण के तौर पर, आप इंस्टैंस ID जोड़ सकते हैं। फिर, जैसे‑जैसे आप अगला अध्याय कवर करने वाले सारे Terraform कमांड्स चलाते हैं, यह मान टर्मिनल में दिखेगा।

output "instance_id" {
  description = "EC2 instance ID for SSM connection"
  value       = aws_instance.web_server.id
}संचालित द्वारा

कॉन्फ़िगरेशन इनिशियलाइज़ और अप्लाई करना

कॉन्फ़िगरेशन लिख लेने के बाद, Terraform वर्कफ़्लो में तीन कमांड होते हैं। सबसे पहले, निम्न कमांड AWS प्रोवाइडर प्लगइन डाउनलोड करता है और आपकी डायरेक्टरी तैयार करता है:

terraform initसंचालित द्वारा

terraform init

दूसरा, terraform plan ठीक‑ठीक दिखाता है कि Terraform क्या बनाएगा, बदलेगा या नष्ट करेगा। यह प्रीव्यू वास्तविक बदलावों से पहले गलतियाँ पकड़ने देता है:

terraform planसंचालित द्वारा

terraform plan

आउटपुट ध्यान से जाँचें। आप देखेंगे कि Terraform कौन‑कौन से संसाधन बनाएगा—EC2 इंस्टैंस, IAM रोल, इंस्टैंस प्रोफ़ाइल, और पॉलिसी अटैचमेंट।

अंत में, terraform apply बदलावों को लागू करता है। आगे बढ़ने से पहले Terraform पुष्टि माँगेगा। यह कमांड चलाने के बाद yes टाइप करें:

terraform applyसंचालित द्वारा

terraform apply

यदि सब कुछ ठीक रहा, तो संसाधन बन जाने के बाद आपको निम्न संदेश दिखाई देगा। 

पुष्टि: Terraform संसाधन बनाए गए

कुछ ही मिनटों में, आपके पास SSM कॉन्फ़िगर किया हुआ एक चलता हुआ EC2 इंस्टैंस होगा, जिसे SSH कीज़ के बिना एक्सेस किया जा सकता है। हाल ही में बने संसाधनों को देखने के लिए AWS कंसोल में जाँच अवश्य करें।

AWS S3 पर Terraform स्टेट मैनेज करना

ऊपर दिए कमांड्स चलाने के बाद, आपको डायरेक्टरी में terraform.tfstate नाम की नई फ़ाइल दिखेगी। Terraform की स्टेट फ़ाइल आपकी कॉन्फ़िगरेशन को वास्तविक AWS संसाधनों से मैप करती है। आइए इस फ़ाइल की सामग्री समझते हैं।

स्टेट फ़ाइल को समझना

स्टेट फ़ाइल में आपके डिप्लॉय किए गए इन्फ्रास्ट्रक्चर का हर विवरण होता है: संसाधन IDs, IP पते और निर्भरताएँ। Terraform इस स्टेट की तुलना आपकी कॉन्फ़िगरेशन और AWS की वास्तविक स्थिति से करता है, ताकि यह तय कर सके कि कौन‑सी कार्रवाइयाँ करनी हैं। यदि स्टेट फ़ाइल खो जाती है, तो Terraform इस बात का ट्रैक खो देता है कि उसने क्या बनाया था।

स्टेट को अपने लैपटॉप पर रखना जोखिम भरा है। यदि मशीन क्रैश हो जाए, तो स्टेट गायब हो सकता है। यदि कई टीम सदस्य एक ही इन्फ्रास्ट्रक्चर पर काम करें, तो अलग‑अलग लोकल स्टेट्स टकराव और करप्शन का कारण बनते हैं। समाधान: रिमोट स्टेट स्टोरेज।

S3 और EFS में गहराई से जाने के लिए, यह AWS Storage Tutorial देखें।

रिमोट S3 बैकएंड कॉन्फ़िगर करना

Terraform का S3 बैकएंड स्टेट को केंद्रीकृत, टिकाऊ स्थान पर स्टोर करता है, जो आपकी पूरी टीम के लिए उपलब्ध होता है। पहले, एक S3 बकेट बनाएँ:

aws s3api create-bucket \
  --bucket datacamp-terraform-state \
  --region eu-central-1 \ 
   --create-bucket-configuration LocationConstraint=eu-central-1

aws s3api put-bucket-versioning \
  --bucket datacamp-terraform-state \
  --versioning-configuration Status=Enabledसंचालित द्वारा

वर्ज़निंग अत्यंत महत्त्वपूर्ण है: यह आपको दुर्घटनाओं से उबरने के लिए पिछले स्टेट वर्ज़न्स पर रोल‑बैक करने देता है।

अब, अपने Terraform कोड में बैकएंड कॉन्फ़िगरेशन जोड़ें:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }

  backend "s3" {
    bucket = "datacamp-terraform-state"
    key    = "terraform.tfstate"
    region = "eu-central-1"
    use_lockfile = true
  }  
}संचालित द्वारा

लोकल स्टेट को S3 में माइग्रेट करने के लिए terraform init फिर चलाएँ। स्टेट फ़ाइल को मूव करने से पहले Terraform पुष्टि माँगेगा।

Terraform S3 रिमोट बैकएंड

कमांड चलाने के बाद, S3 बकेट में नई स्टेट फ़ाइल होगी। आप इसे AWS कंसोल में जाँच सकते हैं।

नेटिव S3 लॉक फ़ाइलों से स्टेट लॉक करना

आपने देखा होगा कि हमने main.tf में यह सेटिंग जोड़ी है: use_lockfile = true। यह सेटिंग Terraform की नई सुविधा—नेटिव S3 स्टेट लॉकिंग—सक्षम करती है। पहले, लॉकिंग के लिए एक अलग DynamoDB तालिका की ज़रूरत होती थी।

Terraform लॉक स्टेट

यह सरलीकरण आपके इन्फ्रास्ट्रक्चर सेटअप से एक पूरे AWS सर्विस को हटा देता है, जबकि रेस कंडीशन्स से समान सुरक्षा प्रदान करता है। कई इंजीनियर सुरक्षित रूप से इन्फ्रास्ट्रक्चर पर काम कर सकते हैं, यह जानते हुए कि एक समय में केवल एक व्यक्ति के बदलाव लागू होंगे।

AWS पर Terraform के साथ इन्फ्रास्ट्रक्चर स्केल करना

जैसे‑जैसे आपकी इन्फ्रास्ट्रक्चर बढ़ती है, हार्डकोडेड मान और कॉपी‑पेस्ट किया हुआ कोड मेंटेनेंस के लिए दुःस्वप्न बन जाते हैं। Terraform की वेरिएबल प्रणाली और मॉड्यूल्स इस समस्या का समाधान हैं।

इनपुट वेरिएबल्स के साथ रिफ़ैक्टरिंग

पहले, हमने variables.tf फ़ाइल बनाई थी। अब आप वे मान, जो पहले main.tf में हार्डकोडेड थे, इस नई फ़ाइल में स्थानांतरित कर सकते हैं जो हमारे वेरिएबल्स रखेगी:

variable "aws_region" {
  description = "AWS region for resources"
  type        = string
  default     = "eu-central-1"
}

variable "instance_type" {
  description = "EC2 instance type"
  type        = string
  default     = "t2.micro"
}संचालित द्वारा

अब अपने संसाधनों में main.tf के अंदर वेरिएबल्स को संदर्भित करें:

provider "aws" {
  region = var.aws_region
}

resource "aws_instance" "web_server" {
  instance_type = var.instance_type
  # ... rest of configuration
  
  tags = {
    Environment = var.environment
  }
}संचालित द्वारा

ध्यान दें कि AWS S3 बकेट्स यूनिक होते हैं, इसलिए आप main.tf के backend पैरामीटर के रीज़न में वेरिएबल्स का उपयोग नहीं कर सकते। यहाँ आपको var.region_aws के बजाय “eu-central-1” जैसा हार्डकोडेड रीज़न रखना होगा।

अब जब हमारे वेरिएबल्स परिभाषित हो चुके हैं, आप अलग‑अलग वातावरण—जैसे डेवलपमेंट या प्रोडक्शन—भी परिभाषित कर सकते हैं, जहाँ वेरिएबल्स भिन्न हो सकते हैं। यह .tfvars एक्सटेंशन वाली नई फ़ाइलें बनाकर किया जाता है।

उदाहरण के लिए, आप डेवलपमेंट के लिए terraform-dev.tfvars और प्रोडक्शन के लिए terraform-prod.tfvars बना सकते हैं:

डेवलपमेंट:

aws_region    = "eu-central-1"
instance_type = "t2.micro"संचालित द्वारा

प्रोडक्शन:

aws_region    = "eu-central-1"
instance_type = "t3.medium"संचालित द्वारा

इसके बाद, उपयुक्त फ़ाइल निर्दिष्ट करके आप अलग‑अलग वातावरण में डिप्लॉय कर सकते हैं:

terraform apply -var-file="terraform-dev.tfvars”संचालित द्वारा

वेरिएबल्स वातावरण‑विशिष्ट मानों की समस्या सुलझाते हैं, लेकिन पूरी इन्फ्रास्ट्रक्चर पैटर्न की नकल करने का क्या? यहीं मॉड्यूल्स आवश्यक हो जाते हैं।

रीयूज़ेबल संसाधन मॉड्यूल्स बनाना

मॉड्यूल्स संबंधित संसाधनों को रीयूज़ेबल घटकों में पैकेज करते हैं। मॉड्यूल्स का सबसे अच्छा उपयोग एक विशिष्ट फ़ोल्डर बनाकर है। उदाहरण के लिए, आप इस तरह की डायरेक्टरी संरचना बना सकते हैं:

modules/
  ec2-with-ssm/
    main.tf
    variables.tf
    outputs.tfसंचालित द्वारा

आप पहले बनाई गई variables.tf फ़ाइल को मॉड्यूल फ़ोल्डर में स्थानांतरित कर सकते हैं (या नई बना सकते हैं)। मुख्य बदलाव main.tf में होता है। मॉड्यूल के अंदर वाली फ़ाइल हमारे संसाधन रखेगी। इसलिए AMI से लेकर फ़ाइल के अंत तक की सारी सामग्री वहाँ स्थानांतरित करें:

data "aws_ami" "amazon_linux" {
  most_recent = true
  
  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
  
  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
  
  owners = ["amazon"]
}

resource "aws_instance" "web_server" {
  ami           = data.aws_ami.amazon_linux.id
  instance_type = var.instance_type
  
  iam_instance_profile = aws_iam_instance_profile.ssm_profile.name
  
  user_data = <<-EOF
              #!/bin/bash
              cd /tmp
              sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
              sudo systemctl enable amazon-ssm-agent
              sudo systemctl start amazon-ssm-agent
              EOF
  
  tags = {
    Name = "TerraformWebServer"
  }
}

resource "aws_iam_instance_profile" "ssm_profile" {
  name = "ec2-ssm-profile"
  role = aws_iam_role.ssm_role.name
}

resource "aws_iam_role" "ssm_role" {
  name = "ec2-ssm-role"
  
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = {
        Service = "ec2.amazonaws.com"
      }
    }]
  })
}

resource "aws_iam_role_policy_attachment" "ssm_policy" {
  role       = aws_iam_role.ssm_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}संचालित द्वारा

इस बदलाव की जगह, आप मुख्य फ़ाइल के शेष हिस्से को रखें, लेकिन एक मॉड्यूल पैरामीटर जोड़ें जो विशिष्ट मॉड्यूल को संदर्भित करे।

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }

  backend "s3" {
    bucket = "datacamp-terraform-state"
    key    = "terraform.tfstate"
    region = "eu-central-1"
    use_lockfile = true
  }
}

provider "aws" {
  region = var.aws_region
}

module "web_server" {
  source = "./modules/ec2-with-ssm"
  
  instance_type = var.instance_type
}संचालित द्वारा

अब यदि आप इन सेटअप्स के साथ init, plan, और apply कमांड्स चलाएँगे, तो पहले जैसी ही संसाधन डिप्लॉयमेंट होगी। अंतर यह है कि मॉड्यूल्स आपको समान कॉन्फ़िगरेशन वाली इन्फ्रास्ट्रक्चर को पुन: उपयोग योग्य ढंग से लॉन्च करने देते हैं। सरल प्रोजेक्ट्स से आगे Terraform को स्केल करने के लिए ये अत्यंत महत्वपूर्ण हैं।

अब एक और महत्त्वपूर्ण विषय पर चलते हैं: सुरक्षा।

AWS पर Terraform के लिए सुरक्षा सर्वोत्तम प्रथाएँ

इन्फ्रास्ट्रक्चर कोड को भी एप्लिकेशन कोड जितनी ही सुरक्षा सख्ती चाहिए। इसलिए अपने Terraform डिप्लॉयमेंट्स की सुरक्षा करना अत्यावश्यक है।

सीक्रेट्स और संवेदनशील डेटा का प्रबंधन

कभी भी सीक्रेट्स Git में कमिट न करें। कभी नहीं। संवेदनशील मानों के लिए AWS Secrets Manager का उपयोग करें। Terraform में आप इसके लिए निम्न संसाधन का उपयोग कर सकते हैं:

resource "aws_secretsmanager_secret" "example" {
  name = "example"
}संचालित द्वारा

वातावरण‑विशिष्ट सीक्रेट्स के लिए, TF_VAR_ प्रीफ़िक्स वाले वातावरण वेरिएबल्स का उपयोग करें। 

उदाहरण के लिए, आप variables.tf फ़ाइल में variable "aws_access_key" {} उपयोग कर सकते हैं और टर्मिनल में export TF_VAR_aws_access_key=<access_key_value> से एक्सपोर्ट कर सकते हैं। Terraform इन्हें अपने‑आप वेरिएबल मानों के रूप में लोड कर लेता है, बिना कोड में उजागर किए।

कॉन्फ़िगरेशन ड्रिफ्ट से निपटना

एक और महत्त्वपूर्ण विषय है ड्रिफ्ट। यह तब होता है जब कोई AWS कंसोल या CLI के माध्यम से इन्फ्रास्ट्रक्चर में बदलाव करता है और Terraform को बाइपास कर देता है। ड्रिफ्ट का पता लगाने के लिए नियमित रूप से terraform plan चलाएँ। प्लान आउटपुट वे संसाधन दिखाता है जो आपकी कॉन्फ़िगरेशन से मेल नहीं खाते।

ड्रिफ्ट दिखने पर आपके पास दो विकल्प हैं: यदि मैनुअल बदलाव जानबूझकर था तो अपने Terraform कोड को वास्तविकता से मेल कराने के लिए अपडेट करें, या terraform apply चलाकर इन्फ्रास्ट्रक्चर को कोड में परिभाषित इच्छित स्थिति में वापस लाएँ। सही विकल्प इस पर निर्भर करता है कि मैनुअल परिवर्तन इरादतन था या नहीं।

संसाधनों की सफ़ाई

अंत में, यह भी महत्त्वपूर्ण है कि जब हमें संसाधनों की ज़रूरत न रहे तो उन्हें हटा दें, ताकि अनावश्यक लागत से बचा जा सके। निम्न कमांड से आप संसाधनों की सफ़ाई कर सकते हैं:

terraform destroyसंचालित द्वारा

विनाश योजना को सावधानी से जाँचें। Terraform वे सारे संसाधन हटा देगा जिन्हें उसने बनाया था। प्रोडक्शन में, सब कुछ हटाने के बजाय विशिष्ट संसाधन हटाने के लिए terraform destroy -target का उपयोग करने पर विचार करें।

निष्कर्ष

आपने Terraform का मुख्य वर्कफ़्लो सीखा: कोड में इन्फ्रास्ट्रक्चर परिभाषित करना, plan से बदलावों का प्रीव्यू देखना, apply से उन्हें लागू करना, और सब कुछ स्टेट मैनेजमेंट के साथ ट्रैक करना। हमने ऑटोमैटिक एजेंट इंस्टॉलेशन के साथ EC2 डिप्लॉयमेंट कवर किया, नेटिव लॉकिंग के साथ स्टेट को S3 में स्थानांतरित किया, वेरिएबल्स और मॉड्यूल्स से स्केल किया, और सीक्रेट्स मैनेजमेंट से सुरक्षा सुनिश्चित की।

इन्फ्रास्ट्रक्चर कोड के साथ उसी सख्ती से पेश आएँ जैसे एप्लिकेशन कोड के साथ। वर्ज़न कंट्रोल का उपयोग करें, बदलावों के लिए कोड रिव्यू अनिवार्य करें, और पहले नॉन‑प्रोडक्शन वातावरण में परीक्षण करें। CI/CD पाइपलाइन्स terraform apply को ऑटोमेट कर सकती हैं, जिससे इन्फ्रास्ट्रक्चर अपडेट्स एप्लिकेशन डिप्लॉयमेंट जितने सुचारु हो जाते हैं।

आपका अगला कदम: जब भी आप कोड पुश करें, Terraform को स्वतः चलाने के लिए GitHub Actions या GitLab CI का पता लगाएँ। यह Infrastructure as Code दृष्टिकोण, ऑटोमेशन के साथ मिलकर, टीमों के क्लाउड संसाधन प्रबंधन के तरीके को बदल देता है—मैनुअल कंसोल कार्य को विश्वसनीय, दोहराने योग्य, वर्ज़न‑कंट्रोल वाली इन्फ्रास्ट्रक्चर से प्रतिस्थापित करते हुए।

मेरी सिफारिश है कि आप इस ज्ञान पर आगे बढ़ें और AWS Cloud Practitioner (CLF-C02) स्किल ट्रैक में नामांकन करें, जो आपको Amazon की CLF‑C02 प्रमाणन पाने के लिए आवश्यक हर चीज़ सिखाता है।