भविष्य के लिए टेराफॉर्म में बुनियादी ढांचे का विवरण। एंटोन बबेंको (2018)

बहुत से लोग टेराफॉर्म को अपने दैनिक कार्यों में जानते हैं और उसका उपयोग करते हैं, लेकिन इसके लिए सर्वोत्तम अभ्यास अभी तक नहीं बनाए गए हैं। प्रत्येक टीम को अपने स्वयं के दृष्टिकोण और तरीकों का आविष्कार करना होगा।

आपका बुनियादी ढांचा लगभग निश्चित रूप से सरल शुरू होता है: कुछ संसाधन + कुछ डेवलपर्स। समय के साथ, यह सभी प्रकार की दिशाओं में बढ़ता है। क्या आप संसाधनों को टेराफॉर्म मॉड्यूल में समूहित करने, कोड को फ़ोल्डरों में व्यवस्थित करने, और संभवतः और क्या गलत हो सकता है, इसके तरीके ढूंढते हैं? (प्रसिद्ध अंतिम शब्द)

समय बीतता है और आपको ऐसा महसूस होता है कि आपका बुनियादी ढांचा आपका नया पालतू जानवर है, लेकिन क्यों? आप बुनियादी ढांचे में अकथनीय परिवर्तनों के बारे में चिंतित हैं, आप बुनियादी ढांचे और कोड को छूने से डरते हैं - परिणामस्वरूप, आप नई कार्यक्षमता में देरी करते हैं या गुणवत्ता कम करते हैं...

जीथब पर एडब्ल्यूएस के लिए टेराफॉर्म सामुदायिक मॉड्यूल के संग्रह को प्रबंधित करने और उत्पादन में टेराफॉर्म के दीर्घकालिक रखरखाव के तीन साल बाद, एंटोन बबेंको अपना अनुभव साझा करने के लिए तैयार हैं: टीएफ मॉड्यूल कैसे लिखें ताकि भविष्य में कोई नुकसान न हो।

बातचीत के अंत तक, प्रतिभागी टेराफॉर्म में संसाधन प्रबंधन सिद्धांतों, टेराफॉर्म में मॉड्यूल से जुड़ी सर्वोत्तम प्रथाओं और बुनियादी ढांचे प्रबंधन से जुड़े कुछ निरंतर एकीकरण सिद्धांतों से अधिक परिचित होंगे।

अस्वीकरण: मैंने नोट किया है कि यह रिपोर्ट नवंबर 2018 की है—2 साल पहले ही बीत चुके हैं। रिपोर्ट में चर्चा की गई टेराफॉर्म 0.11 का संस्करण अब समर्थित नहीं है। पिछले 2 वर्षों में, 2 नई रिलीज़ जारी की गई हैं, जिनमें बहुत सारे नवाचार, सुधार और परिवर्तन शामिल हैं। कृपया इस पर ध्यान दें और दस्तावेज़ की जाँच करें।

कड़ियाँ:

• टेराफॉर्म-समुदाय-मॉड्यूल + टेराफॉर्म-एडब्ल्यूएस-मॉड्यूल
• एंटोनबाबेंको/प्री-कमिट-टेराफॉर्म - ऑटो-फ़ॉर्मेटिंग कोड और दस्तावेज़ीकरण
• एंटोनबाबेंको/टेरापिन - टेराफॉर्म मॉड्यूल (डब्ल्यूआईपी) का जनरेटर
• एंटोनबाबेंको/मॉड्यूल.tf-lambda - दृश्य आरेखों से टेराफॉर्म कोड जनरेटर (डब्ल्यूआईपी)
• www.terraform-best-practices.com
• मीडियम.com/@anton.babeno (नए पोस्ट मेरी निजी वेबसाइट www.antonbabeno.com/ पर हैं)
• @antonbabeno - ट्विटर, और विभिन्न स्लैक्स का एक समूह

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

मैं टेराफॉर्म पर काम करता हूं और 2015 से टेराफॉर्म और अमेज़ॅन से संबंधित बड़ी संख्या में ओपन सोर्स परियोजनाओं में सक्रिय भागीदार और योगदानकर्ता रहा हूं।

तब से मैंने इसे दिलचस्प तरीके से रखने के लिए पर्याप्त कोड लिखा है। और मैं अब आपको इसके बारे में बताने की कोशिश करूंगा।

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

समय के साथ, मैंने टेराफॉर्म मॉड्यूल लिखना शुरू कर दिया। उपयोगकर्ताओं ने प्रश्न लिखे, मैंने उन्हें दोबारा लिखा। फिर मैंने प्री-कमिट हुक आदि का उपयोग करके कोड को प्रारूपित करने के लिए विभिन्न उपयोगिताएँ लिखीं।

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

मैं यूक्रेन से हूं। मैं कई वर्षों तक नॉर्वे में रहा हूँ।

साथ ही, इस रिपोर्ट के लिए जानकारी उन लोगों से एकत्र की गई थी जो मेरा नाम जानते हैं और मुझे सोशल नेटवर्क पर पाते हैं। मेरा उपनाम लगभग हमेशा एक ही जैसा रहता है।

https://github.com/terraform-aws-modules
https://registry.terraform.io/namespaces/terraform-aws-modules

जैसा कि मैंने उल्लेख किया है, मैं टेराफॉर्म एडब्ल्यूएस मॉड्यूल का मुख्य अनुरक्षक हूं, जो गिटहब पर सबसे बड़े रिपॉजिटरी में से एक है जहां हम सबसे सामान्य कार्यों के लिए मॉड्यूल होस्ट करते हैं: वीपीसी, ऑटोस्केलिंग, आरडीएस।

और अब आपने जो सुना वह सबसे बुनियादी है। यदि आपको संदेह है कि आप समझते हैं कि टेराफॉर्म क्या है, तो अपना समय कहीं और बिताना बेहतर है। यहां बहुत सारे तकनीकी शब्द होंगे. और मुझे रिपोर्ट का स्तर उच्चतम बताने में कोई संकोच नहीं हुआ. इसका मतलब यह है कि मैं बिना अधिक स्पष्टीकरण के सभी संभावित शब्दों का उपयोग करके बात कर सकता हूं।

