Linux मा .NET Core, घोडामा DevOps

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

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

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

त्यसोभए, वास्या छोडियो, कार्य ममा छ, विकासकर्ताहरू पिचफोर्कहरूसँग अधीरताका साथ पर्खिरहेका छन्। जब मैले अन्ततः महसुस गरें कि वास्या फर्काउन सकिँदैन, म व्यवसायमा निस्किए। सुरुमा, मैले हाम्रो फ्लीटमा Win VMs को प्रतिशत मूल्याङ्कन गरें। स्कोर विन्डोजको पक्षमा थिएन।

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

किन लिनक्स संग संयोजन मा .NET कोर?

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

विन्डोज भर्चुअल मेसिनहरूले लिनक्स भाइहरू भन्दा बढी स्रोतहरू लिन्छन् - तिनीहरू भारी छन्। ठूलो कम्पनीको स्केललाई ध्यानमा राख्दै, हामीले लिनक्स रोज्यौं।

प्रणाली केवल अवस्थित CI मा एकीकृत छ। हामी आफूलाई प्रगतिशील DevOps मान्छौं, हामी Bamboo, Jenkins र GitLab CI प्रयोग गर्छौं, त्यसैले हाम्रो अधिकांश काम लिनक्समा चल्छ।

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

आवश्यकताहरू

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

नयाँ परियोजना आवश्यक छ अवस्थित CI मा एकीकृत। रेलहरू पहिले नै त्यहाँ थिए र सबै कामहरू कन्फिगरेसन व्यवस्थापन प्रणालीको प्यारामिटरहरू, स्वीकृत डेलिभरी मानकहरू र निगरानी प्रणालीहरूलाई ध्यानमा राखेर गर्नुपर्ने थियो।

समर्थन र सञ्चालनको सजिलो, विभिन्न डिभिजनहरू र समर्थन विभागका सबै नयाँ सहभागीहरूको लागि न्यूनतम प्रविष्टि थ्रेसहोल्डको लागि शर्तको रूपमा।

म्याद - हिजो.

विन विकास समूह

त्यसबेला विन्डोज टोलीले के काम गरिरहेको थियो?

अब म ढुक्क भएर भन्न सक्छु IdentityServer4 समान क्षमताहरू भएको ADFS को लागि एक राम्रो नि: शुल्क विकल्प हो, वा के इकाई फ्रेमवर्क कोर - एक विकासकर्ताको लागि स्वर्ग, जहाँ तपाइँले SQL स्क्रिप्टहरू लेख्नु पर्दैन, तर OOP सर्तहरूमा डाटाबेसमा प्रश्नहरू वर्णन गर्नुहोस्। तर त्यसपछि, कार्य योजनाको छलफलको क्रममा, मैले यो स्ट्याकलाई सुमेरियन क्यूनिफर्म जस्तै हेरें, पोस्टग्रेएसक्यूएल र गिट मात्र पहिचान गर्दै।

त्यसबेला हामीले सक्रिय रूपमा प्रयोग गरेका थियौं कठपुतली कन्फिगरेसन व्यवस्थापन प्रणालीको रूपमा। हाम्रा धेरैजसो परियोजनाहरूमा हामीले प्रयोग गर्‍यौं GitLab सीआई, लोचदार, सन्तुलित उच्च लोड सेवाहरू प्रयोग गर्दै HAProxy सबै कुराको अनुगमन गरे Zabbix, लिगामेन्ट ग्राफाना и Prometheus, जेगरर यी सबै फलामका टुक्राहरूमा घुमिरहेको थियो HP c ESXi मा VMware। सबैलाई थाहा छ - विधा को एक क्लासिक।

हामीले यी सबै हस्तक्षेपहरू सुरु गर्नु अघि के भइरहेको थियो हेरौं र बुझ्न प्रयास गरौं।

के भयो

TFS एक पर्याप्त शक्तिशाली प्रणाली हो जसले विकासकर्ताबाट अन्तिम उत्पादन मेसिनमा कोड मात्र प्रदान गर्दैन, तर विभिन्न सेवाहरूसँग धेरै लचिलो एकीकरणको लागि सेट पनि छ - क्रस-प्लेटफर्म स्तरमा CI प्रदान गर्न।

पहिले, यी ठोस झ्यालहरू थिए। TFS ले धेरै बिल्ड एजेन्टहरू प्रयोग गर्यो, जुन धेरै परियोजनाहरू जम्मा गर्न प्रयोग गरियो। प्रत्येक एजेन्टसँग कार्यहरू समानान्तर गर्न र प्रक्रियालाई अनुकूलन गर्न 3-4 कामदारहरू छन्। त्यसपछि, रिलीज योजनाहरू अनुसार, TFS ले ताजा बेक्ड बिल्डलाई Windows अनुप्रयोग सर्भरमा डेलिभर गर्यो।

