डॉकर और गिटलैब सीआई के साथ विकास और परीक्षण प्रक्रिया

मैं इन्वेंटोस से अलेक्जेंडर सिगाचेव की रिपोर्ट की प्रतिलिपि पढ़ने का प्रस्ताव करता हूं "डॉकर + गिटलैब सीआई के साथ विकास और परीक्षण प्रक्रिया"

जो लोग अभी डॉकर + गिटलैब सीआई पर आधारित विकास और परीक्षण प्रक्रिया को लागू करना शुरू कर रहे हैं वे अक्सर बुनियादी प्रश्न पूछते हैं। कहाँ से शुरू करें? कैसे व्यवस्थित करें? परीक्षण कैसे करें?

यह रिपोर्ट अच्छी है क्योंकि यह डॉकर और गिटलैब सीआई का उपयोग करके विकास और परीक्षण प्रक्रिया के बारे में संरचित तरीके से बात करती है। ये रिपोर्ट 2017 की है. मुझे लगता है कि इस रिपोर्ट से आप मूल बातें, कार्यप्रणाली, विचार, उपयोग का अनुभव सीख सकते हैं।

किसे परवाह है, कृपया बिल्ली के नीचे।

मेरा नाम अलेक्जेंडर सिगाचेव है। मैं इन्वेंटोस के लिए काम करता हूं। मैं आपको डॉकर का उपयोग करने के अपने अनुभव के बारे में बताऊंगा और हम इसे कंपनी में परियोजनाओं पर धीरे-धीरे कैसे लागू कर रहे हैं।

प्रस्तुति विषय: डॉकर और गिटलैब सीआई का उपयोग करके विकास प्रक्रिया।

डॉकर के बारे में यह मेरी दूसरी बातचीत है। पहली रिपोर्ट के समय, हमने केवल डेवलपर मशीनों पर विकास में डॉकर का उपयोग किया था। डॉकर का उपयोग करने वाले कर्मचारियों की संख्या लगभग 2-3 लोग थे। धीरे-धीरे अनुभव प्राप्त हुआ और हम थोड़ा आगे बढ़े। हमारे से लिंक करें पहली रिपोर्ट.

इस रिपोर्ट में क्या होगा? हम अपना अनुभव साझा करेंगे कि हमने कौन सा रेक एकत्र किया है, हमने कौन सी समस्याएं हल की हैं। हर जगह यह सुंदर नहीं था, लेकिन आगे बढ़ने की इजाजत थी।

हमारा आदर्श वाक्य है: जो कुछ भी हम अपने हाथ में ले सकते हैं उसे गोदी में रखें।

हम किन समस्याओं का समाधान कर रहे हैं?

जब किसी कंपनी में कई टीमें होती हैं, तो प्रोग्रामर एक साझा संसाधन होता है। ऐसे चरण होते हैं जब एक प्रोग्रामर को एक प्रोजेक्ट से निकालकर कुछ समय के लिए दूसरे प्रोजेक्ट में दे दिया जाता है।

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

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

अगला कारण विकास में सेटिंग्स का मानकीकरण है। मेरे अनुभव में, डेवलपर्स हमेशा पहल करते हैं। प्रत्येक पांचवें मामले में, एक कस्टम डोमेन दर्ज किया जाता है, उदाहरण के लिए, vasya.dev। उनके बगल में उनकी पड़ोसी पेट्या बैठी हैं, जिनका डोमेन petya.dev है। वे इस डोमेन नाम का उपयोग करके एक वेबसाइट या सिस्टम का कुछ घटक विकसित करते हैं।

जब सिस्टम बढ़ता है और ये डोमेन नाम कॉन्फ़िगरेशन में शामिल होने लगते हैं, तो एक विकास वातावरण संघर्ष उत्पन्न होता है और साइट पथ फिर से लिखा जाता है।

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