टेराफॉर्म 2014 में एक उपयोगिता के रूप में सामने आया जिसने आपको कोड के रूप में बुनियादी ढांचे को लिखने, योजना बनाने और प्रबंधित करने की अनुमति दी। यहां मुख्य अवधारणा "कोड के रूप में बुनियादी ढांचा" है।

जैसा कि मैंने कहा, सभी दस्तावेज़ लिखित हैं terraform.io. मुझे आशा है कि अधिकांश लोग इस साइट के बारे में जानते हैं और दस्तावेज़ पढ़ चुके हैं। अगर ऐसा है तो आप सही जगह पर हैं.

यह एक नियमित टेराफॉर्म कॉन्फ़िगरेशन फ़ाइल जैसा दिखता है, जहां हम पहले कुछ चर परिभाषित करते हैं।

इस मामले में हम "aws_region" को परिभाषित करते हैं।

फिर हम वर्णन करते हैं कि हम कौन से संसाधन बनाना चाहते हैं।

निर्भरता और प्रदाताओं को लोड करने के लिए हम कुछ कमांड चलाते हैं, विशेष रूप से "टेराफॉर्म इनिट"।

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

हम इसकी पुष्टि करते हैं. इस प्रकार हम सीस्नेल नामक एक बाल्टी बनाते हैं।

ऐसी ही कई उपयोगिताएँ भी हैं। आप में से कई लोग जो अमेज़ॅन का उपयोग करते हैं वे AWS क्लाउडफॉर्मेशन या Google क्लाउड परिनियोजन प्रबंधक या Azure संसाधन प्रबंधक को जानते हैं। इनमें से प्रत्येक सार्वजनिक क्लाउड प्रदाता के भीतर संसाधनों के प्रबंधन के लिए किसी न किसी प्रकार का अपना स्वयं का कार्यान्वयन है। टेराफॉर्म विशेष रूप से उपयोगी है क्योंकि यह आपको 100 से अधिक प्रदाताओं को प्रबंधित करने की अनुमति देता है। (अधिक जानकारी यहां)

टेराफ़ॉर्म ने शुरू से ही जिन लक्ष्यों का पीछा किया है:

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

2014 में, इस संदर्भ में "अनुमानित" शब्द बहुत ही असामान्य लग रहा था।

टेराफॉर्म एक सार्वभौमिक उपयोगिता है। यदि आपके पास एपीआई है, तो आप पूरी तरह से सब कुछ नियंत्रित कर सकते हैं:

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

यह सब टेराफॉर्म प्रदाताओं का उपयोग करके हासिल किया गया है, जिनके पास एक खुली एपीआई है जिसे गो में वर्णित किया जा सकता है।

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

और सब कुछ बढ़िया है, आपके पास एक फ़ाइल है जो VPC बनाती है।

यदि आप VPC बनाना चाहते हैं, तो आप लगभग इन 12 पंक्तियों को निर्दिष्ट करते हैं। वर्णन करें कि आप किस क्षेत्र में निर्माण करना चाहते हैं, आईपी पते के किस cidr_block का उपयोग करना है। बस इतना ही।

स्वाभाविक रूप से, परियोजना धीरे-धीरे बढ़ेगी।

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

आइए निम्नलिखित उदाहरण देखें.

आप धीरे-धीरे इंटरनेट_गेटवे जोड़ते हैं क्योंकि आप चाहते हैं कि आपके वीपीसी से संसाधनों तक इंटरनेट की पहुंच हो। यह एक अच्छा विचार है।

परिणाम यह है main.tf:

यह main.tf का शीर्ष भाग है।

यह main.tf का निचला भाग है।

फिर आप सबनेट जोड़ें। जब तक आप NAT गेटवे, रूट, राउटिंग टेबल और अन्य सबनेट का एक समूह जोड़ना चाहेंगे, आपके पास 38 लाइनें नहीं, बल्कि लगभग 200-300 लाइनें होंगी।

यानी आपकी main.tf फ़ाइल धीरे-धीरे बढ़ रही है। और अक्सर लोग सब कुछ एक फ़ाइल में रख देते हैं। Main.tf में 10-20 Kb दिखाई देता है। कल्पना कीजिए कि 10-20 Kb पाठ्य सामग्री है। और हर चीज़ हर चीज़ से जुड़ी हुई है। इसके साथ काम करना धीरे-धीरे कठिन होता जा रहा है। 10-20 केबी एक अच्छा उपयोगकर्ता मामला है, कभी-कभी इससे भी अधिक। और लोग हमेशा यह नहीं सोचते कि यह बुरा है।

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

• कोड बढ़ रहा है.
• संसाधनों के बीच निर्भरता भी बढ़ रही है।

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

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

इसलिए हम यह समझने की कोशिश कर रहे हैं कि हम अपने 10-20-30 Kb कोड को कैसे अनुकूलित करेंगे। हम धीरे-धीरे महसूस कर रहे हैं कि हमें कुछ मॉड्यूल का उपयोग करने की आवश्यकता है।

आपके सामने आने वाले पहले प्रकार के मॉड्यूल संसाधन मॉड्यूल हैं। वे नहीं समझते कि आपका बुनियादी ढांचा किस बारे में है, आपका व्यवसाय किस बारे में है, कहां और क्या स्थितियां हैं। ये बिल्कुल वही मॉड्यूल हैं जिन्हें मैं ओपन सोर्स समुदाय के साथ मिलकर प्रबंधित करता हूं, और जिन्हें हम आपके बुनियादी ढांचे के लिए शुरुआती बिल्डिंग ब्लॉक के रूप में सामने रखते हैं।

संसाधन मॉड्यूल का एक उदाहरण.

जब हम किसी संसाधन मॉड्यूल को कॉल करते हैं, तो हम निर्दिष्ट करते हैं कि हमें इसकी सामग्री को किस पथ से लोड करना चाहिए।

