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

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

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

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

Github मा AWS को लागि Terraform सामुदायिक मोड्युलहरूको संग्रह र उत्पादनमा Terraform को दीर्घकालीन मर्मतसम्भारको तीन वर्षको व्यवस्थापन पछि, Anton Babenko आफ्नो अनुभव साझा गर्न तयार छन्: TF मोड्युलहरू कसरी लेख्ने ताकि यसले भविष्यमा हानि नहोस्।

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

त्याग: म नोट गर्छु कि यो रिपोर्ट नोभेम्बर 2018 को मिति हो - 2 वर्ष पहिले नै बितिसकेको छ। रिपोर्टमा छलफल गरिएको Terraform 0.11 को संस्करण अब समर्थित छैन। विगत २ वर्षमा, २ नयाँ रिलिजहरू जारी गरिएका छन्, जसमा धेरै आविष्कारहरू, सुधारहरू र परिवर्तनहरू छन्। कृपया यसमा ध्यान दिनुहोस् र कागजातहरू जाँच गर्नुहोस्।

सन्दर्भहरू:

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

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

म Terraform मा काम गर्छु र 2015 देखि Terraform र Amazon सम्बन्धी ठूलो संख्यामा खुला स्रोत परियोजनाहरूमा सक्रिय सहभागी र योगदानकर्ता भएको छु।

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

म Terraform सँग काम गर्ने जटिलता र विशिष्टताहरूको बारेमा कुरा गर्नेछु। तर त्यो वास्तवमै HighLoad को विषय होइन। र अब तपाईंले किन बुझ्नुहुनेछ।

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

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

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

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

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

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

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

Terraform 2014 मा एक उपयोगिताको रूपमा देखा पर्‍यो जसले तपाईंलाई कोडको रूपमा पूर्वाधार लेख्न, योजना बनाउन र व्यवस्थापन गर्न अनुमति दियो। यहाँको मुख्य अवधारणा "कोडको रूपमा पूर्वाधार" हो।

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

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

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

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

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

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

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

त्यहाँ धेरै समान उपयोगिताहरू पनि छन्। Amazon प्रयोग गर्ने तपाईंहरू मध्ये धेरैलाई AWS CloudFormation वा Google Cloud Deployment Manager वा Azure Resource Manager थाहा छ। ती मध्ये प्रत्येक सार्वजनिक क्लाउड प्रदायकहरू मध्ये प्रत्येक भित्र स्रोतहरू प्रबन्ध गर्नको लागि कुनै न कुनै प्रकारको आफ्नै कार्यान्वयन छ। Terraform विशेष गरी उपयोगी छ किनभने यसले तपाईंलाई 100 भन्दा बढी प्रदायकहरू व्यवस्थापन गर्न अनुमति दिन्छ। (थप विवरण यहाँ)

Terraform ले सुरुदेखि नै पछ्याएको लक्ष्यहरू:

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

2014 मा, शब्द "पूर्वानुमान्य" यस सन्दर्भमा धेरै असामान्य सुनियो।

Terraform एक विश्वव्यापी उपयोगिता हो। यदि तपाइँसँग एपीआई छ भने, तपाइँ बिल्कुल सबै कुरा नियन्त्रण गर्न सक्नुहुन्छ:

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

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

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

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

यदि तपाइँ VPC सिर्जना गर्न चाहनुहुन्छ भने, तपाइँ लगभग यी 12 रेखाहरू निर्दिष्ट गर्नुहोस्। तपाइँ कुन क्षेत्रमा सिर्जना गर्न चाहनुहुन्छ, IP ठेगानाहरूको कुन cidr_block प्रयोग गर्ने भनेर वर्णन गर्नुहोस्। यति नै।

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

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

निम्न उदाहरण हेरौं।

तपाइँ बिस्तारै इन्टरनेट_गेटवे थप्नुहुन्छ किनभने तपाइँ तपाइँको VPC बाट स्रोतहरू इन्टरनेट पहुँच गर्न चाहनुहुन्छ। यो एक राम्रो विचार हो।

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

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

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

त्यसपछि तपाइँ सबनेट थप्नुहोस्। तपाईंले NAT गेटवेहरू, मार्गहरू, राउटिंग तालिकाहरू र अन्य सबनेटहरूको गुच्छा थप्न चाहनुभएको बेलामा, तपाईंसँग 38 लाइनहरू छैनन्, तर लगभग 200-300 रेखाहरू हुनेछन्।

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

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

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

