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

मुझे अपने टेराफ़ॉर्म कॉन्फ़िगरेशन की संरचना कैसे करनी चाहिए?

यह उन प्रश्नों में से एक है जहां बहुत सारे समाधान मौजूद हैं और सार्वभौमिक सलाह देना बहुत कठिन है, तो आइए यह समझने के साथ शुरू करें कि हम किसके साथ काम कर रहे हैं।

• आपकी परियोजना की जटिलता क्या है?

  • संबंधित संसाधनों की संख्या

  • टेराफॉर्म प्रदाताओं की संख्या ("तार्किक प्रदाताओं" के बारे में नीचे नोट देखें)

• आपका इंफ्रास्ट्रक्चर कितनी बार बदलता है?

  • महीने/सप्ताह/दिन में एक बार से

  • लगातार (हर बार जब कोई नई प्रतिबद्धता होती है)

• कोड परिवर्तन आरंभकर्ता? क्या आप एक नया आर्टिफैक्ट बनने पर सीआई सर्वर को रिपोजिटरी अपडेट करने देते हैं?

  • केवल डेवलपर्स ही इन्फ्रास्ट्रक्चर रिपॉजिटरी को आगे बढ़ा सकते हैं

  • हर कोई पीआर खोलकर किसी भी चीज़ में बदलाव का प्रस्ताव दे सकता है (सीआई सर्वर पर चलने वाले स्वचालित कार्यों सहित

• आप किस परिनियोजन प्लेटफ़ॉर्म या परिनियोजन सेवा का उपयोग करते हैं?

  • AWS CodeDeploy, Kubernetes, या OpenShift को थोड़े अलग दृष्टिकोण की आवश्यकता होती है

• Copy

  परिवेशों को कैसे समूहीकृत किया जाता है?

  • पर्यावरण, क्षेत्र, परियोजना के अनुसार

टेराफॉर्म कॉन्फ़िगरेशन की संरचना के साथ शुरुआत करना

जब आप शुरू कर रहे हों या एक उदाहरण कोड लिख रहे हों तो सभी कोड को main.tf में रखना एक अच्छा विचार है। अन्य सभी मामलों में आप बेहतर होंगे कि कई फाइलें इस तरह तार्किक रूप से विभाजित हों:

• main.tf - सभी संसाधन बनाने के लिए कॉल मॉड्यूल, स्थानीय और डेटा स्रोत

• variables.tf - main.tf में उपयोग किए जाने वाले चरों की घोषणाएं शामिल हैं

• outputs.tf - main.tf में बनाए गए संसाधनों से आउटपुट शामिल हैं

• versions.tf - टेराफॉर्म और प्रदाताओं के लिए संस्करण आवश्यकताएं शामिल हैं

terraform.tfvars composition को छोड़कर कहीं भी उपयोग नहीं किया जाना चाहिए।

टेराफॉर्म कॉन्फ़िगरेशन संरचना के बारे में कैसे सोचें?

कोड की संरचना के लिए सामान्य सिफारिशें

• कम संसाधनों के साथ काम करना आसान और तेज़ है

  • terraform plan औरterraform apply दोनों संसाधनों की स्थिति को सत्यापित करने के लिए क्लाउड एपीआई कॉल करते हैं

  • यदि आपके पास एक ही संरचना में अपना संपूर्ण बुनियादी ढांचा है तो इसमें कुछ समय लग सकता है

• एक विस्फोट त्रिज्या (सुरक्षा उल्लंघन के मामले में) कम संसाधनों के साथ छोटा होता है

  • असंबंधित संसाधनों को अलग-अलग रचनाओं में रखकर एक-दूसरे से इन्सुलेट करने से कुछ गलत होने पर जोखिम कम हो जाता है

• दूरस्थ स्थिति का उपयोग करके अपना प्रोजेक्ट प्रारंभ करें क्योंकि:

  • आपका लैपटॉप आपके बुनियादी ढांचे के सत्य के स्रोत के लिए कोई जगह नहीं है

  • git में tfstate फ़ाइल को प्रबंधित करना एक दुःस्वप्न है

  • बाद में जब बुनियादी ढांचे की परतें कई दिशाओं में बढ़ने लगती हैं (निर्भरता या संसाधनों की संख्या) तो चीजों को नियंत्रण में रखना आसान हो जाएगा

• एक सुसंगत संरचना और नामकरण परंपरा का अभ्यास करें:

  • प्रक्रियात्मक कोड की तरह, लोगों को पहले पढ़ने के लिए टेराफॉर्म कोड लिखा जाना चाहिए, अब से छह महीने बाद परिवर्तन होने पर स्थिरता में मदद मिलेगी

  • टेराफॉर्म राज्य फ़ाइल में संसाधनों को स्थानांतरित करना संभव है, लेकिन यदि आपके पास असंगत संरचना और नामकरण है तो ऐसा करना कठिन हो सकता है

• संसाधन मॉड्यूल को यथासंभव सादा रखें

• उन मानों को हार्डकोड न करें जिन्हें चर के रूप में पारित किया जा सकता है या डेटा स्रोतों का उपयोग करके खोजा जा सकता है

• डेटा स्रोतों और terraform_remote_state का उपयोग विशेष रूप से संरचना के भीतर अवसंरचना मॉड्यूल के बीच गोंद के रूप में करें

इस पुस्तक में, उदाहरण परियोजनाओं को जटिलता के आधार पर समूहीकृत किया गया है - छोटे से लेकर बहुत बड़े बुनियादी ढांचे तक। यह अलगाव सख्त नहीं है, इसलिए अन्य संरचनाओं की भी जांच करें।

बुनियादी ढांचे के मॉड्यूल और रचनाओं का वाद्य-स्थान

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

डेवलपर्स द्वारा उपयोग किए जाने वाले ऑर्केस्ट्रेशन समाधानों के कम से कम 5 अलग-अलग समूह हैं:

1. केवल टेराफॉर्म। बहुत सीधा, डेवलपर्स को काम पूरा करने के लिए केवल टेराफॉर्म को जानना होगा।

2. Terragrunt. शुद्ध ऑर्केस्ट्रेशन टूल जिसका उपयोग संपूर्ण आधारभूत संरचना को व्यवस्थित करने के साथ-साथ निर्भरताओं को संभालने के लिए भी किया जा सकता है।. Tमूल रूप से बुनियादी ढांचे के मॉड्यूल और रचनाओं के साथ काम करता है, इसलिए यह कोड के दोहराव को कम करता है।

3. आन्तरिक स्क्रिप्ट। अक्सर यह ऑर्केस्ट्रेशन की ओर एक प्रारंभिक बिंदु के रूप में और Terragrunt की खोज से पहले होता है।

4. उत्तरदायी या समान सामान्य प्रयोजन स्वचालन उपकरण। आमतौर पर इसका उपयोग तब किया जाता है जब टेराफॉर्म को Ansible के बाद अपनाया जाता है, या जब Ansible UI का सक्रिय रूप से उपयोग किया जाता है।

5. Crossplane और अन्य Kubernetes-inspired समाधान। कभी-कभी कुबेरनेट्स पारिस्थितिकी तंत्र का उपयोग करना और आपके टेराफॉर्म कॉन्फ़िगरेशन की वांछित स्थिति प्राप्त करने के लिए एक सुलह लूप सुविधा को नियोजित करना समझ में आता है। अधिक जानकारी के लिए वीडियो Crossplane vs Terraform देखें।

इसे ध्यान में रखते हुए, यह पुस्तक इन परियोजना संरचनाओं में से पहले दो की समीक्षा करती है, Terraform only और Terragrunt.

अगले अध्याय में Terraform या Terragrunt के लिए कोड संरचनाओं के उदाहरण देखें।

टेराफॉर्म कोड संरचनाएं

टेराग्रंट कोड संरचनाएं

Terraform शक्तिशाली है (यदि अभी सबसे शक्तिशाली नहीं है) और सबसे अधिक उपयोग किए जाने वाले उपकरणों में से एक है जो बुनियादी ढांचे के प्रबंधन को कोड के रूप में अनुमति देता है। यह डेवलपर्स को बहुत सी चीजें करने की अनुमति देता है और उन्हें उन चीजों को करने से प्रतिबंधित नहीं करता है जिनका समर्थन करना या एकीकृत करना मुश्किल होगा।

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

पुस्तक 2018 में सनी मैड्रिड में शुरू की गई थी, यहां मुफ्त में उपलब्ध है

https://www.terraform-best-practices.com/.

कुछ वर्षों बाद इसे टेराफॉर्म 1.0 के साथ उपलब्ध अधिक वास्तविक सर्वोत्तम प्रथाओं के साथ अद्यतन किया गया है। आखिरकार, इस पुस्तक में टेराफॉर्म उपयोगकर्ताओं के लिए निर्विवाद सर्वोत्तम अभ्यास और अनुशंसाएं शामिल होनी चाहिए।

Sponsors

Please contact me if you want to become a sponsor.

Translations

यदि आप इस पुस्तक का अन्य भाषाओं में अनुवाद करने में सहायता करना चाहते हैं तो मुझसे संपर्क करें।

योगदान

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

यदि आप विशिष्ट विषयों में रुचि रखते हैं, तो कृपया open an issue , या उस मुद्दे को स्वीकार करें जिसे आप कवर करना चाहते हैं। यदि आपको लगता है कि आपके पास सामग्री है और आप योगदान देना चाहते हैं, तो एक मसौदा लिखें और एक पुल अनुरोध सबमिट करें (इस समय अच्छा पाठ लिखने की चिंता न करें!)

लेखकों

इस पुस्तक का रखरखाव Anton Babenko द्वारा विभिन्न योगदानकर्ताओं और अनुवादकों की सहायता से किया जाता है।

लाइसेंस

यह काम Apache 2 लाइसेंस के तहत लाइसेंस प्राप्त है। पूरी जानकारी के लिए लाइसेंस देखें।

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

Copyright © 2018-2023 Anton Babenko.

Source:

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

• 2 AWS खाते

• 2 अलग-अलग वातावरण (ठेस और मंच जो कुछ भी साझा नहीं करते हैं)। प्रत्येक परिवेश एक अलग AWS खाते में रहता है

• प्रत्येक परिवेश ऑफ़-द-शेल्फ अवसंरचना मॉड्यूल (alb) के भिन्न संस्करण का उपयोग करता है, जो से प्राप्त होता है

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

सामान्य सम्मेलन

1. हर जगह - (डैश) के बजाय _ (अंडरस्कोर) का उपयोग करें (संसाधन नाम, डेटा स्रोत नाम, चर नाम, आउटपुट आदि में)

2. लोअरकेस अक्षरों और संख्याओं का उपयोग करना पसंद करें (भले ही UTF-8 समर्थित हो)।

संसाधन और डेटा स्रोत तर्क

1. संसाधन नाम में संसाधन प्रकार को न दोहराएं (आंशिक रूप से नहीं, न ही पूरी तरह से):

1. यदि कोई और वर्णनात्मक और सामान्य नाम उपलब्ध नहीं है, या यदि संसाधन मॉड्यूल इस प्रकार का एकल संसाधन बनाता है, तो संसाधन नाम को इसका नाम दिया जाना चाहिए (eg, in प्रकार का एक ही संसाधन है aws_nat_gateway और प्रकार के कई संसाधन typeaws_route_table, इसलिए aws_nat_gatewayनाम दिया जाना चाहिए this तथाaws_route_table अधिक वर्णनात्मक नाम होने चाहिए - जैसे private, public, database).

2. नामों के लिए हमेशा एकवचन संज्ञा का प्रयोग करें।

3. उपयोग - तर्कों के अंदर मूल्यों और उन जगहों पर जहां मूल्य मानव के सामने आ जाएगा (eg, inside DNS name of RDS instance).

4. संसाधन या डेटा स्रोत ब्लॉक के अंदर तर्क count / for_each को शीर्ष पर पहले तर्क के रूप में शामिल करें और इसके बाद न्यूलाइन द्वारा अलग करें।

5. तर्क tags शामिल करें, यदि संसाधन द्वारा समर्थित है, तो अंतिम वास्तविक तर्क के रूप में, यदि आवश्यक हो तो depends_on and lifecycle के बाद। इन सभी को एक खाली लाइन से अलग किया जाना चाहिए।

6. एक तर्क में शर्तों का उपयोग करते समय count / for_each उपयोग करने के बजाय बूलियन मान पसंद करें length या अन्य भाव.

resource कोड के उदाहरण

count / for_each का उपयोग

tags का स्थानन

Conditions in count

चर(Variables)

1. संसाधन मॉड्यूल में पहिया का पुन: आविष्कार न करें: जिस संसाधन के साथ आप काम कर रहे हैं, उसके लिए "तर्क संदर्भ" अनुभाग में परिभाषित चर के लिए नाम, विवरण और डिफ़ॉल्ट मान का उपयोग करें।

2. चरों में सत्यापन के लिए समर्थन सीमित है (उदाहरण के लिए अन्य चरों तक नहीं पहुंच सकते हैं या लुकअप नहीं कर सकते हैं)। तदनुसार योजना बनाएं क्योंकि कई मामलों में यह सुविधा बेकार है।

3. एक चर नाम में बहुवचन रूप का प्रयोग करें जब प्रकार list(...) or map(...) हो।

4. इस तरह एक चर ब्लॉक में आदेश कुंजी:description , type, default, validation.

5. हमेशा सभी चरों पर विवरण शामिल करें, भले ही आपको लगता है कि यह स्पष्ट है (आपको भविष्य में इसकी आवश्यकता होगी)।

6. जब तक आपको प्रत्येक कुंजी पर सख्त बाधाओं की आवश्यकता न हो, तब तक साधारण प्रकार(number, string, list(...), map(...), any) कोई भी) विशिष्ट प्रकार जैसे object() का उपयोग करना पसंद करें।