हम इंगित करते हैं कि हम कौन सा संस्करण डाउनलोड करना चाहते हैं।

हम वहां बहुत सारे तर्क पारित करते हैं। बस इतना ही। जब हम इस मॉड्यूल का उपयोग करते हैं तो हमें बस इतना ही जानना आवश्यक है।

बहुत से लोग सोचते हैं कि यदि वे नवीनतम संस्करण का उपयोग करेंगे तो सब कुछ स्थिर हो जाएगा। लेकिन कोई नहीं। बुनियादी ढांचे का संस्करण होना चाहिए; हमें स्पष्ट रूप से उत्तर देना चाहिए कि यह या वह घटक किस संस्करण में तैनात किया गया था।

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

यूजर को यह जानने की जरूरत नहीं है कि इसे अंदर कैसे बनाया जाता है।

दूसरे प्रकार के मॉड्यूल, जिसमें संसाधन मॉड्यूल शामिल हैं, पहले से ही उन समस्याओं को हल करते हैं जो आपके व्यवसाय पर अधिक लागू होती हैं। अक्सर यह एक ऐसा स्थान होता है जो टेराफॉर्म के लिए एक विस्तार होता है और कंपनी मानकों के लिए टैग के लिए कुछ कठोर मान निर्धारित करता है। आप वहां ऐसी कार्यक्षमता भी जोड़ सकते हैं जिसे टेराफॉर्म वर्तमान में आपको उपयोग करने की अनुमति नहीं देता है। ये अभी है. अब संस्करण 0.11, जो अतीत की बात बनने जा रहा है। लेकिन फिर भी, प्रीप्रोसेसर, जेसननेट, कुकीकटर और अन्य चीजों का एक समूह सहायक तंत्र है जिसका उपयोग पूर्ण कार्य के लिए किया जाना चाहिए।

आगे मैं इसके कुछ उदाहरण दिखाऊंगा.

इन्फ्रास्ट्रक्चर मॉड्यूल को बिल्कुल उसी तरह कहा जाता है।

वह स्रोत जहाँ से सामग्री डाउनलोड करनी है, दर्शाया गया है।

मानों का एक समूह इस मॉड्यूल में डाला और डाला जाता है।

इसके बाद, इस मॉड्यूल के अंदर, वीपीसी या एप्लिकेशन लोड बैलेंसर बनाने के लिए, या सुरक्षा-समूह बनाने के लिए या इलास्टिक कंटेनर सर्विस क्लस्टर के लिए संसाधन मॉड्यूल का एक समूह बुलाया जाता है।

मॉड्यूल दो प्रकार के होते हैं. यह समझना महत्वपूर्ण है क्योंकि इस रिपोर्ट में मैंने जो अधिकांश जानकारी समूहीकृत की है वह दस्तावेज़ में नहीं लिखी गई है।

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

आइए आगे देखें कि इन मॉड्यूल को कैसे लिखा जाए। फिर हम देखेंगे कि उन्हें कैसे कॉल करना है और कोड के साथ कैसे काम करना है।

टेराफॉर्म रजिस्ट्री - https://registry.terraform.io/

युक्ति #0 संसाधन मॉड्यूल नहीं लिखना है। इनमें से अधिकांश मॉड्यूल आपके लिए पहले से ही लिखे गए हैं। जैसा कि मैंने कहा, वे खुले स्रोत हैं, उनमें आपका कोई व्यावसायिक तर्क शामिल नहीं है, उनके पास आईपी पते, पासवर्ड आदि के लिए हार्डकोडेड मान नहीं हैं। मॉड्यूल बहुत लचीला है। और यह संभवतः पहले ही लिखा जा चुका है। अमेज़ॅन के संसाधनों के लिए कई मॉड्यूल हैं। लगभग 650. और उनमें से अधिकांश अच्छी गुणवत्ता के हैं।

इस उदाहरण में, कोई आपके पास आया और बोला, “मैं एक डेटाबेस प्रबंधित करने में सक्षम होना चाहता हूँ। एक मॉड्यूल बनाएं ताकि मैं एक डेटाबेस बना सकूं।" वह व्यक्ति अमेज़ॅन या टेराफ़ॉर्म के कार्यान्वयन विवरण नहीं जानता है। वह बस इतना कहता है: "मैं एमएसएसक्यूएल का प्रबंधन करना चाहता हूं।" यानी, हमारा मतलब है कि यह हमारे मॉड्यूल को कॉल करेगा, वहां इंजन प्रकार को पास करेगा, और समय क्षेत्र को इंगित करेगा।

और किसी व्यक्ति को यह नहीं पता होना चाहिए कि हम इस मॉड्यूल के अंदर दो अलग-अलग संसाधन बनाएंगे: एक एमएसएसक्यूएल के लिए, दूसरा बाकी सभी चीजों के लिए, केवल इसलिए कि टेराफॉर्म 0.11 में आप समय क्षेत्र मानों को वैकल्पिक के रूप में निर्दिष्ट नहीं कर सकते हैं।

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

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

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

https://github.com/mbtproject/mbt

इस समस्या के दो समाधान हैं. पहला है सापेक्ष पथों का उपयोग करना। इस तरह आप कोड में इंगित करते हैं कि फ़ोल्डर स्थानीय (./) है। और इससे पहले कि आप कुछ भी लॉन्च करें, आप स्थानीय स्तर पर इस रिपॉजिटरी का Git क्लोन बनाते हैं। इस तरह आप एक बार करें.

निःसंदेह, इसके बहुत सारे नकारात्मक पक्ष हैं। उदाहरण के लिए, आप संस्करणीकरण का उपयोग नहीं कर सकते. और इसके साथ रहना कभी-कभी कठिन होता है।

