डॉकर आणि गिटलॅब CI सह विकास आणि चाचणी प्रक्रिया

मी इन्व्हेंटोस "डॉकर + गिटलॅब सीआय सह विकास आणि चाचणी प्रक्रिया" मधील अलेक्झांडर सिगाचेव्हच्या अहवालाचा उतारा वाचण्याचा प्रस्ताव देतो.

जे नुकतेच डॉकर + गिटलॅब सीआयवर आधारित विकास आणि चाचणी प्रक्रिया लागू करण्यास प्रारंभ करत आहेत ते सहसा मूलभूत प्रश्न विचारतात. कुठून सुरुवात करायची? कसे आयोजित करावे? चाचणी कशी करावी?

हा अहवाल चांगला आहे कारण तो डॉकर आणि गिटलॅब सीआय वापरून विकास आणि चाचणी प्रक्रियेबद्दल संरचित मार्गाने बोलतो. अहवाल 2017 चा आहे. मला वाटते की या अहवालातून तुम्हाला मूलभूत गोष्टी, कार्यपद्धती, कल्पना, वापराचा अनुभव शिकता येईल.

कोण काळजी घेते, कृपया मांजरीच्या खाली.

माझे नाव अलेक्झांडर सिगाचेव्ह आहे. मी Inventos साठी काम करतो. मी तुम्हाला डॉकर वापरण्याचा माझा अनुभव सांगेन आणि आम्ही कंपनीमधील प्रकल्पांवर ते हळूहळू कसे राबवत आहोत.

सादरीकरणाचा विषय: डॉकर आणि गिटलॅब सीआय वापरून विकास प्रक्रिया.

डॉकरबद्दलची ही माझी दुसरी चर्चा आहे. पहिल्या अहवालाच्या वेळी, आम्ही केवळ विकसक मशीनवर विकासात डॉकर वापरला. डॉकर वापरणार्‍या कर्मचार्‍यांची संख्या सुमारे 2-3 लोक होती. हळूहळू अनुभव मिळत गेला आणि आम्ही थोडे पुढे गेलो. आमच्याशी दुवा पहिला अहवाल.

काय असेल या अहवालात? आम्ही कोणते रेक गोळा केले, कोणत्या समस्या सोडवल्या याबद्दल आमचे अनुभव सांगू. सर्वत्र ते सुंदर नव्हते, परंतु पुढे जाण्याची परवानगी दिली.

आमचे ब्रीदवाक्य आहे: आम्ही जे काही करू शकतो ते डॉक करा.

आम्ही कोणत्या समस्या सोडवत आहोत?

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

प्रोग्रामरला त्वरीत समजण्यासाठी, त्याला प्रकल्पाचा स्त्रोत कोड डाउनलोड करणे आणि शक्य तितक्या लवकर पर्यावरण लाँच करणे आवश्यक आहे, जे त्याला या प्रकल्पाच्या समस्यांचे निराकरण करण्यासाठी पुढे जाण्यास अनुमती देईल.

सहसा, जर तुम्ही सुरवातीपासून सुरुवात केली तर प्रकल्पात थोडे दस्तऐवज आहेत. कसे सेट करावे याबद्दल माहिती फक्त जुन्या-टाइमरसाठी उपलब्ध आहे. कर्मचारी एक-दोन दिवसांत स्वतःहून कामाची जागा तयार करतात. याला गती देण्यासाठी, आम्ही डॉकर वापरला.

पुढील कारण म्हणजे विकासातील सेटिंग्जचे मानकीकरण. माझ्या अनुभवानुसार, विकासक नेहमीच पुढाकार घेतात. प्रत्येक पाचव्या प्रकरणात, एक सानुकूल डोमेन प्रविष्ट केले जाते, उदाहरणार्थ, vasya.dev. त्याच्या शेजारी बसलेला त्याचा शेजारी पेट्या आहे, ज्याचे डोमेन petya.dev आहे. ते या डोमेन नावाचा वापर करून वेबसाइट किंवा सिस्टमचा काही घटक विकसित करतात.

जेव्हा सिस्टीम वाढते आणि ही डोमेन नावे कॉन्फिगरेशनमध्ये येऊ लागतात, तेव्हा विकास पर्यावरण संघर्ष उद्भवतो आणि साइटचा मार्ग पुन्हा लिहिला जातो.

