भविष्यासाठी टेराफॉर्ममधील पायाभूत सुविधांचे वर्णन. अँटोन बाबेंको (२०१८)

बर्‍याच लोकांना त्यांच्या दैनंदिन कामात टेराफॉर्म माहित आहे आणि वापरला आहे, परंतु त्यासाठी सर्वोत्तम पद्धती अद्याप तयार झालेल्या नाहीत. प्रत्येक संघाने स्वतःचे दृष्टिकोन आणि पद्धती शोधल्या पाहिजेत.

तुमची इन्फ्रास्ट्रक्चर जवळजवळ नक्कीच सोपी सुरू होते: काही संसाधने + काही विकासक. कालांतराने, ते सर्व प्रकारच्या दिशेने वाढते. तुम्हाला टेराफॉर्म मॉड्यूल्समध्ये संसाधने गटबद्ध करण्याचे, फोल्डर्समध्ये कोड व्यवस्थापित करण्याचे आणि आणखी काय चुकीचे होऊ शकते असे मार्ग सापडतात का? (शेवटचे प्रसिद्ध शब्द)

वेळ निघून जातो आणि तुम्हाला असे वाटते की तुमची पायाभूत सुविधा ही तुमची नवीन पाळीव प्राणी आहे, पण का? तुम्ही पायाभूत सुविधांमधील अकल्पनीय बदलांबद्दल चिंतित आहात, तुम्ही पायाभूत सुविधा आणि कोडला स्पर्श करण्यास घाबरत आहात - परिणामी, तुम्ही नवीन कार्यक्षमतेला विलंब करता किंवा गुणवत्ता कमी करता...

Github वर AWS साठी टेराफॉर्म कम्युनिटी मॉड्यूल्सचा संग्रह व्यवस्थापित केल्यानंतर आणि उत्पादनात Terraform ची दीर्घकालीन देखभाल केल्यानंतर, Anton Babenko आपला अनुभव शेअर करण्यास तयार आहेत: TF मॉड्यूल्स कसे लिहायचे जेणेकरून भविष्यात दुखापत होणार नाही.

भाषणाच्या शेवटी, सहभागी टेराफॉर्ममधील संसाधन व्यवस्थापन तत्त्वे, टेराफॉर्ममधील मॉड्यूल्सशी संबंधित सर्वोत्तम पद्धती आणि पायाभूत सुविधा व्यवस्थापनाशी संबंधित काही सतत एकीकरण तत्त्वांशी परिचित होतील.

अस्वीकरण: मी लक्षात घेतो की हा अहवाल नोव्हेंबर 2018 चा आहे—2 वर्षे आधीच झाली आहेत. अहवालात चर्चा केलेली Terraform 0.11 ची आवृत्ती यापुढे समर्थित नाही. गेल्या 2 वर्षांमध्ये, 2 नवीन रिलीझ रिलीज केले गेले आहेत, ज्यामध्ये बरेच नवकल्पना, सुधारणा आणि बदल आहेत. कृपया याकडे लक्ष द्या आणि कागदपत्रे तपासा.

दुवे:

• टेराफॉर्म-समुदाय-मॉड्यूल्स + टेराफॉर्म-aws-मॉड्यूल्स
• 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 - Twitter, आणि विविध स्लॅक्सचा समूह

माझे नाव अँटोन बाबेंको आहे. तुमच्यापैकी काहींनी कदाचित मी लिहिलेला कोड वापरला असेल. मी आता याबद्दल नेहमीपेक्षा अधिक आत्मविश्वासाने बोलेन, कारण माझ्याकडे आकडेवारीचा प्रवेश आहे.

मी Terraform वर काम करतो आणि 2015 पासून Terraform आणि Amazon शी संबंधित मोठ्या प्रमाणात ओपन सोर्स प्रकल्पांमध्ये सक्रिय सहभागी आणि योगदानकर्ता आहे.

तेव्हापासून मी ते मनोरंजक पद्धतीने मांडण्यासाठी पुरेसे कोड लिहिले आहे. आणि मी आता याबद्दल सांगण्याचा प्रयत्न करेन.

मी टेराफॉर्मसह काम करण्याच्या गुंतागुंत आणि वैशिष्ट्यांबद्दल बोलेन. पण तो खरोखर हायलोडचा विषय नाही. आणि आता तुम्हाला का समजेल.

कालांतराने, मी टेराफॉर्म मॉड्यूल्स लिहायला सुरुवात केली. वापरकर्त्यांनी प्रश्न लिहिले, मी ते पुन्हा लिहिले. मग मी प्री-कमिट हुक इत्यादी वापरून कोड फॉरमॅट करण्यासाठी विविध उपयुक्तता लिहिल्या.

अनेक मनोरंजक प्रकल्प होते. मला कोड तयार करणे आवडते कारण मला संगणकाने माझ्यासाठी आणि प्रोग्रामरसाठी अधिकाधिक काम करणे आवडते, म्हणून मी सध्या व्हिज्युअल आकृत्यांमधून टेराफॉर्म कोड जनरेटरवर काम करत आहे. कदाचित तुमच्यापैकी काहींनी त्यांना पाहिले असेल. हे बाणांसह सुंदर बॉक्स आहेत. आणि मला वाटते की तुम्ही "निर्यात" बटण क्लिक करू शकता आणि ते सर्व कोड म्हणून मिळवू शकता तर ते छान आहे.

मी युक्रेनचा आहे. मी बर्‍याच वर्षांपासून नॉर्वेमध्ये राहतो.

तसेच, माझे नाव माहीत असलेल्या आणि सोशल नेटवर्क्सवर मला शोधणाऱ्या लोकांकडून या अहवालासाठी माहिती गोळा करण्यात आली. माझे जवळजवळ नेहमीच एकच टोपणनाव असते.

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

मी नमूद केल्याप्रमाणे, मी टेराफॉर्म AWS मॉड्यूल्सचा मुख्य देखभालकर्ता आहे, जो GitHub वरील सर्वात मोठ्या भांडारांपैकी एक आहे जिथे आम्ही सर्वात सामान्य कार्यांसाठी मॉड्यूल होस्ट करतो: VPC, ऑटोस्केलिंग, RDS.

आणि तुम्ही आता जे ऐकले ते सर्वात मूलभूत आहे. जर तुम्हाला शंका असेल की तुम्हाला टेराफॉर्म काय आहे ते समजले आहे, तर तुमचा वेळ कुठेतरी घालवणे चांगले आहे. इथे खूप तांत्रिक संज्ञा असतील. आणि अहवालाची पातळी सर्वोच्च असल्याचे घोषित करण्यास मी मागेपुढे पाहिले नाही. याचा अर्थ मी जास्त स्पष्टीकरण न देता सर्व संभाव्य संज्ञा वापरून बोलू शकतो.

टेराफॉर्म 2014 मध्ये एक युटिलिटी म्हणून दिसले ज्याने तुम्हाला कोड म्हणून पायाभूत सुविधा लिहिण्यास, योजना बनविण्यास आणि व्यवस्थापित करण्यास अनुमती दिली. येथे मुख्य संकल्पना "कोड म्हणून पायाभूत सुविधा" आहे.

मी म्हटल्याप्रमाणे सर्व दस्तऐवज लिहिलेले आहेत terraform.io. मला आशा आहे की बहुतेक लोकांना या साइटबद्दल माहिती आहे आणि त्यांनी दस्तऐवजीकरण वाचले असेल. तसे असल्यास, तुम्ही योग्य ठिकाणी आहात.

नियमित टेराफॉर्म कॉन्फिगरेशन फाइल अशी दिसते, जिथे आपण प्रथम काही व्हेरिएबल्स परिभाषित करतो.

