Terraform Import: मौजूदा इंफ्रास्ट्रक्चर को कोड के तहत लाएँ

आपकी टीम सालों से कंसोल क्लिक्स और शेल स्क्रिप्ट्स के ज़रिए क्लाउड संसाधन तैनात करती रही है। अब आप Infrastructure as Code अपनाना चाहते हैं, लेकिन सबकुछ फिर से बनाना भारी लगता है। मैं भी इस स्थिति में रहा/रही हूँ, और Terraform का इम्पोर्ट फ़ंक्शनलिटी इस चुनौती का समाधान है।

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

इसीलिए संगठन Infrastructure as Code (IaC) अपनाते हैं। इस ट्यूटोरियल में, मैं आपको मौजूदा इंफ्रास्ट्रक्चर को Terraform में इम्पोर्ट करना सिखाऊँगा/सिखाऊँगी। 

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

यदि आप IaC और क्लाउड प्रदाताओं के लिए नए हैं, तो हमारे पाठ्यक्रमों में से कोई लें, जैसे AWS Concepts, Understanding Cloud Computing, या Understanding Microsoft Azure. 

Terraform Import क्या है?

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

लेकिन जब संसाधन Terraform की जानकारी के बाहर पहले से मौजूद हों तो क्या होता है? चलिए समझते हैं कि इम्पोर्ट वास्तव में क्या करता है और यह क्यों मौजूद है।

मुख्य परिभाषा और उद्देश्य

Terraform इम्पोर्ट बिना नए संसाधन बनाए मौजूदा वास्तविक इंफ्रास्ट्रक्चर को Terraform की स्टेट फ़ाइल में प्रविष्टियों से मैप करता है। इसे गोद लेने जैसा समझें: आप Terraform को बता रहे हैं कि वह किसी पहले से चल रहे संसाधन का प्रबंधन शुरू करे।

यह "शैडो आईटी" समस्या का समाधान करता है। संगठन कई तरीकों से इंफ्रास्ट्रक्चर इकट्ठा कर लेते हैं: आउटेज के दौरान कंसोल डिप्लॉयमेंट, अस्थायी टेस्ट संसाधन जो स्थायी हो गए, या IaC अपनाने से पहले के लेगेसी सिस्टम। इम्पोर्ट इस वास्तविकता को Infrastructure as Code सिद्धांतों से मिलाता है।

सबसे महत्वपूर्ण बात: इम्पोर्ट मुख्यतः स्टेट ऑपरेशन है। यह स्वतः कॉन्फ़िगरेशन कोड नहीं लिखता जब तक आप Terraform 1.5+ में जेनरेशन सुविधाएँ न इस्तेमाल करें। आपको यह सुनिश्चित करना होगा कि आपका HCL कॉन्फ़िगरेशन इम्पोर्ट किए गए संसाधन को सटीक रूप से दर्शाए।

अब जब हम समझ गए कि इम्पोर्ट क्या करता है, तो देखें कि इसे कब उपयोग करना चाहिए और कब नहीं।

Terraform इम्पोर्ट बनाम विकल्प

मैं तीन मुख्य परिदृश्यों में इम्पोर्ट की सिफारिश करता/करती हूँ:

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

हालाँकि, इम्पोर्ट हमेशा सही विकल्प नहीं होता। अस्थायी टेस्ट संसाधनों या कम मानकीकृत इंफ्रास्ट्रक्चर के लिए, मैं अक्सर साफ-सुथरी पुनर्रचना की सलाह देता/देती हूँ। 

नए सिरे से शुरू करने पर आप मौजूदा श्रेष्ठ प्रथाएँ लागू कर सकते हैं, सही नेमिंग कन्वेंशन अपना सकते हैं, और वे सुरक्षा कॉन्फ़िगरेशन जोड़ सकते हैं जो लेगेसी संसाधनों में नहीं हैं। पुनर्रचना का प्रारंभिक प्रयास अक्सर दीर्घकालिक मेंटेनबिलिटी में फ़ायदा देता है।

इम्पोर्ट को Terraform डेटा सोर्स से अलग समझना भी महत्त्वपूर्ण है। डेटा सोर्स मौजूदा इंफ्रास्ट्रक्चर से रीड-ओनली जानकारी संदर्भित करने देते हैं, बिना उसे मैनेज किए। उदाहरण के लिए, आप किसी दूसरे टीम द्वारा बनाए गए मौजूदा VPC को लुकअप करने के लिए डेटा सोर्स उपयोग कर सकते हैं, और फिर उसमें अपने संसाधन डिप्लॉय कर सकते हैं। 