दूसरा उपाय. यदि आपके पास बहुत सारे सबमॉड्यूल हैं और आपके पास पहले से ही किसी प्रकार की स्थापित पाइपलाइन है, तो एमबीटी प्रोजेक्ट है, जो आपको एक मोनोरिपोजिटरी से कई अलग-अलग पैकेज इकट्ठा करने और उन्हें एस 3 पर अपलोड करने की अनुमति देता है। ये बहुत अच्छा तरीका है. इस प्रकार, iam-user-1.0.0.zip फ़ाइल का वजन केवल 1 Kb होगा, क्योंकि इस संसाधन को बनाने का कोड बहुत छोटा है। और यह बहुत तेजी से काम करेगा.

आइए इस बारे में बात करें कि मॉड्यूल में क्या उपयोग नहीं किया जा सकता है।

मॉड्यूल में यह बुराई क्यों है? सबसे बुरी बात यह है कि उपयोगकर्ता मान लें। मान लें कि उपयोगकर्ता एक प्रदाता प्रमाणीकरण विकल्प है जिसका उपयोग विभिन्न लोगों द्वारा किया जा सकता है। उदाहरण के लिए, हम सभी भूमिका को आत्मसात करेंगे। इसका मतलब यह है कि टेराफॉर्म यह भूमिका निभाएगा। और फिर इस भूमिका के साथ यह अन्य कार्य भी करेगा।

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

दूसरी बुराई प्रावधानकर्ता है। यहां बुराई इतनी मामूली नहीं है, क्योंकि अगर आप कोड लिखते हैं और यह आपके लिए काम करता है, तो आप सोच सकते हैं कि अगर यह काम करता है, तो इसे क्यों बदलें।

बुराई यह है कि आप हमेशा यह नियंत्रित नहीं करते कि यह प्रावधानकर्ता सबसे पहले कब लॉन्च किया जाएगा। और दूसरी बात, आप यह नियंत्रित नहीं कर सकते कि aws ec2 का क्या मतलब है, यानी अब हम Linux या Windows के बारे में बात कर रहे हैं। इसलिए आप ऐसा कुछ नहीं लिख सकते जो अलग-अलग ऑपरेटिंग सिस्टम पर या अलग-अलग उपयोगकर्ता मामलों के लिए समान रूप से काम करेगा।

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

वास्तव में, हां, इसमें कुछ भी गलत नहीं है। लेकिन वस्तुतः जल्द ही आपको एहसास होगा कि यह स्थानीय-कार्यकारी चीज़ मौजूद नहीं है, उदाहरण के लिए, लॉन्च_कॉन्फिगरेशन में।

और जब आप लॉन्च_कॉन्फिगरेशन का उपयोग करते हैं, और आप एक उदाहरण से एक ऑटोस्केलिंग समूह बनाना चाहते हैं, तो लॉन्च_कॉन्फिगरेशन में "प्रावधानकर्ता" की कोई अवधारणा नहीं है। "उपयोगकर्ता डेटा" की अवधारणा है।

इसलिए, उपयोगकर्ता डेटा का उपयोग करना अधिक सार्वभौमिक समाधान है। और इसे या तो इंस्टेंस पर ही लॉन्च किया जाएगा, जब इंस्टेंस चालू होता है, या उसी उपयोगकर्ता डेटा में, जब ऑटोस्केलिंग समूह इस लॉन्च_कॉन्फिगरेशन का उपयोग करता है।

यदि आप अभी भी प्रोविजनर को चलाना चाहते हैं, क्योंकि यह एक ग्लूइंग घटक है, जब एक संसाधन बनाया जाता है, तो उस समय आपको अपने प्रोविजनर, अपने कमांड को चलाने की आवश्यकता होती है। ऐसी बहुत सी स्थितियाँ हैं.

और इसके लिए सबसे सही संसाधन को null_resource कहा जाता है। Null_resource एक डमी संसाधन है जो वास्तव में कभी नहीं बनाया गया है। यह कुछ भी नहीं छूता, कोई एपीआई नहीं, कोई ऑटोस्केलिंग नहीं। लेकिन यह आपको यह नियंत्रित करने की अनुमति देता है कि कमांड कब चलाना है। इस स्थिति में, कमांड निर्माण के दौरान चलाया जाता है।

लिंक http://bit.ly/common-traits-in-terraform-modules

कई संकेत हैं. मैं सभी संकेतों के बारे में विस्तार से नहीं बताऊंगा। इस बारे में एक लेख है. लेकिन अगर आपने टेराफॉर्म के साथ काम किया है या अन्य लोगों के मॉड्यूल का उपयोग किया है, तो आपने अक्सर देखा होगा कि कई मॉड्यूल, जैसे ओपन सोर्स के अधिकांश कोड, लोगों द्वारा अपनी जरूरतों के लिए लिखे जाते हैं। एक आदमी ने इसे लिखा और अपनी समस्या का समाधान किया। मैंने इसे GitHub में चिपका दिया है, इसे रहने दें। यह जीवित रहेगा, लेकिन अगर वहां कोई दस्तावेज और उदाहरण नहीं हैं, तो कोई इसका उपयोग नहीं करेगा। और यदि ऐसी कोई कार्यक्षमता नहीं है जो आपको इसके विशिष्ट कार्य से थोड़ा अधिक हल करने की अनुमति देती है, तो कोई भी इसका उपयोग नहीं करेगा। उपयोगकर्ताओं को खोने के बहुत सारे तरीके हैं।

यदि आप कुछ लिखना चाहते हैं ताकि लोग इसका उपयोग करें, तो मैं इन संकेतों का पालन करने की सलाह देता हूं।

वे हैं:

• दस्तावेज़ीकरण और उदाहरण.
• पूर्ण कार्यक्षमता.
• उचित चूक.
• साफ़ कोड.
• टेस्ट।

परीक्षण एक अलग स्थिति है क्योंकि उन्हें लिखना काफी कठिन होता है। मैं दस्तावेज़ीकरण और उदाहरणों में अधिक विश्वास करता हूँ।

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

यह दस्तावेज़ का धूसर भाग है. अब आप सोच रहे होंगे: “कुछ अस्पष्ट है। कायल नहीं।" लेकिन हम छह महीने में देखेंगे.

