Docker र Gitlab CI संग विकास र परीक्षण प्रक्रिया

म तपाईंलाई Inventos "Docker + Gitlab CI सँग विकास र परीक्षण प्रक्रिया" बाट अलेक्ज्याण्डर सिगाचेभ द्वारा रिपोर्टको ट्रान्सक्रिप्ट पढ्न सुझाव दिन्छु।

जसले भर्खरै विकास र परीक्षण प्रक्रियालाई Docker + Gitlab CI मा आधारित लागू गर्न थालेका छन् प्राय: आधारभूत प्रश्नहरू सोध्छन्। कहाँ सुरु गर्ने? कसरी व्यवस्थित गर्ने? कसरी परीक्षण गर्ने?

यो रिपोर्ट राम्रो छ किनभने यसले डकर र Gitlab CI प्रयोग गरेर विकास र परीक्षण प्रक्रियाको बारेमा संरचित तरिकामा कुरा गर्छ। रिपोर्ट आफैं 2017 को हो। मलाई लाग्छ कि यस रिपोर्टबाट तपाईंले आधारभूत कुराहरू, पद्धति, विचार, र प्रयोगको अनुभव बटुल्न सक्नुहुन्छ।

जो कोही इच्छुक को लागी, बिरालो हेर्नुहोस्।

मेरो नाम अलेक्जेंडर सिगाचेभ हो। Inventos मा काम गर्नुहुन्छ म तपाईंलाई डकर प्रयोग गर्ने मेरो अनुभव र हामी कसरी कम्पनीमा परियोजनाहरूमा यसलाई बिस्तारै कार्यान्वयन गर्दैछौं भन्ने बारे बताउनेछु।

रिपोर्टको विषय: डकर र Gitlab CI प्रयोग गरेर विकास प्रक्रिया।

यो डकरको बारेमा मेरो दोस्रो कुराकानी हो। पहिलो रिपोर्टको समयमा, हामीले विकासकर्ता मेसिनहरूमा विकासमा मात्र डकर प्रयोग गर्यौं। डकर प्रयोग गर्ने कर्मचारीहरूको संख्या लगभग 2-3 व्यक्ति थियो। बिस्तारै अनुभव बटुल्दै गयो र हामी अलि अगाडि बढ्यौँ । हाम्रो लिङ्क पहिलो रिपोर्ट.

यो रिपोर्टमा के हुनेछ? हामीले कस्ता रेकहरू सङ्कलन गर्‍यौं, कस्ता समस्याहरू समाधान गर्‍यौं भन्ने बारे हाम्रो अनुभव साझा गर्नेछौं। यो जताततै सुन्दर थिएन, तर यसले हामीलाई अगाडि बढ्न अनुमति दियो।

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

हामी कस्ता समस्याहरू समाधान गर्दैछौं?

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

प्रोग्रामरले चाँडै बुझ्नको लागि, उसले परियोजनाको स्रोत कोड डाउनलोड गर्न आवश्यक छ र सकेसम्म चाँडो वातावरण सुरु गर्न आवश्यक छ, जसले उसलाई यस परियोजनाको समस्याहरू समाधान गर्न थप अगाडि बढ्न अनुमति दिनेछ।

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

अर्को कारण विकासमा सेटिङहरूको मानकीकरण हो। मेरो अनुभवमा, विकासकर्ताहरूले सधैं पहल गर्छन्। प्रत्येक पाँचौं केसमा, अनुकूलन डोमेन प्रविष्ट गरिन्छ, उदाहरणका लागि vasya.dev। मेरो छेउमा मेरो छिमेकी पेट्या बसेको छ, जसको डोमेन petya.dev हो। तिनीहरूले यो डोमेन नाम प्रयोग गरेर वेबसाइट वा केही प्रणाली कम्पोनेन्ट विकास गर्छन्।

जब प्रणाली बढ्छ र यी डोमेन नामहरू कन्फिगरेसनमा समावेश हुन थाल्छ, विकास वातावरणमा द्वन्द्व उत्पन्न हुन्छ र साइट मार्ग पुन: लेखिन्छ।

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