एक अन्य समस्या पुस्तकालयों के विभिन्न संस्करण हैं। अक्सर ऐसा होता है कि एक डेवलपर विभिन्न परियोजनाओं के साथ काम करता है। एक लीगेसी परियोजना है जो पांच साल पहले शुरू हुई थी (2017 से - संस्करण नोट)। लॉन्च के समय, हमने MySQL 5.5 से शुरुआत की थी। ऐसी आधुनिक परियोजनाएं भी हैं जहां हम MySQL के अधिक आधुनिक संस्करणों को लागू करने का प्रयास करते हैं, उदाहरण के लिए, 5.7 या पुराने (2017 में - संस्करण नोट)

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

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

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

जेएस पर विकसित होने वाले फ्रोंडेन्ड-डेवलपर का बैकएंड पर लगभग कोई प्रभाव नहीं है। बैकएंड डेवलपर, बदले में, हमारे मामले में, रूबी ऑन रेल्स विकसित करता है और फ्रोंडेंड में हस्तक्षेप नहीं करता है। एपीआई का उपयोग करके इंटरैक्शन किया जाता है।

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

औजार। हम क्या उपयोग करते हैं?

• डोकर ही. Dockerfile एकल एप्लिकेशन की निर्भरता का वर्णन करता है।
• डॉकर-कंपोज़ एक बंडल है जो हमारे कुछ डॉकर अनुप्रयोगों को एक साथ लाता है।
• हम सोर्स कोड को स्टोर करने के लिए GitLab का उपयोग करते हैं।
• हम सिस्टम एकीकरण के लिए GitLab-CI का उपयोग करते हैं।

रिपोर्ट में दो भाग हैं.

पहला भाग इस बारे में बात करेगा कि डेवलपर्स की मशीनों पर डॉकर कैसे चलाया गया।

दूसरा भाग इस बारे में बात करेगा कि GitLab के साथ कैसे इंटरैक्ट करें, हम परीक्षण कैसे चलाते हैं और हम स्टेजिंग तक कैसे पहुंचते हैं।

डॉकर एक ऐसी तकनीक है जो आवश्यक घटकों का वर्णन करने के लिए (घोषणात्मक दृष्टिकोण का उपयोग करके) अनुमति देती है। यह एक उदाहरण है Dockerfile. यहां हम घोषणा करते हैं कि हमें आधिकारिक रूबी:2.3.0 डॉकर छवि विरासत में मिली है। इसमें रूबी संस्करण 2.3 स्थापित है। हम आवश्यक बिल्ड लाइब्रेरी और NodeJS स्थापित करते हैं। हम वर्णन करते हैं कि हम एक निर्देशिका बनाते हैं /app. ऐप निर्देशिका को कार्यशील निर्देशिका के रूप में सेट करें। इस निर्देशिका में हम आवश्यक न्यूनतम Gemfile और Gemfile.lock रखते हैं। फिर हम ऐसे प्रोजेक्ट बनाते हैं जो इस निर्भरता छवि को स्थापित करते हैं। हम इंगित करते हैं कि कंटेनर बाहरी पोर्ट 3000 पर सुनने के लिए तैयार होगा। अंतिम कमांड वह कमांड है जो सीधे हमारे एप्लिकेशन को लॉन्च करता है। यदि हम प्रोजेक्ट स्टार्ट कमांड निष्पादित करते हैं, तो एप्लिकेशन निर्दिष्ट कमांड को चलाने और चलाने का प्रयास करेगा।

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

हम डॉकर हब के आधिकारिक स्रोत से MySQL 5.7.14 की छवि बिना किसी बदलाव के लेते हैं। हम वर्तमान निर्देशिका से वह छवि एकत्र करते हैं जो हमारे वेब एप्लिकेशन के लिए ज़िम्मेदार है। यह पहले लॉन्च के दौरान हमारे लिए एक छवि एकत्र करता है। फिर यह वह कमांड चलाता है जिसे हम यहां निष्पादित कर रहे हैं। यदि हम पीछे जाएं, तो हम देखेंगे कि प्यूमा के माध्यम से लॉन्च कमांड को परिभाषित किया गया है। प्यूमा रूबी में लिखी गई एक सेवा है। दूसरे मामले में, हम ओवरराइड करते हैं। यह आदेश हमारी आवश्यकताओं या कार्यों के आधार पर मनमाना हो सकता है।

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

डेवलपर, पहले की तरह, किसी भी उपलब्ध आईपी पते तक पहुंच सकता है, उदाहरण के लिए, 127.0.0.1 मशीन का स्थानीय या बाहरी आईपी पता है।