अब बात करते हैं कि इन मॉड्यूल को कैसे कॉल करें।

हम समझते हैं कि हमारा कोड समय के साथ बढ़ता जाता है। अब हमारे पास एक फ़ाइल नहीं है, हमारे पास पहले से ही 20 फ़ाइलें हैं। वे सभी एक फ़ोल्डर में हैं. या शायद पाँच फ़ोल्डर. हो सकता है कि हम किसी तरह उन्हें क्षेत्र के आधार पर, कुछ घटकों के आधार पर तोड़ना शुरू कर रहे हों। तब हम समझते हैं कि अब हमारे पास सिंक्रोनाइज़ेशन और ऑर्केस्ट्रेशन की कुछ बुनियादी बातें हैं। अर्थात्, हमें यह समझना चाहिए कि यदि हमने नेटवर्क संसाधनों को बदल दिया है तो हमें क्या करना चाहिए, हमें अपने बाकी संसाधनों के साथ क्या करना चाहिए, इन निर्भरताओं का कारण कैसे बनना चाहिए, आदि।

दो चरम सीमाएँ हैं। पहला चरम सब एक में है। हमारे पास एक मास्टर फ़ाइल है. फिलहाल, यह टेराफॉर्म वेबसाइट पर आधिकारिक सर्वोत्तम अभ्यास था।

लेकिन अब इसमें पदावनत और हटा दिया गया लिखा है। समय के साथ, टेराफ़ॉर्म समुदाय को एहसास हुआ कि यह सर्वोत्तम अभ्यास से बहुत दूर था, क्योंकि लोगों ने इस परियोजना का विभिन्न तरीकों से उपयोग करना शुरू कर दिया था। और समस्याएं हैं. उदाहरण के लिए, जब हम सभी निर्भरताओं को एक ही स्थान पर सूचीबद्ध करते हैं। ऐसी स्थितियाँ होती हैं जब हम "टेराफ़ॉर्म योजना" पर क्लिक करते हैं और जब तक टेराफ़ॉर्म सभी संसाधनों की स्थिति को अद्यतन नहीं करता है, तब तक बहुत समय बीत सकता है।

उदाहरण के लिए, बहुत सारा समय 5 मिनट का होता है। कुछ के लिए यह बहुत समय है. मैंने ऐसे मामले देखे हैं जिनमें 15 मिनट लगे। AWS API ने यह पता लगाने में 15 मिनट का समय बिताया कि प्रत्येक संसाधन की स्थिति के साथ क्या हो रहा है। यह बहुत बड़ा क्षेत्र है.

और, स्वाभाविक रूप से, एक संबंधित समस्या तब सामने आएगी जब आप एक स्थान पर कुछ बदलना चाहते हैं, फिर आप 15 मिनट प्रतीक्षा करते हैं, और यह आपको कुछ परिवर्तनों का एक कैनवास देता है। आपने थूका, "हां" लिखा और कुछ गलत हो गया। यह एक बहुत ही वास्तविक उदाहरण है. टेराफ़ॉर्म आपको समस्याओं से बचाने का प्रयास नहीं करता है। यानी जो चाहो वही लिखो. समस्याएँ होंगी - आपकी समस्याएँ। जबकि टेराफॉर्म 0.11 किसी भी तरह से आपकी मदद करने की कोशिश नहीं कर रहा है। 0.12 में कुछ दिलचस्प जगहें हैं जो आपको यह कहने की अनुमति देती हैं: "वास्या, तुम सच में यह चाहती हो, क्या तुम होश में आ सकती हो?"

दूसरा तरीका यह है कि इस क्षेत्र को कम किया जाए यानी एक जगह से आने वाली कॉल को दूसरी जगह से कम कनेक्ट किया जा सके।

एकमात्र समस्या यह है कि आपको अधिक कोड लिखने की आवश्यकता है, यानी आपको बड़ी संख्या में फ़ाइलों में चर का वर्णन करने और इसे अपडेट करने की आवश्यकता है। कुछ लोगों को यह पसंद नहीं है. ये मेरे लिए सामान्य बात है. और कुछ लोग सोचते हैं: "इसे अलग-अलग स्थानों पर क्यों लिखें, मैं यह सब एक ही स्थान पर रखूंगा।" यह संभव है, लेकिन यह दूसरा चरम है।

यह सब एक ही स्थान पर किसके पास रहता है? एक, दो, तीन लोग यानी कोई न कोई इसका इस्तेमाल कर रहा है.

और एक विशेष घटक, एक ब्लॉक या एक बुनियादी ढांचा मॉड्यूल को कौन कहता है? पांच-सात लोग. यह उत्तम है।

सबसे आम उत्तर बीच में कहीं है। यदि परियोजना बड़ी है, तो आपके सामने अक्सर ऐसी स्थिति होगी जहां कोई समाधान उपयुक्त नहीं होगा और वहां सब कुछ काम नहीं करेगा, इसलिए अंत में आपको एक मिश्रण ही मिलेगा। इसमें कुछ भी गलत नहीं है, जब तक आप समझते हैं कि दोनों के फायदे हैं।

यदि स्टैक वीपीसी में कुछ बदलाव हुआ है और आप इन परिवर्तनों को EC2 पर लागू करना चाहते हैं, यानी आप ऑटोस्केलिंग समूह को अपडेट करना चाहते हैं क्योंकि आपके पास एक नया सबनेट है, तो मैं इस प्रकार की निर्भरता ऑर्केस्ट्रेशन को कॉल करता हूं। कुछ समाधान हैं: कौन क्या उपयोग करता है?

मैं सुझाव दे सकता हूं कि क्या समाधान हैं। आप जादू करने के लिए टेराफॉर्म का उपयोग कर सकते हैं, या आप टेराफॉर्म का उपयोग करने के लिए मेकफाइल्स का उपयोग कर सकते हैं। और देखें कि क्या वहां कुछ बदला है, तो आप उसे यहां लॉन्च कर सकते हैं।