डेटाबेस सेटिंग्जमध्येही असेच घडते. कोणीतरी सुरक्षिततेचा त्रास देत नाही आणि रिकाम्या रूट पासवर्डसह कार्य करतो. इंस्टॉलेशन स्टेजवर, MySQL ने कोणाला पासवर्ड विचारला आणि पासवर्ड 123 निघाला. अनेकदा असे घडते की डेव्हलपरच्या कमिटनुसार डेटाबेस कॉन्फिगरेशन सतत बदलत असते. कोणी दुरुस्त केले, कोणीतरी कॉन्फिगरेशन दुरुस्त केले नाही. जेव्हा आम्ही काही प्रकारचे चाचणी कॉन्फिगरेशन काढले तेव्हा युक्त्या होत्या .gitignore आणि प्रत्येक डेव्हलपरला डेटाबेस इन्स्टॉल करायचा होता. त्यामुळे सुरुवात करणे अवघड झाले. इतर गोष्टींबरोबरच डेटाबेस लक्षात ठेवणे आवश्यक आहे. डेटाबेस आरंभ करणे आवश्यक आहे, पासवर्ड प्रविष्ट करणे आवश्यक आहे, वापरकर्त्याची नोंदणी करणे आवश्यक आहे, एक टेबल तयार करणे आवश्यक आहे, इत्यादी.

दुसरी समस्या म्हणजे लायब्ररीच्या विविध आवृत्त्या. असे अनेकदा घडते की विकासक वेगवेगळ्या प्रकल्पांसह काम करतो. पाच वर्षांपूर्वी सुरू झालेला एक वारसा प्रकल्प आहे (2017 पासून - एड. टीप). लॉन्चच्या वेळी, आम्ही MySQL 5.5 ने सुरुवात केली. तेथे आधुनिक प्रकल्प देखील आहेत जेथे आम्ही MySQL च्या अधिक आधुनिक आवृत्त्या लागू करण्याचा प्रयत्न करतो, उदाहरणार्थ, 5.7 किंवा त्याहून जुने (2017 मध्ये - एड. टीप)

MySQL सह काम करणार्‍या कोणालाही माहीत आहे की ही लायब्ररी त्यांच्यासोबत अवलंबित्व आणते. 2 बेस एकत्र चालवणे ऐवजी समस्याप्रधान आहे. किमान, जुने क्लायंट नवीन डेटाबेसशी कनेक्ट होण्यासाठी समस्याप्रधान आहेत. यामुळे अनेक समस्या निर्माण होतात.

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

मायक्रो सर्व्हिसेसची दिशा आता विकसित होत आहे. जेव्हा आम्ही आमचे मोठे ऍप्लिकेशन एकमेकांशी संवाद साधणारे काही लहान घटकांमध्ये विभागतो. हे तुम्हाला कार्यांच्या विशिष्ट स्टॅकसाठी तंत्रज्ञान निवडण्याची परवानगी देते. हे तुम्हाला विकासकांमध्ये काम आणि जबाबदाऱ्या सामायिक करण्याची देखील अनुमती देते.

Frondend-डेव्हलपर, JS वर विकसित होत आहे, बॅकएंडवर जवळजवळ कोणताही प्रभाव नाही. बॅकएंड विकसक, बदल्यात, आमच्या बाबतीत, रुबी ऑन रेल विकसित करतो आणि फ्रॉन्डेंडमध्ये हस्तक्षेप करत नाही. संवाद API वापरून केला जातो.

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

साधने. आम्ही काय वापरतो?

• डॉकर स्वतः. डॉकरफाइल एका अनुप्रयोगाच्या अवलंबित्वांचे वर्णन करते.
• डॉकर-कंपोज हे एक बंडल आहे जे आमच्या काही डॉकर ऍप्लिकेशन्सना एकत्र आणते.
• आम्ही स्त्रोत कोड संचयित करण्यासाठी GitLab वापरतो.
• सिस्टम इंटिग्रेशनसाठी आम्ही GitLab-CI वापरतो.

अहवालात दोन भाग आहेत.

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

दुसरा भाग GitLab शी संवाद कसा साधायचा, आम्ही चाचण्या कशा चालवतो आणि आम्ही स्टेजिंगमध्ये कसे रोल आउट करतो याबद्दल चर्चा करेल.

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

