Linux वर .NET Core, घोड्यावर DevOps

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

अशी कथा सुरू होते अलेक्झांड्रा सिंचिनोव्हा वर DevOpsConf. जेव्हा आघाडीच्या विंडोज तज्ञाने कंपनी सोडली तेव्हा अलेक्झांडरला आश्चर्य वाटले की आता काय करावे. लिनक्सवर स्विच करा, अर्थातच! अलेक्झांडर तुम्हाला 100 अंतिम वापरकर्त्यांसाठी पूर्ण झालेल्या प्रकल्पाचे उदाहरण वापरून विंडोज डेव्हलपमेंटचा काही भाग लिनक्समध्ये कसे हस्तांतरित करण्यात यशस्वी झाला हे सांगेल.

TFS, Puppet, Linux .NET core वापरून प्रकल्प RPM वर सहज आणि सहजतेने कसा वितरित करायचा? जर डेव्हलपमेंट टीमने पोस्टग्रेस आणि फ्लायवे हे शब्द पहिल्यांदा ऐकले आणि परवा ही अंतिम मुदत असेल तर प्रोजेक्ट डेटाबेसच्या आवृत्तीचे समर्थन कसे करावे? डॉकरसह कसे समाकलित करावे? .NET विकसकांना पपेट आणि लिनक्सच्या बाजूने विंडोज आणि स्मूदीज सोडून देण्यास कसे प्रवृत्त करावे? विंडोज उत्पादनात टिकवून ठेवण्याची ताकद, इच्छा किंवा संसाधने नसल्यास वैचारिक संघर्ष कसे सोडवायचे? याबद्दल, तसेच वेब डिप्लॉय, टेस्टिंग, CI बद्दल, विद्यमान प्रकल्पांमध्ये TFS वापरण्याच्या पद्धतींबद्दल आणि अर्थातच, अलेक्झांडरच्या अहवालाच्या प्रतिलिपीमध्ये, तुटलेल्या क्रॅचेस आणि कार्यरत उपायांबद्दल.

तर, वास्या निघून गेला, कार्य माझ्यावर आहे, विकसक पिचफोर्क्ससह अधीरपणे वाट पाहत आहेत. शेवटी जेव्हा मला समजले की वास्या परत येऊ शकत नाही, तेव्हा मी व्यवसायात उतरलो. सुरुवातीला, मी आमच्या फ्लीटमधील Win VM च्या टक्केवारीचे मूल्यांकन केले. स्कोअर विंडोजच्या बाजूने नव्हता.

आम्ही सक्रियपणे DevOps विकसित करत असल्याने, मला जाणवले की नवीन अनुप्रयोग वितरीत करण्याच्या दृष्टीकोनात काहीतरी बदलणे आवश्यक आहे. एकच उपाय होता - शक्य असल्यास, सर्वकाही Linux वर हस्तांतरित करा. Google ने मला मदत केली - त्या वेळी .Net आधीच Linux वर पोर्ट केले गेले होते, आणि मला समजले की हा उपाय आहे!

लिनक्सच्या संयोगाने .NET कोर का?

याची अनेक कारणे होती. "पैसे द्या" आणि "पैसे देऊ नका" मधील, बहुसंख्य दुसरा निवडतील - माझ्यासारखे. MSDB साठी परवान्याची किंमत सुमारे $1 आहे; विंडोज व्हर्च्युअल मशीन्सचा ताफा राखण्यासाठी शेकडो डॉलर्स खर्च करावे लागतात. मोठ्या कंपनीसाठी हा मोठा खर्च आहे. म्हणून बचत - पहिले कारण. सर्वात महत्वाचे नाही, परंतु महत्त्वपूर्णांपैकी एक.

विंडोज व्हर्च्युअल मशीन्स त्यांच्या लिनक्स बंधूंपेक्षा जास्त संसाधने घेतात - ते जड आहेत. मोठ्या कंपनीचे प्रमाण पाहता, आम्ही लिनक्स निवडले.

प्रणाली फक्त विद्यमान CI मध्ये समाकलित केली आहे. आम्ही स्वतःला प्रगतीशील DevOps समजतो, आम्ही बांबू, जेनकिन्स आणि GitLab CI वापरतो, त्यामुळे आमचे बहुतेक काम Linux वर चालते.