आपको यह फैसला कैसा लगा? क्या कोई मानता है कि यह एक अच्छा समाधान है? मैं मुस्कुराता हुआ देखता हूं, जाहिर तौर पर संदेह घर कर गया है।

बेशक, इसे घर पर न आज़माएँ। टेराफ़ॉर्म को कभी भी टेराफ़ॉर्म से चलाने के लिए डिज़ाइन नहीं किया गया था।

एक रिपोर्ट में उन्होंने मुझसे कहा: "नहीं, यह काम नहीं करेगा।" मुद्दा यह है कि इसे काम नहीं करना चाहिए। हालाँकि यह बहुत प्रभावशाली लगता है जब आप टेराफ़ॉर्म से टेराफ़ॉर्म और फिर टेराफ़ॉर्म लॉन्च कर सकते हैं, आपको ऐसा नहीं करना चाहिए। टेराफॉर्म को हमेशा बहुत आसानी से शुरू करना चाहिए।

https://github.com/gruntwork-io/terragrunt/

यदि आपको एक स्थान पर कुछ बदल जाने पर कॉल ऑर्केस्ट्रेशन की आवश्यकता है, तो टेराग्रंट है।

टेराग्रंट एक उपयोगिता है, टेराफॉर्म का एक ऐड-ऑन, जो आपको इंफ्रास्ट्रक्चर मॉड्यूल में कॉल को समन्वयित और व्यवस्थित करने की अनुमति देता है।

एक विशिष्ट टेराफॉर्म कॉन्फ़िगरेशन फ़ाइल इस तरह दिखती है।

आप निर्दिष्ट करते हैं कि आप किस विशिष्ट मॉड्यूल को कॉल करना चाहते हैं।

मॉड्यूल की क्या निर्भरताएँ हैं?

और यह मॉड्यूल किन तर्कों को स्वीकार करता है. टेराग्रंट के बारे में जानने के लिए बस इतना ही है।

दस्तावेज़ीकरण वहाँ है, और GitHub पर 1 सितारे हैं। लेकिन अधिकांश मामलों में आपको यही जानना आवश्यक है। और इसे उन कंपनियों में लागू करना बहुत आसान है जो अभी टेराफॉर्म के साथ काम करना शुरू कर रही हैं।

तो ऑर्केस्ट्रेशन टेराग्रंट है। अन्य विकल्प भी हैं.

अब बात करते हैं कि कोड के साथ कैसे काम करें।

यदि आपको अपने कोड में नई सुविधाएँ जोड़ने की आवश्यकता है, तो ज्यादातर मामलों में यह आसान है। आप एक नया संसाधन लिख रहे हैं, सब कुछ सरल है।

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

और ब्लॉक संसाधन का उपयोग करके नए संसाधनों के निर्माण का समर्थन किया।

आउटपुट पर हम हमेशा उपयोग की गई चीज़ के आधार पर आउटपुट आईडी लौटाते हैं।

टेराफॉर्म 0.11 में दूसरी बहुत महत्वपूर्ण समस्या सूचियों के साथ काम करना है।

कठिनाई यह है कि यदि हमारे पास उपयोगकर्ताओं की ऐसी सूची है।

और जब हम ब्लॉक संसाधन का उपयोग करके इन उपयोगकर्ताओं को बनाते हैं, तो सब कुछ ठीक हो जाता है। हम पूरी सूची देखते हैं, प्रत्येक के लिए एक फ़ाइल बनाते हैं। और सब ठीक है न। और फिर, उदाहरण के लिए, user3, जो बीच में है, को यहां से हटा दिया जाना चाहिए, फिर उसके बाद बनाए गए सभी संसाधन फिर से बनाए जाएंगे क्योंकि सूचकांक बदल जाएगा।

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

यही समाधान है. यह Jsonnet में लिखा गया कोड है। Jsonnet Google की एक टेम्प्लेटिंग भाषा है।

यह कमांड आपको इस टेम्पलेट को स्वीकार करने की अनुमति देता है और आउटपुट के रूप में यह एक json फ़ाइल लौटाता है जो आपके टेम्पलेट के अनुसार बनाई गई है।

टेम्प्लेट इस तरह दिखता है.

टेराफॉर्म आपको एचसीएल और जेएसओएन दोनों के साथ एक ही तरह से काम करने की अनुमति देता है, इसलिए यदि आपके पास जेएसओएन उत्पन्न करने की क्षमता है, तो आप इसे टेराफॉर्म में डाल सकते हैं। .tf.json एक्सटेंशन वाली फ़ाइल सफलतापूर्वक डाउनलोड हो जाएगी।

और फिर हम इसके साथ हमेशा की तरह काम करते हैं: टेराफॉर्म इनिट, टेरामॉर्म लागू। और हम दो उपयोगकर्ता बनाते हैं।

अब अगर कोई टीम छोड़ेगा तो हमें डर नहीं है. हम सिर्फ json फ़ाइल को संपादित करेंगे। वास्या पुपकिन चले गए, पेट्या पायटोचिन बने रहे। पेट्या पायटोचिन को नई चाबी नहीं मिलेगी।

टेराफॉर्म को अन्य उपकरणों के साथ एकीकृत करना वास्तव में टेराफॉर्म का काम नहीं है। टेराफ़ॉर्म को संसाधन बनाने के लिए एक मंच के रूप में बनाया गया था और बस इतना ही। और बाद में जो कुछ भी सामने आता है वह टेराफॉर्म की चिंता का विषय नहीं है। और वहां इसे बुनने की कोई जरूरत नहीं है. वहाँ Ansible है, जो आपकी ज़रूरत की हर चीज़ करता है।

लेकिन परिस्थितियाँ तब उत्पन्न होती हैं जब हम टेराफॉर्म का विस्तार करना चाहते हैं और कुछ पूरा होने के बाद कुछ कमांड को कॉल करना चाहते हैं।