7. यदि मानचित्र के सभी तत्वों का एक ही प्रकार (जैसे string) है या इसमें परिवर्तित किया जा सकता है (जैसे संख्या प्रकार को स्ट्रिंग में परिवर्तित किया जा सकता है) तो मानचित्र like map(map(string)) जैसे विशिष्ट प्रकारों का उपयोग करें।

8. एक निश्चित गहराई से शुरू होने वाले प्रकार सत्यापन को अक्षम करने के लिए या जब कई प्रकारों का समर्थन किया जाना चाहिए, तो टाइप करें का उपयोग करें।

9. मान {} कभी-कभी एक नक्शा होता है लेकिन कभी-कभी एक वस्तु। नक्शा बनाने के लिए tomap(...) का उपयोग करें क्योंकि कोई वस्तु बनाने का कोई तरीका नहीं है।

उत्पादन

उत्पादन को उसके दायरे के बाहर संगत और समझने योग्य बनाएं (जब कोई उपयोगकर्ता मॉड्यूल का उपयोग कर रहा हो तो यह स्पष्ट होना चाहिए कि यह किस प्रकार और मूल्य का गुण लौटाता है)।

1. आउटपुट का नाम उस संपत्ति का वर्णन करना चाहिए जिसमें यह शामिल है और सामान्य रूप से जितना आप चाहते हैं उससे कम फ्री-फॉर्म होना चाहिए