शेवटचे कारण आहे सोयीस्कर साथीदार. आम्हाला "एस्कॉर्ट्स" - तांत्रिक भाग समजून घेणारे, अखंड सेवा सुनिश्चित करणार्‍या आणि दुसऱ्या ओळीतून सेवा कायम ठेवणार्‍या मुलांसाठी प्रवेशाचा अडथळा कमी करणे आवश्यक होते. ते लिनक्स स्टॅकशी आधीच परिचित होते, त्यामुळे विंडोज प्लॅटफॉर्मसाठी सॉफ्टवेअरची समान कार्यक्षमता समजून घेण्यासाठी अतिरिक्त संसाधने खर्च करण्यापेक्षा नवीन उत्पादन समजून घेणे, समर्थन करणे आणि त्याची देखभाल करणे त्यांच्यासाठी खूप सोपे आहे.

आवश्यकता

प्रथम आणि सर्वात महत्त्वाचे - विकसकांसाठी नवीन समाधानाची सोय. ते सर्वच बदलासाठी तयार नव्हते, विशेषत: लिनक्स हा शब्द बोलल्यानंतर. विकसकांना त्यांचा आवडता व्हिज्युअल स्टुडिओ, असेंब्ली आणि स्मूदीजसाठी ऑटोटेस्टसह TFS हवा आहे. उत्पादनासाठी वितरण कसे होते हे त्यांच्यासाठी महत्त्वाचे नाही. म्हणून, आम्ही नेहमीच्या प्रक्रियेत बदल न करण्याचा आणि विंडोज डेव्हलपमेंटसाठी सर्वकाही अपरिवर्तित ठेवण्याचा निर्णय घेतला.

नवीन प्रकल्प आवश्यक विद्यमान CI मध्ये समाकलित करा. रेल तेथे आधीपासूनच होते आणि कॉन्फिगरेशन व्यवस्थापन प्रणालीचे मापदंड, स्वीकारलेले वितरण मानक आणि मॉनिटरिंग सिस्टम लक्षात घेऊन सर्व काम करावे लागले.

समर्थन आणि ऑपरेशन सुलभ, विविध विभाग आणि समर्थन विभागातील सर्व नवीन सहभागींसाठी किमान प्रवेश उंबरठ्याची अट म्हणून.

अंतिम मुदत - काल.

विकास गट जिंका

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

आता मी हे आत्मविश्वासाने सांगू शकतो IdentityServer4 तत्सम क्षमतेसह ADFS साठी एक छान विनामूल्य पर्याय आहे, किंवा काय एंटिटी फ्रेमवर्क कोर - विकसकासाठी नंदनवन, जिथे तुम्हाला SQL स्क्रिप्ट लिहिण्याचा त्रास घ्यावा लागत नाही, परंतु डेटाबेसमधील प्रश्नांचे OOP शब्दांमध्ये वर्णन करा. पण नंतर, कृती आराखड्याच्या चर्चेदरम्यान, मी या स्टॅककडे असे पाहिले की जणू ते सुमेरियन क्यूनिफॉर्म आहे, फक्त PostgreSQL आणि Git ओळखत आहे.

त्या वेळी आम्ही सक्रियपणे वापरत होतो कठपुतळी कॉन्फिगरेशन व्यवस्थापन प्रणाली म्हणून. आमच्या बहुतेक प्रकल्पांमध्ये आम्ही वापरले गिटलाब सीआय, लवचिक, वापरून संतुलित उच्च-भार सेवा HAProxy सह सर्व गोष्टींचे निरीक्षण केले झब्बीक्स, अस्थिबंधन ग्राफाना и Prometheus, जागर, आणि हे सर्व लोखंडाच्या तुकड्यांवर फिरत होते HP c ESXi वर व्हीएमवेअर. प्रत्येकाला हे माहित आहे - शैलीचा एक क्लासिक.

आपण हे सर्व हस्तक्षेप सुरू करण्यापूर्वी काय झाले ते पाहू आणि समजून घेण्याचा प्रयत्न करूया.

काय झालं

TFS ही एक बऱ्यापैकी शक्तिशाली प्रणाली आहे जी केवळ विकसकाकडून अंतिम उत्पादन मशीनपर्यंत कोड वितरीत करत नाही, तर विविध सेवांसह अतिशय लवचिक एकत्रीकरणासाठी एक संच आहे - क्रॉस-प्लॅटफॉर्म स्तरावर CI प्रदान करण्यासाठी.