अर्को समस्या पुस्तकालयहरूको विभिन्न संस्करण हो। यो अक्सर हुन्छ कि एक विकासकर्ता विभिन्न परियोजनाहरु मा काम गर्दछ। त्यहाँ एक विरासत परियोजना छ, जुन पाँच वर्ष पहिले सुरु भयो (2017 बाट - सम्पादकको नोट)। सुरुमा हामीले MySQL 5.5 सँग सुरु गर्यौं। त्यहाँ आधुनिक परियोजनाहरू पनि छन् जहाँ हामी MySQL को थप आधुनिक संस्करणहरू लागू गर्ने प्रयास गरिरहेका छौं, उदाहरणका लागि 5.7 वा पुरानो (2017 मा - सम्पादकको नोट)

MySQL सँग काम गर्ने जो कोहीलाई थाहा छ कि यी पुस्तकालयहरूमा निर्भरताहरू छन्। 2 डाटाबेस सँगै चलाउन धेरै समस्या छ। कम्तिमा, पुरानो ग्राहकहरूलाई नयाँ डाटाबेसमा जडान गर्न समस्याग्रस्त छ। यसले बारीमा धेरै समस्याहरू जन्माउँछ।

अर्को समस्या हो जब एक विकासकर्ता स्थानीय मेसिनमा काम गर्दछ, उसले स्थानीय स्रोतहरू, स्थानीय फाइलहरू, स्थानीय RAM प्रयोग गर्दछ। समस्याहरूको समाधानको विकासको समयमा सबै अन्तरक्रियाहरू एक मेसिनमा काम गर्ने तथ्यको ढाँचा भित्र गरिन्छ। एउटा उदाहरण हो जब हामीसँग उत्पादन 3 मा ब्याकइन्ड सर्भरहरू छन्, र विकासकर्ताले फाइलहरूलाई रूट डाइरेक्टरीमा बचत गर्दछ र त्यहाँबाट nginx ले अनुरोधलाई प्रतिक्रिया दिन फाइलहरू लिन्छ। जब यस्तो कोड उत्पादनमा जान्छ, यो बाहिर जान्छ कि फाइल 3 सर्भर मध्ये एकमा अवस्थित छ।

माइक्रो सर्भिसको दिशा अहिले विकास भइरहेको छ। जब हामी हाम्रा ठूला अनुप्रयोगहरूलाई एकअर्कासँग अन्तरक्रिया गर्ने केही साना कम्पोनेन्टहरूमा विभाजन गर्छौं। यसले तपाइँलाई विशेष कार्य स्ट्याकको लागि प्रविधिहरू चयन गर्न अनुमति दिन्छ। यसले तपाईंलाई विकासकर्ताहरू बीचको काम र जिम्मेवारीको क्षेत्र विभाजन गर्न पनि अनुमति दिन्छ।

एक फ्रन्टएन्ड विकासकर्ता, JS मा विकास गर्दै, ब्याकएन्डमा वस्तुतः कुनै प्रभाव छैन। ब्याकएन्ड विकासकर्ता, बारीमा, विकास गर्दछ, हाम्रो अवस्थामा, रुबी अन रेलहरू र फ्रन्डेन्डमा हस्तक्षेप गर्दैन। अन्तरक्रिया API प्रयोग गरी गरिन्छ।

बोनसको रूपमा, डकर प्रयोग गरेर हामी स्टेजिङमा स्रोतहरू पुन: प्रयोग गर्न सक्षम थियौं। प्रत्येक परियोजना, यसको विशिष्टताको कारण, निश्चित सेटिङहरू आवश्यक छ। भौतिक रूपमा, यो या त भर्चुअल सर्भर आवंटित गर्न र तिनीहरूलाई अलग कन्फिगर गर्न आवश्यक थियो, वा केही प्रकारको चर वातावरण विभाजन गर्न र पुस्तकालयहरूको संस्करणमा निर्भर परियोजनाहरूले एकअर्कालाई प्रभाव पार्न सक्छ।

उपकरणहरू। हामी के प्रयोग गर्छौं?

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

प्रतिवेदन दुई भागमा समावेश छ।

पहिलो भागले तपाईंलाई विकासकर्ताहरूको मेसिनमा डकर कसरी चलाउने भनेर बताउनेछ।

