लिनक्स पर .NET कोर, घोड़े पर DevOps

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

इस तरह कहानी शुरू होती है एलेक्जेंड्रा सिंचिनोवा पर DevOpsConf. जब प्रमुख विंडोज़ विशेषज्ञ ने कंपनी छोड़ दी, तो अलेक्जेंडर ने सोचा कि अब क्या किया जाए। बेशक, लिनक्स पर स्विच करें! अलेक्जेंडर आपको बताएगा कि कैसे वह 100 अंतिम उपयोगकर्ताओं के लिए एक पूर्ण परियोजना के उदाहरण का उपयोग करके एक मिसाल बनाने और विंडोज विकास के हिस्से को लिनक्स में स्थानांतरित करने में कामयाब रहा।

TFS, Puppet, Linux .NET कोर का उपयोग करके किसी प्रोजेक्ट को RPM तक आसानी से और सहजता से कैसे वितरित करें? यदि विकास टीम पहली बार पोस्टग्रेज और फ्लाईवे शब्द सुनती है, और समय सीमा परसों है तो प्रोजेक्ट डेटाबेस के संस्करणीकरण का समर्थन कैसे करें? डॉकर के साथ कैसे एकीकृत करें? .NET डेवलपर्स को पपेट और लिनक्स के पक्ष में विंडोज़ और स्मूथीज़ को छोड़ने के लिए कैसे प्रेरित करें? यदि विंडोज़ को उत्पादन में बनाए रखने के लिए न तो ताकत है, न इच्छा है, न ही संसाधन हैं तो वैचारिक संघर्षों को कैसे हल किया जाए? इसके बारे में, साथ ही वेब परिनियोजन, परीक्षण, सीआई के बारे में, मौजूदा परियोजनाओं में टीएफएस का उपयोग करने की प्रथाओं के बारे में, और निश्चित रूप से, अलेक्जेंडर की रिपोर्ट की प्रतिलेख में टूटी बैसाखी और कामकाजी समाधानों के बारे में।

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

चूँकि हम सक्रिय रूप से DevOps विकसित कर रहे हैं, मुझे एहसास हुआ कि एक नया एप्लिकेशन वितरित करने के दृष्टिकोण में कुछ बदलाव की आवश्यकता है। केवल एक ही समाधान था - यदि संभव हो तो सब कुछ लिनक्स में स्थानांतरित कर दें। Google ने मेरी मदद की - उस समय .Net को पहले ही Linux में पोर्ट कर दिया गया था, और मुझे एहसास हुआ कि यही समाधान था!

.NET कोर Linux के साथ संयोजन में क्यों?

इसके बहुत से कारण थे। "पैसे का भुगतान करें" और "भुगतान न करें" के बीच, अधिकांश लोग दूसरे को चुनेंगे - मेरी तरह। MSDB के लिए एक लाइसेंस की लागत लगभग $1 है; विंडोज़ वर्चुअल मशीनों के बेड़े को बनाए रखने में सैकड़ों डॉलर खर्च होते हैं। एक बड़ी कंपनी के लिए यह एक बड़ा खर्च है. इसीलिए बचत - पहला कारण. सबसे महत्वपूर्ण तो नहीं, लेकिन महत्वपूर्ण में से एक।

विंडोज़ वर्चुअल मशीनें अपने लिनक्स समकक्षों की तुलना में अधिक संसाधन लेती हैं - वे भारी हैं. बड़ी कंपनी के पैमाने को देखते हुए, हमने लिनक्स को चुना।

सिस्टम को बस मौजूदा सीआई में एकीकृत किया गया है. हम खुद को प्रगतिशील DevOps मानते हैं, हम बैम्बू, जेनकिंस और GitLab CI का उपयोग करते हैं, इसलिए हमारा अधिकांश काम Linux पर चलता है।

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

आवश्यकताएँ

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

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

समर्थन और संचालन में आसानी, विभिन्न प्रभागों और सहायता विभाग से सभी नए प्रतिभागियों के लिए न्यूनतम प्रवेश सीमा की एक शर्त के रूप में।

समय सीमा - कल.

विन डेवलपमेंट ग्रुप

तब विंडोज़ टीम किसके साथ काम कर रही थी?

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

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

आइए देखें और समझने का प्रयास करें कि इन सभी हस्तक्षेपों को शुरू करने से पहले क्या हुआ था।