अंतिम पंक्ति कहती है कि वेब कंटेनर डीबी कंटेनर पर निर्भर करता है। जब हम वेब कंटेनर की शुरुआत कहते हैं, तो docker-compose सबसे पहले हमारे लिए डेटाबेस शुरू करेगा। पहले से ही डेटाबेस की शुरुआत में (वास्तव में, कंटेनर के लॉन्च के बाद! यह डेटाबेस की तैयारी की गारंटी नहीं देता है) एप्लिकेशन लॉन्च करेगा, हमारा बैकएंड।

जब डेटाबेस नहीं लाया जाता है तो यह त्रुटियों से बचाता है और जब हम डेटाबेस कंटेनर को रोकते हैं तो संसाधनों को बचाता है, इस प्रकार अन्य परियोजनाओं के लिए संसाधनों को मुक्त करता है।

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

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

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

छवि निर्माण के बाद, विकास और उत्पादन दोनों में कंटेनर समान होंगे। यह बड़े प्रतिष्ठानों के लिए विशेष रूप से सच है।

फ्रंटएंड पर हम JavaScipt और NodeJS का उपयोग करते हैं।

अब हमारे पास ReacJS पर आखिरी प्रोजेक्ट है। डेवलपर ने कंटेनर में सब कुछ चलाया और हॉट-रीलोड का उपयोग करके विकसित किया।

इसके बाद, JavaScipt असेंबली कार्य लॉन्च किया जाता है और स्टैटिक्स में संकलित कोड nginx सेविंग रिसोर्सेज के माध्यम से दिया जाता है।

यहां मैंने हमारे पिछले प्रोजेक्ट की स्कीम दी है.

कौन से कार्य हल किये गये? हमें एक ऐसा सिस्टम बनाने की ज़रूरत थी जिसके साथ मोबाइल डिवाइस इंटरैक्ट करें। वे डेटा प्राप्त करते हैं. एक संभावना इस डिवाइस पर पुश नोटिफिकेशन भेजने की है।

हमने इसके लिए क्या किया है?

हमने एप्लिकेशन को ऐसे घटकों में विभाजित किया है: JS पर व्यवस्थापक भाग, बैकएंड, जो रूबी ऑन रेल्स के तहत REST इंटरफ़ेस के माध्यम से काम करता है। बैकएंड डेटाबेस के साथ इंटरैक्ट करता है। जो परिणाम उत्पन्न होता है वह ग्राहक को दिया जाता है। एडमिन पैनल REST इंटरफ़ेस के माध्यम से बैकएंड और डेटाबेस के साथ इंटरैक्ट करता है।

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

हमने निम्नलिखित योजना विकसित की है: ब्राउज़र से एक ऑपरेटर एडमिन पैनल के साथ इंटरैक्ट करता है, एडमिन पैनल बैकएंड के साथ इंटरैक्ट करता है, कार्य पुश नोटिफिकेशन भेजना है।

पुश सूचनाएँ NodeJS में कार्यान्वित किसी अन्य घटक के साथ इंटरैक्ट करती हैं।

कतारें बनाई जाती हैं और फिर उनके तंत्र के अनुसार सूचनाएं भेजी जाती हैं।

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

वही लेकिन संख्या में. यहीं पर कोड का पुन: उपयोग महत्वपूर्ण है।

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

उस समय, हम NodeJS के संस्करण 4 का उपयोग कर रहे थे। अब (2017 में - संस्करण नोट) हाल के विकास में हम NodeJS के संस्करण 7 का उपयोग करते हैं। नए घटकों में पुस्तकालयों के नए संस्करणों को शामिल करने में कोई समस्या नहीं है।

यदि आवश्यक हो, तो आप पुश अधिसूचना सेवा से NodeJS संस्करण को रिफैक्टर और बढ़ा सकते हैं।

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

आपको डॉकर जोड़ने की क्या आवश्यकता है? हम अपने रिपॉजिटरी में एक डॉकरफाइल जोड़ते हैं, जो आवश्यक निर्भरताओं का वर्णन करता है। इस उदाहरण में, घटकों को तार्किक रूप से तोड़ा गया है। यह बैकएंड डेवलपर का न्यूनतम सेट है।

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

