🗯️ 🙌🏼 👾 .NET कोर और कुबेरनेट्स पर एक एप्लीकेशन का निर्माण: हमारा अनुभव 🚶🏻 🤴 🙆🏿

सभी को नमस्कार!

आज हम अपने एक DevOps प्रोजेक्ट के अनुभव के बारे में बात करेंगे। हमने एक microservice आर्किटेक्चर पर .Net कोर का उपयोग करके लिनक्स के लिए एक नया एप्लिकेशन लागू करने का निर्णय लिया।

हम उम्मीद करते हैं कि परियोजना सक्रिय रूप से विकसित होगी, और अधिक से अधिक उपयोगकर्ता होंगे। इसलिए, यह कार्यक्षमता और प्रदर्शन दोनों के मामले में आसानी से मापनीय होना चाहिए।

हमें एक दोष-सहिष्णु प्रणाली की आवश्यकता है - यदि कार्यक्षमता का एक ब्लॉक काम नहीं करता है, तो बाकी को काम करना चाहिए। हम ग्राहक के सर्वर पर समाधान की तैनाती सहित निरंतर एकीकरण सुनिश्चित करना चाहते हैं।

इसलिए, हमने निम्नलिखित तकनीकों का उपयोग किया:

। माइक्रोसॉफ़्ट कार्यान्वयन के लिए .नेट कोर। हमारी परियोजना ने संस्करण 2.0 का उपयोग किया,
सूक्ष्मजीवों के ऑर्केस्ट्रेशन के लिए कुबेरनेट्स,
माइक्रोसेर छवियों को बनाने के लिए डॉकर,
एकीकरण बस खरगोश एमक्यू और मास ट्रांजिट,
लॉगिंग के लिए एलिटिक्स खोज और किबाना,
CI / CD पाइपलाइन को लागू करने के लिए TFS।

यह लेख हमारे समाधान का विवरण साझा करेगा।

यह .NET मीटिंग में हमारे भाषण का एक ट्रांसक्रिप्ट है, यहां भाषण के वीडियो का लिंक है ।

हमारे व्यापार चुनौती

हमारा ग्राहक एक संघीय कंपनी है जहां व्यापारी हैं - ये वे लोग हैं जो दुकानों में सामान कैसे प्रस्तुत किए जाते हैं इसके लिए जिम्मेदार हैं। और पर्यवेक्षक हैं - ये व्यापारियों के नेता हैं।

कंपनी के पास पर्यवेक्षकों द्वारा व्यापारियों के काम का प्रशिक्षण और मूल्यांकन करने की एक प्रक्रिया है, जिसे स्वचालित करने की आवश्यकता है।

यहां बताया गया है कि हमारा समाधान कैसे काम करता है:

1. पर्यवेक्षक एक प्रश्नावली तैयार करता है - यह एक चेकलिस्ट है जिसे आपको माल के काम में जांचने की आवश्यकता है।
2. इसके बाद, पर्यवेक्षक उस कर्मचारी का चयन करता है जिसके काम की जाँच की जाएगी। प्रश्न दिनांक सौंपा गया है।
3. इसके बाद, गतिविधि पर्यवेक्षक के मोबाइल डिवाइस पर भेजी जाती है।
4. फिर प्रश्नावली को भरकर पोर्टल पर भेज दिया जाता है।
5. पोर्टल परिणाम और विभिन्न रिपोर्ट तैयार करता है।

माइक्रोसोर्सेज हमें तीन समस्याओं को हल करने में मदद करेगा:

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

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

इस समाधान को लागू करने में किन तकनीकों ने मदद की:

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

यहाँ प्रौद्योगिकियों का हमारा पूरा सेट है:

•। नेट कोर हम microservices बनाने के लिए उपयोग करते हैं,
• माइक्रोस्‍कोर्स को डॉकर इमेज में पैक किया गया है,
• टीएफएस का उपयोग करके निरंतर एकीकरण और निरंतर वितरण लागू किया जाता है,
• सामने के छोर को कोणीय में लागू किया गया है,
• निगरानी और लॉगिंग के लिए हम इलास्टिसर्च और किबाना का उपयोग करते हैं,
• RabbitMQ और MassTransit को एकीकरण बस के रूप में उपयोग किया जाता है।

लिनक्स समाधान के लिए .NET कोर