पूर्वी या पक्क्या खिडक्या होत्या. TFS ने अनेक बिल्ड एजंट वापरले, जे अनेक प्रकल्प एकत्र करण्यासाठी वापरले गेले. प्रत्येक एजंटकडे कार्ये समांतर करण्यासाठी आणि प्रक्रिया ऑप्टिमाइझ करण्यासाठी 3-4 कामगार असतात. त्यानंतर, रिलीझ योजनांनुसार, TFS ने Windows ऍप्लिकेशन सर्व्हरवर ताजे बेक केलेले बिल्ड वितरित केले.

आम्हाला काय साध्य करायचे होते?

आम्ही डिलिव्हरी आणि डेव्हलपमेंटसाठी TFS वापरतो आणि लिनक्स ऍप्लिकेशन सर्व्हरवर ऍप्लिकेशन चालवतो आणि त्यांच्यामध्ये एक प्रकारची जादू आहे. या जादू बॉक्स आणि पुढे कामाचे मीठ आहे. मी ते वेगळे करण्यापूर्वी, मी एक पाऊल बाजूला घेईन आणि अर्जाबद्दल काही शब्द बोलेन.

प्रकल्प

अनुप्रयोग प्रीपेड कार्ड हाताळण्यासाठी कार्यक्षमता प्रदान करतो.

क्लायंट

दोन प्रकारचे वापरकर्ते होते. पहिला SSL SHA-2 प्रमाणपत्र वापरून लॉग इन करून प्रवेश मिळवला. यू दुसरा लॉगिन आणि पासवर्ड वापरून प्रवेश होता.

हाप्रोक्सी

मग क्लायंटची विनंती HAProxy कडे गेली, ज्याने खालील समस्यांचे निराकरण केले:

• प्राथमिक अधिकृतता;
• SSL समाप्ती;
• HTTP विनंत्या ट्यून करणे;
• प्रसारण विनंत्या.

क्लायंट प्रमाणपत्र साखळीसह सत्यापित केले गेले. आम्ही - अधिकार आणि आम्ही हे घेऊ शकतो, कारण आम्ही स्वतः सेवा ग्राहकांना प्रमाणपत्रे जारी करतो.

तिसऱ्या मुद्द्याकडे लक्ष द्या, आम्ही थोड्या वेळाने त्याकडे परत येऊ.

बॅकएंड

त्यांनी लिनक्सवर बॅकएंड बनवण्याची योजना आखली. बॅकएंड डेटाबेसशी संवाद साधतो, विशेषाधिकारांची आवश्यक यादी लोड करतो आणि नंतर, अधिकृत वापरकर्त्याला कोणते विशेषाधिकार आहेत यावर अवलंबून, आर्थिक दस्तऐवजांवर स्वाक्षरी करण्यासाठी प्रवेश प्रदान करतो आणि अंमलबजावणीसाठी पाठवतो किंवा काही प्रकारचा अहवाल तयार करतो.

HAProxy सह बचत

प्रत्येक क्लायंटने नेव्हिगेट केलेल्या दोन संदर्भांव्यतिरिक्त, एक ओळख संदर्भ देखील होता. IdentityServer4 फक्त तुम्हाला लॉग इन करण्याची परवानगी देते, यासाठी हे विनामूल्य आणि शक्तिशाली अॅनालॉग आहे ADFS - Directक्टिव डिरेक्टरी फेडरेशन सर्व्हिसेस.

ओळख विनंतीवर अनेक चरणांमध्ये प्रक्रिया केली गेली. पहिली पायरी - ग्राहक बॅकएंड मध्ये आला, ज्याने या सर्व्हरशी संवाद साधला आणि क्लायंटसाठी टोकनची उपस्थिती तपासली. जर ते सापडले नाही, तर विनंती ज्या संदर्भातून आली होती त्या संदर्भाकडे परत केली गेली, परंतु पुनर्निर्देशनासह, आणि पुनर्निर्देशनासह ती ओळखीकडे गेली.

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

तिसरी पायरी - क्लायंटला परत पाठवले गेले ज्या संदर्भात ते आले आहे.