र हामीसँग ठूलो, ठूलो आवश्यकता छ। हामी बुझ्छौं कि हामी अब यसरी बाँच्न सक्दैनौं। हाम्रो कोड ठूलो हुँदै गइरहेको छ। 10-20 Kb, निस्सन्देह, धेरै विशाल छैन, तर हामी केवल नेटवर्क स्ट्याकको बारेमा कुरा गर्दैछौं, अर्थात् तपाईंले नेटवर्क स्रोतहरू मात्र थप्नुभएको छ। हामी एप्लिकेसन लोड ब्यालेन्सर, डिप्लोइमेन्ट ES क्लस्टर, कुबर्नेट्स, इत्यादिको बारेमा कुरा गरिरहेका छैनौं, जहाँ 100 Kb सजिलैसँग बुन्न सकिन्छ। यदि तपाईंले यी सबै लेख्नुभयो भने, तपाईंले चाँडै थाहा पाउनुहुनेछ कि Terraform ले Terraform मोड्युलहरू प्रदान गर्दछ।

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

त्यसोभए हामी हाम्रो 10-20-30 Kb कोडलाई कसरी अनुकूलन गर्नेछौं भनेर बुझ्न प्रयास गर्दैछौं। हामीले बिस्तारै महसुस गर्दैछौं कि हामीले केहि मोड्युलहरू प्रयोग गर्न आवश्यक छ।

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

संसाधन मोड्युल को एक उदाहरण।

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

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

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

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

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

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

दोस्रो प्रकारको मोड्युल, जसमा संसाधन मोड्युलहरू हुन्छन्, पहिले नै तपाईंको व्यवसायमा लागू हुने समस्याहरू समाधान गर्छन्। प्राय: यो एक स्थान हो जुन Terraform को लागी एक विस्तार हो र कम्पनी मापदण्डहरु को लागी ट्याग को लागी केहि कठोर मानहरु सेट गर्दछ। तपाईं त्यहाँ कार्यक्षमता थप्न सक्नुहुन्छ जुन Terraform ले तपाईंलाई हाल प्रयोग गर्न अनुमति दिँदैन। यो अहिले हो। अब संस्करण ०.११, जुन विगतको कुरा बन्न लागेको छ। तर अझै, प्रिप्रोसेसरहरू, jsonnet, cookiecutter र अन्य चीजहरूको एक गुच्छा सहायक संयन्त्र हो जुन पूर्ण कामको लागि प्रयोग गर्नुपर्छ।

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

पूर्वाधार मोड्युल ठ्याक्कै उस्तै तरिकामा भनिन्छ।

सामग्री कहाँबाट डाउनलोड गर्ने स्रोत संकेत गरिएको छ।

मानहरूको गुच्छा यस मोड्युलमा पास र पास गरिन्छ।

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

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

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

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

Terraform रजिस्ट्री - https://registry.terraform.io/

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

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

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

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

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

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

https://github.com/mbtproject/mbt

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

निस्सन्देह, त्यहाँ धेरै downsides छन्। उदाहरण को लागी, तपाइँ संस्करण प्रयोग गर्न सक्नुहुन्न। र यो कहिलेकाहीं बाँच्न गाह्रो छ।

दोस्रो समाधान। यदि तपाईंसँग धेरै सबमोड्युलहरू छन् र तपाईंसँग पहिले नै कुनै प्रकारको स्थापित पाइपलाइन छ भने, त्यहाँ MBT परियोजना छ, जसले तपाईंलाई मोनोरेपोजिटरीबाट धेरै फरक प्याकेजहरू सङ्कलन गर्न र तिनीहरूलाई S3 मा अपलोड गर्न अनुमति दिन्छ। यो धेरै राम्रो तरिका हो। यसरी, iam-user-1.0.0.zip फाइलको तौल 1 Kb मात्र हुनेछ, किनभने यो स्रोत सिर्जना गर्ने कोड धेरै सानो छ। र यो धेरै छिटो काम गर्नेछ।

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

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

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

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

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

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

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

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

तसर्थ, अधिक विश्वव्यापी समाधान प्रयोगकर्ता डेटा प्रयोग गर्न हो। र यो या त उदाहरणमा सुरु हुनेछ, जब उदाहरण खोलिएको छ, वा उही प्रयोगकर्ता डेटामा, जब स्वत: स्केलिंग समूहले यो launch_configuration प्रयोग गर्दछ।

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

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

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

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

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

यी हुन्:

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

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

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

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

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

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

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

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

धेरै समय, उदाहरणका लागि, 5 मिनेट। कसैको लागि यो धेरै समय हो। मैले केसहरू देखेको छु जहाँ यसले 15 मिनेट लियो। AWS API ले प्रत्येक स्रोतको स्थितिमा के भइरहेको छ भनेर पत्ता लगाउन प्रयास गर्न 15 मिनेट बितायो। यो धेरै ठूलो क्षेत्र हो।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