दोस्रो भागले GitLab सँग कसरी अन्तरक्रिया गर्ने, हामी कसरी परीक्षणहरू चलाउँछौं र कसरी स्टेजिङमा रोल आउट गर्छौं भन्ने बारेमा कुरा गर्नेछ।

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

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

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

हामीले यो पनि वर्णन गर्छौं कि हामीले हाम्रो विकासकर्ता होस्ट मेसिनमा पोर्टलाई 3000 देखि 3000 कन्टेनर पोर्टमा फर्वार्ड गर्न आवश्यक छ। यो स्वचालित रूपमा iptables र यसको आफ्नै संयन्त्र प्रयोग गरेर गरिन्छ, जुन प्रत्यक्ष रूपमा डकरमा इम्बेड गरिएको छ।

विकासकर्ताले, पहिले जस्तै, कुनै पनि उपलब्ध IP ठेगाना पहुँच गर्न सक्छ, उदाहरणका लागि, 127.0.0.1 मेसिनको स्थानीय वा बाह्य IP ठेगाना।

अन्तिम रेखाले वेब कन्टेनर db कन्टेनरमा निर्भर गर्दछ भनी भन्छ। जब हामी वेब कन्टेनर सुरु गर्न कल गर्छौं, डकर-कम्पोजले हाम्रो लागि डाटाबेस सुरु गर्नेछ। डाटाबेसको सुरुवातमा पहिले नै (वास्तवमा, कन्टेनरको सुरुवात पछि! यसले डाटाबेसको तयारीको ग्यारेन्टी गर्दैन) यसले हाम्रो अनुप्रयोग, हाम्रो ब्याकएन्ड सुरु गर्नेछ।

यसले हामीलाई डाटाबेस माथि नभएको बेला त्रुटिहरूबाट बच्न अनुमति दिन्छ र हामीले डाटाबेस कन्टेनर बन्द गर्दा स्रोतहरू बचत गर्न अनुमति दिन्छ, जसले गर्दा अन्य परियोजनाहरूका लागि स्रोतहरू खाली हुन्छ।

परियोजनामा ​​डाटाबेस डकराइजेसन प्रयोग गर्दा हामीलाई के दिन्छ? हामी सबै विकासकर्ताहरूको लागि MySQL संस्करण रेकर्ड गर्छौं। यसले तपाइँलाई केहि त्रुटिहरूबाट बच्न अनुमति दिन्छ जुन संस्करणहरू भिन्न हुँदा, सिन्ट्याक्स, कन्फिगरेसन, र पूर्वनिर्धारित सेटिङहरू परिवर्तन हुँदा हुन सक्छ। यसले तपाइँलाई डाटाबेस, लगइन, पासवर्डको लागि साझा होस्टनाम निर्दिष्ट गर्न अनुमति दिन्छ। हामी पहिले अवस्थित कन्फिग फाइलहरूमा नाम र विवादहरूको चिडियाखानाबाट टाढा जाँदैछौं।

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

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

छवि निर्माण गरेपछि, विकास र उत्पादन दुवैमा कन्टेनरहरू समान हुनेछन्। यो ठूला स्थापनाहरूको लागि विशेष गरी सत्य हो।

Frontend मा हामी JavaScipt र NodeJS प्रयोग गर्छौं।

अब हामीसँग ReacJS मा हाम्रो अन्तिम परियोजना छ। विकासकर्ताले कन्टेनरमा सबै कुरा सुरु गर्यो र हट-रिलोड प्रयोग गरेर विकास गर्यो।

अर्को, JavaScipt एसेम्बल गर्ने कार्य सुरु गरिएको छ र स्थिर रूपमा भेला गरिएको कोड nginx मार्फत पठाइन्छ, स्रोतहरू बचत गर्दै।

यहाँ मैले हाम्रो पछिल्लो परियोजनाको रेखाचित्र प्रदान गरेको छु।

कस्ता समस्या समाधान गर्नुभयो ? हामीले मोबाइल उपकरणहरू अन्तरक्रिया गर्ने प्रणाली निर्माण गर्न आवश्यक थियो। तिनीहरूले डाटा प्राप्त गर्छन्। सम्भावनाहरू मध्ये एक यो उपकरणमा पुश सूचनाहरू पठाउन हो।

