Mikroservisy। टीएफएस का उपयोग करके निरंतर एकीकरण और तैनाती प्रणाली सीआई / सीडी केस स्टडी में संस्करण

समस्याओं

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

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

हमें व्यक्तिगत रूप से यह सुनिश्चित करना था और एक बड़ी परियोजना पर बहुत सारी कठिनाइयों का अनुभव करना था, जिसमें बैकएंड पर 6-8 नए सॉफ्टवेयर और सीआई सिस्टम में फ्रंटएंड पर 2-3 संस्करण सॉफ्टवेयर दैनिक जारी किए गए थे, जहां परीक्षण इंजीनियरों को लोड के साथ उद्देश्यपूर्ण रूप से सामना नहीं करना पड़ सकता था। इस बात की निरंतर कमी थी कि वर्तमान में फ्रंट / बैकएंड पर सॉफ्टवेयर के किस संस्करण को स्थिर माना जाता है।

हमारा अनुभव

हमारी कंपनी अपने काम में विभिन्न CI / CD सिस्टम का उपयोग करती है, जिसका विकल्प अक्सर ग्राहक की आवश्यकताओं के अनुसार निर्धारित किया जाता है। उदाहरण के लिए, हमारे विशेषज्ञ अक्सर जेन / सीडी सिस्टम जैसे कि जेनकिंस, टीमसिटी, ट्रैविस सीआई, सर्कल सीआई, गिटलैब सीआई, एटलसियन बम्बू आते हैं, जहां कभी-कभी हम पूरी तरह से ग्राहक के बुनियादी ढांचे पर काम करते हैं। तदनुसार, इस दृष्टिकोण के साथ, संस्करण के समाधान के साथ समस्या पूरी तरह से ग्राहक के साथ निहित है।

ग्राहकों के लिए समाधान विकसित करते समय, जब हमारे पास अपने स्वयं के बुनियादी ढांचे पर ऐसा करने का अवसर होता है, तो हम निरंतर एकीकरण / सतत वितरण प्रणाली के आधार के रूप में टीएफएस संस्करण 2018 का उपयोग करते हैं। यह हमें पूर्ण सॉफ्टवेयर विकास चक्र, अर्थात् बनाने का मुख्य कार्य हल करने की अनुमति देता है:

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

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

समाधान: TFS और तृतीय-पक्ष उपकरण का उपयोग करना

इसलिए, हमें परीक्षण वातावरण और रिलीज़ को व्यवस्थित करने के लिए माइक्रोसॉफ़्ट आर्किटेक्चर परियोजनाओं के लिए एक संस्करण प्रणाली की आवश्यकता है।

प्रारंभिक डेटा के रूप में हमारे पास है:

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

बिल्ड्स के नाम के सवाल पर

• मौजूदा नामकरण मानकों का उपयोग करना तर्कसंगत होगा, उदाहरण के लिए, जैसे सिमेंटिक संस्करण विशिष्टता ।
• हम मैन्युअल रूप से रिलीज़ संस्करण की निर्माण प्रक्रिया शुरू करते समय इस नाम का अनुसरण करते हैं, क्योंकि अन्यथा आप सही नाम स्वचालित रूप से प्राप्त नहीं कर पाएंगे (जब तक कि आप इसे कोड में मैन्युअल रूप से नहीं डालते हैं, जिसका फिर से सीआई विचारधारा से बहुत कम संबंध है)।
• "डीबगिंग" सॉफ़्टवेयर संस्करणों के लिए CI मोड में हम विभिन्न परियोजनाओं पर निम्नलिखित नामों का उपयोग करते हैं:
  
  
  1. अंतर्निहित TFS एक्सटेंशन
  2. वर्तमान तिथि के आधार पर नंबरिंग और उस दिन नंबर का निर्माण;
  3. बिल्ड शुरू करने वाले कमिटमेंट की संख्या।

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

निर्णय एल्गोरिथ्म

1. TFS2018 में, SibEDGE Semver नामक एक प्रोजेक्ट बनाएं और रिपॉजिटरी को स्थानीय रिपॉजिटरी में आयात करें


चित्रा 1 - TFS 2018 में भंडार में सिबडेज सेवर प्रोजेक्ट

2. हमारी आवश्यकताओं ( लिंक ) के लिए असेंबली नोड के विवरण के साथ एक डॉकरीफाइल फ़ाइल बनाएं।

FROM node:7 WORKDIR /usr/src/app COPY package.json app.js LICENSE /usr/src/app/ COPY lib /usr/src/app/lib/ LABEL license MIT COPY tests tests ENV NODE_ENV dev RUN npm config set strict-ssl false RUN npm update && \ npm install -g mocha CMD ["mocha", "tests/test.js", "--reporter", "spec"] 

स्क्रिप्ट 1 - एक निर्माण के लिए डॉकरफाइल

3. परीक्षण बेंच पर (डॉकटर स्थापित के साथ), जहां हम अपने वातावरण को तैनात करने की योजना बनाते हैं, एक झुंड क्लस्टर बनाते हैं। हमारे मामले में, इसमें एक सर्वर शामिल होगा।

 $ docker swarm init 