या प्रकरणात आम्ही "aws_region" परिभाषित करतो.

मग आम्ही कोणती संसाधने तयार करू इच्छितो याचे वर्णन करतो.

आम्ही काही कमांड्स चालवतो, विशेषतः "टेराफॉर्म इनिट" अवलंबन आणि प्रदाते लोड करण्यासाठी.

आणि निर्दिष्ट कॉन्फिगरेशन आम्ही तयार केलेल्या संसाधनांशी जुळते की नाही हे तपासण्यासाठी आम्ही "टेराफॉर्म लागू" कमांड चालवतो. आम्ही यापूर्वी काहीही तयार केले नसल्यामुळे, टेराफॉर्म आम्हाला ही संसाधने तयार करण्यास सूचित करते.

आम्ही याची पुष्टी करतो. अशा प्रकारे आपण सीझनेल नावाची बादली तयार करतो.

अनेक समान उपयुक्तता देखील आहेत. Amazon वापरणाऱ्या तुमच्यापैकी अनेकांना AWS CloudFormation किंवा Google Cloud Deployment Manager किंवा Azure Resource Manager माहित आहे. या प्रत्येक सार्वजनिक क्लाउड प्रदात्यांच्या अंतर्गत संसाधने व्यवस्थापित करण्यासाठी त्यांच्यापैकी प्रत्येकाची स्वतःची अंमलबजावणी आहे. टेराफॉर्म विशेषतः उपयुक्त आहे कारण ते तुम्हाला 100 पेक्षा जास्त प्रदाते व्यवस्थापित करण्यास अनुमती देते. (अधिक माहितीसाठी येथे)

टेराफॉर्मने सुरुवातीपासूनच ज्या उद्दिष्टांचा पाठपुरावा केला आहे:

• टेराफॉर्म संसाधनांचे एकल दृश्य प्रदान करते.
• तुम्हाला सर्व आधुनिक प्लॅटफॉर्मचे समर्थन करण्याची अनुमती देते.
• आणि टेराफॉर्मची रचना सुरुवातीपासूनच एक उपयुक्तता म्हणून केली गेली होती जी तुम्हाला पायाभूत सुविधा सुरक्षितपणे आणि अंदाजानुसार बदलू देते.

2014 मध्ये, "अंदाज करण्यायोग्य" हा शब्द या संदर्भात खूपच असामान्य वाटला.

टेराफॉर्म ही एक सार्वत्रिक उपयुक्तता आहे. तुमच्याकडे एपीआय असल्यास, तुम्ही पूर्णपणे सर्वकाही नियंत्रित करू शकता:

• तुम्हाला हवे असलेले सर्वकाही व्यवस्थापित करण्यासाठी तुम्ही 120 पेक्षा जास्त प्रदाते वापरू शकता.
• उदाहरणार्थ, GitHub रेपॉजिटरीजमध्ये प्रवेशाचे वर्णन करण्यासाठी तुम्ही Terraform वापरू शकता.
• तुम्ही जिरा मध्ये बग तयार आणि बंद देखील करू शकता.
• तुम्ही नवीन रेलिक मेट्रिक्स व्यवस्थापित करू शकता.
• तुम्हाला खरोखर हवे असल्यास तुम्ही ड्रॉपबॉक्समध्ये फाइल्स देखील तयार करू शकता.

हे सर्व टेराफॉर्म प्रदाते वापरून साध्य केले जाते, ज्यांचे गो मध्ये वर्णन केले जाऊ शकते असे खुले API आहे.

समजा आम्ही Terraform वापरण्यास सुरुवात केली, साइटवरील काही कागदपत्रे वाचली, काही व्हिडिओ पाहिले आणि main.tf लिहायला सुरुवात केली, जसे मी मागील स्लाइड्सवर दाखवले होते.

आणि सर्व काही छान आहे, आपल्याकडे एक फाईल आहे जी VPC तयार करते.

जर तुम्हाला व्हीपीसी तयार करायचा असेल तर तुम्ही अंदाजे या 12 ओळी निर्दिष्ट करा. तुम्हाला कोणत्या प्रदेशात तयार करायचे आहे, IP पत्त्यांचे कोणते cidr_block वापरायचे याचे वर्णन करा. इतकंच.

साहजिकच, प्रकल्प हळूहळू वाढेल.

आणि तुम्ही तेथे बरीच नवीन सामग्री जोडत असाल: संसाधने, डेटा स्रोत, तुम्ही नवीन प्रदात्यांसह समाकलित व्हाल, अचानक तुम्हाला तुमच्या GitHub खात्यातील वापरकर्ते व्यवस्थापित करण्यासाठी टेराफॉर्म वापरायचे असेल, इ. तुम्हाला वापरायचे असेल. भिन्न DNS प्रदाते, सर्वकाही पार करा. टेराफॉर्म हे सोपे करते.

खालील उदाहरण पाहू.

तुम्ही हळूहळू internet_gateway जोडता कारण तुम्हाला तुमच्या VPC कडील संसाधने इंटरनेट ऍक्सेस हवी आहेत. ही एक चांगली कल्पना आहे.

परिणाम हा आहे main.tf:

हा main.tf चा सर्वात वरचा भाग आहे.

हा main.tf चा खालचा भाग आहे.

मग सबनेट जोडा. जोपर्यंत तुम्हाला NAT गेटवे, मार्ग, राउटिंग टेबल आणि इतर सबनेटचा समूह जोडायचा असेल, तेव्हा तुमच्याकडे 38 ओळी नसून अंदाजे 200-300 ओळी असतील.

म्हणजेच तुमची main.tf फाईल हळूहळू वाढत आहे. आणि बरेचदा लोक सर्वकाही एका फाईलमध्ये ठेवतात. main.tf मध्ये 10-20 Kb दिसते. कल्पना करा की 10-20 Kb मजकूर सामग्री आहे. आणि सर्वकाही प्रत्येक गोष्टीशी जोडलेले आहे. यामुळे हळूहळू काम करणे कठीण होत आहे. 10-20 Kb एक चांगला वापरकर्ता केस आहे, कधीकधी अधिक. आणि हे वाईट आहे असे लोकांना नेहमी वाटत नाही.

रेग्युलर प्रोग्रॅमिंग प्रमाणे, म्हणजे कोड म्हणून इन्फ्रास्ट्रक्चर नाही, आम्हाला वेगवेगळ्या क्लासेस, पॅकेजेस, मॉड्युल्स, ग्रुपिंग्जचा समूह वापरण्याची सवय आहे. टेराफॉर्म आपल्याला समान गोष्टी करण्यास अनुमती देते.

• कोड वाढत आहे.
• संसाधनांमधील अवलंबित्वही वाढत आहे.

आणि आम्हाला खूप मोठी गरज आहे. आम्ही समजतो की आम्ही यापुढे असे जगू शकत नाही. आमची संहिता अफाट होत चालली आहे. 10-20 Kb अर्थातच फार मोठे नाही, परंतु आम्ही फक्त नेटवर्क स्टॅकबद्दल बोलत आहोत, म्हणजे तुम्ही फक्त नेटवर्क संसाधने जोडली आहेत. आम्ही ऍप्लिकेशन लोड बॅलन्सर, डिप्लॉयमेंट ES क्लस्टर, कुबर्नेट्स इत्यादींबद्दल बोलत नाही, जिथे 100 Kb सहजपणे विणले जाऊ शकते. तुम्ही हे सर्व लिहून ठेवल्यास, तुम्हाला लवकरच कळेल की टेराफॉर्म टेराफॉर्म मॉड्यूल प्रदान करतो.