IdentityServer4 चे वैशिष्ट्य आहे: ते HTTP द्वारे रिटर्न विनंतीला प्रतिसाद देते. सर्व्हर सेट करण्यासाठी आम्ही कितीही संघर्ष केला, आम्ही दस्तऐवजांसह कितीही प्रबोधन केले हे महत्त्वाचे नाही, प्रत्येक वेळी आम्हाला HTTPS द्वारे आलेल्या URL सह प्रारंभिक क्लायंट विनंती प्राप्त झाली आणि IdentityServer ने तोच संदर्भ परत केला, परंतु HTTP सह. आम्हाला धक्काच बसला! आणि आम्ही हे सर्व ओळखीच्या संदर्भाद्वारे HAProxy मध्ये हस्तांतरित केले, आणि हेडरमध्ये आम्हाला HTTP प्रोटोकॉल HTTPS मध्ये सुधारित करावे लागले.

सुधारणा काय आहे आणि आपण कुठे बचत केली आहे?

आम्ही वापरकर्त्यांचा समूह, संसाधने अधिकृत करण्यासाठी विनामूल्य उपाय वापरून पैसे वाचवले, कारण आम्ही IdentityServer4 हा वेगळा नोड म्हणून वेगळ्या विभागात ठेवला नाही, परंतु अनुप्रयोगाचा बॅकएंड ज्या सर्व्हरवर चालतो त्याच सर्व्हरवर बॅकएंडसह एकत्र वापरला. .

ते कसे कार्य करावे

तर, मी वचन दिल्याप्रमाणे - मॅजिक बॉक्स. आम्हाला आधीच समजले आहे की आम्हाला लिनक्सकडे जाण्याची हमी आहे. चला विशिष्ट कार्ये तयार करू ज्यासाठी उपाय आवश्यक आहेत.

कठपुतळी प्रकट होते. सेवा आणि अनुप्रयोग कॉन्फिगरेशन वितरीत आणि व्यवस्थापित करण्यासाठी, छान पाककृती लिहिणे आवश्यक होते. पेन्सिलचा रोल स्पष्टपणे दाखवतो की ते किती जलद आणि कार्यक्षमतेने केले गेले.

वितरण पद्धत. मानक RPM आहे. प्रत्येकजण समजतो की लिनक्समध्ये आपण त्याशिवाय करू शकत नाही, परंतु प्रकल्प स्वतःच, असेंब्लीनंतर, एक्झिक्युटेबल डीएलएल फायलींचा संच होता. त्यापैकी सुमारे 150 होते, प्रकल्प खूपच कठीण होता. या बायनरीला RPM मध्ये पॅकेज करणे आणि त्यातून अनुप्रयोग उपयोजित करणे हा एकमेव सामंजस्यपूर्ण उपाय आहे.

आवृत्ती तयार करणे. आम्हाला बर्‍याचदा सोडावे लागले आणि पॅकेजचे नाव कसे बनवायचे ते आम्हाला ठरवायचे होते. हा TFS सह एकत्रीकरणाच्या पातळीचा प्रश्न आहे. आमच्याकडे लिनक्सवर एक बिल्ड एजंट होता. जेव्हा TFS एखादे काम हँडलर - वर्करला - बिल्ड एजंटला पाठवते, तेव्हा ते हँडलर प्रक्रियेच्या वातावरणात संपलेल्या व्हेरिएबल्सचा एक समूह देखील देते. या पर्यावरण व्हेरिएबल्समध्ये बिल्डचे नाव, आवृत्तीचे नाव आणि इतर व्हेरिएबल्स असतात. याबद्दल अधिक वाचा “RPM पॅकेज तयार करणे” विभागात.

TFS सेट करत आहे पाईपलाईन उभारण्यासाठी खाली आले. पूर्वी, आम्ही विंडोज एजंट्सवर सर्व विंडोज प्रकल्प एकत्रित केले, परंतु आता एक लिनक्स एजंट दिसतो - एक बिल्ड एजंट, ज्याला बिल्ड ग्रुपमध्ये समाविष्ट करणे आवश्यक आहे, काही कलाकृतींनी समृद्ध केले पाहिजे आणि या बिल्ड एजंटवर कोणत्या प्रकारचे प्रकल्प तयार केले जातील ते सांगितले. , आणि कसा तरी पाइपलाइन सुधारित करा.

आयडेंटिटी सर्व्हर. ADFS हा आमचा मार्ग नाही, आम्ही मुक्त स्रोतासाठी जात आहोत.