हे डॉकर-कंपोज फाइलचे किमान उदाहरण आहे. या प्रकरणात, आम्ही दर्शवितो की दोन कंटेनरमध्ये कनेक्शन आहे. हे थेट डेटाबेस सेवा आणि वेब सेवेमध्ये आहे. आमच्या वेब ऍप्लिकेशन्सना बहुतेक प्रकरणांमध्ये डेटा संचयित करण्यासाठी बॅकएंड म्हणून काही प्रकारच्या डेटाबेसची आवश्यकता असते. आम्ही MySQL वापरत असल्याने, उदाहरण MySQL सोबत आहे - परंतु काहीही आम्हाला इतर डेटाबेस (PostgreSQL, Redis) वापरण्यापासून प्रतिबंधित करत नाही.

आम्ही डॉकर हबच्या अधिकृत स्त्रोताकडून MySQL 5.7.14 ची प्रतिमा बदल न करता घेतो. आम्ही वर्तमान निर्देशिकेतून आमच्या वेब अनुप्रयोगासाठी जबाबदार असलेली प्रतिमा संकलित करतो. पहिल्या लाँच दरम्यान ते आमच्यासाठी एक प्रतिमा संकलित करते. मग ती कमांड चालवते जी आपण येथे कार्यान्वित करत आहोत. जर आपण मागे गेलो, तर आपल्याला दिसेल की पुमा मार्गे लॉन्च कमांड परिभाषित केले गेले आहे. प्यूमा ही रुबीमध्ये लिहिलेली सेवा आहे. दुसऱ्या प्रकरणात, आम्ही ओव्हरराइड करतो. ही आज्ञा आमच्या गरजा किंवा कार्यांवर अवलंबून अनियंत्रित असू शकते.

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

विकसक, पूर्वीप्रमाणे, कोणत्याही उपलब्ध IP पत्त्यावर प्रवेश करू शकतो, उदाहरणार्थ, 127.0.0.1 हा मशीनचा स्थानिक किंवा बाह्य IP पत्ता आहे.

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

जेव्हा डेटाबेस आणला जात नाही तेव्हा हे त्रुटी टाळते आणि जेव्हा आम्ही डेटाबेस कंटेनर थांबवतो तेव्हा संसाधने वाचवते, त्यामुळे इतर प्रकल्पांसाठी संसाधने मुक्त होतात.

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

आमच्याकडे डेव्हलपमेंट वातावरणासाठी अधिक इष्टतम कॉन्फिगरेशन वापरण्याची संधी आहे, जी डीफॉल्टपेक्षा वेगळी असेल. MySQL हे डीफॉल्टनुसार कमकुवत मशीन्ससाठी कॉन्फिगर केले आहे आणि बॉक्सच्या बाहेर त्याचे कार्यप्रदर्शन खूपच खराब आहे.

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

प्रतिमा तयार केल्यानंतर, विकास आणि उत्पादन दोन्हीमधील कंटेनर समान असतील. हे विशेषतः मोठ्या स्थापनेसाठी खरे आहे.

फ्रंटएंडवर आम्ही JavaScipt आणि NodeJS वापरतो.

आता आमच्याकडे ReacJS वर शेवटचा प्रोजेक्ट आहे. विकसकाने कंटेनरमध्ये सर्वकाही चालवले आणि हॉट-रीलोड वापरून विकसित केले.

पुढे, JavaScipt असेंबली कार्य लाँच केले जाते आणि स्टॅटिक्समध्ये संकलित केलेला कोड nginx बचत संसाधनांद्वारे दिला जातो.

येथे मी आमच्या शेवटच्या प्रकल्पाची योजना दिली आहे.

कोणती कामे सोडवली? आम्हाला एक प्रणाली तयार करण्याची आवश्यकता होती ज्यासह मोबाइल डिव्हाइस परस्परसंवाद करतात. त्यांना डेटा मिळतो. या डिव्हाइसवर पुश सूचना पाठवणे ही एक शक्यता आहे.

यासाठी आम्ही काय केले?

आम्ही ऍप्लिकेशनमध्ये असे घटक विभागले आहेत जसे: JS वरील ऍडमिन भाग, बॅकएंड, जो रुबी ऑन रेल अंतर्गत REST इंटरफेसद्वारे कार्य करतो. बॅकएंड डेटाबेसशी संवाद साधतो. व्युत्पन्न झालेला परिणाम क्लायंटला दिला जातो. अॅडमिन पॅनल बॅकएंड आणि डेटाबेसशी REST इंटरफेसद्वारे संवाद साधते.

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

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

पुश नोटिफिकेशन्स NodeJS मध्ये लागू केलेल्या दुसर्‍या घटकाशी संवाद साधतात.

रांगा बांधल्या जातात आणि नंतर त्यांच्या यंत्रणेनुसार सूचना पाठवल्या जातात.

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