हामीले के हासिल गर्न चाहेका थियौं?

हामी वितरण र विकासको लागि TFS प्रयोग गर्छौं, र लिनक्स अनुप्रयोग सर्भरमा अनुप्रयोग चलाउँछौं, र तिनीहरू बीच केही प्रकारको जादू छ। यो म्याजिक बक्स र त्यहाँ कामको नुन अगाडि छ। मैले यसलाई अलग गर्नु अघि, म एक कदम छोड्छु र अनुप्रयोगको बारेमा केही शब्दहरू भन्नेछु।

परियोजना

अनुप्रयोगले प्रिपेड कार्डहरू ह्यान्डल गर्नका लागि कार्यक्षमता प्रदान गर्दछ।

ग्राहक

त्यहाँ दुई प्रकारका प्रयोगकर्ताहरू थिए। पहिलो SSL SHA-2 प्रमाणपत्र प्रयोग गरेर लग इन गरेर पहुँच प्राप्त भयो। U दोस्रो त्यहाँ लगइन र पासवर्ड प्रयोग गरेर पहुँच थियो।

HAProxy

त्यसपछि ग्राहक अनुरोध HAProxy मा गए, जसले निम्न समस्याहरू समाधान गर्यो:

• प्राथमिक प्राधिकरण;
• SSL समाप्ति;
• HTTP अनुरोधहरू ट्युन गर्दै;
• प्रसारण अनुरोधहरू।

ग्राहक प्रमाणपत्र चेनको साथ प्रमाणित गरियो। हामी - अख्तियार र हामी यो किन्न सक्छौं, किनकि हामी आफैले सेवा ग्राहकहरूलाई प्रमाणपत्र जारी गर्छौं।

तेस्रो बिन्दुमा ध्यान दिनुहोस्, हामी यसलाई केहि पछि फर्कनेछौं।

ब्याकइन्ड

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

HAProxy को साथ बचत

प्रत्येक ग्राहकले नेभिगेट गर्ने दुई सन्दर्भहरूको अतिरिक्त, त्यहाँ एक पहिचान सन्दर्भ पनि थियो। IdentityServer4 केवल तपाईंलाई लग इन गर्न अनुमति दिन्छ, यो नि: शुल्क र शक्तिशाली एनालग हो एडीएफएस - सक्रिय निर्देशिका संघ सेवाहरू.

पहिचान अनुरोध धेरै चरणहरूमा प्रशोधन गरिएको थियो। पहिलो पाइला - ग्राहक ब्याकइन्डमा पुग्यो, जसले यस सर्भरसँग सञ्चार गर्‍यो र ग्राहकको लागि टोकनको उपस्थिति जाँच गर्‍यो। यदि यो फेला परेन भने, अनुरोधलाई त्यो सन्दर्भमा फर्काइयो जसबाट यो आएको थियो, तर एक रिडिरेक्टको साथ, र रिडिरेक्टको साथ यो पहिचानमा गयो।

दोस्रो चरण - अनुरोध प्राप्त भयो IdentityServer मा प्राधिकरण पृष्ठमा, जहाँ ग्राहक दर्ता भयो, र त्यो लामो-प्रतीक्षित टोकन IdentityServer डाटाबेसमा देखा पर्‍यो।

तेस्रो चरण - ग्राहक फिर्ता रिडिरेक्ट गरियो जुन सन्दर्भबाट यो आएको हो।

IdentityServer4 को सुविधा छ: यसले HTTP मार्फत फिर्ता अनुरोधको जवाफ फर्काउँछ। हामीले सर्भर सेटअप गर्न जति सङ्घर्ष गर्‍यौं, हामीले कागजातहरूबाट आफूलाई जतिसुकै प्रबुद्ध बनायौं, हरेक पटक हामीले HTTPS मार्फत आएको URL को साथ प्रारम्भिक ग्राहक अनुरोध प्राप्त गर्‍यौं, र IdentityServer ले उही सन्दर्भ फिर्ता गर्‍यो, तर HTTP सँग। हामी छक्क भयौं! र हामीले यी सबैलाई पहिचान सन्दर्भ मार्फत HAProxy मा स्थानान्तरण गर्यौं, र हेडरहरूमा हामीले HTTP प्रोटोकललाई HTTPS मा परिमार्जन गर्नुपर्‍यो।