चला घटकांमधून जाऊया.

जादू बॉक्स

चार भागांचा समावेश होतो.

लिनक्स बिल्ड एजंट. लिनक्स, कारण आम्ही त्यासाठी तयार करतो - ते तार्किक आहे. हा भाग तीन टप्प्यांत केला होता.

• कामगार कॉन्फिगर करा आणि एकट्याने नाही, कारण प्रकल्पावर वितरित काम अपेक्षित होते.
• .NET Core 1.x स्थापित करा. 1.x का 2.0 आधीपासून मानक भांडारात उपलब्ध आहे? कारण जेव्हा आम्ही विकास सुरू केला तेव्हा स्थिर आवृत्ती 1.09 होती, आणि त्यावर आधारित प्रकल्प बनवण्याचा निर्णय घेण्यात आला.
• Git 2.x.

RPM-रेपॉजिटरी. RPM पॅकेजेस कुठेतरी संग्रहित करणे आवश्यक आहे. असे गृहीत धरले होते की आम्ही समान कॉर्पोरेट RPM रेपॉजिटरी वापरू जे सर्व Linux होस्टसाठी उपलब्ध आहे. त्यांनी तेच केले. रेपॉजिटरी सर्व्हर कॉन्फिगर केले आहे वेबहूक ज्याने निर्दिष्ट स्थानावरून आवश्यक RPM पॅकेज डाउनलोड केले. बिल्ड एजंटद्वारे पॅकेज आवृत्तीची वेबहुकला तक्रार करण्यात आली.

गिटलॅब. लक्ष द्या! GitLab येथे विकसकांद्वारे वापरले जात नाही, परंतु ऑपरेशन्स विभागाद्वारे ऍप्लिकेशन आवृत्त्या, पॅकेज आवृत्त्या नियंत्रित करण्यासाठी, सर्व लिनक्स मशीनच्या स्थितीचे निरीक्षण करण्यासाठी वापरले जाते आणि ते रेसिपी संग्रहित करते - सर्व पपेट मॅनिफेस्ट.

कठपुतळी — सर्व वादग्रस्त समस्यांचे निराकरण करते आणि गिटलॅबकडून आम्हाला हवे असलेले कॉन्फिगरेशन वितरीत करते.

आम्ही डुबकी मारण्यास सुरवात करतो. RPM वर DLL वितरण कसे कार्य करते?

RPM वर DDL वितरण

समजा आमच्याकडे .NET डेव्हलपमेंट रॉक स्टार आहे. हे व्हिज्युअल स्टुडिओ वापरते आणि प्रकाशन शाखा तयार करते. त्यानंतर, ते Git वर अपलोड करते, आणि Git येथे एक TFS अस्तित्व आहे, म्हणजेच ते अनुप्रयोग भांडार आहे ज्यासह विकसक कार्य करतो.

ज्यानंतर TFS पाहते की एक नवीन कमिट आले आहे. कोणते अॅप? TFS सेटिंग्जमध्ये विशिष्ट बिल्ड एजंटकडे कोणती संसाधने आहेत हे दर्शवणारे लेबल असते. या प्रकरणात, तो पाहतो की आपण एक .NET कोर प्रकल्प तयार करत आहोत आणि पूलमधून लिनक्स बिल्ड एजंट निवडतो.

बिल्ड एजंट स्रोत प्राप्त करतो आणि आवश्यक ते डाउनलोड करतो अवलंबित्व .NET रेपॉजिटरी, npm, इ. आणि ॲप्लिकेशन स्वतः तयार केल्यानंतर आणि त्यानंतरचे पॅकेजिंग, RPM पॅकेज RPM रेपॉजिटरीकडे पाठवते.

दुसरीकडे, खालील घडते. ऑपरेशन्स विभाग अभियंता प्रकल्पाच्या रोलआउटमध्ये थेट सामील आहे: तो पॅकेजच्या आवृत्त्या बदलतो हिरा रिपॉजिटरीमध्ये जेथे ऍप्लिकेशन रेसिपी संग्रहित केली जाते, त्यानंतर पपेट ट्रिगर होते हं, रेपॉजिटरीमधून नवीन पॅकेज आणते आणि अनुप्रयोगाची नवीन आवृत्ती वापरण्यासाठी तयार आहे.