पहला तरीका. हम एक आउटपुट बनाते हैं जहां हम यह कमांड लिखते हैं।

और फिर हम इस कमांड को शेल टेराफॉर्म आउटपुट से कॉल करते हैं और वह मान निर्दिष्ट करते हैं जो हम चाहते हैं। इस प्रकार, कमांड को सभी प्रतिस्थापित मानों के साथ निष्पादित किया जाता है। यह बहुत आरामदायक है।

दूसरा तरीका. यह हमारे बुनियादी ढांचे में बदलाव के आधार पर null_resource का उपयोग है। जैसे ही कुछ संसाधन की आईडी बदलती है हम उसी लोकल-एक्सई को कॉल कर सकते हैं।

स्वाभाविक रूप से, यह सब कागज पर सहज है, क्योंकि अन्य सभी सार्वजनिक प्रदाताओं की तरह अमेज़ॅन के पास भी अपने स्वयं के किनारे के मामलों का एक समूह है।

सबसे आम मामला यह है कि जब आप AWS खाता खोलते हैं, तो यह मायने रखता है कि आप किन क्षेत्रों का उपयोग करते हैं; क्या यह सुविधा वहां सक्षम है; हो सकता है कि आपने इसे दिसंबर 2013 के बाद खोला हो; हो सकता है कि आप वीपीसी आदि में डिफॉल्ट का उपयोग कर रहे हों। कई प्रतिबंध हैं। और अमेज़ॅन ने उन्हें पूरे दस्तावेज़ में बिखेर दिया।

ऐसी कुछ चीजें हैं जिनसे मैं बचने की सलाह देता हूं।

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

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

साथ ही, दायरा कम करने के लिए लक्ष्य तर्कों का उपयोग न करें। इसके लिए छोटे बुनियादी ढांचे मॉड्यूल का उपयोग करना बहुत आसान है।

साथ ही, समानता को सीमित करने और बढ़ाने की भी कोई आवश्यकता नहीं है। यदि मेरे पास 150 संसाधन हैं और मैं अमेज़ॅन समानता को डिफ़ॉल्ट 10 से 100 तक बढ़ाना चाहता हूं, तो सबसे अधिक संभावना है कि कुछ गलत हो जाएगा। या यह अब ठीक चल सकता है, लेकिन जब अमेज़ॅन कहता है कि आप बहुत अधिक कॉल कर रहे हैं, तो आप परेशानी में पड़ जाएंगे।

टेराफ़ॉर्म इनमें से अधिकांश समस्याओं को पुनः आरंभ करने का प्रयास करेगा, लेकिन आपको लगभग कुछ भी हासिल नहीं होगा। यदि आप AWS API के अंदर या टेराफ़ॉर्म प्रदाता के अंदर किसी बग पर ठोकर खाते हैं तो Parallelism=1 का उपयोग करना एक महत्वपूर्ण चीज़ है। और फिर आपको निर्दिष्ट करने की आवश्यकता है: समानता = 1 और तब तक प्रतीक्षा करें जब तक कि टेराफ़ॉर्म एक कॉल समाप्त न कर ले, फिर दूसरी, फिर तीसरी। वह इन्हें एक-एक करके लॉन्च करेंगे.

लोग अक्सर मुझसे पूछते हैं, "मुझे क्यों लगता है कि टेराफ़ॉर्म कार्यस्थल बुरे हैं?" मेरा मानना ​​है कि कोड के रूप में बुनियादी ढांचे का सिद्धांत यह देखना है कि कौन सा बुनियादी ढांचा बनाया गया है और किन मूल्यों के साथ बनाया गया है।

कार्यस्थान उपयोगकर्ताओं द्वारा नहीं बनाए गए थे. इसका मतलब यह नहीं है कि उपयोगकर्ताओं ने GitHub मुद्दों में लिखा है कि हम टेराफॉर्म वर्कस्पेस के बिना नहीं रह सकते। नहीं ऐसा नहीं है. टेराफॉर्म एंटरप्राइज एक व्यावसायिक समाधान है। HashiCorp के टेराफॉर्म ने निर्णय लिया कि हमें कार्यस्थलों की आवश्यकता है, इसलिए हमने इसे हटा दिया। मुझे इसे एक अलग फ़ोल्डर में रखना बहुत आसान लगता है। फिर थोड़ी और फ़ाइलें होंगी, लेकिन यह अधिक स्पष्ट होगी।

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

रिपोर्ट का विषय "भविष्य के लिए" लिखा गया था। मैं इस बारे में बहुत संक्षेप में बात करूंगा. भविष्य के लिए, इसका मतलब है कि 0.12 जल्द ही जारी किया जाएगा।

0.12 ढेर सारा नया सामान है। यदि आप नियमित प्रोग्रामिंग से आते हैं, तो आप सभी प्रकार के गतिशील ब्लॉक, लूप, सही और सशर्त तुलना संचालन से चूक जाते हैं, जहां बाएं और दाएं पक्षों की गणना एक साथ नहीं की जाती है, बल्कि स्थिति के आधार पर की जाती है। आप इसे बहुत मिस करते हैं, इसलिए 0.12 आपके लिए इसे हल कर देगा।

लेकिन! यदि आप तैयार मॉड्यूल और तृतीय-पक्ष समाधानों का उपयोग करके कम और अधिक सरलता से लिखते हैं, तो आपको इंतजार नहीं करना पड़ेगा और आशा करनी होगी कि 0.12 आएगा और आपके लिए सब कुछ ठीक कर देगा।

रिपोर्ट के लिए धन्यवाद! आपने कोड के रूप में बुनियादी ढांचे के बारे में बात की और सचमुच परीक्षणों के बारे में एक शब्द कहा। क्या मॉड्यूल में परीक्षण आवश्यक हैं? ये किसकी जिम्मेदारी है? क्या मुझे इसे स्वयं लिखने की ज़रूरत है या यह मॉड्यूल की ज़िम्मेदारी है?

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