के सुधार भयो र कहाँ बचत गर्नुभयो?

हामीले IdentityServer4 लाई छुट्टै खण्डमा छुट्टै नोडको रूपमा नराख्ने भएकोले प्रयोगकर्ताहरू, स्रोतहरूको समूहलाई अधिकृत गर्नको लागि नि:शुल्क समाधान प्रयोग गरेर पैसा बचत गर्यौं, तर अनुप्रयोगको ब्याकइन्ड चल्ने सर्भरमा ब्याकइन्डसँग सँगै प्रयोग गर्‍यौं। ।

कसरी काम गर्नुपर्छ

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

कठपुतली प्रकट हुन्छ। सेवा र अनुप्रयोग कन्फिगरेसन डेलिभर गर्न र व्यवस्थापन गर्न, कूल रेसिपीहरू लेख्नुपर्थ्यो। पेन्सिलको रोलले यो कति छिटो र कुशलतापूर्वक गरिएको थियो भनी देखाउँछ।

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

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

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

पहिचान सर्भर। ADFS हाम्रो बाटो होइन, हामी खुला स्रोतको लागि जाँदैछौं।

घटकहरू मार्फत जाऔं।

म्याजिक बक्स

चार भागहरु मिलेर बनेको छ।

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

• कार्यकर्ताहरू कन्फिगर गर्नुहोस् र एक्लै होइन, किनकि परियोजनामा ​​वितरित काम अपेक्षित थियो।
• .NET Core 1.x स्थापना गर्नुहोस्। किन 1.x जब 2.0 पहिले नै मानक भण्डारमा उपलब्ध छ? किनभने हामीले विकास सुरु गर्दा स्टेबल संस्करण १.०९ थियो र त्यसमा आधारित परियोजना बनाउने निर्णय भयो।
• Git 2.x.

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

GitLab ध्यान! GitLab यहाँ विकासकर्ताहरू द्वारा होइन, तर अपरेसन विभागद्वारा अनुप्रयोग संस्करणहरू, प्याकेज संस्करणहरू नियन्त्रण गर्न, सबै लिनक्स मेसिनहरूको स्थिति निगरानी गर्न प्रयोग गरिन्छ, र यसले नुस्खा भण्डार गर्दछ - सबै Puppet manifests।

कठपुतली - सबै विवादास्पद मुद्दाहरू समाधान गर्दछ र ठ्याक्कै हामीले गिटल्याबबाट चाहेको कन्फिगरेसन प्रदान गर्दछ।

हामी डुब्न थाल्छौं। RPM मा DLL डेलिभरीले कसरी काम गर्छ?

RPM मा DDL डेलिभरी

मानौं हामीसँग .NET विकास रक स्टार छ। यसले भिजुअल स्टुडियो प्रयोग गर्दछ र रिलीज शाखा सिर्जना गर्दछ। त्यस पछि, यसले यसलाई Git मा अपलोड गर्दछ, र Git यहाँ TFS इकाई हो, त्यो हो, यो विकासकर्ताले काम गर्ने अनुप्रयोग भण्डार हो।

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

बिल्ड एजेन्टले स्रोतहरू प्राप्त गर्दछ र आवश्यक डाउनलोड गर्दछ निर्भरता .NET रिपोजिटरी, npm, आदिबाट। र एप्लिकेसन आफैं निर्माण गरेपछि र त्यसपछिको प्याकेजिङ, RPM प्याकेजलाई RPM भण्डारमा पठाउँछ।

अर्कोतर्फ, निम्न हुन्छ। अपरेसन डिपार्टमेन्ट इन्जिनियर परियोजनाको रोलआउटमा प्रत्यक्ष रूपमा संलग्न छ: उसले प्याकेजहरूको संस्करणहरू परिवर्तन गर्दछ हिरा भण्डारमा जहाँ अनुप्रयोग नुस्खा भण्डार गरिएको छ, जस पछि पपेट ट्रिगर हुन्छ yum, भण्डारबाट नयाँ प्याकेज ल्याउँछ, र अनुप्रयोगको नयाँ संस्करण प्रयोगको लागि तयार छ।

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

प्याकेजिङ DLL RPM

TFS बाट परियोजना स्रोत र निर्माण कार्य प्राप्त भयो। एजेन्ट बनाउनुहोस् स्रोतबाटै परियोजना निर्माण गर्न थाल्छ। जम्मा गरिएको परियोजना सेटको रूपमा उपलब्ध छ DLL फाइलहरू, जुन फाइल प्रणालीमा लोड कम गर्नको लागि zip अभिलेखमा प्याकेज गरिएको छ।

