👩🏿‍✈️ 👨🏿‍🔧 ✊🏾 हमने टेराफ़ॉर्म पर बुनियादी ढांचा प्रबंधन कैसे रखा

हमारे पास 4 अमेज़ॅन खाते, 9 वीपीसी और 30 सबसे शक्तिशाली विकास वातावरण, चरण, प्रतिगमन - सभी रंगों और रंगों के 1000 से अधिक ईसी 2 उदाहरण हैं। जब से मैंने व्यवसाय के लिए क्लाउड समाधान एकत्र करना शुरू किया है, मुझे अपने शौक को अंत तक जाने की जरूरत है और सोचें कि यह सब कैसे स्वचालित किया जाए।

नमस्ते! मेरा नाम किरिल काज़रीन है, मैं DINS में इंजीनियर के रूप में काम करता हूँ। हम क्लाउड-आधारित व्यावसायिक संचार समाधान विकसित कर रहे हैं। हमारे काम में, हम सक्रिय रूप से टेराफॉर्म का उपयोग करते हैं, जिसके साथ हम लचीले ढंग से अपने बुनियादी ढांचे का प्रबंधन करते हैं। मैं इस समाधान के साथ अपना अनुभव साझा करूंगा।

लेख लंबा है, इसलिए ~~पॉपकॉर्न~~ चाय पर स्टॉक करें और जाएं!

और एक और अति सूक्ष्म अंतर - लेख 0.11 संस्करण के आधार पर लिखा गया था, ताजा 0.12 में बहुत कुछ बदल गया है लेकिन मुख्य प्रथाओं और युक्तियां अभी भी प्रासंगिक हैं। 0.11 से 0.12 तक प्रवास का मुद्दा एक अलग लेख का हकदार है!

टेराफॉर्म क्या है

टेराफॉर्म एक लोकप्रिय हैशिकॉर्प टूल है जो 2014 में दिखाई दिया था।

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

जब लॉन्च किया जाता है, तो Terraform कोड पढ़ता है और, क्लाउड सेवा प्रदाताओं द्वारा प्रदान किए गए प्लग-इन का उपयोग करके, आवश्यक API कॉल करके आपके अवसंरचना को वर्णित स्थिति में लाता है।

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

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

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

टेराफॉर्म किस चीज से बना है

प्रदाता एक सेवा के एपीआई के साथ काम करने के लिए प्लगइन्स हैं। मैंने उन्हें 100 से अधिक गिना। इनमें Amazon, Google, DigitalOcean, VMware Vsphere, Docker के प्रदाता हैं। मैंने इस आधिकारिक सूची पर एक प्रदाता भी पाया जो आपको सिस्को एएसए के लिए नियमों का प्रबंधन करने की अनुमति देता है!

अन्य बातों के अलावा, आप नियंत्रित कर सकते हैं:

Grafana में डैशबोर्ड, डेटा स्रोत और अलर्ट।
GitHub और GitLab पर परियोजनाएं।
RabbitMQ ।
डेटाबेस, उपयोगकर्ता और MySQL में अधिकार।

और ये केवल आधिकारिक प्रदाता हैं, और भी अनौपचारिक प्रदाता हैं। प्रयोगों के दौरान, मैं GitHub पर एक तृतीय-पक्ष में आया था, आधिकारिक सूची प्रदाता में शामिल नहीं था, जो कि GoDaddy से DNS के साथ-साथ Proxmox संसाधनों के साथ काम करने की अनुमति देता था ।

एक टेराफ़ॉर्म परियोजना के भीतर, आप विभिन्न प्रदाताओं और, विभिन्न सेवा प्रदाताओं या प्रौद्योगिकियों के संसाधनों का उपयोग कर सकते हैं। उदाहरण के लिए, आप GoDaddy से बाहरी DNS के साथ, AWS में अपने बुनियादी ढांचे का प्रबंधन कर सकते हैं। और कल, आपकी कंपनी ने एक स्टार्टअप खरीदा, जो DO या Azure में होस्ट किया गया था। और जब आप इसे AWS में स्थानांतरित करने का निर्णय लेते हैं या नहीं, तो आप उसी टूल के साथ भी इसका समर्थन कर सकते हैं!

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

