अराजकता और मैनुअल दिनचर्या से निपटने के लिए टेराफॉर्म में पैटर्न। मैक्सिम कोस्ट्रिकिन (इक्सटेन्स)

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

बड़ी और लंबी परियोजनाओं पर अराजकता और मैनुअल दिनचर्या से निपटने के लिए टेराफॉर्म में पैटर्न के बारे में मेरी रिपोर्ट।

वीडियो:

मैं 40 वर्ष का हूं, मैं 20 वर्षों से आईटी में हूं। मैं 12 वर्षों से Ixtens के लिए काम कर रहा हूँ। हम ईकॉमर्स-संचालित-विकास में लगे हुए हैं। और मैं 5 वर्षों से DevOps प्रथाओं का अभ्यास कर रहा हूं।

मेरी कहानी एक कंपनी में एक परियोजना में मेरे अनुभव के बारे में होगी जिसका नाम मैं नहीं बताऊंगा, एक गैर-प्रकटीकरण समझौते के पीछे छिपा हुआ।

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

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

मैटवे को धन्यवाद, जिन्होंने कल हमें बताया कि डोडो पिज़्ज़ा में क्या हुआ था। 4 साल पहले यहां यही हुआ था.

डेवलपर्स आए और इंफ्रास्ट्रक्चर कोड बनाना शुरू कर दिया।

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

टेराफॉर्म हाशीकॉर्प का एक ओपन सोर्स प्रोजेक्ट है। और जो लोग यह भी नहीं जानते कि यह क्या है, उनके लिए अगली कुछ स्लाइड्स।

कोड के रूप में इन्फ्रास्ट्रक्चर का मतलब है कि हम अपने इन्फ्रास्ट्रक्चर का वर्णन कर सकते हैं और कुछ रोबोटों से यह सुनिश्चित करने के लिए कह सकते हैं कि हमें वे संसाधन प्राप्त हों जिनका हमने वर्णन किया है।

उदाहरण के लिए, हमें एक वर्चुअल मशीन की आवश्यकता है। हम कई आवश्यक मापदंडों का वर्णन करेंगे और जोड़ेंगे।

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

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

आगे हमारा प्रोजेक्ट विकसित हो रहा है। हम वहां कुछ बदलाव जोड़ रहे हैं. हम और उदाहरण मांगते हैं, हम 53 प्रविष्टियाँ जोड़ते हैं।

और हम दोहराते हैं. कृपया योजना बनाएं. हम देखते हैं कि क्या बदलाव की योजना है। हम आवेदन करते हैं. और इसी तरह हमारा बुनियादी ढांचा बढ़ता है।

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

ये राज्य फ़ाइलें मूलतः केवल फ़ाइलें थीं। और हमने उन्हें Git में संग्रहीत किया, जो बेहद असुविधाजनक था। कोई न कोई हमेशा परिवर्तन करना भूल जाता है, और कई संघर्ष उत्पन्न हो जाते हैं।

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

हमारा बुनियादी ढांचा बढ़ रहा है। यहाँ हमारा कोड है. और अब हम केवल एक वर्चुअल मशीन नहीं बनाना चाहते, हम एक परीक्षण वातावरण बनाना चाहते हैं।

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

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

उत्पादन के लिए, हम वहां कुछ बदलाव भेज सकते हैं, क्योंकि परीक्षण में हमें बड़े उदाहरणों की आवश्यकता नहीं है; उत्पादन में, बड़े उदाहरण ही उपयोगी होते हैं।

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

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

संसाधनों की एक विस्तृत लाइब्रेरी होने के कारण, आप परीक्षण और उत्पादन में लगभग समान चीज़ कह सकते हैं।

В нашем случае это не совсем подходило, потому что тестовый стек для разработчиков или для тестирования нужно было получать как-то попроще. А ходить по папочкам и применять в нужной последовательности, и беспокоиться о том, что база поднимется, а потом поднимется instance, который использует эту базу, не хотелось. Поэтому весь тестинг запускался из одной папки. Там вызывались те же самые модули, но проходило все за один прогон.

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