हम सभी जानते हैं कि क्लासिक .Net फ्रेमवर्क क्या है। मंच का मुख्य नुकसान यह है कि यह क्रॉस-प्लेटफॉर्म नहीं है। तदनुसार, हम Docker में Linux के लिए .Net फ्रेमवर्क पर समाधान नहीं चला सकते हैं।

डॉकर में C # का उपयोग करने की क्षमता प्रदान करने के लिए, Microsoft ने .Net फ्रेमवर्क और बनाया .Net कोर को फिर से लाया। और उन्हीं पुस्तकालयों का उपयोग करने के लिए, Microsoft ने .Net मानक लाइब्रेरी विनिर्देश बनाया। .Net Standart लाइब्रेरी असेंबली का उपयोग .Net फ्रेमवर्क और .Net कोर दोनों में किया जा सकता है।

कुबेरनेट्स - माइक्रोसेर्विस ऑर्केस्ट्रेशन के लिए

कुबेरनेट का उपयोग डॉकटर कंटेनरों के प्रबंधन और क्लस्टर के लिए किया जाता है। कुबेरनेट्स के मुख्य लाभ इस प्रकार हैं:

- आसानी से microservices के वातावरण को कॉन्फ़िगर करने की क्षमता प्रदान करता है,
- पर्यावरण प्रबंधन को सरल करता है (देव, क्यूए, स्टेज),
- बॉक्स के बाहर माइक्रोसेक्यूल को दोहराने और प्रतिकृतियों पर संतुलन को लोड करने की क्षमता प्रदान करता है।

समाधान वास्तुकला

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

नतीजतन, हमने ऐसी सेवाएं दिखाई हैं जो प्रश्नावली की योजना बनाने में लगे हुए हैं, परिणाम प्रदर्शित करने के लिए एक माइक्रो सर्विस, एक मोबाइल एप्लिकेशन के साथ काम करने के लिए एक माइक्रो सर्विस और अन्य माइक्रोसर्विस।

बाहरी ग्राहकों के साथ बातचीत करने के विकल्प

Microsoft माइक्रोसॉर्क्स पर अपनी पुस्तक में, “ .NET माइक्रोसर्विसेज। .NET कंटेनर एप्लीकेशन आर्किटेक्चर ”माइक्रोसर्विस के साथ सहभागिता के तीन संभावित कार्यान्वयन प्रदान करता है। हमने तीनों की समीक्षा की और सबसे उपयुक्त चुना।

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

• एज़्योर एपीआई प्रबंधन के साथ एपीआई गेटवे
Microsoft Azure में क्लाउड फ़ेसडे का उपयोग करने की क्षमता प्रदान करता है। लेकिन यह समाधान फिट नहीं हुआ, क्योंकि हम समाधान को क्लाउड में नहीं, बल्कि ग्राहक के सर्वर पर तैनात करने जा रहे थे।

• डायरेक्ट क्लाइंट-टू-मिक्रोसवर्क संचार
नतीजतन, हमारे पास अंतिम विकल्प बचा है - प्रत्यक्ष उपयोगकर्ता इंटरैक्शन माइक्रोसर्विस के साथ। हमने उसे चुना।

गलती सहिष्णुता में इसके प्लस। नकारात्मक पक्ष यह है कि कार्यक्षमता का हिस्सा प्रत्येक सेवा पर अलग से पुन: प्रस्तुत करना होगा। उदाहरण के लिए, प्रत्येक microservice पर प्राधिकरण को अलग से कॉन्फ़िगर करना आवश्यक था, जिसके लिए उपयोगकर्ताओं तक पहुंच है।

बेशक, सवाल उठता है कि हम भार को कैसे संतुलित करेंगे और दोष सहिष्णुता कैसे लागू होगी। यहां सब कुछ सरल है - इनग्रेडेशन कंट्रोलर कुबेरनेट्स ऐसा करता है।

नोड 1, नोड 2 और नोड 3 एक ही माइक्रोसैस सर्विस की प्रतिकृतियां हैं। यदि प्रतिकृतियों में से एक विफल हो जाता है, तो लोड बैलेंसर स्वचालित रूप से लोड को अन्य माइक्रोसर्विसेज पर पुनर्निर्देशित कर देगा।

भौतिक वास्तुकला

यहां हमने अपने समाधान के बुनियादी ढांचे का आयोजन किया है:

• प्रत्येक माइक्रोसर्विस का अपना डेटाबेस होता है (यदि वह, निश्चित रूप से, इसकी आवश्यकता है), अन्य सेवाएं दूसरे माइक्रोसेवा के डेटाबेस तक नहीं पहुंचती हैं।
• माइक्रोसेबल्स केवल RabbitMQ + मास ट्रांजिट बस के माध्यम से, साथ ही साथ HTTP अनुरोधों का उपयोग करके एक दूसरे के साथ संवाद करते हैं।
• प्रत्येक सेवा की अपनी स्पष्ट रूप से परिभाषित जिम्मेदारी है।
• लॉगिंग के लिए हम सेरीलॉग के साथ काम करने के लिए एलाटिसिसर्च और किबाना और लाइब्रेरी का उपयोग करते हैं।

डेटाबेस सेवा को एक अलग वर्चुअल मशीन पर तैनात किया गया था, और कुबेरनेट्स में नहीं, क्योंकि Microsoft DBMS उत्पाद वातावरण पर डॉकर का उपयोग करने की अनुशंसा नहीं करता है।

लॉगिंग सेवा को गलती सहिष्णुता के कारणों के लिए एक अलग वर्चुअल मशीन पर भी तैनात किया गया था - अगर हमें कुबेरनेट की समस्या है, तो हम यह पता लगा सकते हैं कि समस्या क्या है।

तैनाती: हमने विकास और उत्पाद वातावरण को कैसे व्यवस्थित किया

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

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

प्रत्येक 10 माइक्रोसर्विसेस के साथ 5 वातावरण कैसे तैनात करें?

औसतन, हमारे पास प्रति प्रोजेक्ट 10 सेवाएं हैं और तीन वातावरण हैं: क्यूए, डीईवी, स्टेज, जिस पर कुल मिलाकर लगभग 30 माइक्रोसेवा तैनात हैं। और यह केवल विकास के बुनियादी ढांचे पर है! ग्राहक के बुनियादी ढांचे पर 2 और वातावरण जोड़ें, और हमें 50 माइक्रोसर्विसेज मिलते हैं।

यह स्पष्ट है कि इस तरह की कई सेवाओं को किसी न किसी तरह से प्रबंधित किया जाना चाहिए। कुबेरनेट्स इसमें हमारी मदद करते हैं।

आदेश में एक microservice तैनात करने के लिए, आप चाहिए
• विस्तार गुप्त,
• नियोजन की तैनाती,
• सेवा का विस्तार करें।

नीचे गुप्त रहस्य के बारे में।
तैनाती कुबेरनेट्स के लिए एक निर्देश है, जिसके आधार पर यह हमारे माइक्रोसेवर के डॉकटर कंटेनर को लॉन्च करेगा। यहां वह कमांड है जो तैनाती के लिए तैनात है:

kubectl apply -f .\(yaml deployment-) --namespace=DEV

 apiVersion: apps/v1beta1 kind: Deployment metadata: name: imtob-etr-it-dictionary-api spec: replicas: 1 template: metadata: labels: name: imtob-etr-it-dictionary-api spec: containers: - name: imtob-etr-it-dictionary-api image: nexus3.company.ru:18085/etr-it-dictionary-api:18289 resources: requests: memory: "256Mi" limits: memory: "512Mi" volumeMounts: - name: secrets mountPath: /app/secrets readOnly: true volumes: - name: secrets secret: secretName: secret-appsettings-dictionary

यह फ़ाइल वर्णन करती है कि परिनियोजन को क्या कहा जाता है (imtob-etr-it-dictionary-api), इसे निष्पादन के लिए किस छवि का उपयोग करने की आवश्यकता है, साथ ही अन्य सेटिंग्स। गुप्त अनुभाग में, हम अपने पर्यावरण को अनुकूलित करेंगे।

तैनाती को लागू करने के बाद, यदि आवश्यक हो, तो हमें सेवा को तैनात करने की आवश्यकता है।

जब बाहर से माइक्रो सेवा की आवश्यकता होती है तो सेवाओं की आवश्यकता होती है। उदाहरण के लिए, जब आप चाहते हैं कि कोई उपयोगकर्ता या कोई अन्य माइक्रोसेवा सेवा किसी अन्य माइक्रोसेवा से अनुरोध करने में सक्षम हो।

kubectl apply -f .\imtob-etr-it-dictionary-api.yml --namespace=DEV

 apiVersion: v1 kind: Service metadata: name: imtob-etr-it-dictionary-api-services spec: ports: - name: http port: 80 targetPort: 80 protocol: TCP selector: name: imtob-etr-it-dictionary-api

