छोटा, हाँ। पटाखे microvirtual का अनबॉक्सिंग

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



यह microvirtualization टूल OpenSource में उपलब्ध है। यदि आपके कार्यों के लिए बहु-किरायेदार अलगाव की आवश्यकता होती है, (ठीक है, उदाहरण के लिए, आप अपने खुद के बादल बनाने का फैसला करते हैं), पटाखा वह है जो आपको चाहिए।

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

अस्वीकरण: नीचे दी गई सब कुछ वसीली की निजी राय है, और यह अमेज़ॅन वेब सेवाओं की स्थिति से मेल नहीं खा सकता है।

सार्वजनिक बादलों की प्राकृतिक विशेषताएं

सार्वजनिक बादलों के मूलभूत गुणों में से एक बहु-किरायेदारी है।

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

एक और संपत्ति जो सार्वजनिक बादलों में निहित है वह उच्च भार है।

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



यह एक निश्चित विरोधाभास को दर्शाता है। एक ओर, हमें उपयोगकर्ताओं को यथासंभव अलग रखना होगा। दूसरी ओर, हमें बहुत उच्च स्तर की उत्पादकता और संसाधन उपयोग सुनिश्चित करना चाहिए। एक को बेहतर बनाने से अक्सर दूसरे की सीमाएं बदल जाती हैं। सभी मोर्चों पर अधिकतम पाने के लिए एक समझौता, और इससे भी बेहतर कैसे खोजें?

वर्चुअल मशीन या कंटेनर?

दो बुनियादी दृष्टिकोण हैं जो संभावित रूप से मदद कर सकते हैं। ये वर्चुअल मशीन और कंटेनर हैं। प्रत्येक के पास इसके पेशेवरों और विपक्ष हैं।



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

• सुरक्षा जब एक वर्चुअल मशीन किसी अन्य मशीन में डेटा तक पहुंचने में सक्षम नहीं होती है;
• संसाधन , जब मैंने 8 जीबी मेमोरी का आदेश दिया, मुझे उम्मीद है कि यह रैम मेरी होगी और कोई भी उस संसाधन का दावा नहीं कर सकता है जिसके लिए मैंने भुगतान किया था।

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



क्या कंटेनरों को असुरक्षित कहा जा सकता है? नहीं, भले ही गंभीर कमजोरियां हों।

मेरा मानना ​​है कि आज एक उचित "वेल्डेड" कंटेनर सुरक्षा का पर्याप्त स्तर प्रदान करता है।

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

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

पटाखा उत्पादन में पहले से ही है। महत्वपूर्ण सेवाओं के एक ही उच्च भार में, उदाहरण के लिए, AWS लैम्ब्डा (सर्वर रहित फ़ंक्शन) और AWS फ़ारगेट (सर्वर रहित कंटेनर)।

पुराने AWS लैम्ब्डा की समस्याएं

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



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

आपने रीसाइक्लिंग की समस्या को कैसे हल किया?

अपने खुद के पटाखे समाधान खरोंच से विकसित। यह रिपोर्ट के शीर्षक से स्पष्ट है :)

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

• केवीएम द्वारा एक पर्यवेक्षक के रूप में संचालित । जो कोई भी AWS के साथ काम करता है वह जानता है कि हमारे दो पसंदीदा हाइपरवाइजर हैं। लीगेसी वीएम एक्सएन पर चलते हैं। 2017 के अंत से, केवीएम सभी कारों के हुड के नीचे रह रहा है।
• यह जितनी जल्दी हो सके शुरू हो जाता है। संदर्भ हार्डवेयर पर, आवश्यकता १२५ एमएस में माइक्रोवर्टिकल का पूर्ण भार थी।
• न्यूनतम वर्चुअलाइजेशन ओवरहेड । संदर्भ वास्तुकला में, एक एकल पटाखा माइक्रो-वर्चुअल मशीन अतिरिक्त रूप से केवल 5 एमबी मेमोरी का उपभोग करती है।
• सबसे घनी शुरुआत की संभावना । डिजाइन पैरामीटर - प्रति सेकंड 5 माइक्रोवर्ट्यूल्स का पूरा भार। यह आवश्यकता AWS लैम्ब्डा जैसी सेवाओं के लिए मूलभूत है। कार्यों को जल्दी से दूर करना होगा, बाहर काम करना और अगले के लिए संसाधनों को मुक्त करना होगा।
• फिर से सदस्यता की संभावना । यह एक अवसर है - इसका उपयोग करना आवश्यक नहीं है। वास्तव में, यह वर्चुअल संसाधनों का आवंटन अधिक से अधिक हद तक शारीरिक रूप से उपलब्ध है। इसका मतलब है कि सर्वर में 16 जीबी रैम है, और आप एक साथ इस पर 4 वर्चुअल मशीन चलाते हैं, जिनमें से प्रत्येक यह सुनिश्चित करता है कि इसमें 8 जीबी मेमोरी है।