हम स्टेटिक परोसने के लिए nginx के साथ एक अलग तीसरे कंटेनर का उपयोग करते हैं। चित्र अपलोड करना संभव है. बैकएंड उन्हें पहले से तैयार वॉल्यूम में रखता है, जिसे nginx के साथ एक कंटेनर में भी लगाया जाता है, जो स्टैटिक देता है।

nginx, mysql कॉन्फ़िगरेशन को संग्रहीत करने के लिए, हमने एक डॉकर फ़ोल्डर जोड़ा है जिसमें हम आवश्यक कॉन्फ़िगरेशन संग्रहीत करते हैं। जब कोई डेवलपर अपनी मशीन पर रिपॉजिटरी का गिट क्लोन करता है, तो उसके पास स्थानीय विकास के लिए पहले से ही एक प्रोजेक्ट तैयार होता है। इसमें कोई सवाल नहीं है कि कौन सा पोर्ट या कौन सी सेटिंग्स लागू करनी है।

इसके बाद, हमारे पास कई घटक हैं: व्यवस्थापक, सूचना-एपीआई, पुश सूचनाएं।

यह सब शुरू करने के लिए, हमने एक और रिपॉजिटरी बनाई, जिसे हमने dockerized-app कहा। फिलहाल हम प्रत्येक घटक से पहले कई रिपॉजिटरी का उपयोग करते हैं। वे बस तार्किक रूप से भिन्न हैं - GitLab में यह एक फ़ोल्डर जैसा दिखता है, लेकिन डेवलपर की मशीन पर, एक विशिष्ट प्रोजेक्ट के लिए एक फ़ोल्डर। एक स्तर नीचे वे घटक हैं जिन्हें संयोजित किया जाएगा।

यह केवल dockerized-app की सामग्री का एक उदाहरण है। हम यहां डॉकर निर्देशिका भी लाते हैं, जिसमें हम सभी घटकों के इंटरैक्शन के लिए आवश्यक कॉन्फ़िगरेशन भरते हैं। एक README.md है जो संक्षेप में बताता है कि प्रोजेक्ट को कैसे चलाया जाए।

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

यदि पुश सूचनाओं के साथ एकीकृत करने की आवश्यकता है, तो docker-compose.yaml और docker-compose-push.yaml लॉन्च किए जाते हैं।

चूँकि docker-compose.yaml और docker-compose-push.yaml एक फ़ोल्डर में हैं, एक एकल वर्चुअल नेटवर्क स्वचालित रूप से बनाया जाता है।

घटकों का विवरण. यह एक अधिक उन्नत फ़ाइल है जो घटकों के संग्रह के लिए ज़िम्मेदार है। यहाँ क्या उल्लेखनीय है? यहां हम बैलेंसर घटक का परिचय देते हैं।

यह एक तैयार डॉकर छवि है जो nginx और एक एप्लिकेशन चलाती है जो डॉकर सॉकेट पर सुनती है। गतिशील, जैसे ही कंटेनर चालू और बंद होते हैं, यह nginx कॉन्फ़िगरेशन को पुन: उत्पन्न करता है। हम घटकों के प्रबंधन को तीसरे स्तर के डोमेन नामों द्वारा वितरित करते हैं।

विकास परिवेश के लिए, हम .dev डोमेन - api.informer.dev का उपयोग करते हैं। .dev डोमेन वाले एप्लिकेशन डेवलपर की स्थानीय मशीन पर उपलब्ध हैं।

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

ग्राफ़िक रूप से, यह पता चलता है कि क्लाइंट हमारा ब्राउज़र या कोई उपकरण है जिसके साथ हम बैलेंसर से अनुरोध करते हैं।

डोमेन नाम बैलेंसर यह निर्धारित करता है कि किस कंटेनर से संपर्क करना है।

यह nginx हो सकता है, जो एडमिन JS देता है। यह nginx हो सकता है, जो API, या स्थिर फ़ाइलें देता है, जो छवि अपलोड के रूप में nginx को दी जाती हैं।