2. आउटपुट के नाम के लिए अच्छी संरचना दिखती है {name}_{type}_{attribute} , जहां:

   1. {name} प्रदाता उपसर्ग के बिना संसाधन या डेटा स्रोत का नाम है। {name} for aws_subnet is subnet, foraws_vpc it is vpc.

   2. {type} संसाधन स्रोतों का एक प्रकार है

   3. {attribute} आउटपुट द्वारा लौटाई गई एक विशेषता है
5. हमेशा सभी आउटपुट के लिए विवरण description शामिल करें भले ही आपको लगता है कि यह स्पष्ट है.

6. जब तक आप सभी मॉड्यूल में सभी जगहों पर इस आउटपुट के उपयोग को पूरी तरह से नियंत्रित नहीं करते तब तक संवेदनशील sensitive तर्क सेट करने से बचें।

7. Prefer try() (available since Terraform 0.13) over element(concat(...)) (legacy approach for the version before 0.13)

कोड के उदाहरण output

सुरक्षा समूह की अधिकतम एक आईडी पर लौटें:

एक ही प्रकार के कई संसाधन होने पर, इसे आउटपुट के नाम से हटा दिया जाना चाहिए:

बहुवचन नाम का प्रयोग करें यदि रिटर्निंग मान एक सूची है