इसके विपरीत, इम्पोर्ट संसाधनों को पूर्ण Terraform प्रबंधन में लाता है, जिसमें उन्हें संशोधित या नष्ट करने की क्षमता शामिल है। जब आपको किसी संसाधन का पूरा लाइफसाइकल मैनेज करना हो, सिर्फ़ संदर्भित नहीं, तब इम्पोर्ट चुनें।

इम्पोर्ट शुरू करने से पहले, कुछ बुनियादी बाधाएँ हैं जिन्हें समझना ज़रूरी है।

मुख्य बाधाएँ और बुनियादी बातें

हर इम्पोर्ट किए गए संसाधन के लिए एक अनूठा प्रोवाइडर-विशिष्ट पहचानकर्ता चाहिए। AWS के लिए यह i-0123456789abcdef0 जैसा हो सकता है। Azure के लिए यह पूरा रिसोर्स पाथ होता है, जैसे /subscriptions/{id}/resourceGroups/{rg}/providers/{provider}/{resource}। इसे गलत लेना इम्पोर्ट फेल होने का सबसे बड़ा कारण है।

इम्पोर्ट ऑपरेशन आपकी स्टेट फ़ाइल को सीधे संशोधित करते हैं, इसलिए बैकअप आवश्यक हैं। यदि S3 जैसे वर्शनयुक्त बैकएंड का उपयोग कर रहे हैं, तो वर्शनिंग सक्षम होने की जाँच करें। लोकल स्टेट के साथ, मैन्युअल रूप से terraform.tfstate.backup में कॉपी करें।

इम्पोर्ट के बाद आपको "ड्रिफ्ट" का सामना करना पड़ेगा: इम्पोर्ट की गई स्टेट और लोकल कॉन्फ़िगरेशन के बीच असंगति। आप अपना HCL कोड क्रमिक रूप से अपडेट करेंगे जब तक कि terraform plan शून्य लंबित बदलाव दिखाए।

Terraform इम्पोर्ट के लिए पूर्वापेक्षाएँ और तैयारी 

कुछ भी इम्पोर्ट करने से पहले, सफलता के लिए सेटअप सुनिश्चित करें। मैंने ऐसे इम्पोर्ट देखे हैं जो टीमों द्वारा तैयारी चरण छोड़ने के कारण गलत हो गए।

आपका पहला कदम यह सुनिश्चित करना है कि आपका Terraform वातावरण सही से कॉन्फ़िगर है।

पर्यावरण का सत्यापन

सबसे पहले terraform version से अपनी Terraform स्थापना की जाँच करें। यदि आप घोषणात्मक इम्पोर्ट ब्लॉक्स और स्वचालित कोड जेनरेशन तक पहुँचना चाहते हैं, तो सुनिश्चित करें कि आप Terraform 1.5 या बाद के संस्करण पर हैं। ये सुविधाएँ जटिल संसाधनों के लिए इम्पोर्ट प्रक्रिया को काफी सरल बनाती हैं।

इम्पोर्ट करने से पहले, इन पूर्वापेक्षाओं की जाँच करें:

• प्रोवाइडर क्रेडेंशियल सक्रिय हों: AWS के लिए, देखें कि AWS_ACCESS_KEY_ID और AWS_SECRET_ACCESS_KEY सेट हैं, या आपका AWS CLI प्रोफ़ाइल कॉन्फ़िगर है। aws sts get-caller-identity से जाँचें।

• सही वर्कस्पेस चुना हो: गलत वातावरण में इम्पोर्ट से बचने के लिए terraform workspace show चलाएँ।

• स्टेट फ़ाइल अनलॉक हो: टीम सदस्यों से समन्वय करें और CI/CD पाइपलाइंस जाँचें ताकि कोई समवर्ती ऑपरेशन न हो।

• बैकएंड सुलभ हो: यदि रिमोट स्टेट उपयोग कर रहे हैं, तो S3, Azure Storage, या Terraform Cloud से कनेक्टिविटी जाँचें।

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