यसका लागि हामीले के गरेका छौं?

हामीले एप्लिकेसनलाई निम्न कम्पोनेन्टहरूमा विभाजित गर्यौं: JS मा एक प्रशासकको भाग, एक ब्याकइन्ड जसले Ruby on Rails अन्तर्गत REST इन्टरफेस मार्फत काम गर्दछ। ब्याकइन्डले डाटाबेससँग अन्तरक्रिया गर्छ। उत्पन्न भएको परिणाम ग्राहकलाई दिइन्छ। व्यवस्थापक प्यानलले ब्याकइन्ड र डाटाबेससँग REST इन्टरफेस मार्फत अन्तरक्रिया गर्छ।

हामीलाई पुश सूचनाहरू पठाउन पनि आवश्यक थियो। यस अघि, हामीसँग एउटा परियोजना थियो जसमा एउटा संयन्त्र लागू गरिएको थियो जुन मोबाइल प्लेटफर्महरूमा सूचनाहरू डेलिभर गर्न जिम्मेवार थियो।

हामीले निम्न योजना विकास गरेका छौं: ब्राउजरबाट अपरेटरले प्रशासक प्यानलसँग अन्तरक्रिया गर्दछ, प्रशासक प्यानल ब्याकइन्डसँग अन्तर्क्रिया गर्दछ, कार्य पुश सूचनाहरू पठाउने हो।

पुश सूचनाहरूले NodeJS मा लागू गरिएको अर्को कम्पोनेन्टसँग अन्तरक्रिया गर्दछ।

लामहरू बनाइन्छ र सूचनाहरू तिनीहरूको आफ्नै संयन्त्र अनुसार पठाइन्छ।

यहाँ दुई डाटाबेस कोरिएका छन्। हाल, डकर प्रयोग गरेर, हामी 2 स्वतन्त्र डाटाबेसहरू प्रयोग गर्छौं जुन कुनै पनि हिसाबले एकअर्कासँग जोडिएको छैन। तिनीहरूसँग साझा भर्चुअल नेटवर्क छ भन्ने तथ्यको अतिरिक्त, र भौतिक डेटा विकासकर्ताको मेसिनमा विभिन्न डाइरेक्टरीहरूमा भण्डारण गरिएको छ।

एउटै कुरा तर संख्यामा। कोड पुन: प्रयोग यहाँ महत्त्वपूर्ण छ।

यदि पहिले हामीले पुस्तकालयहरूको रूपमा कोड पुन: प्रयोग गर्ने बारे कुरा गर्यौं भने, यस उदाहरणमा हाम्रो सेवा, जसले पुश सूचनाहरूलाई प्रतिक्रिया दिन्छ, पूर्ण सर्भरको रूपमा पुन: प्रयोग गरिन्छ। यसले एपीआई प्रदान गर्दछ। र हाम्रो नयाँ विकास यसको साथ अन्तरक्रिया गर्दछ।

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

यदि आवश्यक छ भने, तपाईंले पुश सूचना सेवाको NodeJS संस्करणलाई रिफ्याक्टर र बढाउन सक्नुहुन्छ।

र यदि हामीले एपीआई अनुकूलता कायम राख्न सक्छौं भने, यसलाई पहिले प्रयोग गरिएका अन्य परियोजनाहरूसँग बदल्न सम्भव हुनेछ।

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

नयाँ परियोजना सिर्जना गर्दा, हामी एक Dockerfile सिर्जना गर्छौं र इच्छित इकोसिस्टम (Python, Ruby, NodeJS) को वर्णन गर्छौं। डकर-कम्पोजमा, यसले आवश्यक निर्भरता वर्णन गर्दछ - डाटाबेस। हामी वर्णन गर्छौं कि हामीलाई त्यहाँ र त्यहाँ डाटा भण्डारण गर्न, त्यस्ता र त्यस्ता संस्करणहरूको डाटाबेस चाहिन्छ।

हामी स्थिर सामग्री सेवा गर्न nginx सँग छुट्टै तेस्रो कन्टेनर प्रयोग गर्छौं। तस्विरहरू अपलोड गर्न सम्भव छ। ब्याकइन्डले तिनीहरूलाई पूर्व-तयार भोल्युममा राख्छ, जुन nginx सँग कन्टेनरमा पनि माउन्ट हुन्छ, जसले स्थिर डेटा प्रदान गर्दछ।

