भविष्यको लागि टेराफर्ममा पूर्वाधारको विवरण। एन्टोन बाबेन्को (२०१८)

धेरै मानिसहरूलाई थाहा छ र आफ्नो दैनिक काममा टेराफर्म प्रयोग गर्छन्, तर यसको लागि उत्तम अभ्यासहरू अझै स्थापित भएका छैनन्। प्रत्येक टोलीले आफ्नै दृष्टिकोण र विधिहरू विकास गर्नुपर्छ।

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

समय बित्छ, र तपाईंलाई आफ्नो पूर्वाधार तपाईंको नयाँ घरपालुवा जनावर जस्तो लाग्छ, तर किन? तपाईं पूर्वाधारमा भएका अस्पष्ट परिवर्तनहरूको बारेमा चिन्तित हुनुहुन्छ, तपाईं यसलाई र कोड छुन डराउनुहुन्छ - र फलस्वरूप, तपाईंले नयाँ सुविधाहरू ढिलाइ गर्नुहुन्छ वा गुणस्तर घटाउनुहुन्छ...

तीन वर्षसम्म Github मा AWS को लागि सामुदायिक टेराफर्म मोड्युलहरूको संग्रह व्यवस्थापन गरेपछि र लामो समयसम्म उत्पादनमा टेराफर्मलाई समर्थन गरेपछि, एन्टोन बाबेन्को आफ्नो अनुभव साझा गर्न तयार छन्: भविष्यको पीडाबाट बच्न टेराफर्म मोड्युलहरू कसरी लेख्ने।

वार्ताको अन्त्यसम्ममा, सहभागीहरू टेराफर्ममा स्रोत व्यवस्थापन सिद्धान्तहरू, टेराफर्ममा मोड्युलहरूसँग सम्बन्धित उत्कृष्ट अभ्यासहरू, र पूर्वाधार व्यवस्थापनसँग सम्बन्धित केही निरन्तर एकीकरण सिद्धान्तहरूसँग बढी परिचित हुनेछन्।

त्याग: कृपया ध्यान दिनुहोस् कि यो वार्ता नोभेम्बर २०१८ को हो—दुई वर्ष बितिसक्यो। यस वार्तामा छलफल गरिएको टेराफर्मको संस्करण, ०.११, अब समर्थित छैन। विगत दुई वर्षमा, दुई नयाँ रिलीजहरू जारी गरिएका छन्, जसले धेरै नयाँ सुविधाहरू, सुधारहरू र परिवर्तनहरू प्रस्तुत गर्दछ। कृपया यसमा ध्यान दिनुहोस् र कागजातहरू हेर्नुहोस्।

सन्दर्भहरू:

• टेराफर्म-समुदाय-मोड्युलहरू + टेराफर्म-एडब्ल्यूएस-मोड्युलहरू
• एन्टोनबाबेन्को/प्रि-कमिट-टेराफॉर्म — कोड र कागजातहरूको स्वचालित ढाँचा
• एन्टोनबाबेन्को/टेरापिन — टेराफर्म मोड्युल जेनेरेटर (WIP)
• एन्टोनबाबेन्को/मोड्युलहरू.टीएफ-लाम्बडा — दृश्य रेखाचित्र (WIP) बाट टेराफर्म कोड जेनेरेटर
• www.terraform-best-practices.com
• medium.com/@anton.babenko मा (नयाँ पोस्टहरू व्यक्तिगत वेबसाइट www.antonbabenko.com/ मा छन्)
• @antonbabenko — ट्विटर, र विभिन्न स्ल्याक्सको गुच्छा

मेरो नाम एन्टोन बाबेन्को हो। तपाईंहरूमध्ये कोही-कोहीले मैले लेखेको कोड प्रयोग गर्नुभएको होला। म यो कुरा पहिलेभन्दा धेरै आत्मविश्वासका साथ भन्न सक्छु किनभने मसँग तथ्याङ्कमा पहुँच छ।

म एक टेराफर्म विकासकर्ता हुँ र २०१५ देखि धेरै टेराफर्म र अमेजन-सम्बन्धित खुला स्रोत परियोजनाहरूमा सक्रिय सहभागी र योगदानकर्ता हुँ।

त्यसबेलादेखि, मैले यसलाई रोचक तरिकाले प्रस्तुत गर्न पर्याप्त कोड लेखेको छु। र म अब यसलाई व्याख्या गर्ने प्रयास गर्नेछु।

म टेराफर्मसँग काम गर्ने जटिलता र विशिष्टताहरू समेट्नेछु। तर त्यो वास्तवमा हाईलोडको केन्द्रबिन्दु होइन। र तपाईंले अब किन भनेर देख्नुहुनेछ।

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

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

म युक्रेनबाट हुँ। म धेरै वर्षदेखि नर्वेमा बस्दै आएको छु।

यस रिपोर्टको लागि जानकारी मेरो नाम चिन्ने र सामाजिक सञ्जालमा मलाई फेला पार्ने व्यक्तिहरूबाट पनि सङ्कलन गरिएको थियो। मेरो प्रायः एउटै उपनाम हुन्छ।

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

मैले भनेझैं, म Terraform AWS मोड्युलहरूको प्रमुख मर्मतकर्ता हुँ, जुन GitHub मा सबैभन्दा ठूलो भण्डारहरू मध्ये एक हो जहाँ हामी सबैभन्दा सामान्य कार्यहरूको लागि मोड्युलहरू होस्ट गर्छौं: VPC, Autoscaling, RDS।

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

टेराफर्म २०१४ मा एक उपकरणको रूपमा सुरु गरिएको थियो जसले विकासकर्ताहरूलाई कोडको रूपमा पूर्वाधार लेख्न, योजना बनाउन र व्यवस्थापन गर्न अनुमति दियो। यहाँको मुख्य अवधारणा "कोडको रूपमा पूर्वाधार" हो।

सबै कागजातहरू, मैले भनेझैं, लेखिएको छ terraform.ioमलाई आशा छ कि धेरैजसो मानिसहरूलाई यो साइटको बारेमा थाहा छ र कागजातहरू पढेका छन्। यदि त्यसो हो भने, तपाईं सही ठाउँमा आउनुभएको छ।

एउटा सामान्य टेराफर्म कन्फिगरेसन फाइल यस्तो देखिन्छ, जहाँ हामी पहिले केही चरहरू परिभाषित गर्छौं।

यस अवस्थामा हामी "aws_region" परिभाषित गर्छौं।

त्यसपछि हामी कुन स्रोतहरू सिर्जना गर्न चाहन्छौं भनेर वर्णन गर्छौं।

हामी केही आदेशहरू चलाउँछौं, विशेष गरी "terraform init" निर्भरताहरू र प्रदायकहरू लोड गर्नको लागि।

निर्दिष्ट कन्फिगरेसन हामीले सिर्जना गरेका स्रोतहरूसँग मेल खान्छ कि खाँदैन भनेर जाँच गर्न हामी "terraform apply" आदेश चलाउँछौं। हामीले अहिलेसम्म केही सिर्जना नगरेको हुनाले, Terraform ले हामीलाई यी स्रोतहरू सिर्जना गर्न प्रेरित गर्छ।