टेराफॉर्म मॉड्युल्स हे एक स्व-निहित टेराफॉर्म कॉन्फिगरेशन आहे जे समूह म्हणून व्यवस्थापित केले जाते. टेराफॉर्म मॉड्यूल्सबद्दल तुम्हाला एवढेच माहित असणे आवश्यक आहे. ते अजिबात हुशार नाहीत, ते आपल्याला एखाद्या गोष्टीवर अवलंबून कोणतेही जटिल कनेक्शन बनविण्याची परवानगी देत ​​​​नाहीत. हे सर्व विकासकांच्या खांद्यावर येते. म्हणजेच, हे फक्त काही प्रकारचे टेराफॉर्म कॉन्फिगरेशन आहे जे तुम्ही आधीच लिहिले आहे. आणि तुम्ही त्याला फक्त ग्रुप म्हणू शकता.

म्हणून आम्ही आमचे 10-20-30 Kb कोड कसे ऑप्टिमाइझ करू हे समजून घेण्याचा प्रयत्न करत आहोत. आपल्याला काही मॉड्यूल्स वापरण्याची गरज आहे हे हळूहळू लक्षात येत आहे.

आपणास प्रथम प्रकारचे मॉड्यूल्स आढळतात ते संसाधन मॉड्यूल्स आहेत. तुमची पायाभूत सुविधा काय आहे, तुमचा व्यवसाय काय आहे, कुठे आणि कोणत्या परिस्थिती आहेत हे त्यांना समजत नाही. हे अगदी मॉड्युल्स आहेत जे मी, ओपन सोर्स कम्युनिटीसह, प्रशासित करतो आणि जे आम्ही तुमच्या पायाभूत सुविधांसाठी अगदी प्रारंभिक बिल्डिंग ब्लॉक्स म्हणून पुढे ठेवले आहेत.

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

जेव्हा आम्ही संसाधन मॉड्यूल कॉल करतो, तेव्हा आम्ही त्यातील सामग्री कोणत्या मार्गावरून लोड करावी हे आम्ही निर्दिष्ट करतो.

आम्हाला कोणती आवृत्ती डाउनलोड करायची आहे ते आम्ही सूचित करतो.

आम्ही तेथे अनेक युक्तिवाद करतो. इतकंच. जेव्हा आपण हे मॉड्यूल वापरतो तेव्हा आपल्याला इतकेच माहित असणे आवश्यक आहे.

बर्याच लोकांना असे वाटते की जर त्यांनी नवीनतम आवृत्ती वापरली तर सर्वकाही स्थिर होईल. पण नाही. पायाभूत सुविधांची आवृत्ती असणे आवश्यक आहे; हे किंवा ते घटक कोणत्या आवृत्तीवर तैनात केले गेले होते याचे स्पष्टपणे उत्तर दिले पाहिजे.

या मॉड्यूलमध्ये असलेला कोड येथे आहे. सुरक्षा-समूह मॉड्यूल. येथे स्क्रोल 640 व्या ओळीवर जाते. Amazon मध्ये प्रत्येक संभाव्य कॉन्फिगरेशनमध्ये सुरक्षा-क्रूप संसाधन तयार करणे हे अत्यंत क्षुल्लक काम आहे. फक्त सुरक्षा गट तयार करणे आणि त्याला कोणते नियम पास करायचे हे सांगणे पुरेसे नाही. हे खूप सोपे असेल. Amazon मध्ये लाखो भिन्न निर्बंध आहेत. उदाहरणार्थ, आपण वापरत असल्यास VPC एंडपॉइंट, उपसर्ग सूची, विविध API आणि हे सर्व इतर सर्व गोष्टींसह एकत्र करण्याचा प्रयत्न करते, नंतर टेराफॉर्म आपल्याला हे करण्याची परवानगी देत ​​​​नाही. आणि Amazon API देखील याची परवानगी देत ​​नाही. म्हणून, आम्हाला हे सर्व भयंकर लॉजिक एका मॉड्यूलमध्ये लपवावे लागेल आणि वापरकर्त्याला यासारखे दिसणारे कोड द्यावे लागेल.

वापरकर्त्याला ते आत कसे बनवले जाते हे माहित असणे आवश्यक नाही.

दुस-या प्रकारचे मॉड्यूल, ज्यामध्ये संसाधन मॉड्यूल असतात, आधीच आपल्या व्यवसायासाठी अधिक लागू असलेल्या समस्यांचे निराकरण करतात. बर्‍याचदा हे असे ठिकाण असते जे टेराफॉर्मसाठी विस्तारित असते आणि टॅगसाठी, कंपनीच्या मानकांसाठी काही कठोर मूल्ये सेट करते. तुम्ही तेथे कार्यक्षमता देखील जोडू शकता जी Terraform तुम्हाला सध्या वापरण्याची परवानगी देत ​​नाही. हे सध्या आहे. आता आवृत्ती 0.11, जी भूतकाळातील गोष्ट बनणार आहे. पण तरीही, प्रीप्रोसेसर, jsonnet, cookiecutter आणि इतर गोष्टींचा समूह ही सहाय्यक यंत्रणा आहे जी पूर्ण कामासाठी वापरली जाणे आवश्यक आहे.

पुढे मी याची काही उदाहरणे दाखवतो.

इन्फ्रास्ट्रक्चर मॉड्यूल अगदी त्याच प्रकारे कॉल केले जाते.

सामग्री कोठून डाउनलोड करायची ते स्त्रोत सूचित केले आहे.

मूल्यांचा समूह या मॉड्यूलमध्ये जातो आणि जातो.

पुढे, या मॉड्यूलमध्ये, संसाधन मॉड्यूल्सचा एक समूह VPC किंवा ऍप्लिकेशन लोड बॅलन्सर तयार करण्यासाठी किंवा सुरक्षा-समूह तयार करण्यासाठी किंवा लवचिक कंटेनर सेवा क्लस्टरसाठी कॉल केला जातो.

दोन प्रकारचे मॉड्यूल आहेत. हे समजून घेणे महत्त्वाचे आहे कारण मी या अहवालात गटबद्ध केलेली बहुतांश माहिती दस्तऐवजीकरणात लिहिलेली नाही.

आणि आत्ता टेराफॉर्म मधील दस्तऐवजीकरण खूप समस्याप्रधान आहे कारण ते फक्त असे म्हणतात की ही वैशिष्ट्ये आहेत, तुम्ही ती वापरू शकता. परंतु ही वैशिष्ट्ये कशी वापरायची, ती का वापरणे चांगले आहे हे ती सांगत नाही. म्हणून, खूप मोठ्या संख्येने लोक असे काहीतरी लिहितात ज्यासह ते जगू शकत नाहीत.

पुढे ही मॉड्युल्स कशी लिहायची ते पाहू. मग आपण त्यांना कसे कॉल करावे आणि कोडसह कसे कार्य करावे ते पाहू.

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

टीप #0 म्हणजे संसाधन मॉड्यूल्स लिहू नका. यापैकी बहुतेक मॉड्यूल तुमच्यासाठी आधीच लिहिलेले आहेत. मी म्हटल्याप्रमाणे, ते ओपन सोर्स आहेत, त्यामध्ये तुमचे कोणतेही व्यावसायिक तर्क नाही, त्यांच्याकडे IP पत्ते, पासवर्ड इत्यादींसाठी हार्डकोड मूल्ये नाहीत. मॉड्यूल खूप लवचिक आहे. आणि बहुधा ते आधीच लिहिले गेले आहे. Amazon कडून संसाधनांसाठी अनेक मॉड्यूल आहेत. सुमारे 650. आणि त्यापैकी बहुतेक चांगल्या दर्जाचे आहेत.