आमतौर पर सेवा का विवरण छोटा होता है। इसमें हम सेवा का नाम देखते हैं, इसे कैसे एक्सेस किया जा सकता है और पोर्ट नंबर।

नतीजतन, पर्यावरण को तैनात करने के लिए, हमें जरूरत है

• सभी माइक्रोसर्विसेज के लिए रहस्यों वाली फाइलों का एक सेट,
• सभी microservices की तैनाती के साथ फ़ाइलों का एक सेट,
• सभी microservices की सेवाओं के साथ फ़ाइलों का एक सेट।

हम इन सभी लिपियों को गिट रिपॉजिटरी में संग्रहीत करते हैं।

समाधान को तैनात करने के लिए, हमें तीन प्रकार की स्क्रिप्ट का एक सेट मिला:

• रहस्यों के साथ फ़ोल्डर - ये प्रत्येक पर्यावरण के लिए विन्यास हैं,
• सभी माइक्रोसर्विसेज के लिए तैनाती वाला फ़ोल्डर,
कुछ microservices के लिए सेवाओं के साथ • फ़ोल्डर,

प्रत्येक में - दस टीमों के बारे में, प्रत्येक के लिए एक microservice। सुविधा के लिए, हमने कॉन्फ्लुएंस में स्क्रिप्ट के साथ एक पेज बनाया है, जो हमें एक नए वातावरण को शीघ्रता से लागू करने में मदद करता है।

यहाँ एक परिनियोजन परिनियोजन स्क्रिप्ट है (गुप्त और सेवा के लिए समान सेट हैं):

परिनियोजन लिपि

kubectl लागू करें -f। \ imtob-etr-it-image-api.yml - namespp = v
kubectl apply -f। \ imtob-etr-it-mobile-api.yml - namespp = v
kubectl लागू करें -f। \ imtob-etr-it-planning-api.yml --namespp =V
kubectl apply -f। \ imtob-etr-it-result-api.yml --namespp =V
kubectl लागू करें -f। \ imtob-etr-it-web.yml --namespace = DEV
kubectl apply -f। \ imtob-etr-it-report-api.yml --namespp =V
kubectl apply -f। \ imtob-etr-it-template-constructor-api.yml --namespace = DEV
kubectl apply -f। \ imtob-etr-it-dictionary-api.yml --namespp =V
kubectl apply -f। \ imtob-etr-it-एकीकरण-api.yml --namespp =V
kubectl apply -f। \ imtob-etr-it-identity-api.yml --namespp =V

सीआई / सीडी कार्यान्वयन

प्रत्येक सेवा अपने स्वयं के फ़ोल्डर में है, साथ ही हमारे पास सामान्य घटकों के साथ एक फ़ोल्डर है।

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

ऐसे बिल्ड संगठन के क्या फायदे हैं?

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

परिभाषा और रिलीज़ परिभाषा बनाएँ

वीएसटीएस एजेंट को कैसे तैनात किया जाए, हमने पहले इस लेख में वर्णित किया था ।

सबसे पहले बिल्ड डेफिनिशन आता है। TFS VSTS कमांड में, एजेंट ने Dockerfile बिल्ड लॉन्च किया। नतीजतन, हमें एक माइक्रोसेवा की छवि मिलती है। यह छवि स्थानीय रूप से उस वातावरण में सहेजी जाती है जहां VSTS एजेंट चल रहा है।

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

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

kubectl set image deployment/imtob-etr-it-dictionary-api imtob-etr-it-dictionary-api=nexus3.company.ru:18085/etr-it-dictionary-api:$(Build.BuildId)

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

चलिए अब Dockerfile के साथ और बिना बिल्ड की तुलना करें।

Dockerfile के बिना, हमें बहुत सारे चरण मिलते हैं, जिनमें बहुत सारी .net बारीकियाँ होती हैं। दाईं ओर हम एक डॉकर छवि निर्माण देखते हैं। सब कुछ बहुत आसान हो गया है।

छवि के निर्माण की पूरी प्रक्रिया डोकरफाइल में वर्णित है। इस विधानसभा को स्थानीय स्तर पर डीबग किया जा सकता है।

कुल: हमें एक सरल और पारदर्शी CI / CD मिला है