हामी यो पुष्टि गर्छौं। यसरी, हामी सिस्नेल भनिने बाल्टिन बनाउँछौं।

यस्तै धेरै उपयोगिताहरू पनि छन्। अमेजन प्रयोग गर्ने तपाईंहरूमध्ये धेरै जना AWS क्लाउडफर्मेसन, गुगल क्लाउड डिप्लोयमेन्ट म्यानेजर, वा एज्युर रिसोर्स म्यानेजरसँग परिचित हुनुहुन्छ। यी प्रत्येक सार्वजनिक क्लाउड प्रदायकहरू भित्र स्रोतहरू व्यवस्थापन गर्न प्रत्येकको आफ्नै कार्यान्वयन हुन्छ। टेराफर्म विशेष गरी उपयोगी छ किनभने यसले तपाईंलाई १०० भन्दा बढी प्रदायकहरू व्यवस्थापन गर्न अनुमति दिन्छ। (थप जान्नुहोस्) यहाँ)

सुरुदेखि नै टेराफर्मका लक्ष्यहरू यस प्रकार छन्:

• टेराफर्मले स्रोतहरूको एकीकृत दृष्टिकोण प्रदान गर्दछ।
• सबै आधुनिक प्लेटफर्महरूको लागि समर्थन अनुमति दिन्छ।
• र टेराफर्मलाई सुरुदेखि नै एक उपयोगिताको रूपमा परिकल्पना गरिएको थियो जसले पूर्वाधारलाई सुरक्षित र अनुमानित रूपमा परिवर्तन गर्न अनुमति दिन्छ।

२०१४ मा, यस सन्दर्भमा "भविष्यवाणी गर्न सकिने" शब्द धेरै असामान्य सुनिन्थ्यो।

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

• तपाईंले आफ्नो मनले चाहेको सबै कुरा व्यवस्थापन गर्न १२० भन्दा बढी प्रदायकहरू प्रयोग गर्न सक्नुहुन्छ।
• उदाहरणका लागि, तपाईंले GitHub भण्डारहरूमा पहुँच वर्णन गर्न Terraform प्रयोग गर्न सक्नुहुन्छ।
• तपाईं जिरामा बगहरू सिर्जना गर्न र बन्द गर्न पनि सक्नुहुन्छ।
• तपाईं नयाँ अवशेष मेट्रिक्स व्यवस्थापन गर्न सक्नुहुन्छ।
• यदि तपाईं साँच्चै चाहनुहुन्छ भने, तपाईं ड्रपबक्समा फाइलहरू पनि सिर्जना गर्न सक्नुहुन्छ।

यो सबै टेराफर्म प्रदायकहरू प्रयोग गरेर प्राप्त गरिन्छ, जससँग गोमा वर्णन गर्न सकिने खुला API छ।

मानौं हामीले टेराफर्म प्रयोग गर्न थाल्यौं, वेबसाइटमा केही कागजातहरू पढ्यौं, केही भिडियो हेर्यौं, र main.tf लेख्न थाल्यौं, जसरी मैले अघिल्लो स्लाइडहरूमा देखाएको थिएँ।

अनि तपाईंको लागि सबै कुरा राम्रो छ, तपाईंसँग एउटा फाइल छ जसले VPC सिर्जना गर्छ।

यदि तपाईं VPC सिर्जना गर्न चाहनुहुन्छ भने, तपाईंले लगभग यी १२ लाइनहरू निर्दिष्ट गर्नुहुन्छ। तपाईंले यसलाई सिर्जना गर्न चाहनुभएको क्षेत्र र प्रयोग गर्नको लागि IP ठेगानाहरूको cidr_block वर्णन गर्नुहुन्छ। त्यति मात्र हो।

स्वाभाविक रूपमा, परियोजना बिस्तारै बढ्दै जानेछ।

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

निम्न उदाहरणलाई विचार गरौं।

तपाईं आफ्नो VPC मा भएका स्रोतहरूमा इन्टरनेट पहुँच होस् भन्ने चाहनुहुन्छ त्यसैले तपाईं बिस्तारै internet_gateway थप्दै हुनुहुन्छ। यो राम्रो विचार हो।

परिणाम main.tf यस प्रकार छ:

यो main.tf को माथिल्लो भाग हो।

यो main.tf को तल्लो भाग हो।

त्यसपछि तपाईंले एउटा सबनेट थप्नुहुन्छ। जबसम्म तपाईं NAT गेटवे, रुट, रुटिङ टेबल, र अन्य धेरै सबनेटहरू थप्न चाहनुहुन्छ, तपाईंसँग ३८ लाइनहरू होइन, तर लगभग २००-३०० लाइनहरू हुनेछन्।

त्यसैले, तपाईंको main.tf फाइल बिस्तारै बढ्दै जान्छ। र धेरैजसो मानिसहरूले सबै कुरा एउटै फाइलमा राख्छन्। main.tf मा १०-२० KB देखिन्छ। कल्पना गर्नुहोस् कि १०-२० KB पाठ सामग्री हो। र सबै कुरा अरू सबै कुरासँग जोडिएको छ। यो बिस्तारै काम गर्न गाह्रो हुँदै जान्छ। १०-२० KB राम्रो प्रयोगकर्ता केस हो, र कहिलेकाहीँ बढी पनि। र मानिसहरूले सधैं त्यो नराम्रो हो भन्ने सोच्दैनन्।

परम्परागत प्रोग्रामिङमा जस्तै - अर्थात्, कोडको रूपमा पूर्वाधार होइन - हामी विभिन्न वर्गहरू, प्याकेजहरू, मोड्युलहरू र समूहहरूको गुच्छा प्रयोग गर्न अभ्यस्त छौं। टेराफर्मले हामीलाई लगभग एउटै काम गर्न अनुमति दिन्छ।

• कोड बढ्दै छ।
• स्रोतसाधनहरू बीचको निर्भरता पनि बढ्दै गएको छ।

अनि हामीलाई ठूलो आवश्यकता छ। हामीलाई थाहा छ कि हामी यसरी बाँच्न सक्दैनौं। हाम्रो कोड विशाल हुँदै गइरहेको छ। १०-२० केबी ठ्याक्कै विशाल होइन, तर त्यो केवल नेटवर्क स्ट्याक हो, जसको अर्थ तपाईंले नेटवर्क स्रोतहरू मात्र थप्नुभएको छ। हामी एप्लिकेसन लोड ब्यालेन्सर, डिप्लोयमेन्ट ईएस क्लस्टर, कुबर्नेट्स, र यस्तै अन्य कुराहरूको बारेमा पनि कुरा गरिरहेका छैनौं, जहाँ तपाईं सजिलै अर्को १०० केबी निचोड गर्न सक्नुहुन्छ। यदि तपाईंले यो सबै लेख्नुभयो भने, तपाईंले चाँडै पत्ता लगाउनुहुनेछ कि टेराफर्मले टेराफर्म मोड्युलहरू प्रदान गर्दछ।

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

त्यसैले हामी हाम्रो १०, २०, वा ३० KB कोडलाई कसरी अप्टिमाइज गर्ने भनेर पत्ता लगाउने प्रयास गरिरहेका छौं। हामीले बिस्तारै महसुस गर्दैछौं कि हामीले केही मोड्युलहरू प्रयोग गर्न आवश्यक छ।