पर्यावरण के सत्यापन के बाद, अगला महत्वपूर्ण कदम उस संसाधन के सही पहचानकर्ता को ढूँढना है जिसे आप इम्पोर्ट करना चाहते हैं।

रिसोर्स ID ढूँढना

प्रोवाइडर और रिसोर्स टाइप के अनुसार रिसोर्स ID काफी भिन्न होती हैं, जिससे यह चरण दिखने से कठिन होता है। यहाँ सामान्य प्रोवाइडर के उदाहरण हैं:

AWS संसाधनों के लिए आप कंसोल में सीधे ID पा सकते हैं। सर्विस (EC2, S3, आदि) पर जाएँ, अपना संसाधन चुनें, और विवरण पैन से पहचानकर्ता कॉपी करें।

Azure के लिए, पूरा रिसोर्स पाथ प्राप्त करने हेतु Azure CLI का उपयोग करें:

az resource show --name myresource --resource-group mygroupसंचालित द्वारा

आउटपुट में इम्पोर्ट के लिए आवश्यक पूर्ण रिसोर्स ID शामिल होगा।

यह एक आम जाल है जिसमें मैं फँसा/फँसी हूँ: गलत रीजन या सब्सक्रिप्शन से संसाधन इम्पोर्ट करने की कोशिश। यदि आपका Terraform प्रोवाइडर कॉन्फ़िगरेशन us-east-1 की ओर इशारा करता है लेकिन आपका EC2 इंस्टांस us-west-2 में है, तो इम्पोर्ट "resource not found" त्रुटि के साथ फेल होगा, भले ही आपका इंस्टांस ID सही हो। 

आगे बढ़ने से पहले हमेशा जाँचें कि स्कोप आपके प्रोवाइडर कॉन्फ़िगरेशन से मेल खाता है। एक बार सही ID मिलने पर, आपको तय करना होगा कि कौन-सा इम्पोर्ट तरीका अपनाना है।

इम्पोर्ट रणनीति चुनना

आपके पास दो रास्ते हैं: terraform import CLI कमांड या import ब्लॉक्स। तुलना इस प्रकार है:

मैं उन टीमों के लिए इम्पोर्ट ब्लॉक्स की सिफारिश करता/करती हूँ जिन्हें कोड रिव्यू और पुनरुत्पादनशील प्लान चाहिए, और लेगेसी संस्करणों पर त्वरित फिक्स के लिए CLI।

यह क्यों मायने रखता है? इम्पोर्ट ब्लॉक्स इंफ्रास्ट्रक्चर अपनाने को कोड की तरह मानते हैं, यानी आपके इम्पोर्ट आपके वर्ज़न-कंट्रोल्ड वर्कफ़्लो का हिस्सा बन जाते हैं, उसी कड़ाई के साथ जैसे कोई अन्य इंफ्रास्ट्रक्चर बदलाव। इससे गलतियों का जोखिम घटता है और एक ऑडिट ट्रेल बनती है जो अनुपालन और टीम समन्वय के लिए आवश्यक है। 

इम्पोर्ट ब्लॉक्स आपके मौजूदा Git वर्कफ़्लो में सहजता से एकीकृत होते हैं, जिससे सहकर्मी इम्पोर्ट को किसी भी अन्य इंफ्रास्ट्रक्चर बदलाव की तरह रिव्यू और अप्रूव कर सकते हैं। CLI, भले ही व्यक्तिगत कार्यों के लिए तेज़ हो, कोई ऑडिट ट्रेल नहीं छोड़ता और वातावरणों में आसानी से पुन: निष्पादित नहीं किया जा सकता।

रणनीति चुन लेने के बाद, अब विस्तार से प्रत्येक वर्कफ़्लो में उतरते हैं, पारंपरिक CLI तरीके से शुरू करते हुए।

कोर वर्कफ़्लो A: Terraform Import CLI कमांड

मैं आपको पारंपरिक CLI-आधारित इम्पोर्ट प्रक्रिया से लेकर चलता/चलती हूँ। भले ही घोषणात्मक इम्पोर्ट ब्लॉक्स पसंदीदा बन रहे हों, CLI विधि को समझना लेगेसी Terraform संस्करणों और त्वरित, एकमुश्त इम्पोर्ट के लिए उपयोगी है।

CLI वर्कफ़्लो का पहला चरण आपका कॉन्फ़िगरेशन फ़ाइल सेट करना है।