ZIP अभिलेख फालिएको छ RPM प्याकेज निर्माण निर्देशिकामा। अर्को, Bash स्क्रिप्टले वातावरण चरहरू प्रारम्भ गर्दछ, निर्माण संस्करण, परियोजना संस्करण, निर्माण डाइरेक्टरीमा मार्ग फेला पार्छ, र RPM-build चलाउँछ। एक पटक निर्माण पूरा भएपछि, प्याकेज प्रकाशित हुनेछ स्थानीय भण्डार, जुन बिल्ड एजेन्टमा अवस्थित छ।

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

किन यो विशेष प्याकेज वितरण योजना RPM भण्डारमा? म किन तुरुन्तै जम्मा गरिएको प्याकेज भण्डारमा पठाउन सक्दिन? तथ्य यो हो कि यो सुरक्षा सुनिश्चित गर्न को लागी एक शर्त हो। यो परिदृश्यले सबै लिनक्स मेसिनहरूमा पहुँचयोग्य सर्भरमा RPM प्याकेजहरू अपलोड गर्ने अनाधिकृत मानिसहरूको सम्भावनालाई सीमित गर्दछ।

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

विकास टोलीसँगको परामर्शमा, यो पत्ता लाग्यो कि केटाहरू MS SQL को नजिक थिए, तर धेरै जसो गैर-Windows प्रोजेक्टहरूमा हामीले पहिले नै आफ्नो सबै शक्तिका साथ PostgreSQL प्रयोग गरिरहेका थियौं। हामीले पहिले नै भुक्तान गरिएका सबै कुरा त्याग्ने निर्णय गरिसकेकाले, हामीले यहाँ पनि PostgreSQL प्रयोग गर्न थाल्यौं।

यस भागमा म तपाईलाई बताउन चाहन्छु कि हामीले कसरी डाटाबेसको संस्करण बनायौं र हामीले कसरी Flyway र Entity Framework Core बीच रोज्यौं। तिनीहरूको फाइदा र बेफाइदा हेरौं।

Минусы

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

Flyway हाम्रो लागि कुनै प्रकारको र्यापर चाहिन्छताकि केटाहरूले लेख्न नपरोस् SQL प्रश्नहरू। तिनीहरू OOP सर्तहरूमा सञ्चालन गर्न धेरै नजिक छन्। हामीले डाटाबेस वस्तुहरूसँग काम गर्न निर्देशनहरू लेख्यौं, SQL क्वेरी उत्पन्न गर्‍यौं र यसलाई कार्यान्वयन गर्‍यौं। डाटाबेसको नयाँ संस्करण तयार छ, परीक्षण गरिएको छ - सबै ठीक छ, सबै काम गर्दछ।

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

Плюсы

इकाई फ्रेमवर्क कोर बक्स बाहिर काम गर्दछ र विकास गर्न सजिलो छ, र फ्लाईवे विद्यमान CI मा सजिलै संग एकीकृत। तर हामी यसलाई विकासकर्ताहरूको लागि सुविधाजनक बनाउँछौं :)

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

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

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

TFS समस्याहरू

हामीले निर्णय गरेपछि र सबै कुरा वास्तवमै हाम्रो लागि काम गरिरहेको महसुस गरेपछि, मैले अन्य परियोजनाहरूमा विन विकास विभागको लागि TFS मा जम्मा भएका सम्मेलनहरूसँग के भइरहेको छ भनेर हेर्ने निर्णय गरे - चाहे हामी निर्माण/छिटो जारी गर्दैछौं वा होइन, र। गति संग महत्वपूर्ण समस्याहरू पत्ता लगाइयो।

एउटा मुख्य परियोजनालाई जम्मा हुन १२-१५ मिनेट लाग्छ - त्यो लामो समय हो, तपाईं त्यसरी बाँच्न सक्नुहुन्न। द्रुत विश्लेषणले I/O मा भयानक ड्रडाउन देखायो, र यो arrays मा थियो।

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

तेस्रो - Npm स्थापना। यो बाहिर भयो कि धेरै पाइपलाइनहरूमा हामीले यो सही परिदृश्य प्रयोग गर्यौं। ऊ किन खराब छ? Npm स्थापना प्रक्रिया चलाइन्छ जब निर्भरता रूख मा गठन हुन्छ package-lock.json, जहाँ परियोजना निर्माण गर्न प्रयोग गरिने प्याकेजहरूको संस्करणहरू रेकर्ड गरिएको छ। नकारात्मक पक्ष यो हो कि एनपीएम स्थापनाले हरेक पटक इन्टरनेटबाट प्याकेजहरूको नवीनतम संस्करणहरू तान्दछ, र यसले ठूलो परियोजनाको मामलामा धेरै समय लिन्छ।

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