हामीले सामना गर्ने पहिलो प्रकारका मोड्युलहरू स्रोत मोड्युलहरू हुन्। तिनीहरूले तपाईंको पूर्वाधार के हो, तपाईंको व्यवसाय के हो, यो कहाँ अवस्थित छ, र अवस्थाहरू के हुन् भनेर बुझ्दैनन्। यी ठ्याक्कै ती मोड्युलहरू हुन् जुन म, खुला स्रोत समुदायसँग मिलेर, प्रशासित गर्छु र जसलाई हामी तपाईंको पूर्वाधारको लागि आधारभूत निर्माण ब्लकको रूपमा प्रचार गर्छौं।

स्रोत मोड्युलको उदाहरण।

जब हामी स्रोत मोड्युल कल गर्छौं, हामी कुन बाटोबाट यसको सामग्री लोड गर्नुपर्छ भनेर निर्दिष्ट गर्छौं।

हामी कुन संस्करण डाउनलोड गर्न चाहन्छौं भनेर संकेत गर्छौं।

हामी त्यहाँ धेरै तर्कहरू पास गर्छौं। र यति नै। यो मोड्युल प्रयोग गर्दा हामीले जान्नुपर्ने यति मात्र हो।

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

यो मोड्युल भित्रको कोड यहाँ छ। सुरक्षा-समूह मोड्युल। लाइन ६४० मा तल स्क्रोल गर्नुहोस्। सबै सम्भावित कन्फिगरेसनहरू सहित अमेजनमा सुरक्षा-समूह स्रोत सिर्जना गर्नु एकदमै सामान्य काम हो। केवल सुरक्षा-समूह सिर्जना गर्नु र त्यसलाई कुन नियमहरू पारित गर्ने भनेर बताउनु पर्याप्त छैन। त्यो धेरै सरल हुनेछ। अमेजनमा लाखौं फरक प्रतिबन्धहरू छन्। उदाहरणका लागि, यदि तपाईं प्रयोग गर्नुहुन्छ भने VPC अन्त्यबिन्दु, उपसर्ग सूची, विभिन्न API हरू र यो सबै कुरालाई अरू सबै कुरासँग मिलाउने प्रयास गर्छ, तर टेराफर्मले तपाईंलाई त्यसो गर्न अनुमति दिँदैन। र अमेजन एपीआईले पनि यसलाई अनुमति दिँदैन। त्यसैले तपाईंले यो सबै डरलाग्दो तर्कलाई मोड्युलमा लुकाउनु पर्छ र यस्तै देखिने प्रयोगकर्ता कोड दिनुपर्छ।

प्रयोगकर्तालाई यो भित्र कसरी बनाइएको छ भनेर जान्नु आवश्यक छैन।

दोस्रो प्रकारको मोड्युल, जसमा स्रोत मोड्युलहरू समावेश छन्, तपाईंको व्यवसायमा बढी लागू हुने समस्याहरू समाधान गर्दछ। यो प्रायः टेराफर्म एक्सटेन्सन हो जसले ट्यागहरू र कम्पनी मापदण्डहरूको लागि कडा मानहरू परिभाषित गर्दछ। यसलाई टेराफर्मले हाल समर्थन नगर्ने कार्यक्षमता थप्न पनि प्रयोग गर्न सकिन्छ। यो अहिलेको लागि विशेष गरी सत्य हो। हामी हाल संस्करण ०.११ मा छौं, जुन सेवानिवृत्त हुन लागेको छ। यद्यपि, प्रिप्रोसेसरहरू, jsonnet, कुकीकटर, र अन्य धेरै सुविधाहरूले अझै पनि पूर्ण कार्यक्षमताको लागि प्रयोग गरिनु पर्ने संयन्त्रहरूलाई समर्थन गरिरहेका छन्।

अर्को म यसका केही उदाहरणहरू देखाउनेछु।

पूर्वाधार मोड्युललाई ठ्याक्कै उस्तै तरिकाले बोलाइएको छ।

सामग्री डाउनलोड गर्ने स्रोत निर्दिष्ट गर्दछ।

यस मोड्युलमा धेरै मानहरू पास हुन्छन्।

अर्को, यस मोड्युल भित्र, VPC वा एप्लिकेसन लोड ब्यालेन्सर सिर्जना गर्न, वा सुरक्षा समूह वा इलास्टिक कन्टेनर सेवा क्लस्टर सिर्जना गर्न स्रोत मोड्युलहरूको गुच्छा बोलाइन्छ।

मोड्युल दुई प्रकारका हुन्छन्। यो बुझ्नु महत्त्वपूर्ण छ किनभने मैले यस वार्तामा एकत्रित गरेको धेरैजसो जानकारी दस्तावेजीकरण गरिएको छैन।

टेराफर्मको कागजात हाल धेरै समस्याग्रस्त छ किनभने यसले केवल यी सुविधाहरू अवस्थित छन् र तपाईंले तिनीहरूलाई प्रयोग गर्न सक्नुहुन्छ भनेर बताउँछ। तर यसले तिनीहरूलाई कसरी प्रयोग गर्ने वा किन तिनीहरूलाई राम्रोसँग प्रयोग गरिन्छ भनेर व्याख्या गर्दैन। त्यसैले, धेरै मानिसहरूले काम गर्न नसकिने कुराहरू लेख्छन्।

यी मोड्युलहरू कसरी लेख्ने भनेर थप हेरौं। त्यसपछि हामी तिनीहरूलाई कसरी कल गर्ने र कोडसँग कसरी काम गर्ने भनेर हेर्नेछौं।

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

सुझाव #० भनेको स्रोत मोड्युलहरू लेख्नबाट बच्नु हो। यी मध्ये धेरैजसो मोड्युलहरू पहिले नै तपाईंको लागि लेखिएका छन्। मैले भनेझैं, तिनीहरू खुला स्रोत हुन्, तपाईंको कुनै पनि व्यापार तर्क समावेश गर्दैनन्, र IP ठेगानाहरू, पासवर्डहरू, आदिको लागि हार्डकोड गरिएको मानहरू समावेश गर्दैनन्। मोड्युल धेरै लचिलो छ। र यो सम्भवतः पहिले नै लेखिएको छ। अमेजन स्रोतहरूको लागि धेरै मोड्युलहरू छन् - लगभग 650। र ती मध्ये धेरैजसो राम्रो गुणस्तरका छन्।

यस उदाहरणमा, कोही तपाईंकहाँ आउँछ र भन्छ, "म डाटाबेस व्यवस्थापन गर्न सक्षम हुन चाहन्छु। एउटा मोड्युल सिर्जना गर्नुहोस् ताकि म डाटाबेस सिर्जना गर्न सकूँ।" यो व्यक्तिलाई Amazon वा Terraform को कार्यान्वयन विवरण थाहा छैन। तिनीहरू केवल भन्छन्, "म MSSQL व्यवस्थापन गर्न चाहन्छु।" त्यसैले, हामी मान्दछौं कि तिनीहरूले हाम्रो मोड्युललाई कल गर्नेछन्, इन्जिन प्रकार पास गर्नेछन्, र समय क्षेत्र निर्दिष्ट गर्नेछन्।