या उदाहरणात, कोणीतरी तुमच्याकडे आला आणि म्हणाला, “मला डेटाबेस व्यवस्थापित करण्यास सक्षम व्हायचे आहे. एक मॉड्यूल तयार करा जेणेकरून मी डेटाबेस तयार करू शकेन." व्यक्तीला Amazon किंवा Terraform यापैकी एकाच्या अंमलबजावणीचे तपशील माहित नाहीत. तो फक्त म्हणतो: "मला MSSQL व्यवस्थापित करायचे आहे." म्हणजेच, आमचा अर्थ असा आहे की ते आमचे मॉड्यूल कॉल करेल, तेथे इंजिनचा प्रकार पास करेल आणि टाइम झोन सूचित करेल.

आणि एखाद्या व्यक्तीला हे माहित नसावे की आम्ही या मॉड्यूलमध्ये दोन भिन्न संसाधने तयार करू: एक MSSQL साठी, दुसरा सर्व गोष्टींसाठी, फक्त कारण Terraform 0.11 मध्ये तुम्ही टाइम झोन मूल्ये पर्यायी म्हणून निर्दिष्ट करू शकत नाही.

आणि या मॉड्यूलमधून बाहेर पडताना, एखादी व्यक्ती फक्त पत्ता प्राप्त करण्यास सक्षम असेल. कुठल्या डेटाबेसमधून, कुठल्या रिसोर्समधून हे सगळं आपण अंतर्गत तयार करतोय हे त्याला कळणार नाही. हे लपविण्याचा एक अतिशय महत्वाचा घटक आहे. आणि हे केवळ ओपन सोर्समध्‍ये सार्वजनिक असलेल्‍या मॉड्युलनाच लागू होत नाही, तर तुम्ही तुमच्‍या प्रोजेक्‍ट आणि टीममध्‍ये लिहिल्‍या मॉड्युललाही लागू होते.

हा दुसरा युक्तिवाद आहे, जर तुम्ही काही काळ टेराफॉर्म वापरत असाल तर ते खूप महत्वाचे आहे. तुमच्याकडे एक भांडार आहे ज्यामध्ये तुम्ही तुमच्या कंपनीसाठी तुमचे सर्व टेराफॉर्म मॉड्यूल ठेवता. आणि हे अगदी सामान्य आहे की कालांतराने हा प्रकल्प एक किंवा दोन मेगाबाइट्स इतका वाढेल. हे ठीक आहे.

परंतु समस्या ही आहे की टेराफॉर्म या मॉड्यूल्सला कसे कॉल करते. उदाहरणार्थ, प्रत्येक वैयक्तिक वापरकर्ता तयार करण्यासाठी तुम्ही मॉड्यूल कॉल केल्यास, टेराफॉर्म प्रथम संपूर्ण रेपॉजिटरी लोड करेल आणि नंतर ते विशिष्ट मॉड्यूल स्थित असलेल्या फोल्डरवर नेव्हिगेट करेल. अशा प्रकारे तुम्ही प्रत्येक वेळी एक मेगाबाइट डाउनलोड कराल. जर तुम्ही 100 किंवा 200 वापरकर्ते व्यवस्थापित करत असाल, तर तुम्ही 100 किंवा 200 मेगाबाइट्स डाउनलोड कराल आणि नंतर त्या फोल्डरवर जाल. त्यामुळे साहजिकच तुम्ही "Terraform init" दाबा तेव्हा प्रत्येक वेळी तुम्हाला अनेक गोष्टी डाउनलोड करायच्या नाहीत.

https://github.com/mbtproject/mbt

या समस्येवर दोन उपाय आहेत. प्रथम सापेक्ष मार्ग वापरणे आहे. अशा प्रकारे तुम्ही कोडमध्ये सूचित करता की फोल्डर स्थानिक आहे (./). आणि तुम्ही काहीही लाँच करण्यापूर्वी, तुम्ही स्थानिक पातळीवर या रेपॉजिटरीचा Git क्लोन करा. अशा प्रकारे तुम्ही एकदाच करा.

त्यात अर्थातच अनेक तोटे आहेत. उदाहरणार्थ, तुम्ही आवृत्ती वापरू शकत नाही. आणि हे जगणे कधीकधी कठीण असते.

दुसरा उपाय. जर तुमच्याकडे बरेच सबमॉड्यूल असतील आणि तुमच्याकडे आधीपासून काही प्रकारची पाइपलाइन असेल, तर एमबीटी प्रकल्प आहे, जो तुम्हाला मोनोरेपॉझिटरीमधून अनेक भिन्न पॅकेजेस गोळा करण्यास आणि त्यांना S3 वर अपलोड करण्यास अनुमती देतो. हा खूप चांगला मार्ग आहे. अशा प्रकारे, iam-user-1.0.0.zip फाईलचे वजन फक्त 1 Kb असेल, कारण हा संसाधन तयार करण्यासाठी कोड खूपच लहान आहे. आणि ते खूप वेगाने कार्य करेल.

मॉड्यूलमध्ये काय वापरले जाऊ शकत नाही याबद्दल बोलूया.

मॉड्यूल्समध्ये हे वाईट का आहे? सर्वात वाईट गोष्ट म्हणजे वापरकर्ता गृहीत धरणे. गृहीत धरा वापरकर्ता हा प्रदाता प्रमाणीकरण पर्याय आहे जो भिन्न लोक वापरु शकतात. उदाहरणार्थ, आपण सर्वजण भूमिका आत्मसात करू. म्हणजे टेराफॉर्म ही भूमिका घेणार आहे. आणि मग या भूमिकेसह तो इतर क्रिया करेल.

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

दुसरे दुष्ट म्हणजे प्रोव्हिजनर. येथे वाईट इतके क्षुल्लक नाही, कारण जर तुम्ही कोड लिहिला आणि तो तुमच्यासाठी काम करत असेल तर तुम्हाला वाटेल की जर ते काम करत असेल तर मग ते का बदला.

वाईट हे आहे की हा प्रोव्हिजनर केव्हा लॉन्च केला जाईल हे तुम्ही नेहमी नियंत्रित करत नाही. आणि दुसरे म्हणजे, aws ec2 चा अर्थ काय आहे हे तुम्ही नियंत्रित करत नाही, म्हणजे आम्ही आता Linux किंवा Windows बद्दल बोलत आहोत. त्यामुळे तुम्ही असे काही लिहू शकत नाही जे वेगवेगळ्या ऑपरेटिंग सिस्टीमवर किंवा वेगवेगळ्या वापरकर्त्यांच्या केसेससाठी सारखेच काम करेल.

सर्वात सामान्य उदाहरण, जे अधिकृत दस्तऐवजात देखील सूचित केले आहे, ते असे आहे की तुम्ही aws_instance लिहिल्यास आणि वितर्कांचा एक समूह निर्दिष्ट केल्यास, जर तुम्ही तेथे प्रोव्हिजनर "स्थानिक-कार्यवाहक" निर्दिष्ट केले आणि तुमचे उत्तरदायित्व चालवले तर त्यात काहीही चूक नाही. प्लेबुक

खरं तर, होय, त्यात काहीही चुकीचे नाही. परंतु अक्षरशः लवकरच तुमच्या लक्षात येईल की ही स्थानिक-एक्झिकेशन गोष्ट अस्तित्वात नाही, उदाहरणार्थ, लॉन्च_कॉन्फिगरेशनमध्ये.

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

