सतत मेघ अवसंरचना

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


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

तो, चलिए कुछ महत्वपूर्ण निष्कर्षों के साथ शुरू करते हैं।

लंबे समय से चल रहा सर्वर बेकार है

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

अपरिवर्तनीय अवसंरचना

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

डिस्पोजेबल इन्फ्रास्ट्रक्चर

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

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

मैं एक उपमा दूंगा। खेत की गायों को आमतौर पर पालतू जानवर नहीं माना जाता है।



जब आपके पास खेत पर मवेशी होते हैं, तो आप उन्हें अलग-अलग नाम नहीं देते हैं। प्रत्येक व्यक्ति का एक नंबर और एक टैग होता है। तो यह सर्वर के साथ है। यदि आपने 2006 में उत्पादन में मैन्युअल रूप से सर्वर बनाए हैं, तो उनके पास महत्वपूर्ण नाम हैं, उदाहरण के लिए, "SQL डेटाबेस ऑन प्रोडक्शन 01"। और उनका एक बहुत विशिष्ट अर्थ है। और अगर सर्वर में से एक क्रैश हो जाता है, तो नरक शुरू होता है।

यदि झुंड में जानवरों में से एक मर जाता है, तो किसान बस एक नया खरीदता है। यह "वन-टाइम इन्फ्रास्ट्रक्चर है।"

निरंतर वितरण

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

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

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

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

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

सतत वितरण सिद्धांत और व्यवहार

सतत वितरण के कई सिद्धांत हैं:

• सॉफ़्टवेयर रिलीज़ / परिनियोजन प्रक्रिया को दोहराने योग्य और विश्वसनीय होना चाहिए।
  
• सब कुछ स्वचालित!
  
• यदि कोई प्रक्रिया कठिन या दर्दनाक है, तो इसे अधिक बार करें।
  
• स्रोत नियंत्रण में सब कुछ रखें।
  
• हो गया - का अर्थ है "असंबंधित"।
  
• गुणवत्ता के साथ एकीकृत काम!
  
• रिहाई की प्रक्रिया के लिए हर कोई जिम्मेदार है।
  
• निरंतरता बढ़ाएं।
  

लेकिन इससे भी महत्वपूर्ण बात यह है कि निरंतर वितरण के चार अभ्यास हैं। उन्हें ले जाएं और बुनियादी ढांचे में सीधे स्थानांतरित करें:

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

क्या किसी ने पुस्तक को निरंतर वितरण पढ़ा है?



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

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



Terraform प्रदाताओं के साथ बातचीत का समर्थन करता है। प्रदाता बादल, सास सेवा आदि हैं।

प्रत्येक क्लाउड सेवा प्रदाता के भीतर, कई संसाधन हैं, जैसे कि सबनेट, वीपीसी, लोड बैलेंसर, आदि। डीएसएल (डोमेन-विशिष्ट भाषा) का उपयोग करके, आप टेराफॉर्म को बताते हैं कि आपका बुनियादी ढांचा कैसा दिखेगा।

टेराफॉर्म ग्राफ सिद्धांत का उपयोग करता है।



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



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

अभ्यास

एक सिद्धांत पर चर्चा करने की तुलना में एक कोड लिखना बहुत बेहतर है।

मैंने पहले AMI (Amazon Machine Images) बनाई थी। मैं उन्हें बनाने के लिए पैकर का उपयोग करता हूं और आपको यह दिखाने के लिए जा रहा हूं कि यह कैसे करना है।

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

इसलिए, मेरे पास एएमआई है, उनके पास आईडी है। अमेज़ॅन इंटरफ़ेस पर जाकर, हम देखते हैं कि हमारे पास केवल एक एएमआई है और इससे अधिक कुछ नहीं:



मैं आपको दिखा सकता हूं कि इस एएमआई में क्या है। सब कुछ बहुत सरल है।

मेरे पास एक JSON फाइल टेम्प्लेट है:

{ "variables": { "source_ami": "", "region": "", "version": "" }, "builders": [{ "type": "amazon-ebs", "region": "{{user 'region'}}", "source_ami": "{{user 'source_ami'}}", "ssh_pty": true, "instance_type": "t2.micro", "ssh_username": "ubuntu", "ssh_timeout": "5m", "associate_public_ip_address": true, "ami_virtualization_type": "hvm", "ami_name": "application_instance-{{isotime \"2006-01-02-1504\"}}", "tags": { "Version": "{{user 'version'}}" } }], "provisioners": [ { "type": "shell", "start_retry_timeout": "10m", "inline": [ "sudo apt-get update -y", "sudo apt-get install -y ntp nginx" ] }, { "type": "file", "source": "application-files/nginx.conf", "destination": "/tmp/nginx.conf" }, { "type": "file", "source": "application-files/index.html", "destination": "/tmp/index.html" }, { "type": "shell", "start_retry_timeout": "5m", "inline": [ "sudo mkdir -p /usr/share/nginx/html", "sudo mv /tmp/index.html /usr/share/nginx/html/index.html", "sudo mv /tmp/nginx.conf /etc/nginx/nginx.conf", "sudo systemctl enable nginx.service" ] } ] } 

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

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

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

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

make validate

मुझे उत्तर मिलता है कि पैकर टेम्पलेट सफलतापूर्वक सत्यापित किया गया था:



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

मान लीजिए कि डेवलपर ने एएमआई का एक नया संस्करण बनाया है।



मैं आपको अंतर दिखाने के लिए केवल 1.0.0 से 1.0.1 तक फाइलों में संस्करण को ठीक करूंगा:

 <html> <head> <tittle>Welcome to DevOops!</tittle> </head> <body> <h1>Welcome!</h1> <p>Welcome to DevOops!</p> <p>Version: 1.0.1</p> </body> </html> 

मैं कमांड लाइन पर लौटूंगा और एएमआई का निर्माण शुरू करूंगा।
मैं एक ही टीम को चलाना पसंद नहीं करता। मुझे एएमआई फास्ट बनाना पसंद है, इसलिए मैं मेकफाइल्स का उपयोग करता हूं। आइए मेरे श्रृंगार में cat साथ एक नज़र डालें:

cat Makefile




यह मेरा मेकअप है। मैंने सहायता भी प्रदान की: मैं टैब टाइप और क्लिक करता हूं, और यह मुझे सभी लक्ष्य दिखाता है।



इसलिए, हम एक नया एएमआई संस्करण 1.0.1 बनाने जा रहे हैं।

make ami




वापस टेराफॉर्म में।

मैं इस बात पर जोर देता हूं कि यह उत्पादन कोड नहीं है। यह एक प्रदर्शन है। एक ही काम को बेहतर तरीके से करने के तरीके हैं।

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

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




यहाँ मैं AWS संसाधन और VPC मॉड्यूल बनाने जा रहा हूँ। यहाँ क्या हो रहा है? शीर्ष-स्तरीय cidr_block लें और तीन निजी सबनेट और तीन सार्वजनिक सबनेट बनाएं। निम्नलिखित acidity_zones की एक सूची है। लेकिन हमें नहीं पता कि ये एक्सेसिबिलिटी जोन क्या हैं।



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





फिर हम एक application_tier बनाते application_tier , जो एक ऑटो स्केलिंग समूह है - एक लोड बैलेंसर। कुछ स्टार्टअप कॉन्फ़िगरेशन AMI-ID पर आधारित है, और यह कई सबनेट और उपलब्धता क्षेत्रों को जोड़ता है, और SSH कुंजी का भी उपयोग करता है।
आइए एक सेकंड में इस पर वापस आते हैं।

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

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

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



हम देखते हैं कि पैकर किया जाता है और हमारे पास एक नया एएमआई है।
मैं अमेज़ॅन पर वापस जाता हूं, पृष्ठ को ताज़ा करता हूं और एक दूसरा एएमआई देखता हूं।



वापस टेराफॉर्म में।

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