मैं इस विषय पर सक्रिय रूप से शोध कर रहा हूं, यानी आपके द्वारा लिखे गए बुनियादी ढांचे के आधार पर स्वचालित रूप से परीक्षण कैसे उत्पन्न करें। यानी अगर आपने यह कोड लिखा है तो मुझे इसे चलाने की जरूरत है, इसके आधार पर मैं परीक्षण बना सकता हूं।

टेराटेस्ट सबसे अधिक बार उल्लेखित पुस्तकालयों में से एक है जो आपको टेराफॉर्म के लिए एकीकरण परीक्षण लिखने की अनुमति देता है। यह उपयोगिताओं में से एक है. मैं डीएसएल प्रकार को पसंद करता हूं, उदाहरण के लिए, आरएसपीईसी।

एंटोन, रिपोर्ट के लिए धन्यवाद! मेरा नाम वालेरी है. मुझे थोड़ा दार्शनिक प्रश्न पूछने दीजिये. वहाँ, सशर्त, प्रावधान है, वहाँ तैनाती है। प्रोविजनिंग मेरे बुनियादी ढांचे का निर्माण करती है, तैनाती में हम इसे कुछ उपयोगी चीज़ों से भरते हैं, उदाहरण के लिए, सर्वर, एप्लिकेशन इत्यादि। और यह मेरे दिमाग में है कि टेराफॉर्म प्रावधान के लिए अधिक है, और Ansible तैनाती के लिए अधिक है, क्योंकि Ansible भौतिक बुनियादी ढांचे के लिए भी है आपको nginx, Postgres इंस्टॉल करने की अनुमति देता है। लेकिन साथ ही, Ansible, उदाहरण के लिए, Amazon या Google संसाधनों के प्रावधान की अनुमति देता प्रतीत होता है। लेकिन टेराफॉर्म आपको इसके मॉड्यूल का उपयोग करके कुछ सॉफ़्टवेयर तैनात करने की भी अनुमति देता है। आपके दृष्टिकोण से, क्या टेराफॉर्म और एन्सिबल के बीच किसी प्रकार की सीमा चलती है, कहां और क्या उपयोग करना बेहतर है? या, उदाहरण के लिए, क्या आपको लगता है कि Ansible पहले से ही कचरा है, आपको हर चीज़ के लिए टेराफ़ॉर्म का उपयोग करने का प्रयास करना चाहिए?

अच्छा प्रश्न, वालेरी। मेरा मानना ​​है कि टेराफॉर्म 2014 के बाद से उद्देश्य के मामले में नहीं बदला है। यह बुनियादी ढांचे के लिए बनाया गया था और बुनियादी ढांचे के लिए ही खत्म हो गया। हमें अभी भी कॉन्फ़िगरेशन प्रबंधन Ansible की आवश्यकता थी और रहेगी। चुनौती यह है कि लॉन्च_कॉन्फ़िगरेशन के अंदर उपयोगकर्ता डेटा है। और वहां आप अन्सिबल आदि खींचते हैं। यह मानक अंतर है जो मुझे सबसे अच्छा लगता है।

अगर हम सुंदर बुनियादी ढांचे के बारे में बात कर रहे हैं, तो पैकर जैसी उपयोगिताएँ हैं जो इस छवि को एकत्र करती हैं। और फिर टेराफॉर्म इस छवि को ढूंढने और इसके लॉन्च_कॉन्फिगरेशन को अपडेट करने के लिए डेटा स्रोत का उपयोग करता है। यानी इस तरह से पाइपलाइन यह है कि हम पहले ट्रैकर को खींचते हैं, फिर टेराफॉर्म को खींचते हैं। और यदि निर्माण होता है, तो एक नया परिवर्तन होता है।

नमस्ते! रिपोर्ट के लिए धन्यवाद! मेरा नाम मिशा है, आरबीएस कंपनी। संसाधन बनाते समय आप प्रोविज़नर के माध्यम से Ansible को कॉल कर सकते हैं। Ansible में डायनेमिक इन्वेंट्री नामक एक विषय भी है। और आप पहले टेराफॉर्म को कॉल कर सकते हैं, और फिर एन्सिबल को कॉल कर सकते हैं, जो राज्य से संसाधन लेगा और इसे निष्पादित करेगा। बेहतर क्या है?

लोग दोनों का उपयोग समान सफलता के साथ करते हैं। मुझे ऐसा लगता है कि अगर हम ऑटोस्केलिंग समूह के बारे में बात नहीं कर रहे हैं, तो Ansible में गतिशील इन्वेंट्री एक सुविधाजनक चीज़ है। क्योंकि ऑटोस्केलिंग ग्रुप में हमारे पास पहले से ही अपना टूलकिट होता है, जिसे लॉन्च_कॉन्फिगरेशन कहा जाता है। लॉन्च_कॉन्फ़िगरेशन में हम वह सब कुछ रिकॉर्ड करते हैं जिसे एक नया संसाधन बनाते समय लॉन्च करने की आवश्यकता होती है। इसलिए, अमेज़ॅन के साथ, डायनामिक इन्वेंट्री का उपयोग करना और टेराफॉर्म टीएस फ़ाइल को पढ़ना, मेरी राय में, अतिश्योक्ति है। और यदि आप अन्य टूल का उपयोग करते हैं जहां "ऑटोस्केलिंग समूह" की कोई अवधारणा नहीं है, उदाहरण के लिए, आप DigitalOcean या किसी अन्य प्रदाता का उपयोग करते हैं जहां कोई ऑटोस्केलिंग समूह नहीं है, तो वहां आपको मैन्युअल रूप से एपीआई खींचना होगा, आईपी पते ढूंढना होगा, बनाना होगा एक गतिशील इन्वेंट्री फ़ाइल, और Ansible पहले से ही इसके माध्यम से घूमेगा। यानी, अमेज़ॅन के लिए लॉन्च_कॉन्फ़िगरेशन है, और बाकी सभी चीज़ों के लिए डायनामिक इन्वेंट्री है।

स्रोत: www.habr.com