क्या था

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

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

हम क्या हासिल करना चाहते थे?

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

परियोजना

एप्लिकेशन प्रीपेड कार्ड को संभालने के लिए कार्यक्षमता प्रदान करता है।

ग्राहक

उपयोगकर्ता दो प्रकार के थे. पहले SSL SHA-2 प्रमाणपत्र का उपयोग करके लॉग इन करके पहुंच प्राप्त की। यू दूसरा लॉगिन और पासवर्ड का उपयोग करके पहुंच थी।

HAProxy

फिर क्लाइंट का अनुरोध HAProxy के पास गया, जिससे निम्नलिखित समस्याएं हल हो गईं:

• प्राथमिक प्राधिकरण;
• एसएसएल समाप्ति;
• HTTP अनुरोधों को ट्यून करना;
• प्रसारण अनुरोध.

ग्राहक प्रमाणपत्र को श्रृंखला के साथ सत्यापित किया गया था। हम - अधिकार और हम इसे वहन कर सकते हैं, क्योंकि हम स्वयं सेवा ग्राहकों को प्रमाणपत्र जारी करते हैं।

तीसरे बिंदु पर ध्यान दें, हम इस पर थोड़ी देर बाद लौटेंगे।

बैकएण्ड

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

HAProxy के साथ बचत

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

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

दूसरा चरण - अनुरोध प्राप्त हुआ IdentityServer में प्राधिकरण पृष्ठ पर, जहां ग्राहक पंजीकृत था, और वह लंबे समय से प्रतीक्षित टोकन IdentityServer डेटाबेस में दिखाई दिया।

तीसरा चरण - क्लाइंट को वापस रीडायरेक्ट किया गया था जिस संदर्भ से यह आया है।

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

क्या सुधार हुआ और आपने कहां बचत की?

हमने उपयोगकर्ताओं, संसाधनों के एक समूह को अधिकृत करने के लिए एक मुफ्त समाधान का उपयोग करके पैसे बचाए, क्योंकि हमने IdentityServer4 को एक अलग खंड में एक अलग नोड के रूप में नहीं रखा, बल्कि इसे उसी सर्वर पर बैकएंड के साथ उपयोग किया जहां एप्लिकेशन का बैकएंड चलता है .

इसे कैसे काम करना चाहिए

तो, जैसा कि मैंने वादा किया था - मैजिक बॉक्स। हम पहले से ही समझते हैं कि हमें लिनक्स की ओर बढ़ने की गारंटी है। आइए उन विशिष्ट कार्यों को तैयार करें जिनके लिए समाधान की आवश्यकता है।

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

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

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

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

पहचान सर्वर. एडीएफएस हमारा रास्ता नहीं है, हम ओपन सोर्स के लिए जा रहे हैं।

आइए घटकों के बारे में जानें।

जादुई बॉक्स

चार भागों से मिलकर बना है.

लिनक्स बिल्ड एजेंट. लिनक्स, क्योंकि हम इसके लिए निर्माण करते हैं - यह तर्कसंगत है। यह भाग तीन चरणों में किया गया।

• कार्यकर्ताओं को कॉन्फ़िगर करें और अकेले नहीं, क्योंकि परियोजना पर वितरित कार्य अपेक्षित था।
• .NET कोर 1.x स्थापित करें. जब 1 पहले से ही मानक भंडार में उपलब्ध है तो 2.0.x क्यों? क्योंकि जब हमने विकास शुरू किया, तो स्थिर संस्करण 1.09 था, और इसके आधार पर परियोजना बनाने का निर्णय लिया गया।
• गिट 2.x.

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

GitLab। ध्यान! यहां GitLab का उपयोग डेवलपर्स द्वारा नहीं, बल्कि संचालन विभाग द्वारा एप्लिकेशन संस्करणों, पैकेज संस्करणों को नियंत्रित करने, सभी लिनक्स मशीनों की स्थिति की निगरानी करने के लिए किया जाता है, और यह रेसिपी - सभी पपेट मैनिफ़ेस्ट को संग्रहीत करता है।

कठपुतली - सभी विवादास्पद मुद्दों को हल करता है और बिल्कुल वही कॉन्फ़िगरेशन प्रदान करता है जो हम Gitlab से चाहते हैं।