निर्णय

• AV अपवादहरूमा स्रोतहरू।
• अनुक्रमणिका असक्षम गर्नुहोस्।
• संक्रमण npm ci.

npm ci को फाइदाहरू यो हो कि हामी हामी एक पटक निर्भरता रूख संकलन गर्छौं, र हामी विकासकर्ता प्रदान गर्ने अवसर पाउँछौं प्याकेजहरूको हालको सूचीजसबाट उनले आफूलाई मन लागे स्थानीय रूपमा प्रयोग गर्न सक्छन्। यो समय बचत गर्छ विकासकर्ताहरू जसले कोड लेख्छन्।

कन्फिगरेसन

अब भण्डार कन्फिगरेसनको बारेमा थोरै। ऐतिहासिक रूपमा हामी प्रयोग गर्छौं नेक्सस भण्डारहरू प्रबन्ध गर्नका लागि, सहित आन्तरिक REPO। यो आन्तरिक भण्डारमा हामीले आन्तरिक उद्देश्यका लागि प्रयोग गर्ने सबै कम्पोनेन्टहरू समावेश गर्दछ, उदाहरणका लागि, स्व-लिखित निगरानी।

हामी पनि प्रयोग गर्छौं नुगेट, अन्य प्याकेज प्रबन्धकहरूको तुलनामा यसमा राम्रो क्यासिङ छ।

परिणाम

हामीले बिल्ड एजेन्टहरूलाई अप्टिमाइज गरेपछि, औसत निर्माण समय 12 मिनेटबाट 7 मा घटाइयो।

यदि हामीले विन्डोजको लागि प्रयोग गर्न सक्ने सबै मेसिनहरू गणना गर्छौं, तर यस परियोजनामा ​​लिनक्समा स्विच गर्यौं भने, हामीले लगभग $10 बचत गर्छौं। र त्यो केवल इजाजतपत्रहरूमा मात्र हो, र यदि हामीले सामग्रीलाई ध्यानमा राख्यौं भने।

योजनाहरु

अर्को क्वार्टरको लागि, हामीले कोड डेलिभरीलाई अनुकूलन गर्ने काम गर्ने योजना बनाएका छौं।

प्रिबिल्ड डकर छविमा स्विच गर्दै। TFS धेरै प्लगइनहरूसँग एक राम्रो चीज हो जसले तपाईंलाई पाइपलाइनमा एकीकृत गर्न अनुमति दिन्छ, ट्रिगर-आधारित असेंबली सहित, भन्नुहोस्, एक डकर छवि। हामी यो ट्रिगर एउटैको लागि बनाउन चाहन्छौं package-lock.json। यदि परियोजना निर्माण गर्न प्रयोग गरिएका कम्पोनेन्टहरूको संरचना कुनै न कुनै रूपमा परिवर्तन भयो भने, हामी नयाँ डकर छवि निर्माण गर्छौं। यो पछि कन्टेनरलाई एसेम्बल गरिएको एप्लिकेसनको साथ प्रयोग गर्न प्रयोग गरिन्छ। अहिले यो अवस्था छैन, तर हामी Kubernetes मा माइक्रोसर्भिस आर्किटेक्चरमा स्विच गर्ने योजना गर्दैछौं, जुन हाम्रो कम्पनीमा सक्रिय रूपमा विकास भइरहेको छ र लामो समयदेखि उत्पादन समाधानहरू प्रदान गर्दै आएको छ।

सारांश

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

अलेक्जेंडर सिन्चिनोभको स्पिकर प्रोफाइल GitHub मा.

DevOps Conf पेशेवरहरू द्वारा पेशेवरहरूको लागि विकास, परीक्षण र सञ्चालन प्रक्रियाहरूको एकीकरणमा सम्मेलन हो। त्यसकारण अलेक्ज्याण्डरले बोलेको परियोजना? कार्यान्वयन र काम, र प्रदर्शन को दिन मा दुई सफल रिलीज थिए। अन RIT++ मा DevOps Conf मे 27 र 28 मा चिकित्सकहरूबाट अझ धेरै समान केसहरू हुनेछन्। तपाईं अझै पनि अन्तिम गाडी मा हाम फाल्न सक्नुहुन्छ र प्रतिवेदन पेश गर्ने वा आफ्नो समय लिनुहोस् बुक गर्न टिकट। हामीलाई Skolkovo मा भेट्नुहोस्!

स्रोत: www.habr.com