प्रदाता लोड किए गए। हम आगे बढ़ने के लिए तैयार हैं।
अगला हमें terraform get करने के लिए निष्पादित terraform get - आवश्यक मॉड्यूल लोड करें। वे अब मेरी स्थानीय मशीन पर हैं। इसलिए Terraform को स्थानीय स्तर पर सभी मॉड्यूल मिलेंगे। सामान्य तौर पर, मॉड्यूल GitHub या अन्य जगहों पर अपने स्वयं के भंडार में संग्रहीत किया जा सकता है। यही कारण है कि मैंने वीपीसी मॉड्यूल के बारे में बात की। आप परिवर्तन करने के लिए नेटवर्क टीम को एक्सेस दे सकते हैं। और यह उनके साथ काम करने के लिए विकास टीम के लिए एपीआई है। वास्तव में सहायक है।

अगला कदम एक ग्राफ बनाना है।

से शुरू करें

terraform plan




Terraform वर्तमान स्थानीय स्थिति को ले जाएगा और AWS खाते के साथ तुलना करेगा, जो मतभेदों का संकेत देगा। हमारे मामले में, वह 35 नए संसाधन बनाएगा।



अब हम परिवर्तन लागू करते हैं:

terraform apply


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

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

इसलिए, मेरे लिए बुनियादी ढांचा बनाया गया है।



टेराफॉर्म एक ग्राफ बना सकता है:

terraform graph


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

ग्राफ एक JSON सूची होगी जिसे PNG या DOC फ़ाइल में सहेजा जा सकता है।

वापस टेराफॉर्म में। हम वास्तव में एक ऑटो स्केलिंग समूह बना रहे हैं।



ऑटो स्केलिंग समूह की क्षमता 3 है।



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

इसलिए, हमारे पास कुछ बुनियादी सुविधाएं हैं:



मैं अपना बहुत ही गुप्त वीपीएन दर्ज करता हूं (अपने वीपीएन को क्रैक न करें)।

यहां सबसे महत्वपूर्ण बात यह है कि हमारे पास आवेदन के तीन उदाहरण हैं। सच है, मुझे यह नोट करना चाहिए कि एप्लिकेशन का कौन सा संस्करण उन पर चल रहा है। यह बहुत महत्वपूर्ण है।


वीपीएन के पीछे वास्तव में सब कुछ है:



अगर मैं इसे ( application-elb-1069500747.eu-west-1.elb.amazonaws.com ) लेता हूं और इसे ब्राउज़र के एड्रेस बार में पेस्ट करता हूं, तो मुझे निम्नलिखित मिलते हैं:



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

 filter { name = "tag:Version" values = ["1.0.1"] } 

जाहिर है, CI उपकरण आपको सही संस्करण बनाने के लिए सुनिश्चित करेंगे।
मैं कोई मैनुअल अद्यतन ध्यान दें! हम अपूर्ण हैं, हम गलतियाँ करते हैं, और हम मैन्युअल रूप से अपडेट करते समय 1.0.1 के बजाय 1.0.6 संस्करण डाल सकते हैं।

 filter { name = "tag:Version" values = ["1.0.6"] } 

लेकिन हमारे संस्करण (1.0.1) पर चलते हैं।

terraform plan


टेराफॉर्म अपडेट स्थिति:





तो, इस समय वह मुझे बताता है कि वह लॉन्च कॉन्फ़िगरेशन में संस्करण को बदलने जा रहा है। पहचानकर्ता में परिवर्तन के कारण, यह कॉन्फ़िगरेशन को फिर से शुरू करने के लिए मजबूर करेगा, और ऑटो स्केलिंग समूह बदल जाएगा (नए लॉन्च कॉन्फ़िगरेशन को सक्षम करने के लिए यह आवश्यक है)।

इससे रनिंग इंस्टेंस में बदलाव नहीं होता है। यह वास्तव में महत्वपूर्ण है। आप इस प्रक्रिया का पालन कर सकते हैं और उत्पादन में उदाहरणों को बदले बिना इसका परीक्षण कर सकते हैं।