4. हमारी आवश्यकताओं ( लिंक ) के लिए माइक्रोसर्विसेस के विवरण के साथ एक yml-file बनाएँ।
ध्यान दें कि vm-docker-registry.development.com:5000 इस परियोजना के लिए आंतरिक भंडार है, जिसे हमने पहले से तैयार किया था। इस रिपॉजिटरी का उपयोग करने में सक्षम होने के लिए परीक्षण स्टैंड के लिए, /etc/docker/certs.d/ <repository नाम> /ca.crt फ़ोल्डर में स्टैंड पर ssl प्रमाणपत्र पंजीकृत करना आवश्यक है

 version: '3.6' services: #--- # Portainer for manage Docker #--- portainer: image: portainer/portainer:1.15.3 command: --templates http://templates/templates.json -d /data -H unix:///var/run/docker.sock networks: - semver-network ports: - 9000:9000 volumes: - /var/run/docker.sock:/var/run/docker.sock #--- #----Service Calculator Test# #--- semver-calc: image: vm-docker-registry.development.com:5000/calculator:latest networks: - semver-network #--- #----Pminder - Nginx# #--- nginx: image: nginx:1.9.6 depends_on: - mysql ports: - "8888:80" - "6443:443" networks: - semver-network # #----------------------------- # START NoSQL - Redis. #--- redis: image: redis:4.0 networks: - semver-network ports: - "8379:6379" # # END NoSQL - Redis. #--- #----Pminder - DB# #--- mysql: image: mysql:5.7 ports: - "3306:3306" environment: MYSQL_ROOT_PASSWORD: 'ODdsX0xcN5A9a6q' MYSQL_DATABASE: 'semver' MYSQL_USER: 'user' MYSQL_PASSWORD: 'uXcgTQS8XUm1RzR' networks: - semver-network #--- #----PhpMyAdmin # #--- phpmyadmin: image: phpmyadmin/phpmyadmin depends_on: - mysql environment: PMA_HOST: 'mysql' PMA_USER: 'user' PMA_PASSWORD: 'uXcgTQS8XUm1RzR' ports: - "8500:80" - "8600:9000" networks: - semver-network #--- networks: semver-network: 

स्क्रिप्ट 2 सेम्वर.माइल फाइल की सामग्री है, जो डॉकटर-कंपोज प्रोजेक्ट फाइल है।

5. TFS2018 (बिल्ड डेफिनिशन) में एक बिल्ड विवरण बनाएं।

6. हमारी स्क्रिप्ट की पहली क्रिया डॉक कंटेनर इमेज बनाना है:


चित्र 2 - TFS 2018 में हमारे निर्माण के लिए एक छवि का निर्माण

7. इस परियोजना के लिए आंतरिक रिपॉजिटरी के लिए निर्माण मशीन पर निर्मित डॉक कंटेनर इमेज भेजें:


चित्र 3 - TFS 2018 रिपॉजिटरी में हमारी विधानसभा के लिए डॉकटर-इमेज सेव करना

8. माइक्रोसॉफ़्ट विवरण फ़ाइल में परीक्षण बेंच पर पूरे वातावरण के लिए, छवि नाम को एक नए में बदलें:


चित्र 4 - TFS 2018 में हमारे निर्माण के लिए बिल्ड स्क्रिप्ट में छवि का नाम बदलना

9. परीक्षण बेंच पर, आंतरिक रिपॉजिटरी से बनाई गई डॉक कंटेनर छवि को कॉपी करें और डॉकटर झुंड में सेवा को अपडेट करें:


चित्र 5 - टीएफएस 2018 में छवि से हमारे निर्माण के लिए बिल्ड स्क्रिप्ट के साथ डॉक कंटेनर को नियोजित करना

परिणामस्वरूप, जब हम TFS रिपॉजिटरी से बाहर निकलते हैं, तो हमारे पास एक yml फ़ाइल होती है जिसमें डॉकटर छवियों के रिलीज़ संस्करण होते हैं, जिसके बदले पूरे प्रोजेक्ट का रिलीज़ नाम होता है।

10. हम परीक्षण बेंच में जाएंगे और सेवाओं के संचालन की जांच करेंगे और सुनिश्चित करेंगे कि कैलकुलेटर सेवा को अपडेट किया गया है और विधानसभा के नए संस्करण का उपयोग करता है।

 $ docker service ls 

चित्र 6 - कैलकुलेटर सेवा को अपडेट करना और हमारे परीक्षण बेंच पर इसके वर्तमान संस्करण की जांच करना

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

सारांश - आपको बाहर निकलने पर क्या मिला

माइक्रोसैसवर्क वास्तुकला के साथ परियोजनाओं में संस्करणकरण के कार्यान्वयन के लिए धन्यवाद, निम्नलिखित परिणाम प्राप्त किया गया था:

• संस्करणों में अराजकता की मात्रा कम हो गई है;
• परियोजनाओं में एक नए वातावरण की तैनाती की गति में वृद्धि हुई है;
• विधानसभाओं की गुणवत्ता में सुधार हुआ है और उनमें त्रुटियों का स्तर कम हुआ है;
• परियोजना प्रबंधकों और ग्राहक के लिए विकास की पारदर्शिता में वृद्धि;
• विभागों के बीच बातचीत में सुधार हुआ है;
• DevOps के काम में नई दिशाएँ हैं।

PS इस लेख को लिखने में मेरी मदद करने के लिए मेरे सहयोगी किरिल बी का धन्यवाद।