म्हणून, वापरकर्ता डेटा वापरणे हा अधिक सार्वत्रिक उपाय आहे. आणि ते एकतर इंस्टन्सवरच लॉन्च केले जाईल, जेव्हा इन्स्टन्स चालू असेल किंवा त्याच वापरकर्ता डेटामध्ये, जेव्हा ऑटोस्केलिंग ग्रुप हे लॉन्च_कॉन्फिगरेशन वापरेल.

तुम्हाला अजूनही प्रोव्हिजनर चालवायचा असेल, कारण तो एक ग्लूइंग घटक आहे, जेव्हा एक संसाधन तयार केले जाते, त्या क्षणी तुम्हाला तुमचा प्रोव्हिजनर, तुमची कमांड चालवावी लागेल. अशा अनेक परिस्थिती आहेत.

आणि यासाठी सर्वात योग्य संसाधनास null_resource म्हणतात. Null_resource हे एक डमी संसाधन आहे जे प्रत्यक्षात कधीही तयार केले जात नाही. ते कशालाही स्पर्श करत नाही, API नाही, ऑटोस्केलिंग नाही. परंतु कमांड केव्हा चालवायची ते नियंत्रित करण्याची परवानगी देते. या प्रकरणात, कमांड निर्मिती दरम्यान चालविली जाते.

दुवा http://bit.ly/common-traits-in-terraform-modules

अनेक चिन्हे आहेत. मी सर्व चिन्हांमध्ये मोठ्या तपशीलात जाणार नाही. याबद्दल एक लेख आहे. परंतु जर तुम्ही Terraform सोबत काम केले असेल किंवा इतर लोकांचे मॉड्यूल वापरले असतील, तर तुम्ही अनेकदा लक्षात घेतले असेल की अनेक मॉड्यूल्स, जसे की ओपन सोर्समधील बहुतेक कोड, लोक त्यांच्या स्वतःच्या गरजांसाठी लिहितात. एका माणसाने ते लिहून त्याची समस्या सोडवली. मी ते GitHub मध्ये अडकले, ते जगू द्या. ते जगेल, परंतु तेथे कागदपत्रे आणि उदाहरणे नसल्यास, कोणीही त्याचा वापर करणार नाही. आणि जर अशी कोणतीही कार्यक्षमता नसेल जी आपल्याला त्याच्या विशिष्ट कार्यापेक्षा थोडे अधिक सोडविण्यास अनुमती देते, तर कोणीही ते वापरणार नाही. वापरकर्ते गमावण्याचे बरेच मार्ग आहेत.

जर तुम्हाला काहीतरी लिहायचे असेल जेणेकरुन लोक ते वापरतील, तर मी या चिन्हांचे अनुसरण करण्याची शिफारस करतो.

हे आहेः

• दस्तऐवजीकरण आणि उदाहरणे.
• पूर्ण कार्यक्षमता.
• वाजवी डीफॉल्ट.
• स्वच्छ कोड.
• चाचण्या

चाचण्या ही एक वेगळी परिस्थिती आहे कारण त्या लिहिणे खूप कठीण आहे. माझा दस्तऐवजीकरण आणि उदाहरणांवर अधिक विश्वास आहे.

तर, आम्ही मॉड्यूल कसे लिहायचे ते पाहिले. दोन वाद आहेत. पहिले, जे सर्वात महत्वाचे आहे, ते शक्य असल्यास लिहू नका, कारण अनेक लोकांनी ही कामे तुमच्या आधी केली आहेत. आणि दुसरे म्हणजे, आपण अद्याप निर्णय घेतल्यास, मॉड्यूल आणि प्रोव्हिजनर्समध्ये प्रदाते न वापरण्याचा प्रयत्न करा.

हा दस्तऐवजीकरणाचा राखाडी भाग आहे. तुम्ही आता विचार करत असाल: “काहीतरी अस्पष्ट आहे. पटले नाही." पण सहा महिन्यात बघू.

आता या मॉड्यूल्सला कसे कॉल करायचे याबद्दल बोलूया.

आम्हाला समजते की आमचा कोड कालांतराने वाढतो. आमच्याकडे यापुढे एक फाईल नाही, आमच्याकडे आधीच 20 फाइल्स आहेत. ते सर्व एका फोल्डरमध्ये आहेत. किंवा कदाचित पाच फोल्डर्समध्ये. कदाचित आम्ही त्यांना प्रदेशानुसार, काही घटकांनुसार खंडित करू लागलो आहोत. मग आम्हाला समजले की आता आमच्याकडे सिंक्रोनाइझेशन आणि ऑर्केस्ट्रेशनचे काही मूळ आहेत. म्हणजेच, आपण नेटवर्क संसाधने बदलल्यास आपण काय केले पाहिजे, आपल्या उर्वरित संसाधनांचे आपण काय करावे, या अवलंबनास कारणीभूत कसे असावे, इत्यादी समजून घेणे आवश्यक आहे.

दोन टोके आहेत. पहिले टोक सर्व एकात आहे. आमच्याकडे एक मास्टर फाइल आहे. काही काळासाठी, टेराफॉर्म वेबसाइटवर ही अधिकृत सर्वोत्तम सराव होती.

पण आता ते नापसंत असे लिहून काढले आहे. कालांतराने, टेराफॉर्म समुदायाच्या लक्षात आले की हे सर्वोत्कृष्ट पद्धतीपासून दूर आहे, कारण लोक वेगवेगळ्या प्रकारे प्रकल्प वापरू लागले. आणि समस्या आहेत. उदाहरणार्थ, जेव्हा आम्ही सर्व अवलंबित्व एकाच ठिकाणी सूचीबद्ध करतो. अशी परिस्थिती असते जेव्हा आम्ही "टेराफॉर्म योजना" वर क्लिक करतो आणि जोपर्यंत टेराफॉर्म सर्व संसाधनांची स्थिती अद्यतनित करत नाही तोपर्यंत बराच वेळ जाऊ शकतो.

बराच वेळ, उदाहरणार्थ, 5 मिनिटे. काहींसाठी हा बराच वेळ असतो. मी अशी प्रकरणे पाहिली आहेत जिथे यास 15 मिनिटे लागली. AWS API ने प्रत्येक संसाधनाच्या स्थितीत काय घडत आहे हे शोधण्यात 15 मिनिटे घालवली. हे खूप मोठे क्षेत्र आहे.

आणि, नैसर्गिकरित्या, जेव्हा तुम्हाला एका ठिकाणी काहीतरी बदलायचे असेल तेव्हा संबंधित समस्या दिसून येईल, नंतर तुम्ही 15 मिनिटे थांबा आणि ते तुम्हाला काही बदलांचा कॅनव्हास देईल. तुम्ही थुंकले, “होय” लिहिले आणि काहीतरी चूक झाली. हे अगदी वास्तव उदाहरण आहे. टेराफॉर्म तुम्हाला समस्यांपासून वाचवण्याचा प्रयत्न करत नाही. म्हणजेच तुम्हाला जे हवे ते लिहा. समस्या असतील - तुमच्या समस्या. Terraform 0.11 तुम्हाला कोणत्याही प्रकारे मदत करण्याचा प्रयत्न करत नाही. 0.12 मध्ये काही मनोरंजक ठिकाणे आहेत जी तुम्हाला असे म्हणू देतात: "वास्या, तुला खरोखर हे हवे आहे, तू शुद्धीवर येऊ शकतोस का?"

दुसरा मार्ग म्हणजे हे क्षेत्र कमी करणे, म्हणजेच एका ठिकाणाहून आलेले कॉल दुसऱ्या ठिकाणाहून कमी जोडले जाऊ शकतात.