इसके अलावा, मंच बहुत बड़ा है. और एक परीक्षण स्टैक लॉन्च करना, भले ही एक घंटे के लिए, भले ही 8 घंटे के लिए, काफी महंगा उपक्रम है।

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

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

और फिर कुछ अन्य चरण भी थे जिन पर मैं नहीं जाना चाहता।

Из-за того, что для тестинга нам требовалось немножко больше опций, чем в production, нам приходилось делать копии модулей, чтобы в этих копиях можно было добавить те фичи, которые нужны только в тестинге.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

मुझे डेटा कहां मिल सकता है? JSON फ़ाइल. टेराफॉर्म आपको न केवल एचसीएल (हाशीकॉर्प कॉन्फ़िगरेशन लैंग्वेज) में, बल्कि JSON में भी बुनियादी ढांचा लिखने की अनुमति देता है।

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

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

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

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

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

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

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

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

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

तदनुसार, परीक्षण को गति देने के लिए, हम समानांतर का उपयोग करके समानांतर में कई प्रक्रियाएं चलाते हैं।

पैरेलल बहुत बढ़िया चीज़ है, इसका प्रयोग करें।

लेकिन हर बार जब टेराफॉर्म आरंभ होता है, तो यह हाशीकॉर्प के पास जाता है और पूछता है, “नवीनतम प्लगइन संस्करण क्या हैं? और मेरे पास कैश में जो प्लगइन है - क्या वह सही है या गलत है? और यह हर कदम पर धीमा होता गया.

यदि आप टेराफ़ॉर्म को बताते हैं कि प्लगइन्स कहाँ हैं, तो टेराफ़ॉर्म कहेगा: “ठीक है, यह संभवतः नवीनतम चीज़ है जो वहाँ है। मैं कहीं नहीं जाऊंगा, मैं तुरंत आपके टेराफॉर्म कोड को सत्यापित करना शुरू कर दूंगा।

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

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

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

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

टेराफ़ॉर्म योजनाएँ अनुरोध पर बनाई जानी चाहिए। कम से कम हम तो यही करते हैं।

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

योजना काफी महँगी चीज़ है. इसमें समय लगता है क्योंकि टेराफॉर्म अमेज़ॅन के पास जाता है और पूछता है, “क्या यह उदाहरण अभी भी मौजूद है? क्या इस ऑटोस्केल में बिल्कुल समान पैरामीटर हैं?" और इसे तेज़ करने के लिए, आप रिफ्रेश=गलत जैसे पैरामीटर का उपयोग कर सकते हैं। इसका मतलब है कि टेराफॉर्म S3 से स्टेट डाउनलोड करेगा। और यह विश्वास करेगा कि राज्य अमेज़ॅन में जो है उससे बिल्कुल मेल खाएगा।

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

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

अगली चीज़ जिसके बारे में मैं बात करना चाहूँगा वह है उपयोगकर्ता-डेटा परीक्षण।

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

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

और यदि आप इस पर ध्यान नहीं देते हैं, तो कुछ टूटी हुई टेक्स्ट फ़ाइल अमेज़ॅन पर, वास्तविक बुनियादी ढांचे पर समाप्त हो सकती है।

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

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

अगली चीज़ जिसके बारे में मैं बात करना चाहूँगा वह है ऑटोमेट टेराफ़ॉर्म अप्लाई।

बेशक, टेराफॉर्म को स्वचालित मोड में लागू करना काफी डरावना है, क्योंकि कौन जानता है कि वहां क्या बदलाव आए हैं और वे रहने वाले बुनियादी ढांचे के लिए कितने विनाशकारी हो सकते हैं।

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

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

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

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

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

और इसे पढ़ना बहुत कठिन है. इसकी समीक्षा करना बहुत कठिन है. और बहुत बार यह पता चलता है कि कुछ मापदंडों की समीक्षा की जाती है और वे बिल्कुल वैसे नहीं हैं जिनकी आवश्यकता है। और इसे बाद में ठीक करने में समय और पैसा खर्च होता है।

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

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

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

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

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