1. विकास और परिनियोजन का पृथक्करण। असेंबली को डॉकरफाइल में वर्णित किया गया है और डेवलपर के कंधों पर स्थित है।
2. जब CI / CD को कॉन्फ़िगर किया जा रहा है, तो आपको विधानसभा के विवरण और विशेषताओं के बारे में जानने की आवश्यकता नहीं है - काम केवल Dockerfile के साथ किया जाता है।
3. हम केवल बदले हुए माइक्रोसर्विसेज को अपडेट करते हैं।

अगला, आपको K8S में RabbitMQ को कॉन्फ़िगर करने की आवश्यकता है: हमने इस बारे में एक अलग लेख लिखा।

पर्यावरण की स्थापना

एक तरह से या किसी अन्य, हम microservices कॉन्फ़िगर करने की आवश्यकता है। पर्यावरण का मुख्य भाग रूट कॉन्फ़िगरेशन फ़ाइल Appsettings.json में कॉन्फ़िगर किया गया है। इस फ़ाइल में ऐसी सेटिंग्स हैं जो पर्यावरण से स्वतंत्र हैं।

उन सेटिंग्स जो पर्यावरण पर निर्भर करती हैं, उन्हें appsettings.secret.json फ़ाइल में रहस्य फ़ोल्डर में संग्रहीत किया जाता है। हमने कुबरनेट पर ASP.NET कोर ऐप सेटिंग्स को प्रबंधित करने वाले लेख में वर्णित दृष्टिकोण लिया।

 var configuration = new ConfigurationBuilder() .AddJsonFile($"appsettings.json", true) .AddJsonFile("secrets/appsettings.secrets.json", optional: true) .Build();

Appsettings.secrets.json फ़ाइल में इलास्टिक खोज अनुक्रमित और डेटाबेस कनेक्शन स्ट्रिंग के लिए सेटिंग्स हैं।

 { "Serilog": { "WriteTo": [ { "Name": "Elasticsearch", "Args": { "nodeUris": "http://192.168.150.114:9200", "indexFormat": "dev.etr.it.ifield.api.dictionary-{0:yyyy.MM.dd}", "templateName": "dev.etr.it.ifield.api.dictionary", "typeName": "dev.etr.it.ifield.api.dictionary.event" } } ] }, "ConnectionStrings": { "DictionaryDbContext": "Server=192.168.154.162;Database=DEV.ETR.IT.iField.Dictionary;User Id=it_user;Password=PASSWORD;" } }

Kubernetes में कॉन्फ़िगरेशन फ़ाइल जोड़ें

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

 apiVersion: apps/v1beta1 kind: Deployment metadata: name: imtob-etr-it-dictionary-api spec: replicas: 1 template: metadata: labels: name: imtob-etr-it-dictionary-api spec: containers: - name: imtob-etr-it-dictionary-api image: nexus3.company.ru:18085/etr-it-dictionary-api:18289 resources: requests: memory: "256Mi" limits: memory: "512Mi" volumeMounts: - name: secrets mountPath: /app/secrets readOnly: true volumes: - name: secrets secret: secretName: secret-appsettings-dictionary

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

kubectl create secret generic secret-appsettings-dictionary
--from-file=./Dictionary/appsettings.secrets.json --namespace=DEMO

निष्कर्ष

चुने हुए दृष्टिकोण के

1. उच्च प्रवेश दहलीज। यदि आप पहली बार इस तरह की परियोजना कर रहे हैं, तो बहुत सी नई जानकारी होगी।
2. माइक्रोसिस्टर्स → अधिक जटिल डिजाइन। इस तथ्य के कारण कई गैर-स्पष्ट समाधान लागू करना आवश्यक है कि हमारे पास एक अखंड समाधान नहीं है, लेकिन एक माइक्रोसेवा है।
3. डॉकर के लिए सब कुछ लागू नहीं है। सब कुछ microservice वास्तुकला में नहीं चलाया जा सकता है। उदाहरण के लिए, जबकि SSRS कर्ता में नहीं है।

एक स्व-परीक्षण दृष्टिकोण के पेशेवरों

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

हमारे लिए निष्कर्ष

1. .NET कोर पर, आप औद्योगिक समाधानों को लागू कर सकते हैं और करना चाहिए।
2. K8S ने वास्तव में जीवन को आसान बना दिया, पर्यावरण के अद्यतन को सरल बनाया, सेवाओं के विन्यास की सुविधा प्रदान की।
3. लिनक्स के लिए CI / CD को लागू करने के लिए TFS का उपयोग किया जा सकता है।

.NET कोर और कुबेरनेट्स पर एक एप्लीकेशन का निर्माण: हमारा अनुभव