फक्त समस्या अशी आहे की तुम्हाला अधिक कोड लिहिणे आवश्यक आहे, म्हणजे तुम्हाला मोठ्या संख्येने फाइल्समध्ये व्हेरिएबल्सचे वर्णन करणे आणि हे अद्यतनित करणे आवश्यक आहे. काही लोकांना ते आवडत नाही. हे माझ्यासाठी सामान्य आहे. आणि काही लोक विचार करतात: "हे वेगवेगळ्या ठिकाणी का लिहा, मी ते सर्व एकाच ठिकाणी ठेवतो." हे शक्य आहे, परंतु हे दुसरे टोक आहे.

हे सर्व एकाच ठिकाणी कोणाचे वास्तव्य आहे? एक, दोन, तीन लोक, म्हणजे कोणीतरी ते वापरत आहे.

आणि एक विशिष्ट घटक, एक ब्लॉक किंवा एक इन्फ्रास्ट्रक्चर मॉड्यूल कोण म्हणतो? पाच ते सात जण. हे मस्त आहे.

सर्वात सामान्य उत्तर मध्यभागी कुठेतरी आहे. जर प्रकल्प मोठा असेल, तर तुमच्याकडे बर्‍याचदा अशी परिस्थिती असेल जिथे कोणताही उपाय योग्य नसतो आणि तेथे सर्वकाही कार्य करत नाही, म्हणून तुम्ही मिश्रणासह समाप्त व्हाल. यामध्ये काहीही चुकीचे नाही, जोपर्यंत तुम्हाला समजते की दोन्हीचे फायदे आहेत.

जर स्टॅक VPC मध्ये काहीतरी बदलले असेल आणि तुम्हाला हे बदल EC2 वर लागू करायचे असतील, म्हणजे तुम्हाला ऑटोस्केलिंग गट अपडेट करायचा असेल कारण तुमच्याकडे नवीन सबनेट आहे, तर मी या प्रकारच्या अवलंबित्व ऑर्केस्ट्रेशन म्हणतो. काही उपाय आहेत: कोण काय वापरते?

त्यावर कोणते उपाय आहेत ते मी सुचवू शकतो. तुम्ही जादू करण्यासाठी टेराफॉर्म वापरू शकता किंवा टेराफॉर्म वापरण्यासाठी मेकफाईल्स वापरू शकता. आणि तेथे काहीतरी बदलले आहे का ते पहा, तुम्ही ते येथे लाँच करू शकता.

तुम्हाला हा निर्णय कसा आवडला? कोणाला विश्वास आहे की हा एक छान उपाय आहे? मला एक स्मित दिसत आहे, वरवर पाहता शंका निर्माण झाल्या आहेत.

अर्थात, घरी हा प्रयत्न करू नका. टेराफॉर्म कधीही टेराफॉर्मवरून चालवण्यासाठी डिझाइन केलेले नव्हते.

एका अहवालात त्यांनी मला सांगितले: "नाही, हे कार्य करणार नाही." मुद्दा असा आहे की ते कार्य करू नये. जरी तुम्ही टेराफॉर्म वरून टेराफॉर्म लाँच करू शकता आणि नंतर टेराफॉर्म लाँच करू शकता तेव्हा ते खूप प्रभावी दिसते, परंतु तुम्हाला ते करण्याची आवश्यकता नाही. टेराफॉर्म नेहमी अगदी सहज सुरू व्हायला हवे.

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

एखाद्या ठिकाणी काहीतरी बदललेले असताना तुम्हाला कॉल ऑर्केस्ट्रेशनची आवश्यकता असल्यास, टेराग्रंट आहे.

टेराग्रंट ही युटिलिटी आहे, टेराफॉर्ममध्ये अॅड-ऑन आहे, जी तुम्हाला इन्फ्रास्ट्रक्चर मॉड्युल्सवर कॉल्सचे समन्वय आणि ऑर्केस्ट्रेट करण्यास अनुमती देते.

ठराविक टेराफॉर्म कॉन्फिगरेशन फाइल यासारखी दिसते.

आपण कोणत्या विशिष्ट मॉड्यूलला कॉल करू इच्छिता ते निर्दिष्ट करा.

मॉड्यूलमध्ये कोणते अवलंबन आहे?

आणि हे मॉड्यूल कोणते युक्तिवाद स्वीकारतात. टेराग्रंटबद्दल इतकेच जाणून घ्यायचे आहे.

दस्तऐवजीकरण तेथे आहे आणि GitHub वर 1 तारे आहेत. परंतु बर्याच बाबतीत हे आपल्याला माहित असणे आवश्यक आहे. आणि ज्या कंपन्यांनी नुकतेच टेराफॉर्मसह काम करणे सुरू केले आहे त्यांच्यामध्ये हे लागू करणे खूप सोपे आहे.

तर ऑर्केस्ट्रेशन म्हणजे टेराग्रंट. इतर पर्याय आहेत.

आता कोडसह कसे कार्य करावे याबद्दल बोलूया.

तुम्हाला तुमच्या कोडमध्ये नवीन वैशिष्ट्ये जोडायची असल्यास, बहुतेक प्रकरणांमध्ये हे सोपे आहे. आपण एक नवीन संसाधन लिहित आहात, सर्वकाही सोपे आहे.

जर तुमच्याकडे काही संसाधने आहेत जी तुम्ही आगाऊ तयार केली आहेत, उदाहरणार्थ, तुम्ही AWS खाते उघडल्यानंतर तुम्हाला टेराफॉर्मबद्दल माहिती मिळाली आणि तुमच्याकडे आधीपासून असलेली संसाधने वापरायची असतील, तर तुमचे मॉड्यूल अशा प्रकारे वाढवणे योग्य ठरेल, जेणेकरून ते विद्यमान संसाधनांच्या वापरास समर्थन देते.

आणि ब्लॉक संसाधन वापरून नवीन संसाधने तयार करण्यास समर्थन दिले.

आउटपुटवर आम्ही नेहमी वापरलेल्या गोष्टींवर अवलंबून आउटपुट आयडी देतो.

टेराफॉर्म 0.11 मधील दुसरी अत्यंत महत्त्वाची समस्या म्हणजे सूचीसह कार्य करणे.

अडचण अशी आहे की जर आपल्याकडे वापरकर्त्यांची अशी यादी असेल.

आणि जेव्हा आम्ही हे वापरकर्ते ब्लॉक संसाधन वापरून तयार करतो, तेव्हा सर्वकाही ठीक होते. आम्ही प्रत्येकासाठी एक फाईल तयार करून संपूर्ण सूचीमधून जातो. सर्व काही ठीक आहे. आणि मग, उदाहरणार्थ, user3, जो मध्यभागी आहे, येथून काढला जावा, नंतर त्याच्या नंतर तयार केलेली सर्व संसाधने पुन्हा तयार केली जातील कारण निर्देशांक बदलेल.

स्टेटफुल वातावरणात सूचीसह कार्य करणे. राज्यपूर्ण वातावरण म्हणजे काय? ही परिस्थिती आहे जेव्हा हे संसाधन तयार केले जाते तेव्हा नवीन मूल्य तयार होते. उदाहरणार्थ, AWS Access Key किंवा AWS Secret Key, म्हणजे जेव्हा आम्ही वापरकर्ता तयार करतो तेव्हा आम्हाला एक नवीन Access किंवा Secret Key प्राप्त होते. आणि प्रत्येक वेळी जेव्हा आम्ही वापरकर्ता हटवतो तेव्हा या वापरकर्त्याकडे नवीन की असेल. परंतु हे फेंग शुई नाही, कारण प्रत्येक वेळी जेव्हा कोणीतरी संघ सोडला तेव्हा आम्ही त्याच्यासाठी नवीन वापरकर्ता तयार केल्यास वापरकर्त्याला आमच्याशी मैत्री करायची नाही.