चलो संक्षेप:

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

• अपरिवर्तनीय बुनियादी ढाँचा। एएमआई डिलीवरी तय समय पर।
• रूट53 के लिए संरचना जब आपके पास बहुत सारी प्रविष्टियाँ हों और आप चाहते हों कि वे एक सुसंगत क्रम में हों।
• एपीआई दर सीमा से लड़ना। तभी अमेज़न कहता है, "बस, मैं और अनुरोध स्वीकार नहीं कर सकता, कृपया प्रतीक्षा करें।" और कार्यालय का आधा हिस्सा तब तक इंतजार कर रहा है जब तक वह अपना बुनियादी ढांचा लॉन्च नहीं कर लेता।
• स्पॉट उदाहरण. अमेज़ॅन कोई सस्ता आयोजन नहीं है और स्पॉट आपको काफी बचत करने की अनुमति देता है। और वहां आप इसके बारे में पूरी रिपोर्ट बता सकते हैं.
• सुरक्षा और आईएएम भूमिकाएँ।
• खोए हुए संसाधनों की खोज करते समय, जब आपके पास अमेज़ॅन में अज्ञात उत्पत्ति के उदाहरण होते हैं, तो वे पैसे खाते हैं। भले ही उदाहरणों की लागत $100-150 प्रति माह हो, यह प्रति वर्ष $1 से अधिक है। ऐसे संसाधन ढूँढना एक लाभदायक व्यवसाय है।
• और आरक्षित उदाहरण.

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

सवाल

रिपोर्ट के लिए धन्यवाद! आपकी स्टेट फ़ाइल S3 में है, लेकिन आप इस समस्या का समाधान कैसे करेंगे कि कई लोग इस स्टेट फ़ाइल को ले सकते हैं और विस्तार करने का प्रयास कर सकते हैं?

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

क्या आप ओपन सोर्स या एंटरप्राइज़ का उपयोग कर रहे हैं?

कोई उद्यम नहीं, यानी सब कुछ आप जा सकते हैं और मुफ्त में डाउनलोड कर सकते हैं।

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

समय सीमित था. अच्छी बात।

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

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

स्थानीय मूल्यों के संबंध में, आइए कमरे के बाहर बातचीत जारी रखें।

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

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

क्या आपने jsonnet के बारे में कुछ सुना है?

नहीं.

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

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

सिर्फ देखो। धन्यवाद!

मेरा नाम मैक्सिम है, मैं सर्बैंक से हूं। आपने इस बारे में थोड़ी बात की कि आप टेराफ़ॉर्म को एक प्रोग्रामिंग भाषा के समकक्ष कैसे लाने का प्रयास कर रहे हैं। क्या Ansible का उपयोग करना आसान नहीं है?

ये बहुत अलग चीजें हैं. आप Ansible में संसाधन बना सकते हैं, और पपेट Amazon में संसाधन बना सकते हैं। लेकिन टेराफ़ॉर्म को सीधे तौर पर तेज़ किया जाता है।

क्या आपके पास केवल अमेज़न है?

ऐसा नहीं है कि हमारे पास केवल अमेज़न है। हमारे पास लगभग केवल अमेज़न है। लेकिन मुख्य विशेषता यह है कि टेराफॉर्म याद रखता है। अन्सिबल में, यदि आप कहते हैं: "मुझे 5 बार दीजिए," तो यह बढ़ जाएगा, और फिर आप कहते हैं: "और अब मुझे 3 चाहिए।" और टेराफॉर्म कहेगा: "ठीक है, मैं 2 को मार डालूँगा," और एन्सिबल कहेगा: "ठीक है, यहाँ तुम्हारे लिए 3 हैं।" कुल 8.

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

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

सवाल ये है. आप रिमोट बैकएंड का उपयोग करते हैं, आप एस 3 का उपयोग करते हैं। आप आधिकारिक बैकएंड का उपयोग क्यों नहीं करते?

