.Net कोर के लिए एक दर्द रहित संक्रमण के लिए एक सूत्र मिला

हर चीज के बारे में हर चीज के लिए, 50 कप कॉफी पर्याप्त है।

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

नीचे एक तैयार कार्य योजना है, एक बहुत ही कैपेसिटिव परीक्षण सूची होगी, यह तस्वीर यहाँ मूड के लिए होगी:

तो, चरणों में:

1. बड़ी सुविधाओं और / या प्रतिगमन के साथ लंबे स्प्रिंट की योजना बनाएं

मौलिक कोड फिर से लिखने के साथ, सेवा को परीक्षण वातावरण पर सभी खामियों को ठीक करने के लिए समय के लिए यथासंभव लंबे समय तक जोर देने की आवश्यकता होगी।

2. सही स्प्रिंट पर .net कोर पर कोड को फिर से लिखना

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

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

• यदि संभव हो, तो इस्तेमाल की गई सेवाओं में वेबसीपी में डब्ल्यूसीएफ इंटरफेस को फिर से लिखना

WCF क्लाइंट का .Net कोर कार्यान्वयन अभी भी आदर्श से बहुत दूर है। इस तथ्य के बावजूद कि पुराने घावों को किसी तरह से तय किया गया है, नए संस्करणों में आपको अभी भी वर्कअराउंड ( 1 , 2 ) का उपयोग करना होगा।

कहानी के लिए: .Net कोर 2.0 पर, WCF का स्थिर कार्य संस्करण myget रिपॉजिटरी से 4.4.2 है। उदाहरण के लिए, उसे शुरुआती समय में कोई समस्या नहीं है

माइग्रेशन की शुरुआत में, हमने .net Core 2.0 के संस्करण का उपयोग किया। इस बीच, Microsoft ने .Net Core 2.1 जारी किया है। प्लेटफॉर्म को अनुकूलित करने में रेडमंड लोगों की सफलताओं को स्वीकार करने में कौन दिलचस्पी रखता है, कृपया पढ़ें कि नए संस्करण में अपग्रेड करते समय बिंग सर्च इंजन ने कौन सी प्रगति की (स्पॉइलर: लैटेंसि 34% गिर गया!)

हमने .Net Core 2.1 और WCF 4.5.3 में भी अपग्रेड किया। और हम Dockerfile में एक ताज़ा आधार microsoft / dotnet image: 2.1-aspnetcore- रनटाइम निर्दिष्ट करना नहीं भूले। क्या आश्चर्य था, जब 1.4 जीबी के बजाय, उन्होंने 0.5 जीबी का एक छवि आकार देखा (हम अचानक, अगर एक विंडोज छवि के बारे में बात कर रहे हैं)।

3. एक परीक्षण और डेमो के लिए काठी

हमारे पास अपने निपटान में दो वातावरण हैं। हमने एक संदर्भ के रूप में पुराने संस्करण के साथ डेमो को छोड़ दिया। एक नई सेवा को परीक्षण वातावरण में तैनात किया गया था - डेवलपर्स और परीक्षकों पर एक रन।

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

• IIS कॉन्फ़िगर करें

IIS में .Net कोर सेवा को चलाने के लिए, आपको रनटाइम के साथ आने वाले मॉड्यूल को स्थापित करना होगा।

AppPool सीएलआर रनटाइम पर स्विच = कोई प्रबंधित कोड नहीं।

मानक web.config के समाधान में , वांछित अनुरोध सेट करने और WebDAV मॉड्यूल को अक्षम करने के लिए नहीं भूलना महत्वपूर्ण है, अगर DELETE विधियाँ हैं।

आगे, IIS में सेवा प्रकाशित करने के दो विकल्प हैं:

• आप MSDeploy सिंक करते हैं - इसका मतलब है कि आपको अतिरिक्त -enableRule स्विच की आवश्यकता है : AppOffline
• आप फ़ाइल प्रकाशन करते हैं - इसका मतलब है कि प्रकाशन से ठीक पहले आपको फ़ाइल को सेवा निर्देशिका में app_offline.htm डालना होगा, और प्रकाशन के बाद इसे प्रकाशित करना होगा

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

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

4. परीक्षण

यहाँ सबसे नाजुक स्थानों के लिए सबसे सिकुड़ा हुआ चेकलिस्ट है:

• स्थिति कोड की वापसी की जांच करें खराब अनुरोध, अनधिकृत, संशोधित नहीं, नहीं मिला - वह सब जो एपीआई दे सकता है
• सभी स्टेटस कोड के लिए चेक रिक्वेस्ट लॉगिंग
• बाहरी निर्भरता का आरेख बनाएं; एक नियम के रूप में, सभी आवश्यक जानकारी appsettings में है
  
  • अपने काम को प्रभावित करने वाले तरीकों को बंद करें
  • बाहरी अनुरोधों की जाँच लॉगिंग
• एप्लेटिंग मापदंडों के लिए सेटिंग्स के कामकाज की जांच करें; उन्हें गर्म करने के लिए बदलने की कोशिश करें
• सकारात्मक और नकारात्मक स्थिति कोड के लिए http कैशिंग की जाँच करें
  
  • ईटैग हेडर
  • हेडर कैश-कंट्रोल
• लंबे अनुरोधों और टाइमआउट की जाँच करें
• खाली उत्तर के साथ अनुरोधों की जांच करें
• DELETE विधियों की जाँच करें (WebDAV अक्षम है या नहीं)
• कच्चे माल के साथ काम की जाँच करें
  
  • अपलोड करें और एक / कई फाइलें डाउनलोड करें
  • सीमा के ऊपर एक आकार के साथ फाइल अपलोड करें
  • हेडर लेआउट सामग्री-विवाद
• अन्य सभी शीर्ष लेख देखें; उन सभी को एक साथ कोड में डालना बहुत आसान है
• वातावरण स्विच करते समय सशर्त कोड निष्पादन की जाँच करें if (env.IsDevelopment())
• ग्राहक और सर्वर से डिस्कनेक्ट की जाँच करें
• मानक swagger.json के साथ तुलना करें - संचारित क्षेत्रों में अंतर का पता लगाने में मदद करेगा
  

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

5. कॉफ़ी पीते समय झगड़े के लिए तैयार

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

इस प्रकार, आपातकाल की स्थिति में, हम पुराने संस्करण में जल्दी से स्विच करने में सक्षम थे।

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

उप-योग

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

अब ग्राहक के लिए नए बुनियादी ढांचे की प्रस्तुति के लिए तैयारी चल रही है। हम अगली श्रृंखला में हमारी उपलब्धियों के बारे में बताएंगे, अपनी उंगली को नाड़ी पर रखें;)