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

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

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

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

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

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

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

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

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

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

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

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

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

  • 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 के लिए कोड संरचनाओं के उदाहरण देखें।

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

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

• 2 AWS खाते

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

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

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

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