अधिकारी?

टेराफॉर्म बादल.

वह कब प्रकट हुआ?

लगभग 4 महीने पहले।

अगर यह 4 साल पहले सामने आया होता तो शायद मैं आपके सवाल का जवाब दे चुका होता।

इसमें पहले से ही एक अंतर्निहित फ़ंक्शन और लॉक मौजूद है, और आप एक स्टेट फ़ाइल संग्रहीत कर सकते हैं। इसे आज़माइए। लेकिन मैंने इसका परीक्षण भी नहीं किया है.

हम एक बड़ी ट्रेन में यात्रा कर रहे हैं जो तेज़ गति से चल रही है। और आप बस कुछ कारें लेकर उन्हें फेंक नहीं सकते।

आपने बर्फ के टुकड़ों के बारे में बात की, आपने शाखा का उपयोग क्यों नहीं किया? यह उस तरह से काम क्यों नहीं किया?

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

तो यह काम नहीं करता?

यह बिल्कुल काम नहीं करता.

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

नमस्ते! मेरा नाम युरा है! रिपोर्ट के लिए धन्यवाद! मॉड्यूल के बारे में प्रश्न. आप कहते हैं कि आप मॉड्यूल का उपयोग कर रहे हैं। यदि एक मॉड्यूल में परिवर्तन किए गए हैं जो किसी अन्य व्यक्ति के परिवर्तन के साथ संगत नहीं हैं तो आप समस्या का समाधान कैसे करेंगे? क्या आप किसी तरह मॉड्यूल का संस्करण बना रहे हैं या दो आवश्यकताओं को पूरा करने के लिए वंडरवफ़ल लाने की कोशिश कर रहे हैं?

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

यानि अभी तक इसका समाधान नहीं हो पाया है?

आप सार्वभौमिक मॉड्यूल बनाते हैं. बर्फ के टुकड़ों से बचें. और सब कुछ ठीक हो जाएगा. रिपोर्ट का दूसरा भाग इस बारे में है कि इससे कैसे बचा जाए.

नमस्ते! रिपोर्ट के लिए धन्यवाद! मैं स्पष्ट करना चाहूंगा. पर्दे के पीछे एक बड़ा ढेर था जिसके लिए मैं आया था। कठपुतली और भूमिका वितरण कैसे एकीकृत हैं?

उपयोगकर्ता का डेटा।

यानी, आप बस फ़ाइल को थूक दें और किसी तरह उसे निष्पादित करें?

उपयोगकर्ता-डेटा एक नोट है, यानी जब हम छवि का क्लोन बनाते हैं, तो डेमन वहां उठता है और यह पता लगाने की कोशिश करता है कि वह कौन है, नोट पढ़ता है कि वह एक लोड बैलेंसर है।

यानी क्या यह किसी तरह की अलग प्रक्रिया है जो दी गई है?

हमने इसका आविष्कार नहीं किया. हम इसका उपयोग करते हैं।

नमस्ते! मेरा बस उपयोगकर्ता-डेटा के बारे में एक प्रश्न है। आपने कहा कि वहाँ समस्याएँ हैं, हो सकता है कोई ग़लत जगह कुछ भेज दे। क्या उपयोगकर्ता-डेटा को उसी Git में संग्रहीत करने का कोई तरीका है, ताकि यह हमेशा स्पष्ट रहे कि उपयोगकर्ता-डेटा क्या संदर्भित करता है?

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

यह पता चला है कि परीक्षण करना ही एकमात्र समाधान है?

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

मेरा नाम तैमुर है. यह बहुत अच्छा है कि टेराफ़ॉर्म को ठीक से व्यवस्थित करने के तरीके पर रिपोर्टें हैं।

मैंने तो शुरुआत भी नहीं की है.

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

यानी, क्या मुझे यहां लिखना चाहिए (स्लाइड: प्रोडक्शन/एनवायरमेंट/सेटिंग्स.टीएफ): डोमेन = वेरिएबल, डोमेन वीपीसीनेटवर्क, वेरिएबल वीपीसीनेटवर्क और स्टवार्स - क्या मुझे वही चीज़ मिल सकती है?