Source:

इस उदाहरण में कोड को एक बड़े आकार के बुनियादी ढांचे के लिए टेराफॉर्म कॉन्फ़िगरेशन की संरचना के उदाहरण के रूप में शामिल किया गया है जो उपयोग करता है:

• 2 AWS खाते

• 2 क्षेत्र

• 2 अलग-अलग वातावरण (ठेस और मंच जो कुछ भी साझा नहीं करते हैं)। प्रत्येक वातावरण एक अलग AWS खाते में रहता है और 2 क्षेत्रों के बीच संसाधन फैलाता है प्रत्येक वातावरण टेराफॉर्म रजिस्ट्री से प्राप्त ऑफ-द-शेल्फ इंफ्रास्ट्रक्चर मॉड्यूल (एलबी) के एक अलग संस्करण का उपयोग करता है प्रत्येक वातावरण एक आंतरिक मॉड्यूल मॉड्यूल/नेटवर्क के समान संस्करण का उपयोग करता है क्योंकि इसे स्थानीय निर्देशिका से प्राप्त किया जाता है।

Source:

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

आधिकारिक टेराफॉर्म दस्तावेज़ीकरण विवरण में कॉन्फ़िगरेशन के सभी पहलुओं का वर्णन करता है। इस सेक्शन के बाकी हिस्सों को समझने के लिए इसे ध्यान से पढ़ें।