र व्यक्तिलाई थाहा नहुनु पर्छ कि हामी यो मोड्युल भित्र दुई फरक स्रोतहरू सिर्जना गर्नेछौं: एउटा MSSQL को लागि, दोस्रो अरू सबै कुराको लागि, किनभने Terraform 0.11 मा तपाईंले समय क्षेत्र मानहरू वैकल्पिक रूपमा निर्दिष्ट गर्न सक्नुहुन्न।

र यो मोड्युलबाट बाहिर निस्कँदा, प्रयोगकर्ताले केवल ठेगाना प्राप्त गर्न सक्षम हुनेछन्। उनीहरूलाई थाहा हुनेछैन कि हामी कुन डाटाबेस वा स्रोतबाट यो सबै आन्तरिक रूपमा सिर्जना गर्दैछौं। यो गोपनीयताको एक धेरै महत्त्वपूर्ण तत्व हो। र यो खुला स्रोतमा सार्वजनिक रूपमा उपलब्ध मोड्युलहरूमा मात्र लागू हुँदैन, तर तपाईंले आफ्नो परियोजनाहरू र टोलीहरू भित्र लेख्ने मोड्युलहरूमा पनि लागू हुन्छ।

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

तर समस्या टेराफर्मले यी मोड्युलहरूलाई कसरी कल गर्छ भन्नेमा छ। उदाहरणका लागि, यदि तपाईंले प्रत्येक व्यक्तिगत प्रयोगकर्ता सिर्जना गर्न मोड्युल कल गर्नुभयो भने, टेराफर्मले पहिले सम्पूर्ण भण्डार डाउनलोड गर्नेछ र त्यसपछि त्यो विशिष्ट मोड्युल भएको फोल्डरमा नेभिगेट गर्नेछ। यसको मतलब तपाईंले प्रत्येक पटक एक मेगाबाइट डाउनलोड गर्नुहुनेछ। यदि तपाईंले १०० वा २०० प्रयोगकर्ताहरू व्यवस्थापन गर्नुभयो भने, तपाईंले १०० वा २०० मेगाबाइट डाउनलोड गर्नुहुनेछ र त्यसपछि त्यो फोल्डरमा नेभिगेट गर्नुहुनेछ। त्यसैले, स्वाभाविक रूपमा, तपाईंले "Terraform init" मा थिच्दा हरेक पटक धेरै सामानहरू डाउनलोड गर्न चाहनुहुन्न।

https://github.com/mbtproject/mbt

यस समस्याको दुई समाधानहरू छन्। पहिलो भनेको सापेक्ष मार्गहरू प्रयोग गर्नु हो। यस तरिकाले, तपाईंले आफ्नो कोडमा फोल्डर स्थानीय (./) हो भनेर निर्दिष्ट गर्नुहुन्छ। र केहि पनि चलाउनु अघि, तपाईंले स्थानीय रूपमा यस भण्डारको Git क्लोन बनाउनुहुन्छ। यस तरिकाले, तपाईंले यो एक पटक मात्र गर्नुपर्छ।

अवश्य पनि, यसका धेरै नकारात्मक पक्षहरू छन्। उदाहरणका लागि, तपाईं संस्करण प्रयोग गर्न सक्नुहुन्न। र कहिलेकाहीं त्योसँग बाँच्न गाह्रो हुन सक्छ।

दोस्रो समाधान। यदि तपाईंसँग धेरै सबमोड्युलहरू र स्थापित पाइपलाइन छ भने, त्यहाँ MBT परियोजना छ, जसले तपाईंलाई मोनोरेपोबाट धेरै प्याकेजहरू निर्माण गर्न र S3 मा अपलोड गर्न अनुमति दिन्छ। यो एक धेरै राम्रो दृष्टिकोण हो। यस तरिकाले, iam-user-1.0.0.zip फाइलको तौल केवल १ KB हुनेछ किनभने यो स्रोत सिर्जना गर्न आवश्यक कोड धेरै सानो छ। यसले चीजहरूलाई धेरै छिटो पनि बनाउनेछ।

मोड्युलहरूमा के प्रयोग गर्न सकिँदैन भन्ने बारेमा कुरा गरौं।

मोड्युलहरूमा यो खराबी किन छ? सबैभन्दा डरलाग्दो कुरा भनेको assume प्रयोगकर्ता हो। assume प्रयोगकर्ता भनेको प्रदायक प्रमाणीकरण विकल्प हो जुन विभिन्न व्यक्तिहरूले प्रयोग गर्न सक्छन्। उदाहरणका लागि, हामी सबैले एउटा भूमिका ग्रहण गर्नेछौं। यसको मतलब Terraform ले यो भूमिका ग्रहण गर्नेछ। र त्यसपछि यसले यो भूमिकाको साथ अन्य सबै कार्यहरू गर्नेछ।

समस्या यो हो कि यदि Vasya ले Amazon मा एकै तरिकाले जडान गर्न मन पराउँछ भने, उदाहरणका लागि, पूर्वनिर्धारित वातावरण चर प्रयोग गरेर, जबकि Petya ले आफ्नै साझा कुञ्जी प्रयोग गर्न मन पराउँछ, जुन उसले गोप्य स्थानमा राख्छ, तब Terraform ले दुवै निर्दिष्ट गर्न सक्दैन। र तिनीहरूलाई पीडाबाट बच्नको लागि, मोड्युलमा यो ब्लक निर्दिष्ट नगर्नुहोस्। यसलाई उच्च स्तरमा निर्दिष्ट गर्न आवश्यक छ। त्यसैले, हामीसँग एक स्रोत मोड्युल, एक पूर्वाधार मोड्युल, र माथि एक संरचना छ। र यो कतै माथि निर्दिष्ट गर्न आवश्यक छ।

दोस्रो खराबी भनेको प्रावधानकर्ता हो। यो त्यति सामान्य कुरा होइन, किनकि यदि तपाईंले कोड लेख्नुभयो र यो तपाईंको लागि काम गर्छ भने, तपाईं सोच्न सक्नुहुन्छ, "यदि यसले काम गर्छ भने, किन परिवर्तन गर्ने?"

समस्या यो हो कि, पहिलो कुरा, यो प्रोभिजनर कहिले सुरु हुन्छ भन्ने कुरा तपाईं सधैं नियन्त्रण गर्नुहुन्न। र, दोस्रो कुरा, aws ec2 को अर्थ के हो भन्ने कुरा तपाईं नियन्त्रण गर्नुहुन्न, अर्थात्, हामी कुरा गर्दैछौं। Linux वा बारेमा Windows। त्यसैले तपाईं फरक अपरेटिङ सिस्टममा वा फरक प्रयोगकर्ता केसहरूमा उस्तै काम गर्ने कुरा लेख्न सक्नुहुन्न।

सबैभन्दा सामान्य उदाहरण, जुन आधिकारिक कागजातमा पनि संकेत गरिएको छ, यो हो कि यदि तपाईंले aws_instance लेख्नुभयो र धेरै तर्कहरू निर्दिष्ट गर्नुभयो भने, यदि तपाईंले त्यहाँ "local-exec" प्रावधानकर्ता पनि निर्दिष्ट गर्नुभयो र आफ्नो ansible-playbook चलाउनुभयो भने त्यसमा केही गलत छैन।