हम गोता लगाना शुरू करते हैं। आरपीएम पर डीएलएल डिलीवरी कैसे काम करती है?

आरपीएम पर डिलीवरी डीडीएल

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

जिसके बाद टीएफएस देखता है कि एक नई कमिट आ गई है। कौन सा ऐप? टीएफएस सेटिंग्स में एक लेबल होता है जो दर्शाता है कि किसी विशेष बिल्ड एजेंट के पास कौन से संसाधन हैं। इस मामले में, वह देखता है कि हम एक .NET कोर प्रोजेक्ट बना रहे हैं और पूल से एक लिनक्स बिल्ड एजेंट का चयन करता है।

बिल्ड एजेंट स्रोत प्राप्त करता है और आवश्यक डाउनलोड करता है निर्भरता .NET रिपॉजिटरी, एनपीएम, आदि से। और एप्लिकेशन के निर्माण और उसके बाद की पैकेजिंग के बाद, RPM पैकेज को RPM रिपॉजिटरी में भेजता है।

दूसरी ओर, निम्नलिखित होता है. परिचालन विभाग का इंजीनियर सीधे परियोजना के कार्यान्वयन में शामिल होता है: वह पैकेजों के संस्करणों को बदलता है हिरा रिपॉजिटरी में जहां एप्लिकेशन रेसिपी संग्रहीत होती है, जिसके बाद पपेट ट्रिगर होता है यम, रिपॉजिटरी से नया पैकेज लाता है, और एप्लिकेशन का नया संस्करण उपयोग के लिए तैयार है।

शब्दों में सब कुछ सरल है, लेकिन बिल्ड एजेंट के अंदर क्या होता है?

पैकेजिंग डीएलएल आरपीएम

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

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

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

आरपीएम भंडार के लिए यह विशेष पैकेज वितरण योजना क्यों? मैं इकट्ठे पैकेज को तुरंत रिपॉजिटरी में क्यों नहीं भेज सकता? तथ्य यह है कि यह सुरक्षा सुनिश्चित करने की एक शर्त है। यह परिदृश्य अनधिकृत लोगों द्वारा RPM पैकेजों को ऐसे सर्वर पर अपलोड करने की संभावना को सीमित करता है जो सभी Linux मशीनों के लिए पहुंच योग्य है।

डेटाबेस संस्करणीकरण

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

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

विपक्ष

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

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

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

पेशेवरों

इकाई फ्रेमवर्क कोर बॉक्स से बाहर काम करता है और इसे विकसित करना आसान है, और फ्लाईवे मौजूदा सीआई में आसानी से एकीकृत हो जाता है. लेकिन हम इसे डेवलपर्स के लिए सुविधाजनक बनाते हैं :)

रोल-अप प्रक्रिया

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

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

टीएफएस समस्याएं

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

मुख्य परियोजनाओं में से एक को तैयार होने में 12-15 मिनट लगते हैं - यह एक लंबा समय है, आप उस तरह नहीं रह सकते। एक त्वरित विश्लेषण ने I/O में एक भयानक कमी दिखाई, और यह सरणियों पर था।

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

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

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

समाधान

• एवी अपवादों में स्रोत.
• अनुक्रमण अक्षम करें.
• के लिए जाओ एनपीएम सीआई.

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

विन्यास

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

हम भी प्रयोग करते हैं NuGet, क्योंकि इसमें अन्य पैकेज प्रबंधकों की तुलना में बेहतर कैशिंग है।

परिणाम

बिल्ड एजेंटों को अनुकूलित करने के बाद, औसत निर्माण समय 12 मिनट से घटाकर 7 मिनट कर दिया गया।

यदि हम उन सभी मशीनों की गिनती करें जिन्हें हम विंडोज़ के लिए उपयोग कर सकते थे, लेकिन इस परियोजना में लिनक्स पर स्विच करने पर, हमने लगभग $10 की बचत की। और यह केवल लाइसेंस पर है, और यदि हम सामग्री को ध्यान में रखते हैं तो और भी अधिक।

योजनाएं

अगली तिमाही के लिए, हमने कोड डिलीवरी को अनुकूलित करने पर काम करने की योजना बनाई है।

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

सारांश

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

अलेक्जेंडर सिनचिनोव की वक्ता प्रोफ़ाइल GitHub पर.

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

स्रोत: www.habr.com