यह खंड उन प्रमुख अवधारणाओं का वर्णन करता है जिनका उपयोग पुस्तक के अंदर किया जाता है।

संसाधन

संसाधन aws_vpc, aws_db_instance, आदि है, एक संसाधन एक प्रदाता से संबंधित है, तर्कों को स्वीकार करता है, विशेषताओं को आउटपुट करता है, और उसका जीवन चक्र होता है। संसाधन बनाया जा सकता है, पुनर्प्राप्त किया जा सकता है, अपडेट किया जा सकता है और हटाया जा सकता है।

संसाधन मॉड्यूल

संसाधन मॉड्यूल कनेक्टेड संसाधनों का एक संग्रह है जो एक साथ सामान्य क्रिया करता है (for e.g., creates VPC, subnets, NAT gateway, etc).यह प्रदाता कॉन्फ़िगरेशन पर निर्भर करता है, जिसे इसमें परिभाषित किया जा सकता है, या उच्च-स्तरीय संरचनाओं (e.g., in infrastructure module).

इंफ्रास्ट्रक्चर मॉड्यूल

एक इंफ्रास्ट्रक्चर मॉड्यूल संसाधन मॉड्यूल का एक संग्रह है, जिसे तार्किक रूप से कनेक्ट नहीं किया जा सकता है, लेकिन वर्तमान स्थिति/प्रोजेक्ट/सेटअप में एक ही उद्देश्य पूरा होता है। यह प्रदाताओं के लिए कॉन्फ़िगरेशन को परिभाषित करता है, जो डाउनस्ट्रीम संसाधन मॉड्यूल और संसाधनों को पास किया जाता है। यह आमतौर पर एक इकाई प्रति लॉजिकल सेपरेटर (जैसे, AWS क्षेत्र, Google प्रोजेक्ट) में काम करने तक सीमित होता है।