वास्तवमा, हो, यसमा केहि गलत छैन। तर तपाईंले चाँडै महसुस गर्नुहुनेछ कि यो स्थानीय-कार्यकारी चीज launch_configuration मा अवस्थित छैन।

अनि जब तपाईं launch_configuration प्रयोग गर्नुहुन्छ र एउटै उदाहरणबाट अटोस्केलिङ समूह सिर्जना गर्न चाहनुहुन्छ, launch_configuration मा "प्रोभिजनर" को अवधारणा हुँदैन। यसमा "प्रयोगकर्ता डेटा" को अवधारणा हुन्छ।

त्यसकारण, प्रयोगकर्ता डेटा प्रयोग गर्नु अझ विश्वव्यापी समाधान हो। यो या त सुरु हुँदा इन्स्टन्समा नै चल्नेछ, वा अटोस्केलिङ समूहले यो launch_configuration प्रयोग गर्दा उही प्रयोगकर्ता डेटामा चल्नेछ।

यदि तपाईं अझै पनि प्रोभिजनर चलाउन चाहनुहुन्छ भने, किनकि यो ग्लु कम्पोनेन्ट हो, तपाईंले एउटा स्रोत सिर्जना भएपछि आफ्नै प्रोभिजनर, आफ्नै कमाण्ड चलाउनु पर्छ। यस्ता धेरै परिस्थितिहरू छन्।

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

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

त्यहाँ धेरै संकेतहरू छन्। म ती सबैको बारेमा विस्तृतमा जाँदिन। यसको बारेमा एउटा लेख छ। तर यदि तपाईंले Terraform सँग काम गर्नुभएको छ वा अन्य व्यक्तिहरूको मोड्युलहरू प्रयोग गर्नुभएको छ भने, तपाईंले प्रायः याद गर्नुभएको छ कि धेरै मोड्युलहरू, जस्तै धेरैजसो खुला स्रोत कोड, मानिसहरूले आफ्नै आवश्यकताको लागि लेखेका हुन्छन्। कसैले यसलाई लेख्यो, आफ्नो समस्या समाधान गर्यो, GitHub मा डम्प गर्यो, र यसलाई लाइभ गर्न दियो। यो लाइभ हुनेछ, तर यदि कुनै कागजात वा उदाहरणहरू छैनन् भने, कसैले यसलाई प्रयोग गर्नेछैन। र यदि यसमा कार्यक्षमता छैन जसले तपाईंलाई तपाईंको विशिष्ट समस्या भन्दा अलि बढी समाधान गर्न अनुमति दिन्छ, कसैले पनि यसलाई प्रयोग गर्नेछैन। प्रयोगकर्ताहरू गुमाउने धेरै तरिकाहरू छन्।

यदि तपाईं मानिसहरूले प्रयोग गर्ने कुरा लेख्न चाहनुहुन्छ भने, म यी संकेतहरू पालना गर्न सिफारिस गर्दछु।

यी हुन्:

• कागजात र उदाहरणहरू।
• पूर्ण कार्यक्षमता।
• उचित पूर्वनिर्धारित मानहरू।
• सफा कोड।
• टेस्ट

परीक्षणहरू फरक कुरा हुन् किनभने तिनीहरू लेख्न धेरै गाह्रो हुन्छन्। म कागजात र उदाहरणहरूमा बढी भर पर्छु।

त्यसोभए, हामीले मोड्युलहरू कसरी लेख्ने भनेर हेरेका छौं। त्यहाँ दुई तर्कहरू छन्। पहिलो, र सबैभन्दा महत्त्वपूर्ण, यदि तपाईं यसलाई मद्दत गर्न सक्नुहुन्छ भने तिनीहरूलाई नलेख्नुहोस्, किनकि धेरै मानिसहरूले पहिले नै यी कार्यहरू गरिसकेका छन्। र दोस्रो, यदि तपाईंले यो गर्ने निर्णय गर्नुभयो भने, मोड्युलहरू र प्रावधानकर्ताहरूमा प्रदायकहरू प्रयोग गर्नबाट बच्न प्रयास गर्नुहोस्।

यो कागजातको खैरो क्षेत्र हो। तपाईं सोच्दै हुनुहुन्छ होला, "केही अस्पष्ट छ। म विश्वस्त छैन।" तर हामी छ महिनामा देख्नेछौं।

अब यी मोड्युलहरूलाई कसरी कल गर्ने भन्ने बारे कुरा गरौं।

हामीलाई थाहा छ कि समयसँगै हाम्रो कोड बढ्दै गइरहेको छ। हामीसँग अब एउटा फाइल छैन; हामीसँग २० वटा फाइलहरू छन्। ती सबै एउटै फोल्डरमा छन्। वा हुनसक्छ पाँच फोल्डरहरूमा। हुनसक्छ हामी तिनीहरूलाई क्षेत्र अनुसार, कम्पोनेन्ट अनुसार विभाजन गर्न थालिरहेका छौं। त्यसपछि हामीले महसुस गर्छौं कि हामीले सिङ्क्रोनाइजेसन र अर्केस्ट्रेसनको सुरुवात देख्न थालिरहेका छौं। अर्थात्, हामीले नेटवर्क स्रोतहरू परिवर्तन गर्दा के गर्ने, हाम्रा अन्य स्रोतहरूसँग के गर्ने, यी निर्भरताहरूलाई कसरी आह्वान गर्ने, आदि बुझ्न आवश्यक छ।

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

तर अब यो हटाइएको छ र हटाइएको छ। समय बित्दै जाँदा, टेराफर्म समुदायले महसुस गर्यो कि यो उत्तम अभ्यासबाट टाढा छ, किनकि मानिसहरूले परियोजनालाई विभिन्न तरिकाले प्रयोग गर्न थाल्छन्। र त्यहाँ समस्याहरू छन्। उदाहरणका लागि, जब हामी सबै निर्भरताहरू एकै ठाउँमा निर्दिष्ट गर्छौं, त्यहाँ परिस्थितिहरू हुन्छन् जब हामी "टेराफर्म योजना" मा क्लिक गर्छौं, र टेराफर्मलाई सबै स्रोतहरूको अवस्था अद्यावधिक गर्न लामो समय लाग्न सक्छ।

धेरै समय, उदाहरणका लागि, ५ मिनेट हो। कसैको लागि, त्यो धेरै समय हो। मैले १५ मिनेट लाग्ने केसहरू देखेको छु। AWS API ले प्रत्येक स्रोतको अवस्था पत्ता लगाउन १५ मिनेट खर्च गर्यो। त्यो धेरै ठूलो क्षेत्र हो।