डेस्टिनेशन ब्लॉक तैयार करना

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

AWS S3 बकेट इम्पोर्ट करने का उदाहरण:

resource "aws_s3_bucket" "legacy_data" {
  # Configuration to be filled after import
}संचालित द्वारा

रिसोर्स टाइप (aws_s3_bucket) बिल्कुल उसी प्रकार का होना चाहिए जिसे आप इम्पोर्ट कर रहे हैं। रिसोर्स नाम (legacy_data) को आपके प्रोजेक्ट के नेमिंग कन्वेंशंस का पालन करना चाहिए। bucket1 जैसे सामान्य नामों के बजाय production_data_bucket जैसे वर्णनात्मक नाम उपयोग करें।

रिसोर्स ब्लॉक बन जाने पर, आप इम्पोर्ट कमांड चलाने के लिए तैयार हैं।

इम्पोर्ट निष्पादित करना

terraform import <resource_address> <resource_id> चलाएँ। हमारे S3 बकेट के लिए:

terraform import aws_s3_bucket.legacy_data my-existing-bucket-nameसंचालित द्वारा

Terraform प्रोवाइडर API से बकेट के मौजूदा एट्रिब्यूट्स प्राप्त करता है और स्टेट में रिकॉर्ड करता है। आपको यह दिखेगा:

aws_s3_bucket.legacy_data: Import complete! 
Imported aws_s3_bucketसंचालित द्वारा

अब स्टेट में संसाधन शामिल है, लेकिन आपका कॉन्फ़िगरेशन खाली या अधूरा बना रहता है।

यहीं से असली काम शुरू होता है—अपने कोड को इम्पोर्ट की गई स्टेट के साथ संरेखित करना।

कॉन्फ़िगरेशन का मिलान

terraform plan चलाएँ ताकि स्टेट और कॉन्फ़िगरेशन के बीच के अंतर दिखें। आपको computed एट्रिब्यूट्स (जैसे टाइमस्टैम्प जैसे रीड-ओनली मान) और वे स्पष्ट कॉन्फ़िगरेशन आवश्यकताएँ दिखेंगी जिन्हें आपको घोषित करना है।

प्लान आउटपुट के मानों का उपयोग करते हुए अपने कॉन्फ़िगरेशन को क्रमिक रूप से अपडेट करें। यदि प्लान "replacing" संसाधन का प्रस्ताव करता है, तो रुकें। यह अपरिवर्तनीय आर्ग्युमेंट्स (जैसे रीजन या availability zone) में असंगति का संकेत है। अपने कॉन्फ़िगरेशन को मौजूदा संसाधन के अपरिवर्तनीय एट्रिब्यूट्स से मिलान करें।

कोर वर्कफ़्लो B: Terraform इम्पोर्ट ब्लॉक

अब Terraform 1.5 में पेश की गई आधुनिक पद्धति देखते हैं। इम्पोर्ट ब्लॉक्स इम्पोर्ट को एक इम्परेटिव कमांड से बदलकर घोषणात्मक कॉन्फ़िगरेशन बना देते हैं, जो आपके इंफ्रास्ट्रक्चर कोड के साथ रहता है।

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

आइए खुद इम्पोर्ट ब्लॉक बनाना शुरू करें।

इम्पोर्ट ब्लॉक परिभाषित करना

एक इम्पोर्ट ब्लॉक के दो घटक होते हैं: to (टार्गेट ऐड्रेस) और id (रिसोर्स पहचानकर्ता):

import {
  to = aws_instance.web_server
  id = "i-0123456789abcdef0"
}संचालित द्वारा

यह वर्ज़न कंट्रोल विज़िबिलिटी देता है। टीमें निष्पादन से पहले पुल रिक्वेस्ट्स में इम्पोर्ट ब्लॉक्स की समीक्षा कर सकती हैं। सफल इम्पोर्ट के बाद आसानी से सफ़ाई के लिए इम्पोर्ट ब्लॉक्स को imports.tf में रखें।

और यहीं इम्पोर्ट ब्लॉक्स सच में चमकते हैं: Terraform आपके लिए स्वचालित रूप से कॉन्फ़िगरेशन कोड जेनरेट कर सकता है, जिससे शून्य से HCL लिखने का थकाऊ अनुमान-कार्य समाप्त हो जाता है।