हा उपाय आहे. हा Jsonnet मध्ये लिहिलेला कोड आहे. Jsonnet ही Google ची टेम्प्लेटिंग भाषा आहे.

ही कमांड तुम्हाला हे टेम्प्लेट स्वीकारण्याची परवानगी देते आणि आउटपुट म्हणून तुमच्या टेम्प्लेटनुसार बनवलेली json फाइल परत करते.

टेम्प्लेट असे दिसते.

Terraform तुम्हाला HCL आणि Json या दोन्हींसोबत एकाच प्रकारे काम करण्याची परवानगी देते, त्यामुळे तुमच्याकडे Json जनरेट करण्याची क्षमता असल्यास, तुम्ही ते Terraform मध्ये स्लिप करू शकता. .tf.json विस्तारासह फाइल यशस्वीरित्या डाउनलोड केली जाईल.

आणि मग आम्ही नेहमीप्रमाणे त्याच्यासह कार्य करतो: टेराफॉर्म इनिट, टेरामॉर्म लागू. आणि आम्ही दोन वापरकर्ते तयार करतो.

आता कोणी संघ सोडल्यास आम्हाला भीती वाटत नाही. आम्ही फक्त json फाइल संपादित करू. वास्या पपकिन सोडले, पेट्या पायटोचकिन राहिले. पेट्या पायटोचकिनला नवीन की मिळणार नाही.

टेराफॉर्मला इतर साधनांसह एकत्रित करणे हे खरोखर टेराफॉर्मचे काम नाही. टेराफॉर्म संसाधने तयार करण्यासाठी एक व्यासपीठ म्हणून तयार केले गेले आणि तेच. आणि नंतर समोर येणारी प्रत्येक गोष्ट टेराफॉर्मची चिंता नाही. आणि तिथे विणण्याची गरज नाही. तेथे Ansible आहे, जे आपल्याला आवश्यक असलेल्या सर्व गोष्टी करते.

परंतु परिस्थिती उद्भवते जेव्हा आम्हाला टेराफॉर्म वाढवायचा असतो आणि काहीतरी पूर्ण झाल्यानंतर काही कमांड कॉल करायची असते.

पहिला मार्ग. ही कमांड जिथे लिहितो तिथे आऊटपुट तयार करतो.

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

दुसरा मार्ग. आमच्या इन्फ्रास्ट्रक्चरमधील बदलांवर अवलंबून हा null_resource चा वापर आहे. काही संसाधनांचा आयडी बदलताच आम्ही त्याच लोकल-एक्सईला कॉल करू शकतो.

साहजिकच, हे सर्व कागदावर गुळगुळीत आहे, कारण Amazon, इतर सर्व सार्वजनिक प्रदात्यांप्रमाणे, त्याच्या स्वत: च्या धार केसांचा समूह आहे.

सर्वात सामान्य एज केस म्हणजे जेव्हा तुम्ही AWS खाते उघडता तेव्हा तुम्ही कोणते प्रदेश वापरता हे महत्त्वाचे असते; हे वैशिष्ट्य तेथे सक्षम आहे का; कदाचित तुम्ही ते डिसेंबर २०१३ नंतर उघडले असेल; कदाचित तुम्ही व्हीपीसी इ. मध्ये डीफॉल्ट वापरत आहात. अनेक निर्बंध आहेत. आणि अॅमेझॉनने त्यांना संपूर्ण दस्तऐवजीकरणात विखुरले.

मी टाळण्याची शिफारस करतो अशा काही गोष्टी आहेत.

सुरू करण्यासाठी, टेराफॉर्म प्लॅन किंवा टेराफॉर्म सीएलआयमधील सर्व गैर-गुप्त युक्तिवाद टाळा. हे सर्व एकतर tfvars फाइलमध्ये किंवा पर्यावरण व्हेरिएबलमध्ये ठेवले जाऊ शकते.

परंतु तुम्हाला ही संपूर्ण जादूची आज्ञा लक्षात ठेवण्याची गरज नाही. टेराफॉर्म प्लॅन – var आणि ऑफ आम्ही जातो. पहिला व्हेरिएबल var आहे, दुसरा व्हेरिएबल var आहे, तिसरा, चौथा आहे. मी बर्‍याचदा वापरत असलेला कोड म्हणून पायाभूत सुविधांचे सर्वात महत्त्वाचे तत्त्व म्हणजे फक्त कोड पाहून, मला तेथे काय तैनात केले आहे, कोणत्या स्थितीत आणि कोणत्या मूल्यांसह आहे हे स्पष्टपणे समजले पाहिजे. आणि म्हणून मला दस्तऐवज वाचण्याची किंवा वास्याला विचारण्याची गरज नाही की त्याने आमचे क्लस्टर तयार करण्यासाठी कोणते मापदंड वापरले. मला फक्त tfvars एक्स्टेंशन असलेली फाइल उघडायची आहे, जी अनेकदा वातावरणाशी जुळते आणि तिथल्या सर्व गोष्टी पहा.

तसेच, व्याप्ती कमी करण्यासाठी लक्ष्य युक्तिवाद वापरू नका. यासाठी लहान इन्फ्रास्ट्रक्चर मॉड्यूल्स वापरणे खूप सोपे आहे.

तसेच, समांतरता मर्यादित आणि वाढविण्याची गरज नाही. जर माझ्याकडे 150 संसाधने असतील आणि मला ऍमेझॉन समांतरता डीफॉल्ट 10 ते 100 पर्यंत वाढवायची असेल, तर बहुधा काहीतरी चूक होईल. किंवा ते आता चांगले जाऊ शकते, परंतु जेव्हा Amazon म्हणते की तुम्ही खूप कॉल करत आहात, तेव्हा तुम्ही अडचणीत असाल.

टेराफॉर्म यापैकी बहुतेक समस्या रीस्टार्ट करण्याचा प्रयत्न करेल, परंतु आपण जवळजवळ काहीही साध्य करू शकणार नाही. AWS API मधील किंवा Terraform प्रदात्याच्या आत काही बग आढळल्यास समांतरता=1 ही एक महत्त्वाची गोष्ट आहे. आणि नंतर तुम्हाला निर्दिष्ट करणे आवश्यक आहे: parallelism=1 आणि टेराफॉर्म एक कॉल पूर्ण होईपर्यंत प्रतीक्षा करा, नंतर दुसरा, नंतर तिसरा. तो त्यांना एक एक करून लॉन्च करेल.

लोक मला नेहमी विचारतात, "मला टेराफॉर्म वर्कस्पेसेस वाईट का वाटतात?" माझा विश्वास आहे की पायाभूत सुविधांचे तत्त्व कोड म्हणून काय पायाभूत सुविधा निर्माण केल्या गेल्या आहेत आणि कोणत्या मूल्यांसह आहेत.

कार्यक्षेत्रे वापरकर्त्यांनी तयार केलेली नाहीत. याचा अर्थ असा नाही की वापरकर्त्यांनी GitHub समस्यांमध्ये असे लिहिले आहे की आम्ही टेराफॉर्म वर्कस्पेसशिवाय जगू शकत नाही. नाही असे नाही. टेराफॉर्म एंटरप्राइझ एक व्यावसायिक उपाय आहे. HashiCorp मधील टेराफॉर्मने ठरवले की आम्हाला वर्कस्पेसेसची आवश्यकता आहे, म्हणून आम्ही ते भरले. वेगळ्या फोल्डरमध्ये ठेवणे मला खूप सोपे वाटते. नंतर थोड्या अधिक फायली असतील, परंतु ते अधिक स्पष्ट होईल.