अनि, स्वाभाविक रूपमा, जब तपाईं एकै ठाउँमा केही परिवर्तन गर्न चाहनुहुन्छ, त्यसपछि १५ मिनेट पर्खनुहोस्, तब सम्बन्धित समस्या उत्पन्न हुनेछ, र यसले तपाईंलाई केही परिवर्तनहरूको सूची देखाउँछ। तपाईंले बन्दुक हाम फाल्नुभयो, "हो" टाइप गर्नुभयो र केही गलत भयो। यो एकदमै वास्तविक उदाहरण हो। टेराफर्मले तपाईंलाई समस्याहरूबाट जोगाउने प्रयास गर्दैन। त्यसैले, तपाईं जे चाहनुहुन्छ लेख्नुहोस्। यदि समस्याहरू छन् भने, त्यो तपाईंको समस्या हो। टेराफर्म ०.११ ले तपाईंलाई कुनै पनि तरिकाले मद्दत गर्ने प्रयास गर्दैन। ०.१२ मा केही रोचक ठाउँहरू छन् जसले तपाईंलाई भन्न अनुमति दिन्छ, "वास्या, के तपाईं साँच्चै यो चाहनुहुन्छ? के तपाईं पुनर्विचार गर्न सक्नुहुन्छ?"

दोस्रो तरिका भनेको यो क्षेत्र घटाउनु हो, अर्थात् एक ठाउँबाट अर्को ठाउँमा हुने कलहरू कम जोड्नु हो।

समस्या एउटै हो कि तपाईंले धेरै कोड लेख्नुपर्छ, अर्थात् तपाईंले धेरै फाइलहरूमा चरहरू घोषणा गर्नुपर्छ र तिनीहरूलाई अद्यावधिक गरिरहनुपर्छ। केही मानिसहरूलाई त्यो मन पर्दैन। मेरो लागि, यो ठीक छ। तर केही मानिसहरू सोच्छन्, "यो किन फरक-फरक ठाउँमा लेख्ने? म यो सबैलाई एकै ठाउँमा जम्मा गर्नेछु।" त्यो सम्भव छ, तर त्यो अर्को चरम हो।

कसले यो सबै एकै ठाउँमा राख्छ? एक, दुई, तीन जना, अर्थात्, कसैले प्रयोग गर्छ।

अनि कसले एउटा विशेष कम्पोनेन्ट, एउटा ब्लक, वा एउटा पूर्वाधार मोड्युल भन्छ? पाँच देखि सात जना। त्यो त राम्रो कुरा हो।

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

यदि स्ट्याक VPC मा केहि परिवर्तन हुन्छ र तपाईं ती परिवर्तनहरू EC2 मा लागू गर्न चाहनुहुन्छ - अर्थात्, तपाईंसँग नयाँ सबनेट भएको कारणले गर्दा अटोस्केलिंग समूह अपडेट गर्न चाहनुहुन्छ - म यस प्रकारको निर्भरता अर्केस्ट्रेसन भन्छु। के त्यहाँ कुनै समाधानहरू छन्: यसलाई कसले प्रयोग गर्छ?

म केही समाधानहरू सुझाव दिन सक्छु। तपाईं जादु गर्न Terraform प्रयोग गर्न सक्नुहुन्छ, वा Terraform प्रयोग गर्न makefiles प्रयोग गर्न सक्नुहुन्छ। र केही परिवर्तन भएको छ कि छैन भनेर हेर्नको लागि तपाईं यसलाई यहाँ चलाउन सक्नुहुन्छ।

तपाईंलाई यो निर्णय कस्तो लाग्यो? के कसैलाई यो राम्रो समाधान हो जस्तो लाग्छ? म मुस्कान देख्छु, शंकाहरू भित्र पसेको देखिन्छ।

अवश्य पनि, घरमा यो प्रयास नगर्नुहोस्। टेराफर्म कहिल्यै टेराफर्मबाट चलाउनको लागि डिजाइन गरिएको थिएन।

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

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

यदि तपाईंलाई एकै ठाउँमा केहि परिवर्तन हुँदा कलहरू व्यवस्थित गर्न आवश्यक छ भने, त्यहाँ टेराग्रन्ट छ।

टेराग्रन्ट एउटा उपयोगिता हो, टेराफर्मको एड-अन, जसले तपाईंलाई पूर्वाधार मोड्युलहरूमा कलहरू समन्वय र अर्केस्ट्रेट गर्न अनुमति दिन्छ।

एउटा सामान्य टेराफर्म कन्फिगरेसन फाइल यस्तो देखिन्छ।

तपाईंले कुन विशिष्ट मोड्युल कल गर्न चाहनुहुन्छ भनेर निर्दिष्ट गर्नुहुन्छ।

मोड्युलमा के निर्भरताहरू छन्?

अनि यो मोड्युलले कुन तर्कहरू स्वीकार गर्छ? टेराग्रन्टको बारेमा तपाईंले जान्नुपर्ने यति मात्र हो।

त्यहाँ कागजातहरू छन्, र यसमा GitHub मा १,७०० ताराहरू छन्। तर धेरैजसो अवस्थामा, तपाईंले जान्नुपर्ने कुरा यही हो। र Terraform बाट भर्खरै सुरु गर्ने कम्पनीहरूको लागि यो कार्यान्वयन गर्न धेरै सजिलो छ।

त्यसैले, अर्केस्ट्रेसन टेराग्रन्ट हो। अन्य विकल्पहरू पनि छन्।

अब कोडसँग कसरी काम गर्ने भन्ने बारे कुरा गरौं।

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

यदि तपाईंसँग पहिले नै सिर्जना गरिएको स्रोत छ भने, उदाहरणका लागि, तपाईंले AWS खाता खोलिसकेपछि Terraform को बारेमा सिक्नुभयो र तपाईंसँग पहिले नै भएका स्रोतहरू प्रयोग गर्न चाहनुहुन्छ भने, तपाईंको मोड्युल विस्तार गर्नु उपयुक्त हुनेछ ताकि यसले अवस्थित स्रोतहरूको प्रयोगलाई समर्थन गर्दछ।

र ब्लक रिसोर्स प्रयोग गरेर नयाँ रिसोर्सहरूको सिर्जनालाई समर्थन गर्‍यो।

आउटपुटमा, हामी सधैं के प्रयोग गरिएको थियो भन्ने आधारमा आउटपुट आईडी फर्काउँछौं।

टेराफर्म ०.११ मा दोस्रो धेरै महत्त्वपूर्ण मुद्दा सूचीहरूसँग काम गर्नु हो।

कठिनाई यो छ कि यदि हामीसँग प्रयोगकर्ताहरूको यस्तो सूची छ भने।

र जब हामी ब्लक रिसोर्स प्रयोग गरेर यी प्रयोगकर्ताहरू सिर्जना गर्छौं, सबै कुरा ठीक हुन्छ। हामी सम्पूर्ण सूची हेर्छौं, प्रत्येकको लागि फाइल सिर्जना गर्छौं। सबै कुरा ठीक छ। र त्यसपछि, उदाहरणका लागि, user3, जुन बीचमा छ, यहाँबाट हटाउनु पर्छ, त्यसपछि सिर्जना गरिएका सबै स्रोतहरू पुन: सिर्जना गरिनेछ किनभने अनुक्रमणिका परिवर्तन हुनेछ।

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

समाधान यो हो: यो कोड Jsonnet मा लेखिएको छ। Jsonnet गुगलको टेम्प्लेटिङ भाषा हो।