मॉड्यूल। ये वे इकाइयाँ हैं जिनके साथ टेराफ़ॉर्म आपको अपने कॉन्फ़िगरेशन को टेम्प्लेट करने की अनुमति देता है। इस प्रकार, टेम्पलेट आपको अपना कोड छोटा करने की अनुमति देते हैं, जिससे आप उसका पुन: उपयोग कर सकते हैं। खैर, वे उसके साथ आराम से काम करने में मदद करते हैं।

हमने टेराफॉर्म को क्यों चुना

अपने लिए, हमने 5 मुख्य कारणों की पहचान की। शायद आपके दृष्टिकोण से, उनमें से सभी महत्वपूर्ण नहीं लगेंगे:

टेराफॉर्म एक ~~क्लाउड एग्नॉस्टिक~~ मल्टीपल क्लाउड सपोर्ट यूटिलिटी है (टिप्पणियों में मूल्यवान टिप्पणी के लिए धन्यवाद) । जब हमने इस टूल का चयन किया, तो हमने सोचा: - अगर कल या एक सप्ताह में प्रबंधन हमारे पास आता है और क्या कहता है: " दोस्तों, और हमने सोचा - चलो सिर्फ अमेज़ॅन पर ही तैनात नहीं हैं। हमारे पास किसी तरह का प्रोजेक्ट है। जहां हमें Google क्लाउड में आधारभूत संरचना प्राप्त करने की आवश्यकता होगी। या अज़ुरे में - ठीक है, आप कभी नहीं जानते । " हमने तय किया कि हम एक ऐसा उपकरण लेना चाहेंगे जो किसी भी क्लाउड सेवा से पूरी तरह से जुड़ा हुआ न हो।
खुला स्रोत । टेराफॉर्म एक ओपन सोर्स सॉल्यूशन है । प्रोजेक्ट रिपॉजिटरी की रेटिंग 16 हजार से अधिक सितारों की है, यह प्रोजेक्ट की प्रतिष्ठा की अच्छी पुष्टि है।

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

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

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

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

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

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

Terraform बनाम CloudFormation

नेटवर्क अक्सर Terraform की तुलना CloudFormation से करता है। इसे चुनते समय हमने यह सवाल भी पूछा। और यहाँ हमारी तुलना का परिणाम है।

तुलना	terraform	CloudFormation
मल्टीपल क्लाउड सपोर्ट	विभिन्न प्रदाताओं के उपयोग के माध्यम से, प्लग-इन किसी भी बड़े क्लाउड प्रदाता के साथ काम कर सकता है।	मजबूती से अमेज़न से जुड़ी।
ट्रैकिंग बदलें	यदि आपके पास एक परिवर्तन है टीएफ कोड में नहीं, लेकिन जो संसाधन उसने बनाया है, उस पर टीएफ यह पता लगाने में सक्षम होगा और आपको स्थिति को सही करने की अनुमति देगा	इसी तरह का कार्य दिखाई दिया केवल नवंबर 2018 में ।
स्थिति	केवल स्थितियों के लिए कोई समर्थन नहीं टर्नरी ऑपरेटरों के रूप में)।	शर्तों का समर्थन किया जाता है।
भंडारण राज्यों	आपको कई प्रकार के बैकेंड का चयन करने की अनुमति देता है, उदाहरण के लिए, स्थानीय रूप से आपकी मशीन पर (यह डिफ़ॉल्ट व्यवहार है), एक फ़ाइल साझा पर, S3 और अन्य जगहों पर। यह कभी-कभी उपयोगी होता है क्योंकि Tststate Terraform को JSON जैसी संरचना के साथ एक बड़ी टेक्स्ट फ़ाइल के रूप में प्रस्तुत किया जाता है। और कभी-कभी इसे पाने के लिए कभी-कभी उपयोगी होता है, इसे पढ़ें - और कम से कम इसे बैकअप बनाने में सक्षम हो, क्योंकि आप कभी नहीं जानते कि क्या। व्यक्तिगत रूप से, उदाहरण के लिए, मैं इस तथ्य से शांत हूं कि यह मेरे द्वारा नियंत्रित किसी स्थान पर है।	केवल AWS के अंदर ही भंडारण की स्थिति
संसाधन आयात	Terraform आयात करने के संसाधनों को आसान बनाता है। आप सभी संसाधनों को अपने नियंत्रण में ले सकते हैं। आप बस उस कोड को लिखें जो इस ऑब्जेक्ट को चिह्नित करेगा, या टेराफ़ॉर्मिंग का उपयोग करेगा। वह उसी अमेज़ॅन पर जाती है, वहां से पर्यावरण के बारे में जानकारी लेती है, और फिर उसे कोड के रूप में डंप करती है। यह मशीन-जनरेट किया गया है, अनुकूलित नहीं है, लेकिन माइग्रेशन शुरू करने के लिए यह एक अच्छा पहला कदम है। और फिर आप सिर्फ इम्पोर्ट कमांड दें। टेराफॉर्म तुलना करता है, इस वातावरण को अपने राज्य में लाता है - और अब इसे नियंत्रित करता है।	CloudFormation पता नहीं कैसे। अगर आपने पहले अपने हाथों से कुछ किया है, आप या तो इसे धमाके से उड़ाते हैं और CloudFormation के साथ फिर से बनाते हैं, या रहते हैं। दुर्भाग्य से, कोई विकल्प नहीं।