nginx र mysql कन्फिगरेसन भण्डारण गर्न, हामीले डकर फोल्डर थप्यौं जसमा हामी आवश्यक कन्फिगरेसनहरू भण्डार गर्छौं। जब एक विकासकर्ताले आफ्नो मेसिनमा भण्डारको गिट क्लोन बनाउँछ, ऊसँग पहिले नै स्थानीय विकासको लागि एक परियोजना तयार छ। कुन पोर्ट वा कुन सेटिङहरू लागू गर्ने बारे कुनै प्रश्न छैन।

अर्को हामीसँग धेरै कम्पोनेन्टहरू छन्: प्रशासक, जानकारी-एपीआई, पुश सूचनाहरू।

यी सबै सुरु गर्नको लागि, हामीले डकराइज्ड-एप भनिने अर्को भण्डार सिर्जना गर्यौं। हामी हाल प्रत्येक कम्पोनेन्टको लागि बहु भण्डारहरू प्रयोग गर्छौं। तिनीहरू केवल तार्किक रूपमा फरक छन् - GitLab मा यो फोल्डर जस्तो देखिन्छ, तर विकासकर्ताको मेसिनमा यो एक विशेष परियोजनाको लागि फोल्डर जस्तो देखिन्छ। एक तह तल कम्पोनेन्टहरू छन् जुन संयोजन गरिनेछ।

यो dockerized-app को सामग्री को एक उदाहरण हो। हामी यहाँ डकर डाइरेक्टरी पनि राख्छौं, जसमा हामी सबै कम्पोनेन्टहरूको अन्तरक्रियाका लागि आवश्यक कन्फिगरेसनहरू भर्छौं। त्यहाँ एउटा README.md छ जसले परियोजना कसरी सुरु गर्ने भनेर संक्षिप्त रूपमा वर्णन गर्दछ।

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

यदि पुश सूचनाहरूसँग एकीकरणको आवश्यकता छ भने, त्यसपछि docker-compose.yaml र docker-compose-push.yaml सुरू गरिन्छ।

डकर-compose.yaml र docker-compose-push.yaml फोल्डरमा भएकाले, एकल भर्चुअल नेटवर्क स्वतः सिर्जना हुन्छ।

अवयवहरूको विवरण। यो एक थप उन्नत फाइल हो जुन कम्पोनेन्टहरू सङ्कलन गर्न जिम्मेवार छ। यहाँ के उल्लेखनीय छ? यहाँ हामी ब्यालेन्सर कम्पोनेन्ट परिचय गर्छौं।

यो एक तयार-निर्मित डकर छवि हो जसले nginx चलाउँछ र एक अनुप्रयोग जसले डकर सकेट सुन्दछ। डायनामिक, कन्टेनरहरू सक्रिय र बन्द हुँदा, nginx कन्फिगरेसन पुन: उत्पन्न हुन्छ। हामी तेस्रो-स्तर डोमेन नामहरू प्रयोग गरेर कम्पोनेन्टहरूको ह्यान्डलिङ वितरण गर्छौं।

विकास वातावरणको लागि हामी .dev डोमेन - api.informer.dev प्रयोग गर्छौं। .dev डोमेन भएका अनुप्रयोगहरू विकासकर्ताको स्थानीय मेसिनमा उपलब्ध छन्।

त्यसपछि कन्फिगहरू प्रत्येक परियोजनामा ​​हस्तान्तरण गरिन्छ र सबै परियोजनाहरू एकै समयमा सँगै सुरू हुन्छन्।

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

ब्यालेन्सरले डोमेन नामको आधारमा कुन कन्टेनर पहुँच गर्न आवश्यक छ भनेर निर्धारण गर्दछ।

यो nginx हुन सक्छ, जसले प्रशासन प्यानललाई JS प्रदान गर्दछ। यो nginx द्वारा गर्न सकिन्छ, जसले API प्रदान गर्दछ, वा स्थिर फाइलहरू, जुन छविहरू लोड गर्ने रूपमा nginx द्वारा प्रदान गरिन्छ।