यो आदेशले तपाईंलाई यो टेम्प्लेट स्वीकार गर्न अनुमति दिन्छ र आउटपुटमा यसले तपाईंको टेम्प्लेट अनुसार बनाइएको json फाइल फर्काउँछ।

टेम्प्लेट यस्तो देखिन्छ।

टेराफर्मले HCL र JSON दुवैसँग समान रूपमा राम्रोसँग काम गर्छ, त्यसैले यदि तपाईंसँग JSON उत्पन्न गर्ने क्षमता छ भने, तपाईं यसलाई टेराफर्ममा पास गर्न सक्नुहुन्छ। .tf.json फाइल सफलतापूर्वक लोड हुनेछ।

अनि हामी यसलाई सामान्य रूपमा प्रयोग गर्छौं: terraform init, terramorm apply। अनि हामी दुई प्रयोगकर्ताहरू सिर्जना गर्छौं।

अब हामीले टोली छोड्ने कोही छ कि भनेर चिन्ता लिनु पर्दैन। हामी केवल JSON फाइल सम्पादन गर्नेछौं। वास्या पपकिन गए, पेट्या प्याटोचिन रहे। पेट्या प्याटोचिनले नयाँ कुञ्जी पाउने छैनन्।

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

तर त्यहाँ परिस्थितिहरू हुन्छन् जब हामी टेराफर्म विस्तार गर्न चाहन्छौं र केहि पूरा भएपछि केही आदेश कल गर्न चाहन्छौं।

पहिलो तरिका: हामी एउटा आउटपुट सिर्जना गर्छौं जहाँ हामी यो आदेश लेख्छौं।

त्यसपछि हामी यो कमाण्डलाई टेराफर्म आउटपुट शेलबाट कल गर्छौं र हामीले चाहेको मान निर्दिष्ट गर्छौं। यसले सबै मानहरू प्रतिस्थापन गरेर कमाण्ड कार्यान्वयन गर्छ। यो धेरै सुविधाजनक छ।

दोस्रो विधि भनेको हाम्रो पूर्वाधारमा भएको परिवर्तनको आधारमा null_resource प्रयोग गर्नु हो। कुनै पनि स्रोतको ID परिवर्तन हुँदा हामी उही स्थानीय कार्यान्वयनयोग्यलाई कल गर्न सक्छौं।

स्वाभाविक रूपमा, यो सबै कागजमा राम्रो देखिन्छ, किनकि अमेजन, अन्य सबै सार्वजनिक प्रदायकहरू जस्तै, आफ्नै एज केसहरूको गुच्छा छ।

सबैभन्दा सामान्य एज केस भनेको जब तपाईंले AWS खाता खोल्नुहुन्छ, तपाईंले कुन क्षेत्रहरू प्रयोग गर्नुहुन्छ भन्ने कुराले फरक पार्छ; त्यहाँ यो सुविधा सक्षम छ कि छैन; हुनसक्छ तपाईंले यसलाई डिसेम्बर २०१३ पछि खोल्नुभएको थियो; हुनसक्छ तपाईं पूर्वनिर्धारित VPC प्रयोग गर्दै हुनुहुन्छ, आदि। त्यहाँ धेरै सीमितताहरू छन्। र अमेजनले तिनीहरूलाई कागजातहरूमा छरिएको छ।

म केही कुराहरूबाट बच्न सिफारिस गर्छु।

पहिले, Terraform योजना वा Terraform CLI भित्रका सबै गैर-गोप्य तर्कहरूबाट बच्नुहोस्। यी या त tfvars फाइल वा वातावरण चरहरूमा भण्डारण गर्न सकिन्छ।

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

साथै, दायरा साँघुरो पार्न लक्षित आर्गुमेन्टहरू प्रयोग नगर्नुहोस्। यसको लागि साना पूर्वाधार मोड्युलहरू प्रयोग गर्न धेरै सजिलो छ।

साथै, समानान्तरतालाई सीमित नगर्नुहोस् वा बढाउनुहोस्। यदि मसँग १५० स्रोतहरू छन् र म अमेजनको समानान्तरतालाई पूर्वनिर्धारित १० बाट १०० मा बढाउन चाहन्छु भने, केहि गलत हुन सक्छ। वा यो अहिले ठीकसँग काम गर्न सक्छ, तर जब अमेजनले मलाई भन्छ कि तपाईं धेरै कलहरू गर्दै हुनुहुन्छ, तपाईं समस्यामा पर्नुहुनेछ।

टेराफर्मले यी धेरैजसो समस्याहरू पुन: सुरु गर्ने प्रयास गर्नेछ, तर तपाईंले लगभग केही पनि प्राप्त गर्नुहुनेछैन। यदि तपाईंले AWS API मा वा टेराफर्म प्रदायक भित्र बगको सामना गर्नुभएको छ भने Parallelism=1 प्रयोग गर्नको लागि एउटा महत्त्वपूर्ण सुविधा हो। त्यसपछि तपाईंले parallelism=1 निर्दिष्ट गर्नुपर्नेछ र टेराफर्मले एउटा कल पूरा नगरेसम्म पर्खनु पर्नेछ, त्यसपछि दोस्रो, त्यसपछि तेस्रो। यसले तिनीहरूलाई क्रमिक रूपमा चलाउनेछ।

मलाई प्रायः सोधिन्छ, "मलाई किन टेराफर्म कार्यस्थानहरू खराब लाग्छ?" मलाई विश्वास छ कि कोडको रूपमा पूर्वाधारको सिद्धान्त भनेको कुन पूर्वाधार निर्माण गरिएको थियो र कुन मूल्यहरूसँग बनाइएको थियो भनेर हेर्नु हो।

कार्यस्थानहरू प्रयोगकर्ताहरूद्वारा सिर्जना गरिएको थिएन। यसको मतलब यो होइन कि प्रयोगकर्ताहरूले GitHub समस्याहरू लेखे कि तिनीहरू Terraform Workspaces बिना बाँच्न सक्दैनन्। होइन, यो सत्य होइन। Terraform Enterprise एक व्यावसायिक समाधान हो। HashiCorp को Terraform ले निर्णय गर्यो कि हामीलाई कार्यस्थानहरू चाहिन्छ, त्यसैले हामी यसलाई निर्माण गर्नेछौं। मलाई लाग्छ कि यसलाई छुट्टै फोल्डरमा राख्न धेरै सजिलो छ। यसको लागि केही थप फाइलहरू आवश्यक पर्नेछ, तर यो स्पष्ट हुनेछ।

कोडसँग कसरी काम गर्नुहुन्छ? मूलतः, सूचीहरूसँग काम गर्नु मात्र पीडा हो। र टेराफर्मलाई हल्का रूपमा लिनुहोस्। यो त्यस्तो चीज होइन जसले सबै कुरा पूर्ण रूपमा गर्नेछ। कागजातमा भएका सबै कुराहरू त्यहाँ नथुपार्नुहोस्।

रिपोर्टको विषय "भविष्यको लागि" भनिएको थियो। म यसलाई धेरै छोटकरीमा व्याख्या गर्नेछु। "भविष्यको लागि" को अर्थ ०.१२ चाँडै जारी हुनेछ।