आरेख से पता चलता है कि कंटेनर एक वर्चुअल नेटवर्क से जुड़े हुए हैं और एक प्रॉक्सी के पीछे छिपे हुए हैं।

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

अपने एप्लिकेशन को डॉकराइज़ करने के लिए कौन सा उदाहरण देखें? मेरी राय में, एक अच्छा उदाहरण MySQL के लिए आधिकारिक डॉकर छवि है।

यह काफी चुनौतीपूर्ण है. इसके कई संस्करण हैं. लेकिन इसकी कार्यक्षमता आपको आगे के विकास की प्रक्रिया में उत्पन्न होने वाली कई ज़रूरतों को पूरा करने की अनुमति देती है। यदि आप समय बिताते हैं और यह पता लगाते हैं कि यह सब कैसे इंटरैक्ट करता है, तो मुझे लगता है कि आपको स्व-कार्यान्वयन में कोई समस्या नहीं होगी।

hub.docker.com में आमतौर पर github.com के लिंक होते हैं, जिसमें सीधे कच्चा डेटा होता है जिससे आप स्वयं छवि बना सकते हैं।

इसके अलावा इस रिपॉजिटरी में एक docker-endpoint.sh स्क्रिप्ट है, जो प्रारंभिक आरंभीकरण और एप्लिकेशन लॉन्च की आगे की प्रक्रिया के लिए जिम्मेदार है।

साथ ही इस उदाहरण में, पर्यावरण चर का उपयोग करके कॉन्फ़िगर करने की क्षमता है। एकल कंटेनर चलाते समय या डॉकर-कंपोज़ के माध्यम से एक पर्यावरण चर को परिभाषित करके, हम कह सकते हैं कि हमें डॉकटर को MySQL या जो भी हम चाहते हैं, पर रूट करने के लिए एक खाली पासवर्ड सेट करने की आवश्यकता है।

रैंडम पासवर्ड बनाने का विकल्प है। हम कहते हैं कि हमें एक उपयोगकर्ता की आवश्यकता है, हमें उपयोगकर्ता के लिए एक पासवर्ड सेट करने की आवश्यकता है, और हमें एक डेटाबेस बनाने की आवश्यकता है।

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

यह एक उदाहरण है कि MySQL का एक विशिष्ट संस्करण github.com पर कैसा दिखता है। आप डॉकरफ़ाइल खोल सकते हैं और देख सकते हैं कि वहां इंस्टॉलेशन कैसे चल रहा है।

docker-endpoint.sh प्रवेश बिंदु के लिए जिम्मेदार स्क्रिप्ट है। प्रारंभिक आरंभीकरण के दौरान, कुछ तैयारी चरणों की आवश्यकता होती है, और ये सभी क्रियाएं आरंभीकरण स्क्रिप्ट में ही की जाती हैं।

आइए दूसरे भाग पर चलते हैं।

स्रोत कोड को संग्रहीत करने के लिए, हमने gitlab पर स्विच किया। यह एक काफी शक्तिशाली प्रणाली है जिसमें एक दृश्य इंटरफ़ेस है।

Gitlab के घटकों में से एक Gitlab CI है। यह आपको आदेशों के अनुक्रम का वर्णन करने की अनुमति देता है जिसका उपयोग बाद में कोड वितरण प्रणाली को व्यवस्थित करने या स्वचालित परीक्षण चलाने के लिए किया जाएगा।

गिटलैब सीआई 2 टॉक https://goo.gl/uohKjI - रूबी रशिया क्लब की रिपोर्ट - काफी विस्तृत और शायद इसमें आपकी रुचि होगी।

अब हम देखेंगे कि Gitlab CI को सक्रिय करने के लिए क्या आवश्यक है। Gitlab CI शुरू करने के लिए, हमें बस प्रोजेक्ट के रूट में .gitlab-ci.yml फ़ाइल डालनी होगी।

यहां हम वर्णन करते हैं कि हम परीक्षण, तैनाती जैसे राज्यों के अनुक्रम को निष्पादित करना चाहते हैं।

हम स्क्रिप्ट निष्पादित करते हैं जो हमारे एप्लिकेशन को बनाने के लिए सीधे डॉकर-कंपोज़ को कॉल करते हैं। यह सिर्फ एक बैकएंड उदाहरण है.

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