कॉन्फ़िगरेशन जेनरेट करना (Terraform 1.5+)

इम्पोर्ट ब्लॉक्स स्वचालित कॉन्फ़िगरेशन जेनरेशन सक्षम करते हैं। terraform plan -generate-config-out=generated.tf चलाएँ ताकि इम्पोर्ट की योजना बने और साथ ही पूर्ण HCL कोड लिखा जाए।

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

कॉन्फ़िगरेशन तैयार होने पर, इम्पोर्ट निष्पादित करने का समय है।

लागू करना और अंतिम रूप देना

अंत में, terraform apply चलाएँ ताकि इम्पोर्ट निष्पादित हो और स्टेट कॉन्फ़िगरेशन के साथ संरेखित हो जाए। Terraform स्टेट फ़ाइल में कोई बदलाव करने से पहले आपको ठीक-ठीक दिखाएगा कि क्या इम्पोर्ट हो रहा है।

सफल एप्लाई के बाद, अपने कॉन्फ़िगरेशन से इम्पोर्ट ब्लॉक्स हटा दें। उनका उद्देश्य पूरा हो चुका है, और उन्हें रखना भविष्य के रन को उलझा देगा। अंत में, terraform plan एक बार फिर चलाएँ ताकि शून्य लंबित बदलावों की पुष्टि हो सके, यह सुनिश्चित करते हुए कि आपका कॉन्फ़िगरेशन और स्टेट पूरी तरह समकालिक हैं।

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

जटिल संसाधनों और मॉड्यूल्स के लिए Terraform इम्पोर्ट

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

चाइल्ड मॉड्यूल्स में इम्पोर्ट करना

मॉड्यूल संसाधनों के लिए पूर्ण पाथ ऐड्रेसिंग चाहिए: module.<module_name>.<resource_type>.<resource_name>, जो इस तरह दिख सकता है:

terraform import module.network.aws_vpc.main vpc-0abcdef123456789संचालित द्वारा

सही ऐड्रेस ढूँढने के लिए, सामान्य apply के बाद terraform state list का उपयोग करें। यह दिखाता है कि Terraform मॉड्यूल संसाधनों को कैसे संदर्भित करता है। ऐड्रेस गलत होने से डुप्लीकेट स्टेट एंट्री बनती हैं, जिन्हें Terraform अगली apply में बनाने की कोशिश करेगा।

इसके अलावा, जब count या for_each वाले मॉड्यूल इंस्टांसेज़ में इम्पोर्ट करें, तो आपको कोट्स में इंस्टांस पहचानकर्ता शामिल करना होगा:

terraform import 'module.network[0].aws_vpc.main' vpc-0abcdef123456789संचालित द्वारा

मॉड्यूल ऐड्रेसिंग के अलावा, count या for_each मेटा-आर्ग्युमेंट्स का उपयोग करने वाले संसाधन अपनी चुनौतियाँ पेश करते हैं।

count और for_each को संभालना

जब आपका Terraform कॉन्फ़िगरेशन count का उपयोग कर किसी संसाधन की कई इंस्टांस बनाता है, तो इम्पोर्ट के लिए एरे सिंटैक्स चाहिए। उदाहरण के लिए, यदि आपका कॉन्फ़िगरेशन ऐसा दिखता है:

resource "aws_instance" "server" {
  count         = 3
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
}संचालित द्वारा

आप प्रत्येक इंस्टांस को उसके इंडेक्स से अलग-अलग इम्पोर्ट करेंगे:

terraform import 'aws_instance.server[0]' i-0123456789abcdef0
terraform import 'aws_instance.server[1]' i-1234567890abcdef1
terraform import 'aws_instance.server[2]' i-2345678901abcdef2संचालित द्वारा

दूसरी ओर, for_each का उपयोग करने वाले संसाधनों के लिए स्ट्रिंग कीज़ चाहिए। यह उदाहरण देखें:

resource "aws_instance" "server" {
  for_each      = toset(["web", "api", "worker"])
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
}संचालित द्वारा

यहाँ, आप की-नेम से इम्पोर्ट करेंगे:

terraform import 'aws_instance.server["web"]' i-0123456789abcdef0
terraform import 'aws_instance.server["api"]' i-1234567890abcdef1
terraform import 'aws_instance.server["worker"]' i-2345678901abcdef2संचालित द्वारा

