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

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

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

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

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

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

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

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

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

हमारा आदर्श वाक्य है: हमारे हाथों तक पहुँचने वाली हर चीज़ को नियंत्रित करना।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

इसके बाद, JavaScipt को असेंबल करने का कार्य शुरू किया गया है और स्टैटिक्स में एकत्र किए गए कोड को nginx बचत संसाधनों के माध्यम से दिया गया है।

यहाँ मैंने हमारे पिछले प्रोजेक्ट का आरेख दिया।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

हम दूसरे भाग को पास करते हैं।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

तब हम init कमांड को कमांड लाइन पर कहते हैं।

Gitlab रनर को डायलॉग मोड (शेल, डॉकर, वर्चुअलबॉक्स, SSH) में कॉन्फ़िगर करें

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

वेब इंटरफ़ेस में यह Gitlab में कैसे दिखता है। GItlab CI को जोड़ने के बाद, एक ध्वज दिखाई देता है जो बिल्ड की वर्तमान स्थिति दिखाता है।

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

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

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

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

जब हमने डॉकटर को पेश किया, तो हमने मंचन पर क्या काम किया? , , , .

.

Docker-compose .

, Docker . Docker-compose .

, .

— staging .

production 80 443 , WEB.

? Gitlab Runner .

Gitlab Gitlab Runner, - , .

Gitlab Runner, .

nginx-proxy .

, . .

80 , .

? root. root root .

, root , root.

- , , , , .

? , .

, ?

ID (UID) ID (GID).

ID 1000.

Ubuntu. Ubuntu ID 1000.

?

Docker. , . , - , .

, .

.

Docker Docker Swarm, . - Docker Swarm.

. . . web-.