हम बिल्कुल यही करते हैं। उदाहरण के लिए, हम सेटिंग सोर्स मॉड्यूल का संदर्भ लेते हैं।

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

क्या सब कुछ एक ही स्थान पर होना संभव है?

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

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

चाबियों के साथ, लेकिन हां, बुनियादी ढांचे का कुछ हिस्सा इस चीज से प्रभावित होता है, यानी टेराफॉर्म कुछ भी नहीं बदल सकता है। हम अपने हाथों से भी कुछ नहीं बदल सकते। हम अभी इसके साथ रहेंगे।

यानी, आपने कुछ इस तरह का सामना किया है, लेकिन कुछ भी लेकर नहीं आए हैं कि वह यह कैसे करता है और खुद करता है?

दुर्भाग्य से हाँ।

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

जो उदाहरण हमारे लिए बहुत महत्वपूर्ण होते हैं, हम उन्हें खूबसूरती से नाम देते हैं। जिनकी आवश्यकता नहीं है, वहां एक नोट है कि यह एक ऑटोस्केल समूह है। और सैद्धांतिक रूप से आप इसे ख़त्म कर सकते हैं और एक नया प्राप्त कर सकते हैं।

जहाँ तक टैग की समस्या की बात है तो ऐसी कोई समस्या नहीं है, लेकिन ऐसा एक कार्य है। और हम टैग का उपयोग बहुत अधिक मात्रा में करते हैं, क्योंकि बुनियादी ढांचा बड़ा और महंगा है। और हमें यह देखने की ज़रूरत है कि पैसा कहां जा रहा है, इसलिए टैग हमें यह बताने की अनुमति देते हैं कि क्या कहां गया। और, तदनुसार, किसी चीज़ की खोज यानी कि यहां बहुत सारा पैसा खर्च किया जाता है।

प्रश्न और किस बारे में था?

जब एसजी सैकड़ों उदाहरण बनाता है, तो क्या उन्हें किसी तरह अलग करने की आवश्यकता है?

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

यानी, क्या आप विशेष रूप से आईपी पर ध्यान केंद्रित कर रहे हैं, होस्ट नाम पर नहीं?

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

नमस्ते! मुझे एहसास हुआ कि टेराफॉर्म एक अच्छी चीज़ है, जिसे बादलों के लिए तैयार किया गया है।

ही नहीं।

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

Ansible कुछ और ही चीज़ के बारे में है। यानी, इंस्टेंस शुरू होने पर Ansible पहले से ही काम करता है। और टेराफॉर्म इंस्टेंस शुरू होने से पहले काम करता है। बेयर मेटल पर स्विच करना - नहीं।

Сейчас нет, а придет бизнес и скажет: «Давай».

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

प्रारंभ में, कार्य निर्धारित किया गया था कि हमारा पूरा बुनियादी ढांचा अज्ञेयवादी था, यानी कोई भी बादल उपयुक्त होना चाहिए, लेकिन कुछ बिंदु पर व्यवसाय ने हार मान ली और कहा: "ठीक है, अगले एन वर्षों में हम कहीं भी नहीं जाएंगे, हम सेवाओं का उपयोग कर सकते हैं अमेज़ॅन से "

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

Спасибо за доклад! Я уже тоже 4 года кручу Terraform. На этапе плавного перехода к Terraform, к инфраструктуре, к декларативному описанию, мы сталкивались с ситуацией, когда кто-то что-то делал руками, а ты пытался сделать plan. И получал там какую-то ошибку. Как вы такие проблемы разбираете? Как находите потерянные ресурсы, которые были указаны?

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

यदि कोई त्रुटि हो तो क्या आप रोलबैक करते हैं? क्या आपने ऐसा करने का प्रयास किया है?

नहीं, यह उस समय व्यक्ति का निर्णय होता है जब उसे कोई समस्या दिखाई देती है।

स्रोत: www.habr.com