रेखाचित्रले देखाउँछ कि कन्टेनरहरू भर्चुअल नेटवर्कमा जोडिएका छन् र प्रोक्सी पछाडि लुकेका छन्।

विकासकर्ताको मेसिनमा, तपाईंले कन्टेनरलाई IP थाहा पाएर पहुँच गर्न सक्नुहुन्छ, तर सिद्धान्तमा हामी यसलाई प्रयोग गर्दैनौं। प्रत्यक्ष सम्पर्कको लागि व्यावहारिक रूपमा कुनै आवश्यकता छैन।

मेरो आवेदन डकराइज गर्न मैले कुन उदाहरण हेर्नुपर्छ? मेरो विचारमा, एक राम्रो उदाहरण MySQL को लागि आधिकारिक डकर छवि हो।

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

Hub.docker.com ले सामान्यतया github.com को लिङ्कहरू समावेश गर्दछ, जहाँ कच्चा डाटा सीधै प्रदान गरिन्छ जसबाट तपाईं आफैंले छवि बनाउन सक्नुहुन्छ।

यस रिपोजिटरीमा थप एक स्क्रिप्ट docker-endpoint.sh छ, जुन प्रारम्भिक सुरुवात र एप्लिकेसन लन्चको थप प्रशोधनको लागि जिम्मेवार छ।

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

त्यहाँ अनियमित पासवर्ड सिर्जना गर्ने विकल्प छ। हामी भन्छौं कि हामीलाई एक प्रयोगकर्ता चाहिन्छ, हामीले प्रयोगकर्ताको लागि पासवर्ड सेट गर्न आवश्यक छ, र हामीले डाटाबेस सिर्जना गर्न आवश्यक छ।

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

यो MySQL को एक विशिष्ट संस्करण github.com मा कस्तो देखिन्छ भन्ने उदाहरण हो। तपाईं Dockerfile खोल्न सक्नुहुन्छ र त्यहाँ स्थापना कसरी हुन्छ हेर्नुहोस्।

docker-endpoint.sh स्क्रिप्ट प्रविष्टि बिन्दुको लागि जिम्मेवार। प्रारम्भिक प्रारम्भिकताको समयमा, केही तयारी कार्यहरू आवश्यक हुन्छन् र यी सबै कार्यहरू प्रारम्भिक लिपिमा समावेश हुन्छन्।

दोस्रो भागमा जाऔं।

हामीले स्रोत कोडहरू भण्डारण गर्न gitlab मा स्विच गर्यौं। यो एकदम शक्तिशाली प्रणाली हो जसमा भिजुअल इन्टरफेस छ।

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

Gitlab CI 2 मा रिपोर्ट https://goo.gl/uohKjI - रुबी रूस क्लबको रिपोर्ट धेरै विस्तृत छ र तपाइँको लागि चासोको हुन सक्छ।

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

यहाँ हामी वर्णन गर्छौं कि हामी परीक्षण, तैनाती जस्ता राज्यहरूको अनुक्रम प्रदर्शन गर्न चाहन्छौं।

हामी स्क्रिप्टहरू कार्यान्वयन गर्छौं जसले प्रत्यक्ष रूपमा हाम्रो अनुप्रयोगको डकर-कम्पोज निर्माणलाई कल गर्छ। यो ब्याकइन्डको उदाहरण मात्र हो।

अर्को हामी भन्छौं कि डाटाबेस परिवर्तन गर्न र परीक्षणहरू चलाउन माइग्रेसनहरू चलाउन आवश्यक छ।

यदि स्क्रिप्टहरू सही रूपमा कार्यान्वयन गरिन्छ र त्रुटि कोड फिर्ता गर्दैन भने, त्यसपछि प्रणाली प्रयोगको दोस्रो चरणमा अगाडि बढ्छ।

डिप्लोइमेन्ट स्टेज हाल स्टेजिङको लागि लागू गरिएको छ। हामीले नो-डाउनटाइम रिस्टार्टलाई व्यवस्थित गरेका छैनौं।

हामी जबरजस्ती सबै कन्टेनरहरू निभाउँछौं, र त्यसपछि हामी परीक्षणको क्रममा पहिलो चरणमा सङ्कलन गरिएका सबै कन्टेनरहरू फेरि उठाउँछौं।