र यो मोड्युलले के तर्कहरू स्वीकार गर्दछ। Terragrunt को बारे मा जान्न को लागी यति मात्र छ।

कागजात त्यहाँ छ, र GitHub मा 1 ताराहरू छन्। तर धेरै जसो केसहरूमा यो तपाईले जान्न आवश्यक छ। र यो कम्पनीहरूमा लागू गर्न धेरै सजिलो छ जुन भर्खर Terraform सँग काम गर्न थालेको छ।

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

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

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

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

र ब्लक स्रोत प्रयोग गरी नयाँ स्रोतहरू सिर्जना गर्न समर्थन गर्नुभयो।

आउटपुटमा हामी जहिले पनि प्रयोग भएको आधारमा आउटपुट आईडी फिर्ता गर्छौं।

Terraform 0.11 मा दोस्रो धेरै महत्त्वपूर्ण समस्या सूची संग काम गरिरहेको छ।

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

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

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

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

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

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

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

र त्यसपछि हामी यसलाई सामान्य रूपमा काम गर्छौं: टेराफार्म इनिट, टेरामोर्म लागू। र हामी दुई प्रयोगकर्ताहरू सिर्जना गर्छौं।

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

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

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

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

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

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

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

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

त्यहाँ केहि चीजहरू छन् जुन म बेवास्ता गर्न सिफारिस गर्दछु।

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

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

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

साथै, समानान्तरतालाई सीमित र बढाउन आवश्यक छैन। यदि मसँग 150 स्रोतहरू छन् र म पूर्वनिर्धारित 10 बाट 100 सम्म अमेजन समानान्तर बढाउन चाहन्छु, तब सम्भवतः केहि गलत हुनेछ। वा यो अहिले राम्रो हुन सक्छ, तर जब Amazon ले भन्छ कि तपाइँ धेरै कलहरू गर्दै हुनुहुन्छ, तपाइँ समस्यामा हुनुहुनेछ।

Terraform यी धेरै समस्याहरू पुन: सुरु गर्न प्रयास गर्नेछ, तर तपाईं लगभग केहि प्राप्त गर्नुहुनेछैन। यदि तपाइँ AWS API भित्र वा Terraform प्रदायक भित्र केहि बग मा ठोकर खानुहुन्छ भने समानान्तर = 1 प्रयोग गर्न को लागी एक महत्वपूर्ण कुरा हो। र त्यसपछि तपाइँ निर्दिष्ट गर्न आवश्यक छ: parallelism=1 र Terraform एक कल, त्यसपछि दोस्रो, त्यसपछि तेस्रो सम्म पर्खनुहोस्। उसले तिनीहरूलाई एक-एक गरी सुरु गर्नेछ।

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

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

कोड संग कसरी काम गर्ने? वास्तवमा, सूचीहरूसँग काम गर्नु मात्र पीडा हो। र Terraform सजिलो लिनुहोस्। यो चीज होइन जुन तपाइँको लागि सबै राम्रो गर्नेछ। त्यहाँ कागजातमा लेखिएका सबै चीजहरू खन्याउनु आवश्यक छैन।

रिपोर्टको विषय "भविष्यको लागि" लेखिएको थियो। म यस बारे धेरै छोटकरीमा कुरा गर्नेछु। भविष्यको लागि, यसको मतलब 0.12 चाँडै जारी हुनेछ।

0.12 नयाँ सामानको एक टन हो। यदि तपाइँ नियमित प्रोग्रामिङबाट आउनुभएको छ भने, तपाइँले सबै प्रकारका गतिशील ब्लकहरू, लूपहरू, सही र सशर्त तुलना अपरेसनहरू गुमाउनुहुन्छ, जहाँ बायाँ र दायाँ पक्षहरू एकै साथ गणना गरिएको छैन, तर परिस्थितिमा निर्भर गर्दछ। तपाइँ यसलाई धेरै सम्झनुहुन्छ, त्यसैले 0.12 ले तपाइँको लागि यो समाधान गर्नेछ।

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

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

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

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

टेरेटेस्ट तपाईलाई Terraform का लागि एकीकरण परीक्षण लेख्न अनुमति दिने प्रायः उल्लेख गरिएका पुस्तकालयहरू मध्ये एक हो। यो उपयोगिताहरु मध्ये एक हो। म DSL प्रकार रुचाउँछु, उदाहरण को लागी, rspec।

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

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

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

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

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

स्रोत: www.habr.com