सर्व काही शब्दात सोपे आहे, परंतु बिल्ड एजंटच्या आत काय होते?

पॅकेजिंग DLL RPM

TFS कडून प्रकल्प स्रोत आणि बिल्ड टास्क प्राप्त झाले. एजंट तयार करा स्त्रोतांकडूनच प्रकल्प तयार करण्यास सुरुवात करते. एकत्रित प्रकल्प एक संच म्हणून उपलब्ध आहे DLL फायली, जे फाईल सिस्टीमवरील भार कमी करण्यासाठी झिप आर्काइव्हमध्ये पॅक केले जातात.

झिप संग्रहण फेकून दिले आहे RPM पॅकेज बिल्ड निर्देशिकेत. पुढे, बॅश स्क्रिप्ट पर्यावरण व्हेरिएबल्स सुरू करते, बिल्ड आवृत्ती, प्रोजेक्ट आवृत्ती, बिल्ड डिरेक्टरीचा मार्ग शोधते आणि RPM-बिल्ड चालवते. एकदा बिल्ड पूर्ण झाल्यावर, पॅकेज प्रकाशित केले जाईल स्थानिक भांडार, जे बिल्ड एजंटवर स्थित आहे.

पुढे, बिल्ड एजंटपासून RPM रेपॉजिटरीमधील सर्व्हरपर्यंत JSON विनंती पाठवली आहे आवृत्ती आणि बिल्डचे नाव दर्शवित आहे. वेबहूक, ज्याबद्दल मी आधी बोललो होतो, हेच पॅकेज बिल्ड एजंटवरील स्थानिक भांडारातून डाउनलोड करते आणि नवीन असेंब्ली इंस्टॉलेशनसाठी उपलब्ध करते.

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

डेटाबेस आवृत्ती

डेव्हलपमेंट टीमशी सल्लामसलत केल्यावर, असे दिसून आले की मुले एमएस एसक्यूएलच्या जवळ आहेत, परंतु बहुतेक नॉन-विंडोज प्रोजेक्टमध्ये आम्ही आधीच पोस्टग्रेएसक्यूएल त्यांच्या सर्व शक्तीने वापरत आहोत. आम्ही आधीच दिलेली प्रत्येक गोष्ट सोडून देण्याचा निर्णय घेतल्याने, आम्ही येथे देखील PostgreSQL वापरण्यास सुरुवात केली.

या भागात मी तुम्हाला सांगू इच्छितो की आम्ही डेटाबेसची आवृत्ती कशी तयार केली आणि आम्ही Flyway आणि Entity Framework Core मधील निवड कशी केली. चला त्यांचे फायदे आणि तोटे पाहू.

मिनिन्स

फ्लायवे फक्त एका मार्गाने जातो, आम्ही आम्ही मागे फिरू शकत नाही - हे एक महत्त्वपूर्ण नुकसान आहे. तुम्ही त्याची तुलना इतर मार्गांनी - विकासकाच्या सोयीनुसार Entity Framework Core शी करू शकता. तुम्हाला आठवत असेल की आम्ही हे अग्रस्थानी ठेवले आहे आणि मुख्य निकष म्हणजे विंडोज डेव्हलपमेंटसाठी काहीही बदलू नये.

फ्लायवे आमच्यासाठी काही प्रकारचे रॅपर आवश्यक होतेजेणेकरून मुले लिहू नयेत SQL क्वेरी. ते OOP अटींमध्ये कार्य करण्याच्या खूप जवळ आहेत. आम्ही डेटाबेस ऑब्जेक्ट्ससह कार्य करण्यासाठी सूचना लिहिल्या, SQL क्वेरी तयार केली आणि ती कार्यान्वित केली. डेटाबेसची नवीन आवृत्ती तयार आहे, चाचणी केली आहे - सर्वकाही ठीक आहे, सर्वकाही कार्य करते.

एंटिटी फ्रेमवर्क कोरमध्ये एक वजा आहे - ते जास्त भाराखाली आहे सबऑप्टिमल SQL क्वेरी तयार करते, आणि डेटाबेसमधील ड्रॉडाउन महत्त्वपूर्ण असू शकते. परंतु आमच्याकडे उच्च-लोड सेवा नसल्यामुळे, आम्ही शेकडो आरपीएसमध्ये लोडची गणना करत नाही, आम्ही ही जोखीम स्वीकारली आणि भविष्यातील समस्या आमच्याकडे सोपवली.