हुड के नीचे पटाखे के साथ AWS लाम्बा

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

आधुनिक वास्तुकला कैसा दिखता है?

निम्नतम स्तर पर अब एक आभासी मशीन नहीं है, बल्कि एक भौतिक नंगे-धातु है।

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



लोहे के टुकड़े के ऊपर कर्नेल में KVM मॉड्यूल के साथ होस्ट OS है । अपने स्वयं के अतिथि OS के साथ पटाखे microvirtuals ऊपर लॉन्च किए गए हैं। खैर, उन्होंने पहले ही AWS लाम्बा सेवा के घटकों को लागू कर दिया।

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

बॉक्स में क्या है?

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

डिजाइन सिद्धांतों

जब हमने पहली बार पटाखे के विकास पर चर्चा शुरू की, तो हम दो सिद्धांतों का पालन करने के लिए सहमत हुए।

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

हर चीज से बेखबर होकर एक काम पर ध्यान केंद्रित करें।

जो बचा है, उसे सरल कीजिए। यहां तक ​​कि जो कुछ बचा है वह यथासंभव सरल होना चाहिए।

उन्होंने क्या लिखा था?

पटाखे ट्रेंडी जंग में लिखा है क्योंकि:

• यह आपको अधिक सुरक्षित कोड लिखने की अनुमति देता है, विशेष रूप से, स्मृति के संदर्भ में;
• प्रदर्शन और ओवरहेड आधुनिक सी ++ के तुलनीय हैं;
• लंबे समय तक जंग का उपयोग किया गया है, 2015 के बाद से इसने बहुत अच्छे हाईलोड समाधान लिखे हैं।

लोहा

मैं दोहराता हूं - पटाखे को वास्तविक हार्डवेयर पर स्थापना की आवश्यकता होती है। संदर्भ कॉन्फ़िगरेशन के रूप में, i3.metal नंगे-धातु मशीन को चुना गया था।


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

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

क्या कोई सस्ता विकल्प है? हां, आप वर्चुअल वातावरण में पटाखे को बूट कर सकते हैं। लेकिन अब एडब्ल्यूएस में नहीं - हम मूल रूप से ईसी 2 पर नेस्टेड वर्चुअलाइजेशन का समर्थन नहीं करते हैं। लेकिन आप इसे GCP, Azure, DigitalOcean में कर सकते हैं या Proxmox, Parallels, VMware Fusion का उपयोग कर सकते हैं। सब कुछ काम करेगा यदि आप आवश्यकताओं का पालन करते हैं, विशेष रूप से, अतिथि ओएस के कर्नेल संस्करण के अनुसार।

कोर

समाधान का मूल तत्व KVM कर्नेल मॉड्यूल है।

बस के मामले में, मैं एक विषयांतर के रूप में वर्णन करूंगा कि केवीएम क्या है। यह संपूर्ण हाइपरविजर नहीं है, बल्कि इसका केवल एक हिस्सा है। इसके मुख्य कार्य एक वर्चुअल प्रोसेसर (vCPU) स्थापित कर रहे हैं और एक वर्चुअल मशीन शुरू कर रहे हैं ।



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

VMM

प्रदर्शित होने के लिए कम से कम बुनियादी उपकरणों के लिए, आपको एक अन्य घटक - वर्चुअल मशीन मैनेजर (VMM) की आवश्यकता है। पटाखे से पहले, VMM का प्राथमिक विकल्प QEMU था।



हमने QEMU का उपयोग करने की संभावना पर गंभीरता से विचार किया, लेकिन अपनी खुद की "बाइक" विकसित करने का फैसला किया। इसके कई कारण थे।

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

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

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

उपकरणों

पटाखे वीएमएम को लागू करता है, जिसका उपयोग उपकरणों का अनुकरण करने के लिए किया जाता है। हम निम्नलिखित उपकरणों का अनुकरण करते हैं:

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

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

खैर, हमें संसाधन खपत को नियंत्रित करने की क्षमता भी चाहिए। इसके लिए रेट लिमिटर जिम्मेदार है।

उपकरण हैं। लेकिन microvirtuals को प्रबंधित और कॉन्फ़िगर कैसे करें? प्रबंधन एपीआई यहां हमारी मदद करेगा।

प्रबंध

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



हम ओपन एपीआई विनिर्देश का पालन करते हैं, ताकि आप स्वैगर का उपयोग कर सकें।

मेटाडाटा

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



हम सॉकेट के माध्यम से आईएमडीएस मेटाडेटा व्यापार के लिए आवश्यक जानकारी पास करते हैं। Microvirtual के अंदर यह जानकारी प्राप्त करने के लिए, आपको REST API का उपयोग करके http://169.254.169.254/latest/meta-data का अनुरोध करना होगा। AWS उपयोगकर्ता इस मैजिक आईपी को पहले से जानते हैं। उसी तरह, microvirtuals अपने स्वयं के विन्यास के बारे में विस्तृत जानकारी प्राप्त कर सकते हैं।