यदि आपको "index out of range" त्रुटियाँ मिलें, तो इसका अर्थ है कि आपका count मान उन संसाधनों की संख्या से मेल नहीं खाता जिन्हें आप इम्पोर्ट कर रहे हैं। समाधान सरल है: इम्पोर्ट चलाने से पहले सही count सेट करें या उपयुक्त for_each कीज़ परिभाषित करें।

इसके अतिरिक्त, आपको संसाधनों के आपसी संबंधों के बारे में सोचना होगा, विशेषकर जटिल आर्किटेक्चर में।

डिपेंडेंसीज़ और साइड-इफेक्ट्स को मैनेज करना

कुछ क्लाउड संसाधन एकल एंटिटी के रूप में इम्पोर्ट नहीं होते। वे कई Terraform संसाधनों के रूप में इम्पोर्ट होते हैं। सामान्य उदाहरण:

• सिक्योरिटी ग्रुप नियम
• IAM पॉलिसी अटैचमेंट्स
• नेटवर्क ACL नियम

इन मामलों में, हमेशा "पैरेंट" संसाधनों को पहले इम्पोर्ट करें। उदाहरण के लिए, सबनेट से पहले VPC, पॉलिसी अटैचमेंट्स से पहले IAM रोल्स, और व्यक्तिगत नियमों से पहले सिक्योरिटी ग्रुप्स इम्पोर्ट करें। यह आपकी स्टेट फ़ाइल में सही डिपेंडेंसी चेइन स्थापित करता है।

इम्पोर्ट के बाद, जहाँ प्रोवाइडर स्वतः डिपेंडेंसी नहीं पहचानता, वहाँ अपने कॉन्फ़िगरेशन में depends_on का स्पष्ट रूप से उपयोग करें। इससे भविष्य के apply ऑपरेशन सही क्रम में चलेंगे, और ऐसी त्रुटियों से बचेंगे जैसे VPC से पहले सबनेट बनाने की कोशिश।

संसाधनों के सफल इम्पोर्ट और उचित कॉन्फ़िगरेशन के बाद, अगला चरण दीर्घकालिक रखरखाव और संगठन पर केंद्रित होता है।

स्टेट मैनेजमेंट और रिफैक्टरिंग

संसाधनों का इम्पोर्ट तो बस शुरुआत है। दीर्घकालिक सफलता के लिए उचित स्टेट मैनेजमेंट और समय-समय पर रिफैक्टरिंग आवश्यक है।

प्रोडक्शन संसाधनों को इम्पोर्ट करते समय सुरक्षा आपकी पहली चिंता होनी चाहिए।

संवेदनशील स्टेट को सुरक्षित करना

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

समाधान है एन्क्रिप्टेड रिमोट बैकएंड्स का उपयोग। AWS के लिए, इसका अर्थ है S3 के साथ encrypt = true विकल्प और वैकल्पिक रूप से KMS एन्क्रिप्शन सक्षम करना। Azure के लिए, at-rest एन्क्रिप्शन के साथ Azure Storage का उपयोग करें। यदि आप HCP Terraform / Terraform Cloud का उपयोग कर रहे हैं, तो स्टेट डिफ़ॉल्ट रूप से at-rest और इन-ट्रांज़िट एन्क्रिप्टेड होती है, लेकिन आप एक्सेस कंट्रोल्स की जाँच फिर भी करें।

इसके अलावा, संवेदनशील डेटा वाले प्रोडक्शन संसाधनों के इम्पोर्ट के बाद दो अतिरिक्त कदम उठाएँ: स्टेट स्टोरेज एक्सेस कंट्रोल्स सही से कॉन्फ़िगर हैं, यह सत्यापित करें; और यह ट्रैक करने के लिए ऑडिट लॉगिंग सक्षम करें कि स्टेट को कौन और कब एक्सेस करता है। ये उपाय अनुपालन के लिए अमूल्य सुरक्षा ऑडिट ट्रेल बनाते हैं।

जैसे-जैसे आपका इंफ्रास्ट्रक्चर विकसित होता है, आप इम्पोर्ट किए गए संसाधनों को पुनर्गठित और नया नाम देना चाहेंगे।

इम्पोर्टेड संसाधनों का रिफैक्टरिंग