टेराफॉर्म से कैसे शुरू करें

सामान्यतया, आरंभ करना बहुत सरल है। यहाँ पहले चरण संक्षिप्त हैं:

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

टेराफॉर्म के साथ हमारा अभ्यास

स्रोत कोड

आपने अपनी पहली परियोजना शुरू की और एक बड़ी main.tf फ़ाइल में सब कुछ बचा लिया। यहाँ एक विशिष्ट उदाहरण है (मैंने ईमानदारी से पहला मौका लिया जो मुझे गीताब से मिला)।

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

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

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

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

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

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

कम कोड - पढ़ने में आसान

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

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

कोर रिपॉजिटरी का चयन कई चरणों में होता है।

स्टेज 1 । एक अलग भंडार बनाएँ। इसमें सभी कोड स्टोर करें, अलग-अलग - और उन संस्थाओं का वर्णन करें जिन्हें इस आउटपुट का उपयोग करके तीसरे पक्ष के भंडार में पुन: उपयोग किया जाना चाहिए। मान लें कि हम एक एडब्ल्यूएस सबनेट संसाधन बनाते हैं जिसमें हम वर्णन करते हैं कि यह कहाँ स्थित है, जो उपलब्धता क्षेत्र, पता स्थान।

resource "aws_subnet" "lab_pub1a" { vpc_id = "${aws_vpc.lab.id}" cidr_block = "10.10.10.0/24" Availability_zone = "us-east-1a" ... } output "sn_lab_pub1a-id" { value = "${aws_subnet.lab_pub1a.id}" }

और फिर हम कहते हैं कि हम इस ऑब्जेक्ट की आईडी को आउटपुट में भेजते हैं। आप प्रत्येक पैरामीटर के लिए आउटपुट कर सकते हैं जिसकी आपको आवश्यकता है।

यहाँ क्या चाल है? जब आप किसी मूल्य का वर्णन करते हैं, तो Terraform अलग से tfstate कोर में सहेजता है। और जब आप उसकी ओर मुड़ते हैं, तो उसे सिंक्रनाइज़ करने, पुनरावृत्ति करने की आवश्यकता नहीं होगी - वह इस मामले को तुरंत आपको इस राज्य से देने में सक्षम होगा। आगे, रिपॉजिटरी में, जो गैर-कोर है, आप दूरस्थ राज्य के साथ इस तरह के संबंध का वर्णन करते हैं: आपके पास एक दूरस्थ राज्य है जैसे और, यह एस 3-बाल्टी में निहित है जैसे और, इस तरह के और इस तरह के एक कुंजी और एक क्षेत्र।

स्टेज 2 । एक गैर-कोर परियोजना में, हम कोर परियोजना की स्थिति के लिए एक लिंक बनाते हैं, ताकि हम आउटपुट के माध्यम से निर्यात किए गए मापदंडों का उल्लेख कर सकें।

 data "terraform_remote_state" "lab_core" { backend = "s3" config { bucket = "lab-core-terraform-state" key = "terraform.tfstate" region = "us-east-1" } }

स्टेज 3 । शुरू हो रही है! जब मुझे एक विशिष्ट सबनेट में एक उदाहरण के लिए एक नया नेटवर्क इंटरफ़ेस तैनात करने की आवश्यकता होती है, तो मैं कहता हूं: यहां डेटा दूरस्थ स्थिति है, इसमें इस राज्य का नाम ढूंढें, इसमें यह पैरामीटर ढूंढें, जो वास्तव में, इस नाम से मेल खाता है।

 resource "aws_network_interface" "fwl01" { ... subnet_id = "${data.terraform_remote_state.lab_core.sn_lab_pub1a-id}" }

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