यदि स्क्रिप्ट सही ढंग से निष्पादित की जाती है और कोई त्रुटि कोड नहीं लौटाती है, तो सिस्टम परिनियोजन के दूसरे चरण में आगे बढ़ता है।

परिनियोजन चरण वर्तमान में स्टेजिंग के लिए कार्यान्वित किया गया है। हमने शून्य-डाउनटाइम पुनरारंभ का आयोजन नहीं किया।

हम सभी कंटेनरों को जबरन बुझाते हैं, और फिर हम परीक्षण के दौरान पहले चरण में एकत्र किए गए सभी कंटेनरों को फिर से उठाते हैं।

हम वर्तमान परिवेश चर के लिए डेटाबेस माइग्रेशन चला रहे हैं जो डेवलपर्स द्वारा लिखे गए थे।

एक नोट है कि यह केवल मास्टर शाखा पर लागू होता है.

अन्य शाखाओं को बदलते समय निष्पादित नहीं किया जाता है।

शाखाओं द्वारा रोलआउट व्यवस्थित करना संभव है।

इसे और व्यवस्थित करने के लिए, हमें Gitlab Runner इंस्टॉल करना होगा।

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

स्टार्टअप पर, हम Gitlab Runner को पंजीकृत करते हैं।

हमें Gitlab वेब इंटरफ़ेस में कुंजी मिलती है।

फिर हम कमांड लाइन पर इनिशियलाइज़ेशन कमांड को कॉल करते हैं।

गिटलैब रनर को इंटरैक्टिव तरीके से सेट करें (शेल, डॉकर, वर्चुअलबॉक्स, एसएसएच)

Gitlab रनर पर कोड .gitlab-ci.yml सेटिंग के आधार पर प्रत्येक कमिट पर निष्पादित होगा।

यह वेब इंटरफ़ेस में Gitlab में दृश्यमान रूप से कैसा दिखता है। जीआईटीलैब सीआई को कनेक्ट करने के बाद, हमारे पास एक ध्वज है जो इस समय निर्माण की स्थिति दिखाता है।

हम देखते हैं कि 4 मिनट पहले एक कमिट बनाई गई थी, जो सभी परीक्षणों में सफल रही और कोई समस्या नहीं हुई।

हम बिल्ड्स पर करीब से नज़र डाल सकते हैं। यहां हम देखते हैं कि दो राज्य पहले ही पारित हो चुके हैं। स्टेजिंग पर परीक्षण की स्थिति और तैनाती की स्थिति।

यदि हम किसी विशिष्ट बिल्ड पर क्लिक करते हैं, तो .gitlab-ci.yml के अनुसार प्रक्रिया में चलाए गए कमांड का कंसोल आउटपुट होगा।

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

जब हमने डॉकर लागू किया तो स्टेजिंग पर हमने कौन से कार्य हल किए? हमारे सिस्टम में घटक शामिल हैं और हमें पुनः आरंभ करने की आवश्यकता थी, केवल घटकों का एक हिस्सा जो रिपॉजिटरी में अपडेट किया गया था, न कि संपूर्ण सिस्टम।

ऐसा करने के लिए, हमें हर चीज़ को अलग-अलग फ़ोल्डरों में तोड़ना होगा।

ऐसा करने के बाद, हमें इस तथ्य से समस्या हुई कि डॉकर-कंपोज़ प्रत्येक डैडी के लिए अपना नेटवर्क स्थान बनाता है और पड़ोसी के घटकों को नहीं देखता है।

चारों ओर घूमने के लिए, हमने डॉकर में मैन्युअल रूप से नेटवर्क बनाया। Docker-compose में लिखा था कि आप इस प्रोजेक्ट के लिए ऐसे नेटवर्क का उपयोग करें।

इस प्रकार, प्रत्येक घटक जो इस जाल से शुरू होता है वह सिस्टम के अन्य भागों में घटकों को देखता है।

अगला मुद्दा कई परियोजनाओं में स्टेजिंग को विभाजित करना है।

