नामकरण की परंपरा
Last updated
Last updated
हर जगह - (डैश) के बजाय _ (अंडरस्कोर) का उपयोग करें (संसाधन नाम, डेटा स्रोत नाम, चर नाम, आउटपुट आदि में)
लोअरकेस अक्षरों और संख्याओं का उपयोग करना पसंद करें (भले ही 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
सुरक्षा समूह की अधिकतम एक आईडी पर लौटें:
एक ही प्रकार के कई संसाधन होने पर, इसे आउटपुट के नाम से हटा दिया जाना चाहिए:
.
यदि आउटपुट प्रक्षेप कार्यों और कई संसाधनों के साथ एक मान लौटा रहा है, {name}
and {type}
जितना संभव हो उतना सामान्य होना चाहिए (this
as prefix should be omitted). .
यदि लौटाया गया मान एक सूची है तो उसका बहुवचन नाम होना चाहिए। .