मॉड्यूल

आपको याद दिला दूं कि एक मॉड्यूल एक स्व-निहित कॉन्फ़िगरेशन है जिसमें एक या अधिक संबंधित संसाधन होते हैं। इसे एक समूह के रूप में प्रबंधित किया जाता है:

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

 module "AAA" { source = "..." count = "3" count_offset = "0" host_name_prefix = "XXX-YYY-AAA" ami_id = "${data.terraform_remote_state.lab_core.ami-base-ami_XXXX-id}" subnet_ids = ["${data.terraform_remote_state.lab_core.sn_lab_pub1a-id}", "${data.terraform_remote_state.lab_core.sn_lab_pub1b-id}"] instance_type = "t2.large" sgs_ids = [ "${data.terraform_remote_state.lab_core.sg_ssh_lab-id}", "${aws_security_group.XXX_lab.id}" ] boot_device = {volume_size = "50" volume_type = "gp2"} root_device = {device_name = "/dev/sdb" volume_size = "50" volume_type = "gp2" encrypted = "true"} tags = "${var.gas_tags}" }

उदाहरण के लिए: जब हम एक नया EC2 उदाहरण तैनात करते हैं, तो हम इसके लिए एक नेटवर्क इंटरफ़ेस और अनुलग्नक बनाते हैं, हम अक्सर इसके लिए एक इलास्टिक आईपी एड्रेस बनाते हैं, हम रूट -53 रिकॉर्ड बनाते हैं, और कुछ और। यही है, हमें कम से कम 4 इकाइयाँ मिलती हैं।

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

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

उदाहरण के लिए, कुछ मॉड्यूल हैं जो एक टेम्पलेट को संदर्भित करते हैं। मैं केवल विशिष्ट पैरामीटर पास करता हूं: आईडी सबनेट; एएमआई के साथ तैनात करने के लिए; उदाहरण के प्रकार; सुरक्षा समूह सेटिंग्स; कुछ और, और संकेत करें कि इनमें से कितनी चीजें मुझे करनी हैं। महान, उन्हें ले लिया और उन्हें घुमा दिया!

कल, डेवलपर्स मेरे पास आते हैं और कहते हैं: "सुनो, हम लोड के साथ प्रयोग करना चाहते हैं, कृपया हमें इनमें से दो और दें।" मुझे क्या करने की आवश्यकता है: मैं एक अंक को 5 में बदलता हूं। कोड की मात्रा बिल्कुल समान है।

परंपरागत रूप से, मॉड्यूल को दो प्रकारों में विभाजित किया जा सकता है - संसाधन और बुनियादी ढाँचा। कोड के दृष्टिकोण से, कोई अंतर नहीं है, बल्कि उच्च स्तर की अवधारणाएं हैं जो ऑपरेटर खुद का परिचय देता है।
संसाधन मॉड्यूल संसाधनों का एक मानकीकृत और मानकीकृत, तार्किक रूप से संबंधित संग्रह प्रदान करते हैं। ऊपर दिया गया उदाहरण एक सामान्य संसाधन मॉड्यूल है। उनके साथ कैसे काम करें:

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

हम मॉड्यूल के संस्करण से जुड़े हुए हैं, और हम सिर्फ पिछले एक को लेते हैं - बुनियादी ढांचे को संस्करणबद्ध किया जाना चाहिए (संसाधन संस्करण नहीं किए जा सकते हैं, लेकिन कोड कर सकते हैं)। एक संसाधन को हटाया या बनाया जा सकता है। वह सब है! हमें यह भी स्पष्ट रूप से पता होना चाहिए कि हमने किस संस्करण में प्रत्येक बुनियादी ढांचे का निर्माण किया है।

इन्फ्रास्ट्रक्चर मॉड्यूल काफी सरल हैं। उनके पास संसाधन हैं, और इसमें कंपनी के मानक (उदाहरण के लिए, टैग, मानक मानों की सूची, स्वीकृत चूक और इसी तरह) शामिल हैं।

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