चूँकि यह सब सुंदर दिखने और उत्पादन के जितना करीब हो सके, पोर्ट 80 या 443 का उपयोग करना अच्छा है, जिसका उपयोग वेब में हर जगह किया जाता है।

हमने इसे कैसे हल किया? हमने सभी प्रमुख परियोजनाओं के लिए एक Gitlab रनर सौंपा है।

Gitlab आपको कई वितरित Gitlab रनर चलाने की अनुमति देता है, जो सभी कार्यों को एक-एक करके अव्यवस्थित तरीके से चलाएगा।

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

हमने nginx-प्रॉक्सी को एक अलग स्टार्टअप स्क्रिप्ट में स्थानांतरित कर दिया और इसमें सभी परियोजनाओं के लिए ग्रिड जोड़ दिए।

हमारे प्रोजेक्ट में एक ग्रिड है, और बैलेंसर में प्रोजेक्ट नामों के अनुसार कई ग्रिड हैं। यह डोमेन नाम से आगे प्रॉक्सी कर सकता है।

हमारे अनुरोध पोर्ट 80 पर डोमेन के माध्यम से आते हैं और इस डोमेन की सेवा करने वाले कंटेनर समूह में हल किए जाते हैं।

वहाँ अन्य कौन सी समस्याएँ थीं? यह वही है जो सभी कंटेनर डिफ़ॉल्ट रूप से रूट के रूप में चलते हैं। यह सिस्टम के रूट होस्ट से असमान है।

हालाँकि, यदि आप कंटेनर में प्रवेश करते हैं, तो यह रूट होगा और इस कंटेनर में हम जो फ़ाइल बनाते हैं उसे रूट अधिकार मिलते हैं।

यदि डेवलपर ने कंटेनर में प्रवेश किया और वहां कुछ कमांड किए जो फ़ाइलें उत्पन्न करते हैं, फिर कंटेनर छोड़ दिया, तो उसकी कार्यशील निर्देशिका में एक फ़ाइल है जिस तक उसकी पहुंच नहीं है।

इसे कैसे हल किया जा सकता है? आप उन उपयोगकर्ताओं को जोड़ सकते हैं जो कंटेनर में होंगे।

जब हमने उपयोगकर्ता जोड़ा तो क्या समस्याएँ उत्पन्न हुईं?

उपयोगकर्ता बनाते समय, हमारे पास अक्सर एक ही समूह आईडी (यूआईडी) और उपयोगकर्ता आईडी (जीआईडी) नहीं होती है।

कंटेनर में इस समस्या को हल करने के लिए, हम आईडी 1000 वाले उपयोगकर्ताओं का उपयोग करते हैं।

हमारे मामले में, यह इस तथ्य से मेल खाता है कि लगभग सभी डेवलपर्स उबंटू ओएस का उपयोग करते हैं। और उबंटू पर, पहले उपयोगकर्ता की आईडी 1000 है।

क्या हमारे पास योजनाएँ हैं?

डॉकर दस्तावेज़ पढ़ें। परियोजना सक्रिय रूप से विकसित हो रही है, दस्तावेज़ीकरण बदल रहा है। जो डेटा दो या तीन महीने पहले प्राप्त हुआ था वह पहले से ही धीरे-धीरे पुराना हो रहा है।

जिन समस्याओं को हमने हल किया उनमें से कुछ संभवतः मानक तरीकों से पहले ही हल हो चुकी हैं।

इसलिए मैं सीधे ऑर्केस्ट्रेशन पर जाने के लिए पहले से ही आगे बढ़ना चाहता हूं।

एक उदाहरण डॉकर का अंतर्निर्मित तंत्र है जिसे डॉकर झुंड कहा जाता है, जो बॉक्स से बाहर आता है। मैं डॉकर स्वार्म तकनीक पर आधारित उत्पादन में कुछ चलाना चाहता हूं।

कंटेनरों को फैलाने से लॉग के साथ काम करना असुविधाजनक हो जाता है। अब लॉग अलग कर दिए गए हैं। वे कंटेनरों में बिखरे हुए हैं। कार्यों में से एक वेब इंटरफ़ेस के माध्यम से लॉग तक सुविधाजनक पहुंच बनाना है।

स्रोत: www.habr.com