हालको चर वातावरणको लागि विकासकर्ताहरूले लेखेका डाटाबेस माइग्रेसनहरू चलाउनुहोस्।

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

अन्य शाखाहरू परिवर्तन गर्दा काम गर्दैन।

शाखाहरूमा रोलआउटहरू व्यवस्थित गर्न सम्भव छ।

यसलाई थप व्यवस्थित गर्न, हामीले Gitlab धावक स्थापना गर्न आवश्यक छ।

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

स्टार्टअपमा हामी Gitlab धावक दर्ता गर्छौं।

हामीले Gitlab वेब इन्टरफेसमा कुञ्जी प्राप्त गर्छौं।

त्यसपछि हामी कमाण्ड लाइनमा प्रारम्भिक आदेशलाई कल गर्छौं।

संवाद मोडमा Gitlab धावक कन्फिगर गर्दै (Shell, Docker, VirtualBox, SSH)

Gitlab रनरको कोड .gitlab-ci.yml सेटिङको आधारमा प्रत्येक कमिटमा कार्यान्वयन हुनेछ।

यो वेब इन्टरफेसमा Gitlab मा कसरी देखिन्छ। GItlab CI जडान गरेपछि, हामीसँग झण्डा छ जसले देखाउँछ कि निर्माण कुन अवस्थामा छ।

हामी देख्छौं कि 4 मिनेट पहिले एक प्रतिबद्धता बनाइएको थियो जसले सबै परीक्षणहरू पास गर्यो र कुनै समस्या उत्पन्न गर्दैन।

हामी थप विवरणमा निर्माणहरू हेर्न सक्छौं। यहाँ हामी देख्छौं कि दुई राज्य पहिले नै पारित भइसकेको छ। स्टेजिङमा परीक्षण स्थिति र तैनाती स्थिति।

यदि हामीले एक विशिष्ट निर्माणमा क्लिक गर्यौं भने, .gitlab-ci.yml अनुसार प्रक्रियामा सुरु गरिएका आदेशहरूको कन्सोल आउटपुट हुनेछ।

हाम्रो उत्पादनको कथा यस्तो देखिन्छ। हामीले देखेका छौं कि त्यहाँ सफल प्रयासहरू छन्। जब परीक्षणहरू पेश गरिन्छ, तिनीहरू अर्को चरणमा सर्दैनन् र स्टेजिङ कोड अपडेट हुँदैन।

हामीले डकर लागू गर्दा हामीले स्टेजिङमा के समस्याहरू समाधान गर्यौं? हाम्रो प्रणालीमा कम्पोनेन्टहरू हुन्छन् र हामीले रिपोजिटरीमा अद्यावधिक गरिएका केही कम्पोनेन्टहरू मात्र पुन: सुरु गर्न आवश्यक छ, र सम्पूर्ण प्रणालीलाई होइन।

यो गर्नको लागि, हामीले सबै कुरालाई अलग-अलग फोल्डरहरूमा छुट्याउनुपर्छ।

हामीले यो गरेपछि, हामीसँग समस्या थियो कि डकर-कम्पोजले प्रत्येक फोल्डरको लागि आफ्नै नेटवर्क स्पेस सिर्जना गर्दछ र यसको छिमेकीका घटकहरू देख्दैन।

वरपर जानको लागि, हामीले डकरमा म्यानुअल रूपमा नेटवर्क सिर्जना गर्यौं। डकर-कम्पोजमा तपाईले यो परियोजनाको लागि यस्तो नेटवर्क प्रयोग गर्नुपर्छ भनेर लेखिएको थियो।

यसरी, यो जालबाट सुरु हुने प्रत्येक कम्पोनेन्टले प्रणालीको अन्य भागहरूमा कम्पोनेन्टहरू देख्छ।

अर्को समस्या धेरै परियोजनाहरू बीच स्टेजिङ विभाजन हो।

यो सबै सुन्दर देखिन र उत्पादनको लागि सकेसम्म नजिक हुनको लागि, यो पोर्ट 80 वा 443 प्रयोग गर्न राम्रो छ, जुन WEB मा सबै ठाउँमा प्रयोग गरिन्छ।