समान पण संख्येने. येथे कोडचा पुनर्वापर महत्त्वाचा आहे.

जर आधी आपण लायब्ररीच्या रूपात कोड पुन्हा वापरण्याबद्दल बोललो, तर या उदाहरणात, पुश सूचनांना प्रतिसाद देणारी आमची सेवा पूर्ण सर्व्हर म्हणून पुन्हा वापरली जाते. हे एक API प्रदान करते. आणि आमचा नवीन विकास आधीच त्याच्याशी संवाद साधतो.

त्यावेळी, आम्ही NodeJS ची आवृत्ती 4 वापरत होतो. आता (2017 मध्ये - एड. टीप) अलीकडील घडामोडींमध्ये आम्ही NodeJS ची आवृत्ती 7 वापरतो. लायब्ररीच्या नवीन आवृत्त्यांचा समावेश करण्यासाठी नवीन घटकांमध्ये कोणतीही अडचण नाही.

आवश्यक असल्यास, तुम्ही पुश सूचना सेवेमधून नोडजेएस आवृत्ती रिफॅक्टर आणि वाढवू शकता.

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

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

नवीन प्रकल्प तयार करताना, आम्ही एक डॉकरफाइल तयार करतो, इच्छित इकोसिस्टमचे वर्णन करतो (पायथन, रुबी, नोडजेएस). डॉकर-कंपोजमध्ये, ते आवश्यक अवलंबित्वाचे वर्णन करते - डेटाबेस. आम्ही वर्णन करतो की आम्हाला अशा आणि अशा आवृत्तीचा डेटाबेस आवश्यक आहे, तेथे आणि तेथे डेटा संग्रहित करा.

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

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

पुढे, आमच्याकडे अनेक घटक आहेत: प्रशासक, माहिती-एपीआय, पुश सूचना.

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

हे फक्त डॉकराइज्ड अॅपच्या सामग्रीचे उदाहरण आहे. आम्ही येथे डॉकर निर्देशिका देखील आणतो, ज्यामध्ये आम्ही सर्व घटकांच्या परस्परसंवादासाठी आवश्यक कॉन्फिगरेशन भरतो. एक 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 वर रूट करण्यासाठी किंवा आम्हाला पाहिजे ते रिकामे पासवर्ड सेट करणे आवश्यक आहे.

यादृच्छिक पासवर्ड तयार करण्याचा पर्याय आहे. आम्ही म्हणतो की आम्हाला वापरकर्त्याची गरज आहे, आम्हाला वापरकर्त्यासाठी पासवर्ड सेट करणे आवश्यक आहे आणि आम्हाला डेटाबेस तयार करणे आवश्यक आहे.

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

github.com वर MySQL ची विशिष्ट आवृत्ती कशी दिसते याचे हे उदाहरण आहे. तुम्ही डॉकरफाईल उघडू शकता आणि तिथे इन्स्टॉलेशन कसे चालू आहे ते पाहू शकता.

docker-endpoint.sh ही एंट्री पॉइंटसाठी जबाबदार असलेली स्क्रिप्ट आहे. सुरुवातीच्या प्रारंभादरम्यान, काही तयारीच्या चरणांची आवश्यकता असते, आणि या सर्व क्रिया फक्त आरंभिक स्क्रिप्टमध्ये केल्या जातात.

दुसऱ्या भागाकडे वळू.

स्त्रोत कोड संचयित करण्यासाठी, आम्ही gitlab वर स्विच केले. ही एक बऱ्यापैकी शक्तिशाली प्रणाली आहे ज्यामध्ये व्हिज्युअल इंटरफेस आहे.

Gitlab च्या घटकांपैकी एक Gitlab CI आहे. हे तुम्हाला आदेशांच्या क्रमाचे वर्णन करण्यास अनुमती देते जे नंतर कोड वितरण प्रणाली आयोजित करण्यासाठी किंवा स्वयंचलित चाचणी चालवण्यासाठी वापरले जाईल.

Gitlab CI 2 चर्चा https://goo.gl/uohKjI - रुबी रशिया क्लबचा अहवाल - अगदी तपशीलवार आणि कदाचित तो तुम्हाला स्वारस्य असेल.

आता आपण Gitlab CI सक्रिय करण्यासाठी काय आवश्यक आहे ते पाहू. Gitlab CI सुरू करण्यासाठी, आम्हाला फक्त .gitlab-ci.yml फाइल प्रोजेक्टच्या रूटमध्ये ठेवायची आहे.