नोट: पुराने को नष्ट करने से पहले आपको हमेशा एक नया लॉन्च कॉन्फ़िगरेशन बनाना होगा, अन्यथा एक त्रुटि होगी।

आइए परिवर्तन लागू करें:

terraform apply


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



अमेज़ॅन गारंटी देता है कि अगर हम सेवा के तीन उदाहरण चलाना चाहते हैं, तो वे वास्तव में लॉन्च किए जाएंगे। यही कारण है कि हम उन्हें पैसे देते हैं।

चलिए प्रयोगों पर चलते हैं।

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

तो, उदाहरणों में से एक को हटा दें:





जब यह बन्द हो जाता है तो ऑटो स्केलिंग समूह में क्या होगा? इसके स्थान पर एक नया उदाहरण दिखाई देगा।



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

यहां सब कुछ और भी दिलचस्प हो जाता है। जैसा कि मैं दिखाता हूं, सीआई स्क्रिप्ट और टूल के साथ क्यों नहीं, और मैन्युअल रूप से नहीं? ऐसे उपकरण हैं जो ऐसा कर सकते हैं, जैसे GitHub पर उत्कृष्ट AWS-लापता-उपकरण।



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

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

इस तरह की नियंत्रण स्क्रिप्ट आपको निश्चित बग और सुरक्षा अपडेट के साथ हमेशा नवीनतम संस्करण रखने की अनुमति देती है।

आप स्क्रिप्ट को केवल चलाकर उपयोग कर सकते हैं:

aws-ha-relesae.sh -a my-scaling-group


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

अमेज़न पर वापस। हमारे पास एक नया उदाहरण है:



ब्राउज़र में पृष्ठ को अपडेट करने के बाद, जहाँ हमने पहले संस्करण 1.0.0 देखा था, हमें यह मिलता है:



दिलचस्प बात यह है कि चूंकि हमने एएमआई निर्माण स्क्रिप्ट बनाई है, इसलिए हम एएमआई के निर्माण का परीक्षण कर सकते हैं।

कुछ महान उपकरण हैं, जैसे कि सर्वरस्क्रिप्ट या सर्वरपेक।

Serverspec आपको यह जांचने के लिए रूबी-शैली विनिर्देश बनाने की अनुमति देता है कि आपका एप्लिकेशन सर्वर कैसा दिखता है। उदाहरण के लिए, नीचे मैं एक परीक्षण देता हूं जो यह जांचता है कि सर्वर पर nginx स्थापित है।

 require 'spec_helper' describe package('nginx') do it { should be_installed } end describe service('nginx') do it { sould be_enabled } it { sould be_running } end describe port(80) do it { should be_listening } end 

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

एक निष्कर्ष के बजाय

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

और उसने सवाल पूछा: आपके संगठन को कोड की एक पंक्ति से जुड़े परिवर्तनों को तैनात करने में कितना समय लगेगा? क्या आप इस प्रक्रिया को विश्वसनीय और दोहराने योग्य बना सकते हैं?

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

मैंने ओपनटेबल नामक कंपनी के लिए काम किया। इसमें, हमने इसे चक्र की अवधि कहा। और ओपनटेबल में वह सात सप्ताह की थी। और यह अपेक्षाकृत अच्छा है। मुझे पता है कि उत्पादन के लिए एक कोड भेजने में कंपनियों को महीनों लग जाते हैं। ओपनटेबल में, हमने चार वर्षों के लिए प्रक्रिया की समीक्षा की। इसमें बहुत समय लगा, क्योंकि संगठन बड़ा है - 200 लोग। और हमने चक्र का समय घटाकर तीन मिनट कर दिया। यह हमारे परिवर्तनों के प्रभाव के मापन के लिए संभव था।

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

पॉल स्टैक सेंट पीटर्सबर्ग में DevOops 2018 सम्मेलन में "अराजकता के साथ सतत प्रणाली परीक्षण" के साथ आएंगे । पॉल कैओस इंजीनियरिंग पद्धति के बारे में बात करेंगे और यह दिखाएंगे कि वास्तविक परियोजनाओं पर इस पद्धति का उपयोग कैसे करें।