For example, मॉड्यूल जैसे संसाधन मॉड्यूल का उपयोग करता है and चलाने के लिए आवश्यक बुनियादी ढांचे का प्रबंधन करने के लिए on .

एक और उदाहरण मॉड्यूल जहां द्वारा कई मॉड्यूल बुनियादी ढांचे के प्रबंधन के साथ-साथ डॉकर छवियों को बनाने, धक्का देने और तैनात करने के लिए डॉकर संसाधनों का उपयोग करने के लिए एक साथ उपयोग किया जा रहा है। ऑल इन वन सेट।

संरचना

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

एक रचना में बुनियादी ढांचे के मॉड्यूल शामिल होते हैं, जिसमें संसाधन मॉड्यूल शामिल होते हैं, जो व्यक्तिगत संसाधनों को लागू करते हैं।

डेटा स्त्रोत

डेटा स्रोत केवल पढ़ने के लिए ऑपरेशन करता है और प्रदाता कॉन्फ़िगरेशन पर निर्भर होता है, इसका उपयोग संसाधन मॉड्यूल और इन्फ्रास्ट्रक्चर मॉड्यूल में किया जाता है।

डेटा स्रोत terraform_remote_state उच्च-स्तरीय मॉड्यूल और रचनाओं के लिए एक गोंद के रूप में कार्य करता है।

रिमोट स्टेट

प्रदाता, प्रोविजनर, आदि

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

इतना मुश्किल क्यों है?

मॉड्यूल के आउटपुट और डेटा स्रोतों का उपयोग करके अणुओं (संसाधन मॉड्यूल और अवसंरचना मॉड्यूल) में डेटा तक पहुंच की जाती है।

छद्म संबंधों में ऊपर वर्णित अवधारणाओं को डालते समय यह इस तरह दिख सकता है:

- उन लोगों की सूची जो टेराफॉर्म के साथ बहुत सक्रिय रूप से काम करते हैं और आपको बहुत कुछ बता सकते हैं (यदि आप उनसे पूछें)।

- हशीकॉर्प के टेराफॉर्म पर संसाधनों की क्यूरेटेड सूची।

- "Your Weekly Dose of Terraform" YouTube channel by Anton Babenko. समीक्षा, साक्षात्कार, प्रश्नोत्तर, लाइव कोडिंग और टेराफॉर्म के साथ कुछ हैकिंग के साथ लाइव स्ट्रीम।

- टेराफॉर्म साप्ताहिक समाचार पत्र। टेराफॉर्म दुनिया में विभिन्न समाचार (परियोजनाएं, घोषणाएं, चर्चाएं) by Anton Babenko.

संसाधनों के बीच स्पष्ट निर्भरता निर्दिष्ट करने के लिए locals का प्रयोग करें

टेराफॉर्म को संकेत देने का मददगार तरीका कि टेराफॉर्म कॉन्फ़िगरेशन में कोई प्रत्यक्ष निर्भरता न होने पर भी कुछ संसाधनों को पहले हटा दिया जाना चाहिए।

टेराफॉर्म 0.12 - आवश्यक बनाम वैकल्पिक तर्क

1. आवश्यक तर्क index_document सेट किया जाना चाहिए, यदि var.website एक खाली नक्शा नहीं है।

2. वैकल्पिक तर्क error_document छोड़ा जा सकता है।