०.१२ धेरै नयाँ कुराहरू हुन्। यदि तपाईं परम्परागत प्रोग्रामिङ पृष्ठभूमिबाट आउँदै हुनुहुन्छ भने, तपाईंले ती सबै गतिशील ब्लकहरू, लूपहरू, र सही र सर्तगत तुलनाहरू छुटाउनुहुनेछ जहाँ बायाँ र दायाँ पक्षहरू एकैसाथ मूल्याङ्कन गरिँदैन, बरु परिस्थितिमा निर्भर गर्दछ। तपाईंले ती सबै धेरै छुटाउनुहुनेछ, त्यसैले ०.१२ ले तपाईंको लागि त्यो समाधान गर्नेछ।

तर! यदि तपाईंले तयार मोड्युलहरू र तेस्रो-पक्ष समाधानहरू प्रयोग गरेर कम र सरल रूपमा लेख्नुभयो भने, तपाईंले ०.१२ आउने र तपाईंको लागि सबै कुरा ठीक गर्ने आशा गर्नुपर्दैन।

कुराकानीको लागि धन्यवाद! तपाईंले पूर्वाधारको बारेमा कोडको रूपमा कुरा गर्नुभयो र परीक्षणहरूको बारेमा शाब्दिक रूपमा एक शब्द भन्नुभयो। के मोड्युलहरूमा परीक्षणहरू आवश्यक छन्? त्यो कसको जिम्मेवारी हो? के म आफैंले लेख्नु पर्छ, वा त्यो मोड्युलहरूको जिम्मेवारी हो?

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

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

टेरेटेस्ट – यो टेराफर्मको लागि एकीकरण परीक्षण लेख्नको लागि सबैभन्दा धेरै उल्लेख गरिएको पुस्तकालयहरू मध्ये एक हो। यो उपयोगिताहरू मध्ये एक हो। मलाई rspec जस्तो DSL मन पर्छ।

एन्टोन, कुराकानीको लागि धन्यवाद! मेरो नाम भ्यालेरी हो। म तपाईंलाई अलि दार्शनिक प्रश्न सोध्न चाहन्छु। त्यहाँ प्रावधान छ, भन्नुपर्दा, र त्यहाँ तैनाती छ। प्रावधानले मेरो पूर्वाधार सिर्जना गर्छ, र तैनातीमा हामी यसलाई सर्भर, अनुप्रयोगहरू, र यस्तै उपयोगी चीजहरूले भर्छौं। मलाई लाग्छ कि टेराफर्म प्रावधानको लागि बढी हो, र एन्सिबल डिप्लोयमेन्टको लागि बढी हो, किनभने एन्सिबलले तपाईंलाई भौतिक पूर्वाधारमा NGINX र पोस्टग्रेस स्थापना गर्न दिन्छ। तर एकै समयमा, एन्सिबलले तपाईंलाई अमेजन वा गुगल जस्ता स्रोतहरू पनि प्रावधान गर्न दिन्छ जस्तो देखिन्छ। टेराफर्मले तपाईंलाई यसको मोड्युलहरू प्रयोग गरेर सफ्टवेयर तैनाती गर्न पनि दिन्छ। तपाईंको विचारमा, के टेराफर्म र एन्सिबल बीच विभाजन रेखा छ, र कुन प्रयोग गर्नु राम्रो हो? वा, उदाहरणका लागि, के तपाईंलाई लाग्छ कि एन्सिबल समयको बर्बादी हो र टेराफर्म सबै कुराको लागि प्रयोग गर्नुपर्छ?

राम्रो प्रश्न, भ्यालेरी। मलाई विश्वास छ कि टेराफर्मको उद्देश्य २०१४ देखि परिवर्तन भएको छैन। यो पूर्वाधारको लागि सिर्जना गरिएको थियो र पूर्वाधारको लागि मरेको थियो। हामीलाई अझै पनि एन्सिबलको कन्फिगरेसन व्यवस्थापनको आवश्यकता छ र रहनेछ। चुनौती यो हो कि यसमा launch_configuration भित्र प्रयोगकर्ता डेटा छ। र त्यसपछि तपाईंले एन्सिबल, आदि प्रयोग गर्नुहुन्छ। यो मानक भिन्नता हो जुन मलाई सबैभन्दा मन पर्छ।

यदि हामी सुन्दर पूर्वाधारको बारेमा कुरा गर्दैछौं भने, प्याकर जस्ता उपयोगिताहरू छन् जसले यो छवि निर्माण गर्दछ। त्यसपछि टेराफर्मले यो छवि फेला पार्न र यसको launch_configuration अपडेट गर्न डेटा स्रोत प्रयोग गर्दछ। त्यसैले, पाइपलाइनमा पहिले ट्र्याकरलाई कल गर्ने, त्यसपछि टेराफर्मलाई कल गर्ने समावेश छ। र यदि निर्माण हुन्छ भने, नयाँ परिवर्तन हुन्छ।

नमस्ते! कुराकानीको लागि धन्यवाद! मेरो नाम मिशा हो, RBS बाट। तपाईंले स्रोत सिर्जना गर्दा प्रोभिजनर मार्फत Ansible लाई कल गर्न सक्नुहुन्छ। Ansible मा गतिशील सूची भनिने सुविधा पनि छ। तपाईं पहिले Terraform लाई पनि कल गर्न सक्नुहुन्छ, र त्यसपछि Ansible लाई कल गर्न सक्नुहुन्छ, जसले राज्यबाट स्रोतहरू लिनेछ र तिनीहरूलाई कार्यान्वयन गर्नेछ। कुन राम्रो छ?

मानिसहरूले दुवैलाई समान सफलताका साथ प्रयोग गर्छन्। मलाई लाग्छ कि Ansible मा गतिशील सूची एक सुविधाजनक सुविधा हो, जबसम्म हामी अटोस्केलिंग समूहको बारेमा कुरा गरिरहेका छैनौं। किनभने अटोस्केलिंग समूहमा, हामीसँग पहिले नै launch_configuration भनिने आफ्नै उपकरण छ। launch_configuration मा, हामी नयाँ स्रोत सिर्जना गर्दा सुरु गर्न आवश्यक पर्ने सबै कुरा रेकर्ड गर्छौं। त्यसैले, Amazon सँग, गतिशील सूची प्रयोग गर्नु र Terraform .ts फाइल पढ्नु, मेरो विचारमा, अनावश्यक छ। र यदि तपाईंले अन्य उपकरणहरू प्रयोग गर्नुहुन्छ जसमा "अटोस्केलिंग समूह" को अवधारणा छैन - उदाहरणका लागि, तपाईंले DigitalOcean वा अन्य प्रदायक प्रयोग गर्नुहुन्छ जसमा अटोस्केलिंग समूह छैन - तब तपाईंले म्यानुअल रूपमा API पहुँच गर्नुपर्नेछ, IP ठेगानाहरू फेला पार्नुपर्नेछ, गतिशील सूची फाइल उत्पन्न गर्नुपर्नेछ, र Ansible ले त्यसपछि यसलाई पार गर्नेछ। त्यसैले, Amazon को लागि, त्यहाँ launch_configuration छ, र अरू सबै कुराको लागि, गतिशील सूची छ।

स्रोत: www.habr.com