लॉग

इससे पहले कि वह मरने से पहले बाहरी दुनिया में microvirtuals के लॉग फेंकने में सक्षम होना जरूरी है। यह एक नियमित यूनिक्स फीफो के माध्यम से किया जाता है।

अतिरिक्त इन्सुलेशन

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



ये मानक सावधानियां हैं:

• संसाधनों को सीमित करने के लिए cgroups ;

• नामस्थान प्रक्रियाओं को अलग करने के लिए;
• seccomp - सिस्टम कॉल के लिए फ़ायरवॉल का एक एनालॉग;
• और, ज़ाहिर है, हर किसी का पसंदीदा चुरोट।

अन्य सेवाओं के साथ एकीकरण

क्या पटाखे पर आधारित कोई तैयार समाधान हैं? बेशक हाँ।

OSV

यह ऑपरेटिंग सिस्टम सिर्फ एक एप्लिकेशन को चलाने के लिए तैयार है। इसके कारण, उसने स्मृति और एक अनुसूचक के साथ बहुत ही सरलता से काम किया है। एक शक्तिशाली और आसानी से प्रबंधित ओएस अब पटाखे के शीर्ष पर काम करता है ।

Containerd

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



सामान्य शिम के बजाय, कंटेनर पटाखे के शिम को संदर्भित करता है। यह पहले से ही रनवे का प्रबंधन करता है, एक एजेंट के माध्यम से जो कि माइक्रोवार्तेल के अंदर स्थापित होता है। जाँच की, काम करता है ।

काटा कंटेनर

जब हमने पहली बार पटाखे की घोषणा की, तो सबसे लोकप्रिय ग्राहक प्रश्नों में से एक था:

- कंटेनरों को अलग करने के तंत्र का आविष्कार पहले ही हो चुका है - यह काटा कंटेनर है। आपने उनका उपयोग क्यों नहीं किया? अपना खुद का विकास क्यों?
- काटा QEMU के साथ काम करता है, लेकिन हम QEMU के साथ काम नहीं करना चाहते हैं। इसलिए, हमने अपना खाना पकाने का फैसला किया।

लेकिन यह दिलचस्प निकला। काटा डेवलपर्स पटाखे डेवलपर्स के साथ मुलाकात की और एकीकृत करने के लिए सहमत हुए। क्योंकि हर कोई इसे एक विशाल प्लस के रूप में देखता है। काटा कंटेनर v1.5 पहले से ही QEMU और पटाखे दोनों का समर्थन करता है।

यह पता चला है कि हम प्रतिस्पर्धा नहीं करते हैं, लेकिन सामंजस्यपूर्ण रूप से एक दूसरे के पूरक हैं। V1.12 के साथ कुबेरनेट्स में, आप runtimeClassName को काटा FC या काटा QEMU के रूप में परिभाषित कर सकते हैं, और अपने कंटेनर को उपयुक्त अलगाव में चला सकते हैं।



इन्सुलेशन का चयन कैसे करें जो आपके आवेदन के अनुरूप है - पटाखे या क्यूईएमयू? मेरी निजी राय है कि क्या मायने रखता है कि आपका आवेदन पालतू जानवर है या मवेशी ?



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

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

परिणाम क्या है?

हमने विरोधाभासों के साथ शुरुआत की। ऐसा लगता है कि विरोधाभास का समाधान एक "हमारा और तुम्हारा" दोनों दृष्टिकोण है, इस बीच की कोई चीज सभी को संतुष्ट करेगी। लेकिन अनुभव कहता है कि समझौता आवश्यक नहीं है।

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

हम पहले से ही अपनी कई सेवाओं के उत्पादन में पटाखे का उपयोग करते हैं। मुख्य प्लस जो हमें मिला वह सेवा उपयोग का सुधार है। इससे काफी बचत हुई। इस बचत का एक हिस्सा हमने ग्राहकों के साथ साझा किया। उदाहरण के लिए, पटाखे की शुरुआत के बाद, जनवरी 2019 में AWS Fargate सर्वर रहित कंटेनरों की कीमतें 35-50% तक गिर गईं। लाभ नग्न आंखों को दिखाई देता है, इसलिए इसमें कोई संदेह नहीं है कि हम इस उत्पाद को विकसित करना जारी रखेंगे और ओपन सोर्स के साथ अपनी सर्वोत्तम प्रथाओं को साझा करेंगे। तथ्य यह है कि पटाखे पहले से ही अन्य समाधानों के साथ एकीकृत करना शुरू कर चुके हैं, समुदाय की ओर से बढ़ती रुचि को इंगित करता है।

यदि आपके पास एक विचार या एक तैयार उत्पाद है जिसके विवरण में "मल्टी-टेनेंट आइसोलेशन" शब्द हैं - यह एक स्पष्ट संकेतक है कि आपको पटाखे के माइक्रोवैरिट्स के साथ क्या प्रयोग करना चाहिए।

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