हामीले यसलाई कसरी समाधान गर्यौं? हामीले सबै ठूला परियोजनाहरूमा एक Gitlab धावक तोक्यौं।

Gitlab ले तपाईंलाई धेरै वितरित Gitlab धावकहरू सुरू गर्न अनुमति दिन्छ, जसले सबै कार्यहरू एक एक गरी अराजक क्रममा लिनेछ र तिनीहरूलाई चलाउनेछ।

घरको समस्याबाट बच्नको लागि, हामीले हाम्रा परियोजनाहरूको समूहलाई एक गिटल्याब रनरमा सीमित गर्यौं, जसले हाम्रो भोल्युमहरू बिना समस्याहरू सामना गर्दछ।

हामीले nginx-proxy लाई छुट्टै लन्च स्क्रिप्टमा सार्यौं र यसमा सबै परियोजनाहरूको ग्रिडहरू लेख्यौं।

हाम्रो परियोजनाको एउटा ग्रिड छ, र ब्यालेन्सरमा परियोजनाको नाममा आधारित धेरै ग्रिडहरू छन्। यसले डोमेन नामहरूद्वारा थप प्रोक्सी गर्न सक्छ।

हाम्रा अनुरोधहरू पोर्ट 80 मा डोमेन मार्फत आउँछन् र यो डोमेन सेवा गर्ने कन्टेनरहरूको समूहमा समाधान गरिन्छ।

अन्य समस्या के के थिए ? यो सबै कन्टेनरहरू पूर्वनिर्धारित रूपमा रूटको रूपमा चल्ने कुरा हो। यो प्रणालीको मूल असमान रूट होस्ट हो।

यद्यपि, यदि तपाईंले कन्टेनर प्रविष्ट गर्नुभयो भने, यो रूट हुनेछ र हामीले यस कन्टेनरमा सिर्जना गर्ने फाइलले रूट अधिकारहरू प्राप्त गर्दछ।

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

यसलाई कसरी समाधान गर्न सकिन्छ? तपाईं कन्टेनरमा हुने प्रयोगकर्ताहरू थप्न सक्नुहुन्छ।

हामीले प्रयोगकर्ता थप्दा के समस्या उत्पन्न भयो?

प्रयोगकर्ता सिर्जना गर्दा, समूह ID (UID) र प्रयोगकर्ता ID (GID) प्राय: मेल खाँदैन।

कन्टेनरमा यो समस्या समाधान गर्न हामी ID 1000 भएका प्रयोगकर्ताहरू प्रयोग गर्छौं।

हाम्रो अवस्थामा, यो तथ्यसँग मेल खान्छ कि लगभग सबै विकासकर्ताहरूले Ubuntu OS प्रयोग गर्छन्। र Ubuntu OS मा पहिलो प्रयोगकर्तासँग ID 1000 छ।

के हामीसँग योजना छ?

डकर कागजात पुन: पढ्नुहोस्। परियोजना सक्रिय रूपमा विकास भइरहेको छ, कागजात परिवर्तन हुँदैछ। दुई–तीन महिनाअघि प्राप्त तथ्याङ्क विस्तारै पुरानो हुँदै गइरहेको छ ।

हामीले समाधान गरेका केही समस्याहरू मानक माध्यमबाट पहिले नै समाधान भइसकेका हुन सक्छन्।

म वास्तवमै अगाडि बढ्न चाहन्छु र सिधै अर्केस्ट्रेशनमा जान चाहन्छु।

एउटा उदाहरण डकरको बिल्ट-इन मेकानिजम हो जसलाई डकर स्वार्म भनिन्छ, जुन बक्सबाट बाहिर आउँछ। म डकर स्वार्म टेक्नोलोजीमा आधारित उत्पादनमा केहि सुरू गर्न चाहन्छु।

स्प्यानिङ कन्टेनरहरूले लगहरूसँग काम गर्न असुविधाजनक बनाउँछ। अब लगहरू अलग छन्। तिनीहरू कन्टेनरहरूमा छरिएका छन्। कार्यहरू मध्ये एउटा वेब इन्टरफेस मार्फत लगहरूमा सुविधाजनक पहुँच बनाउनु हो।

स्रोत: www.habr.com