मॉड्यूल का उपयोग करने के लिए सिफारिशें

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

एक अच्छे मॉड्यूल के संकेत (यहां थोड़ा और विस्तृत है ):

अच्छे मॉड्यूल में प्रलेखन और उदाहरण हैं। यदि प्रत्येक को एक अलग भंडार के रूप में डिज़ाइन किया गया है, तो यह करना आसान है।
उनके पास हार्डकोडेड सेटिंग्स नहीं हैं (उदाहरण के लिए, AWS क्षेत्र)।
उचित चूक का उपयोग करें, चूक के रूप में डिज़ाइन किया गया। उदाहरण के लिए, डिफ़ॉल्ट रूप से EC2 उदाहरण के लिए मॉड्यूल आपके लिए टाइप m5d.24xlarge की वर्चुअल मशीन नहीं बनाएगा, यह इसके लिए न्यूनतम t2 या t3 प्रकारों में से एक का उपयोग करता है।
कोड "साफ" है - संरचित, टिप्पणियों के साथ प्रदान किया गया, अनावश्यक रूप से भ्रमित नहीं, उसी शैली में डिज़ाइन किया गया।
यह अत्यधिक वांछनीय है कि यह परीक्षणों से सुसज्जित है, हालांकि यह मुश्किल है। दुर्भाग्य से, हम अभी तक इस पर नहीं आए हैं।

टैगिंग

टैग महत्वपूर्ण हैं।

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

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

एक उदाहरण:

 variable "XXX_tags" { description = "The set of XXX tags." type = "map" default = { "TerminationDate" = "03.23.2018", "Environment" = "env_name_here", "Department" = "dev", "Subsystem" = "subsystem_name", "Component" = "XXX", "Type" = "application", "Team" = "team_name" } }

ऐसा हुआ कि हमारी कंपनी में हमारी एक से अधिक टीम AWS का उपयोग करती है, और आवश्यक टैग की कुछ सूची है।

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

अब - टैग कैसे करें।

हमने तय किया कि हम प्रत्येक घटक के लिए अपना स्वयं का टैग-मैप करेंगे, जिसमें हम सभी निर्दिष्ट टैग सूचीबद्ध करेंगे: जब इसे समाप्त करना है, तो यह क्या संदर्भित करता है। उन्होंने जल्दी से महसूस किया कि यह असुविधाजनक था। क्योंकि कोड आधार बढ़ रहा है, क्योंकि हमारे पास 30 से अधिक घटक हैं, और कोड के 30 ऐसे टुकड़े असुविधाजनक हैं। अगर आपको कुछ बदलने की जरूरत है, तो आप दौड़ें और बदलें।

अच्छी तरह से टैग करने के लिए, हम लोकल संस्था का उपयोग करते हैं।

 locals { common_tags = {"TerminationDate" = "XX.XX.XXXX", "Environment" = "env_name", "Department" = "dev", "Team" = "team_name"} subsystem_1_tags = "${merge(local.common_tags, map("Subsystem", "subsystem_1_name"))}" subsystem_2_tags = "${merge(local.common_tags, map("Subsystem", "subsystem_2_name"))}" }

इसमें आप एक सबसेट को सूचीबद्ध कर सकते हैं, और फिर उन्हें एक दूसरे के साथ उपयोग कर सकते हैं।

उदाहरण के लिए, हमने ऐसी संरचना में कुछ सामान्य टैग हटा दिए, और फिर उपप्रणालियों द्वारा विशिष्ट। हम कहते हैं: "यह ब्लॉक लें और जोड़ें, उदाहरण के लिए, सबसिस्टम 1. और सबसिस्टम 2 के लिए, सबसिस्टम 2 जोड़ें"। हम कहते हैं: "टैग, कृपया, सामान्य लोगों को ले लो और टाइप, एप्लिकेशन, नाम, घटक और जो उन्हें है, उन्हें जोड़ें।" यह बहुत संक्षेप में, स्पष्ट रूप से और केंद्रीकृत परिवर्तन से निकलता है, अगर अचानक इसकी आवश्यकता होती है।

 module "ZZZ02" { count = 1 count_offset = 1 name = "XXX-YYY-ZZZ" ... tags = "${merge(local.core_tags, map("Type", "application", "Component", "XXX"))}" }

संस्करण नियंत्रण

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

 module "ZZZ02" { source = "./modules/srvroles/ZZZ" name = "XXX-YYY-ZZZ" }