रिसोर्स का नाम बदलने के लिए आपके पास दो विकल्प हैं: terraform state mv (इम्परेटिव) या moved ब्लॉक्स (घोषणात्मक)। मैं moved ब्लॉक्स को प्राथमिकता देता/देती हूँ क्योंकि वे वर्ज़न कंट्रोल इतिहास में बदलाव को दस्तावेज़ित करते हैं:

moved {
  from = aws_instance.old_name
  to   = aws_instance.new_name
}संचालित द्वारा

रीनेमिंग से आगे, आपको हार्ड-कोडेड IDs को रिसोर्स रेफरेंसेज़ से बदलना चाहिए। vpc_id = "vpc-123456" के बजाय vpc_id = aws_vpc.main.id का उपयोग करें। यह दृष्टिकोण उचित डिपेंडेंसी ग्राफ़ बनाता है जिसका उपयोग Terraform ऑपरेशंस के सही क्रम निर्धारित करने में कर सकता है।

स्टेट मैनेजमेंट का अंतिम हिस्सा है भविष्य के ड्रिफ्ट को रोकना।

ड्रिफ्ट के विरुद्ध सख़्ती

इम्पोर्ट के बाद सबसे महत्वपूर्ण नीति यह स्थापित करें: सभी बदलाव Terraform के माध्यम से जाएँ, क्लाउड कंसोल के नहीं। यही एक तरीका है जिससे आपके कोड और वास्तविकता के बीच ड्रिफ्ट को रोका जा सकता है।

हालाँकि, कुछ एट्रिब्यूट्स लगातार ड्रिफ्ट करते हैं लेकिन उनका प्रबंधन आवश्यक नहीं। इनके लिए ignore_changes लाइफ़साइकल आर्ग्युमेंट का उपयोग करें:

lifecycle {
  ignore_changes = [tags["LastModified"]]
}संचालित द्वारा

अंततः, "क्लीन प्लान" मानक स्थापित करें जहाँ terraform plan केवल जानबूझकर किए गए बदलाव दिखाए। यह आदत डालें कि भले ही आप डिप्लॉय न कर रहे हों, योजनाएँ नियमित रूप से चलाएँ ताकि ड्रिफ्ट जल्दी पकड़ में आ जाए और वह बड़ी समस्या न बने।

सामान्य Terraform इम्पोर्ट त्रुटियों का समाधान

सावधानीपूर्वक तैयारी के बावजूद, इम्पोर्ट ऑपरेशन असफल हो सकते हैं। आइए सबसे आम समस्याओं का निदान और समाधान करें जिनका आप सामना करेंगे।

ऐड्रेस और ID असंगतियाँ सबसे अधिक सामान्य मुद्दे हैं।

ऐड्रेस और ID त्रुटियों का समाधान

यहाँ सबसे सामान्य इम्पोर्ट त्रुटियाँ और उनके समाधान हैं:

Resource address does not exist

• कारण: Terraform को आपके कॉन्फ़िगरेशन में रिसोर्स ब्लॉक नहीं मिल रहा
• CLI इम्पोर्ट के लिए समाधान: कमांड चलाने से पहले एक खाली रिसोर्स ब्लॉक बनाएँ
• इम्पोर्ट ब्लॉक्स के लिए समाधान: to ऐड्रेस या गलत मॉड्यूल पाथ में टाइपो जाँचें

Cannot import non-existent remote object

• कारण: गलत ID फ़ॉर्मेट या ग़लत प्रोवाइडर रीजन/सब्सक्रिप्शन
• समाधान: सुनिश्चित करें कि प्रोवाइडर कॉन्फ़िगरेशन सही AWS रीजन, Azure सब्सक्रिप्शन, या GCP प्रोजेक्ट की ओर इशारा करता हो
• यह भी जाँचें: प्रोवाइडर दस्तावेज़ में रिसोर्स ID फ़ॉर्मेट

Resource already managed

• कारण: डुप्लीकेट स्टेट एंट्री। संसाधन पहले से किसी दूसरे नाम से ट्रैक हो रहा है

• समाधान: terraform state list चलाएँ और डुप्लीकेट्स ढूँढें, फिर terraform state rm से पुरानी एंट्री हटाकर पुनः इम्पोर्ट करें

अनजाने में रिप्लेसमेंट रोकना

संसाधनों को सफलतापूर्वक इम्पोर्ट करने के बाद, उन प्लान्स से सावधान रहें जो उन्हें रिप्लेस करना चाहते हैं।

