उन लोगों के लिए एक कार्यशाला भी है जो इस गाइड में वर्णित कुछ चीजों का अभ्यास करना चाहते हैं।

The content is here - https://github.com/antonbabenko/terraform-best-practices-workshop

https://twitter.com/antonbabenko/lists/terraform-experts - उन लोगों की सूची जो टेराफॉर्म के साथ बहुत सक्रिय रूप से काम करते हैं और आपको बहुत कुछ बता सकते हैं (यदि आप उनसे पूछें)।

https://github.com/shuaibiyy/awesome-terraform - हशीकॉर्प के टेराफॉर्म पर संसाधनों की क्यूरेटेड सूची।

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

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

प्रलेखन

स्वचालित रूप से उत्पन्न दस्तावेज

बहु-भाषा प्री-कमिट हुक के प्रबंधन और रखरखाव के लिए एक ढांचा है। यह Python में लिखा गया है और एक गिट रिपॉजिटरी के लिए कोड प्रतिबद्ध होने से पहले एक डेवलपर की मशीन पर स्वचालित रूप से कुछ करने के लिए एक शक्तिशाली उपकरण है। आम तौर पर, इसका उपयोग लिंटर चलाने और कोड को प्रारूपित करने के लिए किया जाता है (see ).

टेराफॉर्म कॉन्फ़िगरेशन के साथ pre-commit का उपयोग कोड को प्रारूपित करने और मान्य करने के साथ-साथ प्रलेखन को अपडेट करने के लिए किया जा सकता है.

इसके साथ खुद को परिचित करने के लिए भंडार देखें, और मौजूदा भंडार (उदाहरण के लिए, )) जहां यह पहले से ही उपयोग किया जाता है।

terraform-docs

एक ऐसा उपकरण है जो विभिन्न आउटपुट स्वरूपों में टेराफॉर्म मॉड्यूल से प्रलेखन तैयार करता है। आप इसे मैन्युअल रूप से चला सकते हैं (प्री-कमिट हुक के बिना), or use दस्तावेज़ को स्वचालित रूप से अपडेट करने के लिए.

@todo: Document module versions, release, GH actions

साधन

3. Blog post by :

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

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

संसाधन

संसाधन 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 उच्च-स्तरीय मॉड्यूल और रचनाओं के लिए एक गोंद के रूप में कार्य करता है।

The डेटा स्रोत एक बाहरी प्रोग्राम को डेटा स्रोत के रूप में कार्य करने की अनुमति देता है, जो टेराफ़ॉर्म कॉन्फ़िगरेशन में कहीं और उपयोग के लिए मनमाने ढंग से डेटा को उजागर करता है.यहां से एक उदाहरण दिया गया है जहां बाहरी पायथन स्क्रिप्ट को कॉल करके फ़ाइल नाम की गणना की जाती है।

The डेटा स्रोत दिए गए URL पर एक HTTP GET अनुरोध करता है और प्रतिक्रिया के बारे में जानकारी निर्यात करता है जो अक्सर उन एंडपॉइंट्स से जानकारी प्राप्त करने के लिए उपयोगी होता है जहां एक देशी टेराफ़ॉर्म प्रदाता मौजूद नहीं है।

रिमोट स्टेट

इन्फ्रास्ट्रक्चर मॉड्यूल और रचनाओं को अपना बना रहना चाहिए एक दूरस्थ स्थान पर जहां इसे दूसरों द्वारा नियंत्रित तरीके से पुनर्प्राप्त किया जा सकता है (e.g., specify ACL, versioning, logging).

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

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

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

जबकि व्यक्तिगत संसाधन बुनियादी ढांचे में परमाणुओं की तरह होते हैं, संसाधन मॉड्यूल अणु (परमाणुओं से युक्त) होते हैं। एक मॉड्यूल सबसे छोटी संस्करण वाली और साझा करने योग्य इकाई है। इसमें तर्कों की एक सटीक सूची है, ऐसी इकाई के लिए आवश्यक फ़ंक्शन करने के लिए मूल तर्क लागू करें। e.g., module creates aws_security_group and aws_security_group_rule resources based on input. इन्फ्रास्ट्रक्चर मॉड्यूल बनाने के लिए अपने आप में इस संसाधन मॉड्यूल का उपयोग अन्य मॉड्यूल के साथ किया जा सकता है।

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

रचनाओं के बीच पहुंच अक्सर रिमोट स्टेट डेटा स्रोतों का उपयोग करके की जाती है। There are .

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

Source: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/large-terraform

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

• 2 AWS खाते

• 2 क्षेत्र

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

Source:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• outputs.tf - main.tf

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Source: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/medium-terraform

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

• 2 AWS खाते

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

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

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

मुझे किन उपकरणों के बारे में पता होना चाहिए और उनका उपयोग करने पर विचार करना चाहिए?

• - Orchestration tool (ऑर्केस्ट्रेशन टूल)

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

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

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

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

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

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

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

count / for_each का उपयोग

tags का स्थानन

Conditions in count

चर(Variables)

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

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

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

उत्पादन

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

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

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

   1. {name} प्रदाता उपसर्ग के बिना संसाधन या डेटा स्रोत का नाम है। {name}

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

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

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

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

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

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

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

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

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

Sponsors

Please if you want to become a sponsor.

Translations

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

योगदान

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

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

लेखकों

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

लाइसेंस

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

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

Copyright © 2018-2023 Anton Babenko.