मान लीजिए कि डेवलपर्स आपके पास आए और कहा: "तो, हमें इस तरह के और इस तरह की एक इकाई की आवश्यकता है, जैसे कि हमारे बुनियादी ढांचे में।" आपने इसे लिखा, इसे अपनी परियोजना के भंडार में स्थानीय मॉड्यूल के रूप में बनाया। तैनात - उत्कृष्ट। उन्होंने परीक्षण किया, कहा: “यह होगा! उत्पादन में। " हम मंच पर आते हैं, तनाव परीक्षण, उत्पादन। हर बार Ctrl-C, Ctrl-V; Ctrl-C, Ctrl-V। जब हम बिक्री के लिए आए, तो हमारे सहयोगी ने इसे ले लिया, प्रयोगशाला वातावरण से कोड की नकल की, इसे दूसरी जगह स्थानांतरित कर दिया और इसे वहां बदल दिया। और हम पहले से ही असंगत स्थिति प्राप्त करते हैं। क्षैतिज स्केलिंग के साथ, जब आपके पास जितने प्रयोगशाला वातावरण होते हैं, तो यह सिर्फ एक आदत है।

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

 module "ZZZ" { source = "git::ssh://git@GIT_SERVER_FQDN/terraform/modules/general-vm/2-disks.git" host_name_prefix = "XXX-YYY-ZZZ"

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

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

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

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

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

उपशाखा

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

कहाँ tfstate स्टोर करने के लिए

आपको अपने राज्य को स्थानीय स्तर पर संग्रहीत नहीं करना चाहिए। आपको अपने राज्य को गिट में स्टोर नहीं करना चाहिए।

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

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

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

टेराफॉर्म डायनेमिक्स में जाता है, देखता है - लॉक, बंद हो जाता है, उपयोगकर्ता को बताता है: "क्षमा करें, tfstate को किसी चीज से अवरुद्ध किया गया है।" एक सहकर्मी देखता है कि मैं अभी काम कर रहा हूं, वह मेरे पास आ सकता है और कह सकता है: "सुनो, मेरा परिवर्तक अधिक महत्वपूर्ण है, कृपया मुझे दे दो।" मैं कहता हूं: "अच्छा," मैं योजना को रद्द करता हूं, ब्लॉक को हटाता हूं, बल्कि, यहां तक कि अगर आप इसे सही ढंग से करते हैं, तो Ctrl-C को बाधित किए बिना, इसे स्वचालित रूप से हटा दिया जाता है। एक सहकर्मी जाता है और करता है। इस प्रकार, हम एक स्थिति के खिलाफ खुद का बीमा करते हैं जब आप दो कुछ बदल रहे होते हैं।

मर्ज अनुरोध

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

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

पाइपलाइन

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

मास्टर शाखा के लिए पाइपलाइन (मास्टर पाइपलाइन)
अन्य सभी शाखाओं के लिए पाइपलाइन (शाखा पाइपलाइन)

ब्रंच पाइपलाइन क्या करती है? ( , ). . , merge-request, — , . . .

. , , . Terraform- , , . , merge-request . . . , , , .

, . .

Terraform

. Terraform , , .

, «» — , .

, , count — , , , , availability-. , , , . . , AZ . , count .

, 4 AZ 5 , AZ — 4, , . : « ». ! , . Terraform .

. — . . - - If Else. , — , .

. , , , , Terraform- , CI.

CI . , , , — merge, . .

, . . , , Terraform , , tfstate Terraform : «, , ». , , .

CI, , pipeline — , .

, . , . , target , . , : «Terraform apply target instance», -. - (, - ), .

, . . CI — , Terraform , . , - . , , , . .

Terraform —

Terraform , . , , . , , , . , , , .

, — Tfstate, , . . « , » — .

, -, , - — . , . , — .
Terraform , . Terraform . क्यों? , . . , , AZ - -. , North Virginia, 6 . . , , : «, ». — . — , , Terraform .
Terraform . , — 200 , 198 , 5. . , API . अफसोस।
, . , S3 bucket. , — , - . Terraform – , , : «, - ». . - , .

, Terraform — , . , .

हमने टेराफ़ॉर्म पर बुनियादी ढांचा प्रबंधन कैसे रखा - और जीना शुरू किया