येथे आम्ही वर्णन करतो की आम्हाला चाचणी, तैनाती सारख्या राज्यांचा क्रम कार्यान्वित करायचा आहे.

आमचा ऍप्लिकेशन तयार करण्यासाठी आम्ही थेट डॉकर-कंपोज कॉल करणाऱ्या स्क्रिप्ट्स कार्यान्वित करतो. हे फक्त बॅकएंड उदाहरण आहे.

पुढे, आम्ही म्हणतो की डेटाबेस बदलण्यासाठी आणि चाचण्या चालवण्यासाठी स्थलांतर करणे आवश्यक आहे.

जर स्क्रिप्ट योग्यरित्या अंमलात आणल्या गेल्या आणि एरर कोड परत केला नाही, तर सिस्टम उपयोजनाच्या दुसऱ्या टप्प्यावर जाते.

स्टेजिंगसाठी सध्या तैनातीचा टप्पा लागू केला आहे. आम्ही शून्य-डाउनटाइम रीस्टार्ट आयोजित केले नाही.

आम्ही सर्व कंटेनर जबरदस्तीने विझवतो आणि नंतर आम्ही चाचणी दरम्यान पहिल्या टप्प्यावर गोळा केलेले सर्व कंटेनर पुन्हा वाढवतो.

आम्ही डेव्हलपर्सनी लिहिलेल्या डेटाबेस माइग्रेशन्ससाठी सध्याच्या पर्यावरण व्हेरिएबलसाठी धावत आहोत.

एक नोंद आहे की हे फक्त मास्टर शाखेला लागू होते.

इतर शाखा बदलताना अंमलात येत नाही.

शाखांद्वारे रोलआउट्स आयोजित करणे शक्य आहे.

हे आणखी व्यवस्थित करण्यासाठी, आम्हाला गिटलॅब रनर स्थापित करणे आवश्यक आहे.

ही उपयुक्तता गोलंगमध्ये लिहिलेली आहे. ही एकच फाइल आहे, जसे की गोलंग जगात सामान्य आहे, ज्याला कोणत्याही अवलंबनाची आवश्यकता नाही.

स्टार्टअपवर, आम्ही गिटलॅब रनरची नोंदणी करतो.

आम्हाला Gitlab वेब इंटरफेसमध्ये की मिळते.

त्यानंतर कमांड लाइनवरील इनिशिएलायझेशन कमांडला कॉल करतो.

गिटलॅब रनर परस्परसंवादीपणे सेट करा (शेल, डॉकर, व्हर्च्युअलबॉक्स, एसएसएच)

.gitlab-ci.yml सेटिंगवर अवलंबून, Gitlab रनरवरील कोड प्रत्येक कमिटवर कार्यान्वित होईल.

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

आम्ही पाहतो की 4 मिनिटांपूर्वी एक कमिट केले गेले होते, ज्याने सर्व चाचण्या उत्तीर्ण केल्या आणि कोणतीही समस्या उद्भवली नाही.

आम्ही बिल्ड्स जवळून पाहू शकतो. येथे आपण पाहतो की दोन राज्ये आधीच निघून गेली आहेत. स्टेजिंगवर चाचणी स्थिती आणि उपयोजन स्थिती.

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

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

जेव्हा आम्ही डॉकर लागू केला तेव्हा आम्ही स्टेजिंगवर कोणती कार्ये सोडवली? आमच्या सिस्टममध्ये घटक असतात आणि आम्हाला रीस्टार्ट करण्याची गरज होती, फक्त रेपॉजिटरीमध्ये अपडेट केलेल्या घटकांचा भाग होता, संपूर्ण सिस्टमला नाही.

हे करण्यासाठी, आम्हाला प्रत्येक गोष्ट स्वतंत्र फोल्डरमध्ये फोडावी लागली.

आम्ही हे केल्यानंतर, आम्हाला एक समस्या आली की डॉकर-कंपोज प्रत्येक वडिलांसाठी स्वतःचे नेटवर्क स्पेस तयार करते आणि शेजारचे घटक दिसत नाहीत.

जवळपास जाण्यासाठी, आम्ही डॉकरमध्ये मॅन्युअली नेटवर्क तयार केले. या प्रकल्पासाठी तुम्ही असे नेटवर्क वापरता असे डॉकर-कंपोजमध्ये लिहिले होते.

अशा प्रकारे, या जाळीपासून सुरू होणारा प्रत्येक घटक प्रणालीच्या इतर भागांमध्ये घटक पाहतो.

