Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
आधिकारिक टेराफॉर्म दस्तावेज़ीकरण विवरण में कॉन्फ़िगरेशन के सभी पहलुओं का वर्णन करता है। इस सेक्शन के बाकी हिस्सों को समझने के लिए इसे ध्यान से पढ़ें।
यह खंड उन प्रमुख अवधारणाओं का वर्णन करता है जिनका उपयोग पुस्तक के अंदर किया जाता है।
संसाधन aws_vpc, aws_db_instance, आदि है, एक संसाधन एक प्रदाता से संबंधित है, तर्कों को स्वीकार करता है, विशेषताओं को आउटपुट करता है, और उसका जीवन चक्र होता है। संसाधन बनाया जा सकता है, पुनर्प्राप्त किया जा सकता है, अपडेट किया जा सकता है और हटाया जा सकता है।
संसाधन मॉड्यूल कनेक्टेड संसाधनों का एक संग्रह है जो एक साथ सामान्य क्रिया करता है (for e.g., AWS VPC Terraform module creates VPC, subnets, NAT gateway, etc).यह प्रदाता कॉन्फ़िगरेशन पर निर्भर करता है, जिसे इसमें परिभाषित किया जा सकता है, या उच्च-स्तरीय संरचनाओं (e.g., in infrastructure module).
एक इंफ्रास्ट्रक्चर मॉड्यूल संसाधन मॉड्यूल का एक संग्रह है, जिसे तार्किक रूप से कनेक्ट नहीं किया जा सकता है, लेकिन वर्तमान स्थिति/प्रोजेक्ट/सेटअप में एक ही उद्देश्य पूरा होता है। यह प्रदाताओं के लिए कॉन्फ़िगरेशन को परिभाषित करता है, जो डाउनस्ट्रीम संसाधन मॉड्यूल और संसाधनों को पास किया जाता है। यह आमतौर पर एक इकाई प्रति लॉजिकल सेपरेटर (जैसे, AWS क्षेत्र, Google प्रोजेक्ट) में काम करने तक सीमित होता है।
For example, terraform-aws-atlantis मॉड्यूल जैसे संसाधन मॉड्यूल का उपयोग करता है terraform-aws-vpc and terraform-aws-security-group चलाने के लिए आवश्यक बुनियादी ढांचे का प्रबंधन करने के लिए Atlantis on AWS Fargate.
एक और उदाहरण terraform-aws-cloudquery मॉड्यूल जहां द्वारा कई मॉड्यूल terraform-aws-modules बुनियादी ढांचे के प्रबंधन के साथ-साथ डॉकर छवियों को बनाने, धक्का देने और तैनात करने के लिए डॉकर संसाधनों का उपयोग करने के लिए एक साथ उपयोग किया जा रहा है। ऑल इन वन सेट।
संरचना बुनियादी ढांचे के मॉड्यूल का एक संग्रह है, जो कई तार्किक रूप से अलग क्षेत्रों (जैसे, AWS क्षेत्र, कई AWS खातों) में फैला हो सकता है। संरचना का उपयोग पूरे संगठन या परियोजना के लिए आवश्यक संपूर्ण बुनियादी ढांचे का वर्णन करने के लिए किया जाता है।
एक रचना में बुनियादी ढांचे के मॉड्यूल शामिल होते हैं, जिसमें संसाधन मॉड्यूल शामिल होते हैं, जो व्यक्तिगत संसाधनों को लागू करते हैं।
डेटा स्रोत केवल पढ़ने के लिए ऑपरेशन करता है और प्रदाता कॉन्फ़िगरेशन पर निर्भर होता है, इसका उपयोग संसाधन मॉड्यूल और इन्फ्रास्ट्रक्चर मॉड्यूल में किया जाता है।
डेटा स्रोत terraform_remote_state उच्च-स्तरीय मॉड्यूल और रचनाओं के लिए एक गोंद के रूप में कार्य करता है।
The external डेटा स्रोत एक बाहरी प्रोग्राम को डेटा स्रोत के रूप में कार्य करने की अनुमति देता है, जो टेराफ़ॉर्म कॉन्फ़िगरेशन में कहीं और उपयोग के लिए मनमाने ढंग से डेटा को उजागर करता है.यहां से एक उदाहरण दिया गया है terraform-aws-lambda module जहां बाहरी पायथन स्क्रिप्ट को कॉल करके फ़ाइल नाम की गणना की जाती है।
The http डेटा स्रोत दिए गए URL पर एक HTTP GET अनुरोध करता है और प्रतिक्रिया के बारे में जानकारी निर्यात करता है जो अक्सर उन एंडपॉइंट्स से जानकारी प्राप्त करने के लिए उपयोगी होता है जहां एक देशी टेराफ़ॉर्म प्रदाता मौजूद नहीं है।
इन्फ्रास्ट्रक्चर मॉड्यूल और रचनाओं को अपना बना रहना चाहिए Terraform state एक दूरस्थ स्थान पर जहां इसे दूसरों द्वारा नियंत्रित तरीके से पुनर्प्राप्त किया जा सकता है (e.g., specify ACL, versioning, logging).
आधिकारिक दस्तावेज़ीकरण में प्रदाता, प्रोविजनर और कुछ अन्य शर्तें बहुत अच्छी तरह से वर्णित हैं और यहां इसे दोहराने का कोई मतलब नहीं है। मेरी राय में, अच्छे टेराफॉर्म मॉड्यूल लिखने से उनका कोई लेना-देना नहीं है।
जबकि व्यक्तिगत संसाधन बुनियादी ढांचे में परमाणुओं की तरह होते हैं, संसाधन मॉड्यूल अणु (परमाणुओं से युक्त) होते हैं। एक मॉड्यूल सबसे छोटी संस्करण वाली और साझा करने योग्य इकाई है। इसमें तर्कों की एक सटीक सूची है, ऐसी इकाई के लिए आवश्यक फ़ंक्शन करने के लिए मूल तर्क लागू करें। e.g., terraform-aws-security-group module creates aws_security_group
and aws_security_group_rule
resources based on input. इन्फ्रास्ट्रक्चर मॉड्यूल बनाने के लिए अपने आप में इस संसाधन मॉड्यूल का उपयोग अन्य मॉड्यूल के साथ किया जा सकता है।
मॉड्यूल के आउटपुट और डेटा स्रोतों का उपयोग करके अणुओं (संसाधन मॉड्यूल और अवसंरचना मॉड्यूल) में डेटा तक पहुंच की जाती है।
रचनाओं के बीच पहुंच अक्सर रिमोट स्टेट डेटा स्रोतों का उपयोग करके की जाती है। There are multiple ways to share data between configurations.
छद्म संबंधों में ऊपर वर्णित अवधारणाओं को डालते समय यह इस तरह दिख सकता है:
ये उदाहरण AWS प्रदाता दिखा रहे हैं लेकिन उदाहरणों में दिखाए गए अधिकांश सिद्धांत अन्य सार्वजनिक क्लाउड प्रदाताओं के साथ-साथ अन्य प्रकार के प्रदाताओं (DNS, DB, मॉनिटरिंग, आदि) पर लागू किए जा सकते हैं।
कुछ संसाधन, कोई बाहरी निर्भरता नहीं। एकल एडब्ल्यूएस खाता। एकल क्षेत्र। एकल वातावरण।
Yes
टेराफॉर्म का उपयोग करते हुए कई AWS खाते और वातावरण, ऑफ-द-शेल्फ इंफ्रास्ट्रक्चर मॉड्यूल।
Yes
कई AWS खाते, कई क्षेत्र, कॉपी-पेस्ट, कस्टम इंफ्रास्ट्रक्चर मॉड्यूल, रचनाओं के भारी उपयोग को कम करने की तत्काल आवश्यकता है। टेराफॉर्म का उपयोग करना।
WIP
very-large
कई प्रदाता (AWS, GCP, Azure)। मल्टी-क्लाउड परिनियोजन। टेराफॉर्म का उपयोग करना।
No
medium
कई AWS खाते और वातावरण, ऑफ-द-शेल्फ इंफ्रास्ट्रक्चर मॉड्यूल, टेराग्रंट का उपयोग कर संरचना पैटर्न।
No
large
कई AWS खाते, कई क्षेत्र, कॉपी-पेस्ट, कस्टम इंफ्रास्ट्रक्चर मॉड्यूल, रचनाओं के भारी उपयोग को कम करने की तत्काल आवश्यकता है। टेराग्रंट का उपयोग करना।
No
very-large
कई प्रदाता (AWS, GCP, Azure)। मल्टी-क्लाउड परिनियोजन। टेराग्रंट का उपयोग करना।
No
Source:
इस उदाहरण में छोटे आकार के बुनियादी ढांचे के लिए टेराफॉर्म कॉन्फ़िगरेशन की संरचना के उदाहरण के रूप में कोड शामिल है, जहां कोई बाहरी निर्भरता का उपयोग नहीं किया जाता है।
आरंभ करने के लिए बिल्कुल सही और जैसे ही आप जाते हैं रिफैक्टर करें
छोटे संसाधन मॉड्यूल के लिए बिल्कुल सही
छोटे और रैखिक आधारभूत संरचना मॉड्यूल के लिए अच्छा है (eg, )
संसाधनों की एक छोटी संख्या के लिए अच्छा है (20-30 से कम)
यदि संसाधनों की संख्या बढ़ रही है तो सभी संसाधनों के लिए सिंगल स्टेट फाइल टेराफॉर्म के साथ काम करने की प्रक्रिया को धीमा कर सकती है (संसाधनों की संख्या को सीमित करने के लिए एक argument -target
का उपयोग करने पर विचार करें)
Source: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/large-terraform
इस उदाहरण में कोड को एक बड़े आकार के बुनियादी ढांचे के लिए टेराफॉर्म कॉन्फ़िगरेशन की संरचना के उदाहरण के रूप में शामिल किया गया है जो उपयोग करता है:
2 AWS खाते
2 क्षेत्र
2 अलग-अलग वातावरण (ठेस और मंच जो कुछ भी साझा नहीं करते हैं)। प्रत्येक वातावरण एक अलग AWS खाते में रहता है और 2 क्षेत्रों के बीच संसाधन फैलाता है प्रत्येक वातावरण टेराफॉर्म रजिस्ट्री से प्राप्त ऑफ-द-शेल्फ इंफ्रास्ट्रक्चर मॉड्यूल (एलबी) के एक अलग संस्करण का उपयोग करता है प्रत्येक वातावरण एक आंतरिक मॉड्यूल मॉड्यूल/नेटवर्क के समान संस्करण का उपयोग करता है क्योंकि इसे स्थानीय निर्देशिका से प्राप्त किया जाता है।
यहां वर्णित एक बड़ी परियोजना में टेराग्रंट का उपयोग करने के लाभ बहुत स्पष्ट हो जाते हैं. देखें Code Structures examples with Terragrunt.
देखेंउन परियोजनाओं के लिए बिल्कुल सही जहां बुनियादी ढांचा तार्किक रूप से अलग है (अलग AWSखाते)
अच्छा है जब AWS खातों के बीच साझा संसाधनों को संशोधित करने की आवश्यकता नहीं है (एक वातावरण = एक AWS खाता = एक राज्य फ़ाइल)
अच्छा है जब वातावरण के बीच परिवर्तन के आयोजन की कोई आवश्यकता नहीं है
अच्छा है जब बुनियादी ढाँचे के संसाधन प्रति पर्यावरण उद्देश्य से भिन्न होते हैं और उन्हें सामान्यीकृत नहीं किया जा सकता है (उदाहरण के लिए, कुछ संसाधन एक वातावरण में या कुछ क्षेत्रों में अनुपस्थित हैं)
जैसे-जैसे परियोजना बढ़ती है, इन परिवेशों को एक-दूसरे के साथ अप-टू-डेट रखना कठिन होगा। दोहराने योग्य कार्यों के लिए इंफ्रास्ट्रक्चर मॉड्यूल (ऑफ-द-शेल्फ या आंतरिक) का उपयोग करने पर विचार करें।
Source: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/medium-terraform
इस उदाहरण में एक मध्यम आकार के बुनियादी ढांचे के लिए टेराफॉर्म कॉन्फ़िगरेशन को संरचित करने के उदाहरण के रूप में कोड शामिल है जो उपयोग करता है:
2 AWS खाते
2 अलग-अलग वातावरण (ठेस और मंच जो कुछ भी साझा नहीं करते हैं)। प्रत्येक परिवेश एक अलग AWS खाते में रहता है
प्रत्येक परिवेश ऑफ़-द-शेल्फ अवसंरचना मॉड्यूल (alb) के भिन्न संस्करण का उपयोग करता है, जो Terraform Registry से प्राप्त होता है
प्रत्येक वातावरण एक आंतरिक मॉड्यूल मॉड्यूल/नेटवर्क के समान संस्करण का उपयोग करता है क्योंकि इसे स्थानीय निर्देशिका से प्राप्त किया जाता है।
उन परियोजनाओं के लिए बिल्कुल सही जहां बुनियादी ढांचा तार्किक रूप से अलग है (अलग AWS खाते)
अच्छा है जब AWS खातों के बीच साझा संसाधनों को संशोधित करने की आवश्यकता नहीं है (एक वातावरण = एक AWS खाता = एक राज्य फ़ाइल)
अच्छा है जब वातावरण के बीच परिवर्तन के आयोजन की कोई आवश्यकता नहीं है
अच्छा है जब बुनियादी ढाँचे के संसाधन प्रति पर्यावरण उद्देश्य से भिन्न होते हैं और उन्हें सामान्यीकृत नहीं किया जा सकता है (उदाहरण के लिए, कुछ संसाधन एक वातावरण में या कुछ क्षेत्रों में अनुपस्थित हैं)
जैसे-जैसे परियोजना बढ़ती है, इन परिवेशों को एक-दूसरे के साथ अप-टू-डेट रखना कठिन होगा। दोहराने योग्य कार्यों के लिए इंफ्रास्ट्रक्चर मॉड्यूल (ऑफ-द-शेल्फ या आंतरिक) का उपयोग करने पर विचार करें।
यह दस्तावेज़ टेराफ़ॉर्म का उपयोग करके सर्वोत्तम प्रथाओं का व्यवस्थित रूप से वर्णन करने का एक प्रयास है और टेराफ़ॉर्म उपयोगकर्ताओं द्वारा अनुभव की जाने वाली सबसे लगातार समस्याओं के लिए सिफारिशें प्रदान
Terraform शक्तिशाली है (यदि अभी सबसे शक्तिशाली नहीं है) और सबसे अधिक उपयोग किए जाने वाले उपकरणों में से एक है जो बुनियादी ढांचे के प्रबंधन को कोड के रूप में अनुमति देता है। यह डेवलपर्स को बहुत सी चीजें करने की अनुमति देता है और उन्हें उन चीजों को करने से प्रतिबंधित नहीं करता है जिनका समर्थन करना या एकीकृत करना मुश्किल होगा।
इस पुस्तक में वर्णित कुछ जानकारी सर्वोत्तम प्रथाओं की तरह नहीं लग सकती है। मुझे यह पता है, और पाठकों को स्थापित सर्वोत्तम प्रथाओं को अलग करने में मदद करने के लिए और चीजों को करने का एक और राय वाला तरीका क्या है, मैं कभी-कभी सर्वोत्तम प्रथाओं से संबंधित प्रत्येक उपखंड पर परिपक्वता के स्तर को निर्दिष्ट करने के लिए कुछ संदर्भ और आइकन प्रदान करने के लिए संकेतों का उपयोग करता हूं।
पुस्तक 2018 में सनी मैड्रिड में शुरू की गई थी, यहां मुफ्त में उपलब्ध है
https://www.terraform-best-practices.com/.
कुछ वर्षों बाद इसे टेराफॉर्म 1.0 के साथ उपलब्ध अधिक वास्तविक सर्वोत्तम प्रथाओं के साथ अद्यतन किया गया है। आखिरकार, इस पुस्तक में टेराफॉर्म उपयोगकर्ताओं के लिए निर्विवाद सर्वोत्तम अभ्यास और अनुशंसाएं शामिल होनी चाहिए।
Please contact me if you want to become a sponsor.
—
यदि आप इस पुस्तक का अन्य भाषाओं में अनुवाद करने में सहायता करना चाहते हैं तो मुझसे संपर्क करें।
मैं हमेशा फीडबैक प्राप्त करना चाहता हूं और इस पुस्तक को अपडेट करना चाहता हूं क्योंकि समुदाय परिपक्व होता है और समय के साथ नए विचारों को लागू और सत्यापित किया जाता है।
यदि आप विशिष्ट विषयों में रुचि रखते हैं, तो कृपया open an issue , या उस मुद्दे को स्वीकार करें जिसे आप कवर करना चाहते हैं। यदि आपको लगता है कि आपके पास सामग्री है और आप योगदान देना चाहते हैं, तो एक मसौदा लिखें और एक पुल अनुरोध सबमिट करें (इस समय अच्छा पाठ लिखने की चिंता न करें!)
इस पुस्तक का रखरखाव Anton Babenko द्वारा विभिन्न योगदानकर्ताओं और अनुवादकों की सहायता से किया जाता है।
यह काम Apache 2 लाइसेंस के तहत लाइसेंस प्राप्त है। पूरी जानकारी के लिए लाइसेंस देखें।
इस सामग्री के लेखक और योगदानकर्ता यहां मिली जानकारी की वैधता की गारंटी नहीं दे सकते। कृपया सुनिश्चित करें कि आप समझते हैं कि यहां प्रदान की गई जानकारी स्वतंत्र रूप से प्रदान की जा रही है, और यह कि आपके और इस सामग्री या परियोजना से जुड़े किसी भी व्यक्ति के बीच किसी प्रकार का समझौता या अनुबंध नहीं किया गया है। लेखक और योगदानकर्ता किसी भी पक्ष के लिए किसी भी नुकसान, क्षति, या इस सामग्री से जुड़ी या जुड़ी जानकारी में त्रुटियों या चूक के कारण होने वाले व्यवधान के लिए किसी भी दायित्व को स्वीकार नहीं करते हैं और इससे इनकार करते हैं, चाहे ऐसी त्रुटियां या चूक से परिणाम लापरवाही, दुर्घटना, या कोई अन्य कारण।
Copyright © 2018-2023 Anton Babenko.
कम से कम इन सम्मेलनों का पालन न करने का कोई कारण नहीं होना चाहिए :)
सावधान रहें कि वास्तविक क्लाउड संसाधनों में अक्सर अनुमत नामों पर प्रतिबंध होते हैं। उदाहरण के लिए, कुछ संसाधनों में डैश नहीं हो सकते, कुछ में ऊंट-आवरण होना चाहिए। इस पुस्तक में सम्मेलन स्वयं टेराफॉर्म नामों का उल्लेख करते हैं।
हर जगह - (डैश) के बजाय _ (अंडरस्कोर) का उपयोग करें (संसाधन नाम, डेटा स्रोत नाम, चर नाम, आउटपुट आदि में)
लोअरकेस अक्षरों और संख्याओं का उपयोग करना पसंद करें (भले ही UTF-8 समर्थित हो)।
संसाधन नाम में संसाधन प्रकार को न दोहराएं (आंशिक रूप से नहीं, न ही पूरी तरह से):
यदि कोई और वर्णनात्मक और सामान्य नाम उपलब्ध नहीं है, या यदि संसाधन मॉड्यूल इस प्रकार का एकल संसाधन बनाता है, तो संसाधन नाम को इसका नाम दिया जाना चाहिए (eg, in प्रकार का एक ही संसाधन है aws_nat_gateway
और प्रकार के कई संसाधन typeaws_route_table
, इसलिए aws_nat_gateway
नाम दिया जाना चाहिए this
तथाaws_route_table
अधिक वर्णनात्मक नाम होने चाहिए - जैसे private
, public
, database
).
नामों के लिए हमेशा एकवचन संज्ञा का प्रयोग करें।
उपयोग - तर्कों के अंदर मूल्यों और उन जगहों पर जहां मूल्य मानव के सामने आ जाएगा (eg, inside DNS name of RDS instance).
संसाधन या डेटा स्रोत ब्लॉक के अंदर तर्क count / for_each को शीर्ष पर पहले तर्क के रूप में शामिल करें और इसके बाद न्यूलाइन द्वारा अलग करें।
तर्क tags
शामिल करें, यदि संसाधन द्वारा समर्थित है, तो अंतिम वास्तविक तर्क के रूप में, यदि आवश्यक हो तो depends_on
and lifecycle
के बाद। इन सभी को एक खाली लाइन से अलग किया जाना चाहिए।
एक तर्क में शर्तों का उपयोग करते समय count
/ for_each
उपयोग करने के बजाय बूलियन मान पसंद करें length
या अन्य भाव.
resource
कोड के उदाहरणcount
/ for_each
का उपयोगtags
का स्थाननcount
संसाधन मॉड्यूल में पहिया का पुन: आविष्कार न करें: जिस संसाधन के साथ आप काम कर रहे हैं, उसके लिए "तर्क संदर्भ" अनुभाग में परिभाषित चर के लिए नाम, विवरण और डिफ़ॉल्ट मान का उपयोग करें।
चरों में सत्यापन के लिए समर्थन सीमित है (उदाहरण के लिए अन्य चरों तक नहीं पहुंच सकते हैं या लुकअप नहीं कर सकते हैं)। तदनुसार योजना बनाएं क्योंकि कई मामलों में यह सुविधा बेकार है।
एक चर नाम में बहुवचन रूप का प्रयोग करें जब प्रकार list(...) or map(...) हो।
इस तरह एक चर ब्लॉक में आदेश कुंजी:description , type, default, validation.
हमेशा सभी चरों पर विवरण शामिल करें, भले ही आपको लगता है कि यह स्पष्ट है (आपको भविष्य में इसकी आवश्यकता होगी)।
जब तक आपको प्रत्येक कुंजी पर सख्त बाधाओं की आवश्यकता न हो, तब तक साधारण प्रकार(number, string, list(...), map(...), any) कोई भी) विशिष्ट प्रकार जैसे object() का उपयोग करना पसंद करें।
यदि मानचित्र के सभी तत्वों का एक ही प्रकार (जैसे string) है या इसमें परिवर्तित किया जा सकता है (जैसे संख्या प्रकार को स्ट्रिंग में परिवर्तित किया जा सकता है) तो मानचित्र like map(map(string)) जैसे विशिष्ट प्रकारों का उपयोग करें।
एक निश्चित गहराई से शुरू होने वाले प्रकार सत्यापन को अक्षम करने के लिए या जब कई प्रकारों का समर्थन किया जाना चाहिए, तो टाइप करें का उपयोग करें।
मान {} कभी-कभी एक नक्शा होता है लेकिन कभी-कभी एक वस्तु। नक्शा बनाने के लिए tomap(...) का उपयोग करें क्योंकि कोई वस्तु बनाने का कोई तरीका नहीं है।
उत्पादन को उसके दायरे के बाहर संगत और समझने योग्य बनाएं (जब कोई उपयोगकर्ता मॉड्यूल का उपयोग कर रहा हो तो यह स्पष्ट होना चाहिए कि यह किस प्रकार और मूल्य का गुण लौटाता है)।
आउटपुट का नाम उस संपत्ति का वर्णन करना चाहिए जिसमें यह शामिल है और सामान्य रूप से जितना आप चाहते हैं उससे कम फ्री-फॉर्म होना चाहिए
आउटपुट के नाम के लिए अच्छी संरचना दिखती है {name}_{type}_{attribute}
, जहां:
{name}
प्रदाता उपसर्ग के बिना संसाधन या डेटा स्रोत का नाम है। {name}
for aws_subnet
is subnet
, foraws_vpc
it is vpc
.
{type}
संसाधन स्रोतों का एक प्रकार है
{attribute}
आउटपुट द्वारा लौटाई गई एक विशेषता है
हमेशा सभी आउटपुट के लिए विवरण description
शामिल करें भले ही आपको लगता है कि यह स्पष्ट है.
जब तक आप सभी मॉड्यूल में सभी जगहों पर इस आउटपुट के उपयोग को पूरी तरह से नियंत्रित नहीं करते तब तक संवेदनशील sensitive
तर्क सेट करने से बचें।
Prefer try()
(available since Terraform 0.13) over element(concat(...))
(legacy approach for the version before 0.13)
output
सुरक्षा समूह की अधिकतम एक आईडी पर लौटें:
एक ही प्रकार के कई संसाधन होने पर, इसे आउटपुट के नाम से हटा दिया जाना चाहिए:
locals
का प्रयोग करेंटेराफॉर्म को संकेत देने का मददगार तरीका कि टेराफॉर्म कॉन्फ़िगरेशन में कोई प्रत्यक्ष निर्भरता न होने पर भी कुछ संसाधनों को पहले हटा दिया जाना चाहिए।
आवश्यक तर्क index_document सेट किया जाना चाहिए, यदि var.website एक खाली नक्शा नहीं है।
वैकल्पिक तर्क error_document
छोड़ा जा सकता है।
उन लोगों के लिए एक कार्यशाला भी है जो इस गाइड में वर्णित कुछ चीजों का अभ्यास करना चाहते हैं।
The content is here -
FTP (Frequent Terraform Problems)
- Orchestration tool (ऑर्केस्ट्रेशन टूल)
- Code linter (कोड लिंटर)
- Version manager (संस्करण प्रबंधक)
- Pull Request automation (पुल अनुरोध स्वचालन)
- उपयोग किए जाने वाले टेराफॉर्म के लिए गिट हुक का संग्रह
- टेराफॉर्म इन पुल अनुरोधों के लिए क्लाउड लागत अनुमान। Terragrunt, Atlantis और pre-commit-terraform के साथ भी काम करता है.
संसाधन और आधारभूत संरचना मॉड्यूल के संस्करण निर्दिष्ट किए जाने चाहिए। प्रदाताओं को मॉड्यूल के बाहर कॉन्फ़िगर किया जाना चाहिए, लेकिन केवल संरचना में। प्रदाताओं के संस्करण और टेराफॉर्म को भी लॉक किया जा सकता है।
कोई मास्टर निर्भरता प्रबंधन उपकरण नहीं है, लेकिन निर्भरता विनिर्देशों को कम समस्याग्रस्त बनाने के लिए कुछ सुझाव हैं। उदाहरण के लिए, निर्भरता अद्यतनों को स्वचालित करने के लिए उपयोग किया जा सकता है। Dependabot आपकी निर्भरताओं को सुरक्षित और अद्यतित रखने के लिए पुल अनुरोध बनाता है। डिपेंडाबॉट टेराफॉर्म कॉन्फ़िगरेशन का समर्थन करता है।
— Terraform Compliance Simplified. Make your Terraform modules compliance-ready.
.
यदि आउटपुट प्रक्षेप कार्यों और कई संसाधनों के साथ एक मान लौटा रहा है, {name}
and {type}
जितना संभव हो उतना सामान्य होना चाहिए (this
as prefix should be omitted). .
यदि लौटाया गया मान एक सूची है तो उसका बहुवचन नाम होना चाहिए। .
बहुत सारे लोग हैं जो महान सामग्री बनाते हैं और टेराफॉर्म समुदाय के लिए प्रासंगिक ओपन-सोर्स परियोजनाओं का प्रबंधन करते हैं, लेकिन मैं इन लिंक्स को सूचीबद्ध करने के लिए सबसे अच्छी संरचना के बारे में नहीं सोच सकता, जैसे कि सूचियों की नकल किए बिना awesome-terraform.
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.
उदाहरण और टेराफॉर्म मॉड्यूल में सुविधाओं की व्याख्या करने वाले दस्तावेज और उनका उपयोग कैसे करना चाहिए।
टेराफॉर्म रजिस्ट्री वेबसाइट को सही ढंग से दिखाने के लिए README.md फाइलों के सभी लिंक पूर्ण होने चाहिए।
दस्तावेज़ीकरण में mermaid के साथ बनाए गए आरेख और cloudcraft.co के साथ बनाए गए ब्लूप्रिंट शामिल हो सकते हैं।
यह सुनिश्चित करने के लिए Terraform pre-commit hooks का उपयोग करें कि कोड मान्य है, ठीक से स्वरूपित है, और स्वचालित रूप से इसे git में धकेलने और मनुष्यों द्वारा समीक्षा करने से पहले प्रलेखित किया गया है।
pre-commit बहु-भाषा प्री-कमिट हुक के प्रबंधन और रखरखाव के लिए एक ढांचा है। यह Python में लिखा गया है और एक गिट रिपॉजिटरी के लिए कोड प्रतिबद्ध होने से पहले एक डेवलपर की मशीन पर स्वचालित रूप से कुछ करने के लिए एक शक्तिशाली उपकरण है। आम तौर पर, इसका उपयोग लिंटर चलाने और कोड को प्रारूपित करने के लिए किया जाता है (see supported hooks).
टेराफॉर्म कॉन्फ़िगरेशन के साथ pre-commit
का उपयोग कोड को प्रारूपित करने और मान्य करने के साथ-साथ प्रलेखन को अपडेट करने के लिए किया जा सकता है.
इसके साथ खुद को परिचित करने के लिए pre-commit-terraform repository भंडार देखें, और मौजूदा भंडार (उदाहरण के लिए, terraform-aws-vpc)) जहां यह पहले से ही उपयोग किया जाता है।
terraform-docs एक ऐसा उपकरण है जो विभिन्न आउटपुट स्वरूपों में टेराफॉर्म मॉड्यूल से प्रलेखन तैयार करता है। आप इसे मैन्युअल रूप से चला सकते हैं (प्री-कमिट हुक के बिना), or use pre-commit-terraform hooks दस्तावेज़ को स्वचालित रूप से अपडेट करने के लिए.
@todo: Document module versions, release, GH actions
टेराफॉर्म कोड संरचना से संबंधित प्रश्न समुदाय में अब तक सबसे अधिक बार आते हैं। सभी ने क