कोडसह कसे कार्य करावे? किंबहुना, याद्यांसोबत काम करणे हेच दुखणे आहे. आणि Terraform सोपे घ्या. ही अशी गोष्ट नाही जी तुमच्यासाठी सर्व काही उत्तम करेल. तिथल्या कागदपत्रात जे काही लिहिलंय ते सगळं ढकलून देण्याची गरज नाही.

अहवालाचा विषय "भविष्यासाठी" लिहिलेला होता. मी याबद्दल अगदी थोडक्यात बोलणार आहे. भविष्यासाठी, याचा अर्थ असा की 0.12 लवकरच सोडले जाईल.

0.12 ही एक टन नवीन सामग्री आहे. जर तुम्ही नियमित प्रोग्रामिंगमधून येत असाल, तर तुम्ही सर्व प्रकारचे डायनॅमिक ब्लॉक्स, लूप, योग्य आणि सशर्त तुलना ऑपरेशन्स चुकवता, जिथे डाव्या आणि उजव्या बाजू एकाच वेळी मोजल्या जात नाहीत, परंतु परिस्थितीनुसार. तुमची खूप आठवण येते, त्यामुळे 0.12 तुमच्यासाठी ते सोडवेल.

परंतु! जर तुम्ही रेडीमेड मॉड्यूल्स आणि थर्ड-पार्टी सोल्यूशन्स वापरून कमी आणि अधिक सोप्या पद्धतीने लिहित असाल, तर तुम्हाला प्रतीक्षा करावी लागणार नाही आणि आशा आहे की 0.12 येईल आणि तुमच्यासाठी सर्वकाही ठीक करेल.

अहवालाबद्दल धन्यवाद! तुम्ही कोड म्हणून पायाभूत सुविधांबद्दल बोललात आणि चाचण्यांबद्दल अक्षरशः एक शब्द बोललात. मॉड्यूलमध्ये चाचण्या आवश्यक आहेत का? ही जबाबदारी कोणाची? मला ते स्वतः लिहिण्याची गरज आहे की मॉड्यूलची जबाबदारी आहे?

पुढचे वर्ष अहवालांनी भरले जाईल की आम्ही सर्व काही तपासण्याचे ठरवले आहे. काय चाचणी करायची हा सर्वात मोठा प्रश्न आहे. विविध प्रदात्यांकडून भरपूर अवलंबित्व, बरेच निर्बंध आहेत. जेव्हा तुम्ही आणि मी बोलत असतो आणि तुम्ही म्हणता: "मला चाचण्यांची गरज आहे," तेव्हा मी विचारतो: "तुम्ही कशाची चाचणी घ्याल?" तुम्ही म्हणाल की तुमच्या प्रदेशात चाचणी करणार. मग मी म्हणतो की माझ्या प्रदेशात हे चालत नाही. म्हणजेच, आम्ही यावर सहमत होऊ शकणार नाही. त्यात अनेक तांत्रिक अडचणी आहेत हे सांगायला नको. म्हणजेच या चाचण्या कशा लिहायच्या जेणेकरून त्या पुरेशा असतील.

मी या विषयावर सक्रियपणे संशोधन करत आहे, म्हणजे तुम्ही लिहिलेल्या पायाभूत सुविधांवर आधारित चाचण्या स्वयंचलितपणे कशा तयार करायच्या. म्हणजेच, जर तुम्ही हा कोड लिहिला असेल तर मला तो चालवावा लागेल, त्यावर आधारित मी चाचण्या तयार करू शकतो.

टेरटेस्ट सर्वात वारंवार उल्लेख केलेल्या लायब्ररींपैकी एक आहे जी तुम्हाला टेराफॉर्मसाठी एकत्रीकरण चाचण्या लिहिण्याची परवानगी देते. ही एक उपयुक्तता आहे. मी DSL प्रकार पसंत करतो, उदाहरणार्थ, rspec.

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

चांगला प्रश्न, व्हॅलेरी. माझा विश्वास आहे की टेराफॉर्म 2014 पासून उद्देशाच्या दृष्टीने बदललेला नाही. ते पायाभूत सुविधांसाठी तयार केले गेले आणि पायाभूत सुविधांसाठी मरण पावले. आमच्याकडे अजूनही कॉन्फिगरेशन व्यवस्थापनाची आवश्यकता होती आणि असेल. आव्हान हे आहे की लॉन्च_कॉन्फिगरेशनमध्ये वापरकर्ता डेटा आहे. आणि तिथे तुम्ही Ansible वगैरे खेचता. मला सर्वात जास्त आवडणारा हा मानक फरक आहे.

जर आपण सुंदर पायाभूत सुविधांबद्दल बोलत आहोत, तर पॅकर सारख्या उपयुक्तता आहेत ज्या ही प्रतिमा संकलित करतात. आणि नंतर टेराफॉर्म ही प्रतिमा शोधण्यासाठी आणि तिचे लॉन्च_कॉन्फिगरेशन अपडेट करण्यासाठी डेटा स्रोत वापरते. म्हणजेच, अशा प्रकारे पाइपलाइन अशी आहे की आपण प्रथम ट्रॅकर खेचतो, नंतर टेराफॉर्म ओढतो. आणि जर बिल्ड झाला तर नवीन बदल घडतो.

नमस्कार! अहवालाबद्दल धन्यवाद! माझे नाव मिशा, आरबीएस कंपनी आहे. संसाधन तयार करताना तुम्ही प्रोव्हिजनरद्वारे Ansible ला कॉल करू शकता. Ansible मध्ये डायनॅमिक इन्व्हेंटरी नावाचा विषय देखील आहे. आणि तुम्ही प्रथम टेराफॉर्मला कॉल करू शकता आणि नंतर अॅन्सिबलला कॉल करू शकता, जे राज्याकडून संसाधने घेईल आणि ते कार्यान्वित करेल. काय चांगले आहे?

लोक दोन्ही समान यशाने वापरतात. मला असे वाटते की अॅन्सिबलमधील डायनॅमिक इन्व्हेंटरी ही एक सोयीची गोष्ट आहे, जर आपण ऑटोस्केलिंग गटाबद्दल बोलत नाही. कारण ऑटोस्केलिंग ग्रुपमध्ये आमच्याकडे आधीच आमचे स्वतःचे टूलकिट आहे, ज्याला लॉन्च_कॉन्फिगरेशन म्हणतात. लॉन्च_कॉन्फिगरेशनमध्ये आम्ही नवीन संसाधन तयार केल्यावर लॉन्च करणे आवश्यक असलेल्या प्रत्येक गोष्टीची नोंद करतो. म्हणून, Amazon सह, डायनॅमिक इन्व्हेंटरी वापरणे आणि Terraform ts फाईल वाचणे, माझ्या मते, ओव्हरकिल आहे. आणि जर तुम्ही इतर साधने वापरत असाल जिथे "ऑटोस्केलिंग ग्रुप" ची संकल्पना नाही, उदाहरणार्थ, तुम्ही DigitalOcean किंवा इतर काही प्रदाता वापरता जेथे ऑटोस्केलिंग गट नाही, तर तेथे तुम्हाला स्वतः API खेचणे, IP पत्ते शोधणे, तयार करणे आवश्यक आहे. डायनॅमिक इन्व्हेंटरी फाइल , आणि Ansible आधीच त्यातून भटकत राहील. म्हणजेच, Amazon साठी लॉन्च_कॉन्फिगरेशन आहे आणि इतर सर्व गोष्टींसाठी डायनॅमिक इन्व्हेंटरी आहे.

स्त्रोत: www.habr.com