Плюсы

एंटिटी फ्रेमवर्क कोर बॉक्सच्या बाहेर कार्य करते आणि विकसित करणे सोपे आहे, आणि फ्लायवे विद्यमान CI मध्ये सहजपणे समाकलित होते. परंतु आम्ही ते विकसकांसाठी सोयीस्कर बनवतो :)

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

पपेट पाहते की पॅकेज आवृत्तीमध्ये बदल येत आहे, ज्यामध्ये स्थलांतरासाठी जबाबदार आहे. प्रथम, ते एक पॅकेज स्थापित करते ज्यामध्ये मायग्रेशन स्क्रिप्ट आणि डेटाबेस-संबंधित कार्यक्षमता असते. यानंतर, डेटाबेससह कार्य करणारा अनुप्रयोग रीस्टार्ट केला जातो. पुढे उर्वरित घटकांची स्थापना येते. पपेट मॅनिफेस्टमध्ये ज्या क्रमाने पॅकेजेस इन्स्टॉल केले जातात आणि अॅप्लिकेशन लॉन्च केले जातात त्याचे वर्णन केले आहे.

अनुप्रयोग संवेदनशील डेटा वापरतात, जसे की टोकन, डेटाबेस पासवर्ड, हे सर्व पपेट मास्टरच्या कॉन्फिगरेशनमध्ये खेचले जाते, जेथे ते एनक्रिप्टेड स्वरूपात संग्रहित केले जातात.

TFS समस्या

आम्‍ही ठरवल्‍यानंतर आणि सर्वकाही खरोखरच आमच्यासाठी कार्य करत आहे हे लक्षात आल्‍यानंतर, मी इतर प्रकल्पांवरील विन डेव्हलपमेंट डिपार्टमेंटसाठी संपूर्णपणे TFS मधील असेंब्लीमध्ये काय चालले आहे ते पाहण्‍याचे ठरवले - आम्‍ही त्‍वरितपणे तयार/रिलीज करत आहोत की नाही, आणि गतीसह महत्त्वपूर्ण समस्या शोधल्या.

मुख्य प्रकल्पांपैकी एकाला जमण्यासाठी 12-15 मिनिटे लागतात - तो बराच काळ आहे, आपण असे जगू शकत नाही. द्रुत विश्लेषणाने I/O मध्ये भयंकर घट दर्शविली आणि हे अॅरेवर होते.

घटकानुसार घटकाचे विश्लेषण केल्यानंतर, मी तीन केंद्रे ओळखली. पहिला - "कॅस्परस्की अँटीव्हायरस", जे सर्व विंडोज बिल्ड एजंट्सवरील स्त्रोत स्कॅन करते. दुसरा - विंडोज इंडेक्सर. ते अक्षम केलेले नव्हते, आणि तैनाती प्रक्रियेदरम्यान बिल्ड एजंट्सवर सर्वकाही रिअल टाइममध्ये अनुक्रमित केले गेले होते.

तिसऱ्या - एनपीएम स्थापित करा. असे दिसून आले की बहुतेक पाइपलाइनमध्ये आम्ही ही अचूक परिस्थिती वापरली आहे. तो वाईट का आहे? जेव्हा अवलंबित्व वृक्ष तयार होतो तेव्हा Npm स्थापना प्रक्रिया चालविली जाते package-lock.json, जेथे प्रकल्प तयार करण्यासाठी वापरल्या जाणार्‍या पॅकेजच्या आवृत्त्या रेकॉर्ड केल्या जातात. नकारात्मक बाजू अशी आहे की एनपीएम इंस्टॉल प्रत्येक वेळी इंटरनेटवरून पॅकेजेसच्या नवीनतम आवृत्त्या काढते आणि मोठ्या प्रकल्पाच्या बाबतीत यास बराच वेळ लागतो.

एखादा विशिष्ट भाग किंवा संपूर्ण प्रकल्प कसा कार्य करतो हे तपासण्यासाठी विकसक कधीकधी स्थानिक मशीनवर प्रयोग करतात. कधीकधी असे दिसून आले की सर्व काही स्थानिक पातळीवर थंड होते, परंतु त्यांनी ते एकत्र केले, ते रोल आउट केले आणि काहीही कार्य केले नाही. आम्ही समस्या काय आहे ते शोधू लागतो - होय, अवलंबित्वांसह पॅकेजच्या भिन्न आवृत्त्या.

