Source: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/medium-terraform
इस उदाहरण में एक मध्यम आकार के बुनियादी ढांचे के लिए टेराफॉर्म कॉन्फ़िगरेशन को संरचित करने के उदाहरण के रूप में कोड शामिल है जो उपयोग करता है:
2 AWS खाते
2 अलग-अलग वातावरण (ठेस और मंच जो कुछ भी साझा नहीं करते हैं)। प्रत्येक परिवेश एक अलग AWS खाते में रहता है
प्रत्येक परिवेश ऑफ़-द-शेल्फ अवसंरचना मॉड्यूल (alb) के भिन्न संस्करण का उपयोग करता है, जो Terraform Registry से प्राप्त होता है
प्रत्येक वातावरण एक आंतरिक मॉड्यूल मॉड्यूल/नेटवर्क के समान संस्करण का उपयोग करता है क्योंकि इसे स्थानीय निर्देशिका से प्राप्त किया जाता है।
उन परियोजनाओं के लिए बिल्कुल सही जहां बुनियादी ढांचा तार्किक रूप से अलग है (अलग AWS खाते)
अच्छा है जब AWS खातों के बीच साझा संसाधनों को संशोधित करने की आवश्यकता नहीं है (एक वातावरण = एक AWS खाता = एक राज्य फ़ाइल)
अच्छा है जब वातावरण के बीच परिवर्तन के आयोजन की कोई आवश्यकता नहीं है
अच्छा है जब बुनियादी ढाँचे के संसाधन प्रति पर्यावरण उद्देश्य से भिन्न होते हैं और उन्हें सामान्यीकृत नहीं किया जा सकता है (उदाहरण के लिए, कुछ संसाधन एक वातावरण में या कुछ क्षेत्रों में अनुपस्थित हैं)
जैसे-जैसे परियोजना बढ़ती है, इन परिवेशों को एक-दूसरे के साथ अप-टू-डेट रखना कठिन होगा। दोहराने योग्य कार्यों के लिए इंफ्रास्ट्रक्चर मॉड्यूल (ऑफ-द-शेल्फ या आंतरिक) का उपयोग करने पर विचार करें।
Source: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/small-terraform
इस उदाहरण में छोटे आकार के बुनियादी ढांचे के लिए टेराफॉर्म कॉन्फ़िगरेशन की संरचना के उदाहरण के रूप में कोड शामिल है, जहां कोई बाहरी निर्भरता का उपयोग नहीं किया जाता है।
आरंभ करने के लिए बिल्कुल सही और जैसे ही आप जाते हैं रिफैक्टर करें
छोटे संसाधन मॉड्यूल के लिए बिल्कुल सही
छोटे और रैखिक आधारभूत संरचना मॉड्यूल के लिए अच्छा है (eg, terraform-aws-atlantis)
संसाधनों की एक छोटी संख्या के लिए अच्छा है (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 खाता = एक राज्य फ़ाइल)
अच्छा है जब वातावरण के बीच परिवर्तन के आयोजन की कोई आवश्यकता नहीं है
अच्छा है जब बुनियादी ढाँचे के संसाधन प्रति पर्यावरण उद्देश्य से भिन्न होते हैं और उन्हें सामान्यीकृत नहीं किया जा सकता है (उदाहरण के लिए, कुछ संसाधन एक वातावरण में या कुछ क्षेत्रों में अनुपस्थित हैं)
जैसे-जैसे परियोजना बढ़ती है, इन परिवेशों को एक-दूसरे के साथ अप-टू-डेट रखना कठिन होगा। दोहराने योग्य कार्यों के लिए इंफ्रास्ट्रक्चर मॉड्यूल (ऑफ-द-शेल्फ या आंतरिक) का उपयोग करने पर विचार करें।