यदि इम्पोर्ट के बाद terraform plan "forces replacement" दिखाता है, तो पहचानें कि कौन-सा आर्ग्युमेंट पुनर्निर्माण करा रहा है। सामान्य कारण अपरिवर्तनीय आर्ग्युमेंट्स होते हैं, जैसे EC2 AMI IDs या availability zones। इन्हें संसाधन निर्माण के बाद बदला नहीं जा सकता।

समाधान सीधा है: अपने कॉन्फ़िगरेशन को वास्तविकता से मिलाएँ। प्लान आउटपुट से वास्तविक मानों को अपने कॉन्फ़िगरेशन फ़ाइल में कॉपी करें। 

और एक महत्वपूर्ण सुरक्षा नियम: यदि यह महत्वपूर्ण संसाधनों को नष्ट करने का प्रस्ताव देता है, तो कभी पुष्टि या apply न करें। यह इस बात का संकेत है कि कुछ गलत है।

प्रोवाइडर संबंधी समस्याओं से निपटना

कभी-कभी समस्या आपके कॉन्फ़िगरेशन में नहीं, बल्कि आपके प्रोवाइडरों के कॉन्फ़िगर होने के तरीके में होती है।

"Provider configuration depends on non-var" त्रुटियाँ तब होती हैं जब आपका प्रोवाइडर ब्लॉक इम्पोर्ट के दौरान computed वैल्यू का उपयोग करता है। Terraform को इम्पोर्ट के लिए संसाधन ढूँढने हेतु स्थैतिक प्रोवाइडर कॉन्फ़िगरेशन चाहिए।

वर्कअराउंड है अस्थायी हार्ड-कोडिंग: डायनेमिक प्रोवाइडर सेटिंग्स को लिटरल वैल्यू से बदलें, इम्पोर्ट चलाएँ, फिर अपनी डायनेमिक कॉन्फ़िगरेशन वापस लाएँ। वैकल्पिक रूप से, आप प्रोवाइडर ऑथेंटिकेशन के लिए environment variables का उपयोग कर सकते हैं, जिन्हें Terraform इम्पोर्ट के दौरान हल कर सकता है।

यदि आपका रिसोर्स ID सही लगता है लेकिन इम्पोर्ट फिर भी फेल होता है, तो ID फ़ॉर्मेट की सटीक आवश्यकताओं के लिए प्रोवाइडर दस्तावेज़ के "Import" सेक्शन की जाँच करें। कुछ संसाधन स्लैश या कॉलन सेपरेटर वाले यौगिक IDs का उपयोग करते हैं, और फ़ॉर्मेट बिल्कुल सही होना आवश्यक है।

निष्कर्ष

आपने CLI कमांड्स और इम्पोर्ट ब्लॉक्स दोनों का उपयोग करके मौजूदा इंफ्रास्ट्रक्चर को Terraform प्रबंधन के अंतर्गत लाना सीख लिया है। हर इम्पोर्ट से पहले, इस सुरक्षा चेकलिस्ट का पालन करें:

• अपने प्रोवाइडर के अनुसार रिसोर्स IDs की शुद्धता सत्यापित करें
• अपनी स्टेट फ़ाइल का बैकअप लें (रिमोट बैकएंड्स पर वर्शनिंग सक्षम करें)
• अनपेक्षित रिप्लेसमेंट हेतु प्लान्स ध्यान से समीक्षा करें
• सुनिश्चित करें कि आप सही वर्कस्पेस/एन्वायरनमेंट में हैं
• पहले गैर-आवश्यक संसाधनों पर परीक्षण करें

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

अगले चरण के लिए, मैं terraform state mv और terraform state rm के साथ Terraform स्टेट में बदलाव की खोज करने की सलाह देता/देती हूँ। ये कमांड्स इम्पोर्ट के पूरक हैं और जैसे-जैसे आपका इंफ्रास्ट्रक्चर विकसित होता है, वे आपकी स्टेट फ़ाइल को पुनर्गठित और रिफैक्टर करने में मदद करते हैं।

मैं यह भी सलाह देता/देती हूँ कि हमारे Docker के साथ Terraform उपयोग पर गाइड देखें, और हमारे शीर्ष Terraform इंटरव्यू प्रश्नों के साथ अपनी अगली इंटरव्यू की तैयारी करें।