निर्णय

• AV अपवाद मध्ये स्रोत.
• अनुक्रमणिका अक्षम करा.
• जा npm ci.

npm ci चे फायदे म्हणजे आम्ही आम्ही एकदा अवलंबित्व वृक्ष गोळा करतो, आणि आम्हाला विकसक प्रदान करण्याची संधी मिळते पॅकेजची वर्तमान यादी, ज्याद्वारे तो त्याला आवडेल तितका स्थानिक प्रयोग करू शकतो. या वेळ वाचवतो विकासक जे कोड लिहितात.

कॉन्फिगरेशन

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

आम्ही देखील वापरतो न्यूजीट, कारण इतर पॅकेज व्यवस्थापकांच्या तुलनेत त्यात उत्तम कॅशिंग आहे.

परिणाम

आम्ही बिल्ड एजंट्स ऑप्टिमाइझ केल्यानंतर, सरासरी बिल्ड वेळ 12 मिनिटांवरून 7 पर्यंत कमी करण्यात आला.

जर आम्ही सर्व मशीन्स मोजल्या ज्या आम्ही विंडोजसाठी वापरू शकलो असतो, परंतु या प्रकल्पात लिनक्सवर स्विच केले तर आम्ही सुमारे $10 वाचवतो. आणि ते फक्त परवान्यांवर आहे आणि आम्ही सामग्री विचारात घेतल्यास अधिक.

योजना

पुढील तिमाहीसाठी, आम्ही कोड वितरण ऑप्टिमाइझ करण्यावर काम करण्याची योजना आखली आहे.

प्रीबिल्ड डॉकर इमेजवर स्विच करत आहे. TFS ही अनेक प्लगइन्ससह एक छान गोष्ट आहे जी तुम्हाला पाइपलाइनमध्ये समाकलित करण्याची परवानगी देते, जसे की, डॉकर इमेजच्या ट्रिगर-आधारित असेंब्लीसह. आम्हाला हा ट्रिगर त्याचसाठी बनवायचा आहे package-lock.json. प्रकल्प तयार करण्यासाठी वापरल्या जाणार्‍या घटकांची रचना काही प्रमाणात बदलल्यास, आम्ही एक नवीन डॉकर प्रतिमा तयार करतो. हे नंतर एकत्रित केलेल्या अनुप्रयोगासह कंटेनर तैनात करण्यासाठी वापरले जाते. आता असे नाही, परंतु आम्ही कुबर्नेट्समधील मायक्रोसर्व्हिस आर्किटेक्चरवर स्विच करण्याचा विचार करत आहोत, जे आमच्या कंपनीमध्ये सक्रियपणे विकसित होत आहे आणि बर्याच काळापासून उत्पादन समाधाने देत आहे.

सारांश

मी प्रत्येकाला विंडोज फेकून देण्यास प्रोत्साहित करतो, परंतु असे नाही कारण मला ते कसे शिजवायचे हे माहित नाही. कारण बहुतेक Opensource उपाय आहेत लिनक्स स्टॅक. तू ठीक आहेस ना संसाधनांवर बचत करा. माझ्या मते, भविष्य हे एका शक्तिशाली समुदायासह लिनक्सवरील ओपन सोर्स सोल्यूशन्सचे आहे.

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

DevOps Conf व्यावसायिकांद्वारे व्यावसायिकांसाठी विकास, चाचणी आणि ऑपरेशन प्रक्रियेच्या एकत्रीकरणावर एक परिषद आहे. म्हणूनच अलेक्झांडर ज्या प्रकल्पाबद्दल बोलला होता? अंमलात आणले आणि कार्य केले, आणि कामगिरीच्या दिवशी दोन यशस्वी रिलीझ झाले. चालू RIT++ वर DevOps Conf 27 आणि 28 मे रोजी प्रॅक्टिशनर्सकडून आणखी समान प्रकरणे असतील. आपण अद्याप शेवटच्या कॅरेजमध्ये उडी मारू शकता आणि अहवाल सादर करा किंवा तुमचा वेळ घ्या बुक करणे तिकीट आम्हाला Skolkovo मध्ये भेटा!

स्त्रोत: www.habr.com