पुढील समस्या अनेक प्रकल्पांमध्ये स्टेजिंग विभाजित करणे आहे.

हे सर्व सुंदर दिसण्यासाठी आणि उत्पादनाच्या शक्य तितक्या जवळ असल्याने, पोर्ट 80 किंवा 443 वापरणे चांगले आहे, जे WEB मध्ये सर्वत्र वापरले जाते.

आम्ही ते कसे सोडवले? आम्ही सर्व मोठ्या प्रकल्पांसाठी एक गिटलॅब रनर नियुक्त केला आहे.

गिटलॅब तुम्हाला अनेक वितरीत गिटलॅब रनर्स चालवण्याची परवानगी देतो, जे सर्व कार्ये अव्यवस्थितपणे घेतील आणि त्यांना चालवतील.

आमच्याकडे घर नाही म्हणून आम्ही आमच्या प्रोजेक्ट्सचा गट एका गिटलॅब रनरपर्यंत मर्यादित ठेवला आहे, जो आमच्या व्हॉल्यूमसह कोणत्याही समस्यांशिवाय सामना करतो.

आम्ही nginx-प्रॉक्सी वेगळ्या स्टार्टअप स्क्रिप्टमध्ये हलवले आणि त्यातील सर्व प्रकल्पांसाठी ग्रिड जोडले.

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

आमच्या विनंत्या पोर्ट 80 वरील डोमेनद्वारे येतात आणि या डोमेनला सेवा देणाऱ्या कंटेनर गटामध्ये सोडवल्या जातात.

इतर कोणत्या समस्या होत्या? डीफॉल्टनुसार सर्व कंटेनर रूट म्हणून चालतात. हे सिस्टीमच्या रूट होस्टसाठी रूट असमान आहे.

तथापि, आपण कंटेनर प्रविष्ट केल्यास, ते रूट होईल आणि आम्ही या कंटेनरमध्ये तयार केलेली फाईल रूट अधिकार प्राप्त करतो.

जर विकसकाने कंटेनरमध्ये प्रवेश केला आणि तेथे काही आज्ञा केल्या ज्या फायली तयार करतात, नंतर कंटेनर सोडला, तर त्याच्याकडे त्याच्या कार्यरत निर्देशिकेत एक फाइल आहे ज्यामध्ये त्याला प्रवेश नाही.

ते कसे सोडवता येईल? तुम्ही कंटेनरमध्ये असणारे वापरकर्ते जोडू शकता.

जेव्हा आम्ही वापरकर्ता जोडला तेव्हा कोणत्या समस्या उद्भवल्या?

वापरकर्ता तयार करताना, आमच्याकडे अनेकदा समान गट आयडी (यूआयडी) आणि वापरकर्ता आयडी (जीआयडी) नसतो.

कंटेनरमध्ये या समस्येचे निराकरण करण्यासाठी, आम्ही आयडी 1000 वापरकर्ते वापरतो.

आमच्या बाबतीत, हे या वस्तुस्थितीशी जुळले की जवळजवळ सर्व विकसक उबंटू ओएस वापरतात. आणि उबंटूवर, पहिल्या वापरकर्त्याचा आयडी 1000 आहे.

आमच्याकडे योजना आहेत का?

डॉकर दस्तऐवजीकरण वाचा. प्रकल्प सक्रियपणे विकसित होत आहे, दस्तऐवजीकरण बदलत आहे. दोन-तीन महिन्यांपूर्वी मिळालेला डेटा हळूहळू कालबाह्य होत चालला आहे.

आम्ही सोडवलेल्या काही समस्या मानक मार्गांनी आधीच सोडवल्या जाऊ शकतात.

त्यामुळे मला थेट ऑर्केस्ट्रेशनमध्ये जाण्यासाठी आधीच पुढे जायचे आहे.

एक उदाहरण म्हणजे डॉकरची अंगभूत यंत्रणा ज्याला डॉकर स्वार्म म्हणतात, जे बॉक्समधून बाहेर येते. मला डॉकर स्वार्म तंत्रज्ञानावर आधारित उत्पादनात काहीतरी चालवायचे आहे.

स्पॉनिंग कंटेनर लॉगसह काम करणे गैरसोयीचे बनवते. आता नोंदी वेगळ्या केल्या आहेत. ते कंटेनरमध्ये विखुरलेले आहेत. वेब इंटरफेसद्वारे लॉगमध्ये सोयीस्कर प्रवेश करणे हे एक कार्य आहे.

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