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

सबसे पहले, थोड़ा सिद्धांत. क्या हुआ है बारह-कारक ऐप?

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

दस्तावेज़ हेरोकू प्लेटफ़ॉर्म के डेवलपर्स द्वारा बनाया गया था।

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

संक्षेप में उन कारकों के बारे में जिन पर यह पद्धति आधारित है:

कोडबेस - संस्करण नियंत्रण में ट्रैक किया गया एक कोडबेस - एकाधिक परिनियोजन
निर्भरता - निर्भरता को स्पष्ट रूप से घोषित करें और अलग करें
विन्यास - रनटाइम में कॉन्फ़िगरेशन सहेजें
समर्थन सेवाएँ - बैकिंग सेवाओं को प्लग-इन संसाधनों के रूप में मानें
निर्माण करें, जारी करें, चलाएं - असेंबली और निष्पादन चरणों को सख्ती से अलग करें
Процессы - एप्लिकेशन को एक या अधिक स्टेटलेस प्रक्रियाओं के रूप में चलाएं
बंदरगाह की जिल्दबंदी - पोर्ट बाइंडिंग के माध्यम से निर्यात सेवाएँ
समानता - प्रक्रियाओं का उपयोग करके अपने एप्लिकेशन को स्केल करें
प्रयोज्यता - तेज स्टार्टअप और क्लीन शटडाउन के साथ विश्वसनीयता को अधिकतम करें
अनुप्रयोग विकास/संचालन समता - अपने विकास, मंचन और उत्पादन परिवेश को यथासंभव समान रखें
लॉगिंग - लॉग को घटनाओं की एक धारा के रूप में देखें
प्रशासन के कार्य - तदर्थ प्रक्रियाओं का उपयोग करके प्रशासन/प्रबंधन कार्य करना

आप निम्नलिखित संसाधनों से 12 कारकों के बारे में अधिक जानकारी प्राप्त कर सकते हैं:

आधिकारिक स्रोत - एक अवश्य पढ़ने की बात
हबर पर लेख. बारह-कारक ऐप - आधिकारिक अनुवाद
हबर पर लेख. 7 फैक्टर ऐप में 12 गायब फैक्टर - सुधार के उद्देश्य से 12 कारकों पर नए सिरे से नजर डालें।

ब्लू-ग्रीन परिनियोजन क्या है?

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

क्लासिक बीजी परिनियोजन योजना नीचे दी गई छवि में दिखाई गई योजना जैसी दिखती है।

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

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

बुरी और अच्छी सलाह

Disclaimer: नीचे दिए गए उदाहरण मेरे द्वारा उपयोग की जाने वाली उपयोगिताओं/कार्यप्रणालियों को दर्शाते हैं, आप समान कार्यों वाले किसी भी विकल्प का उपयोग कर सकते हैं।

अधिकांश उदाहरण किसी न किसी तरह वेब विकास (यह आश्चर्य की बात है) के साथ, PHP और डॉकर के साथ जुड़ेंगे।

नीचे दिए गए पैराग्राफ विशिष्ट उदाहरणों का उपयोग करके कारकों के उपयोग का एक सरल व्यावहारिक विवरण प्रदान करते हैं; यदि आप इस विषय पर अधिक सिद्धांत प्राप्त करना चाहते हैं, तो मूल स्रोत के लिए उपरोक्त लिंक का अनुसरण करें।

1. कोडबेस

सर्वर पर एक-एक करके फ़ाइलें अपलोड करने के लिए FTP और FileZilla का उपयोग करें, कोड को उत्पादन सर्वर के अलावा कहीं और संग्रहीत न करें।

प्रोजेक्ट में हमेशा एक ही कोड बेस होना चाहिए, यानी सभी कोड एक से आते हैं जाना भण्डार. सर्वर (उत्पादन, स्टेजिंग, टेस्ट1, टेस्ट2...) एक सामान्य रिपॉजिटरी की शाखाओं से कोड का उपयोग करते हैं। इस तरह हम कोड स्थिरता प्राप्त करते हैं।

2. निर्भरता

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

एक प्रोजेक्ट में हमेशा निर्भरताओं की स्पष्ट रूप से समझने योग्य सूची होनी चाहिए (निर्भरता से मेरा मतलब पर्यावरण से भी है)। सभी निर्भरताएँ स्पष्ट रूप से परिभाषित और पृथक की जानी चाहिए।
चलिए एक उदाहरण के तौर पर लेते हैं संगीतकार и डाक में काम करनेवाला मज़दूर.

संगीतकार - एक पैकेज मैनेजर जो आपको PHP में लाइब्रेरी स्थापित करने की अनुमति देता है। कंपोज़र आपको संस्करणों को सख्ती से या शिथिल रूप से निर्दिष्ट करने और उन्हें स्पष्ट रूप से परिभाषित करने की अनुमति देता है। सर्वर पर 20 अलग-अलग प्रोजेक्ट हो सकते हैं और प्रत्येक के पास दूसरे से स्वतंत्र पैकेज और लाइब्रेरी की एक व्यक्तिगत सूची होगी।

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

3. विन्यास

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

विन्यास - यही एकमात्र तरीका है जिससे प्रोजेक्ट परिनियोजन भिन्न होना चाहिए। आदर्श रूप से, कॉन्फ़िगरेशन को पर्यावरण चर (env vars) के माध्यम से पारित किया जाना चाहिए।

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

4. तृतीय पक्ष सेवाएँ

परिवेश से सख्ती से बंधे रहें, कुछ परिवेशों में समान सेवाओं के लिए अलग-अलग कनेक्शन का उपयोग करें।

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

बाहरी सेवाओं से सभी कनेक्शन, जैसे कतार सर्वर, डेटाबेस, कैशिंग सेवाएँ, स्थानीय वातावरण और तृतीय-पक्ष/उत्पादन वातावरण दोनों के लिए समान होने चाहिए। दूसरे शब्दों में, किसी भी समय, कनेक्शन स्ट्रिंग को बदलकर, मैं एप्लिकेशन कोड को बदले बिना आधार #1 पर कॉल को आधार #2 से बदल सकता हूं। या, उदाहरण के तौर पर, आगे देखते हुए, सेवा को स्केल करते समय, आपको अतिरिक्त कैश सर्वर के लिए किसी विशेष तरीके से कनेक्शन निर्दिष्ट नहीं करना होगा।

5. निर्माण करना, जारी करना, निष्पादित करना

सर्वर पर कोड का केवल अंतिम संस्करण रखें, रिलीज़ को वापस लाने की कोई संभावना नहीं है। डिस्क स्थान भरने की कोई आवश्यकता नहीं. जो कोई भी सोचता है कि वह किसी त्रुटि के साथ कोड को उत्पादन में जारी कर सकता है वह एक बुरा प्रोग्रामर है!

तैनाती के सभी चरणों को एक दूसरे से अलग किया जाना चाहिए।

वापस रोल करने का मौका है. त्वरित पहुंच में सहेजे गए एप्लिकेशन की पुरानी प्रतियों (पहले से ही इकट्ठे और युद्ध के लिए तैयार) के साथ रिलीज करें, ताकि त्रुटियों के मामले में आप पुराने संस्करण को पुनर्स्थापित कर सकें। यानी सशर्त रूप से एक फ़ोल्डर है विज्ञप्ति और फ़ोल्डर वर्तमान, और सफल परिनियोजन और फ़ोल्डर को असेंबल करने के बाद वर्तमान नई रिलीज के लिए एक प्रतीकात्मक लिंक से जुड़ा हुआ है जो अंदर मौजूद है विज्ञप्ति रिलीज नंबर के पारंपरिक नाम के साथ।

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

6. प्रक्रियाएं

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

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

7. पोर्ट बाइंडिंग

केवल वेब सर्वर को ही पता होना चाहिए कि तृतीय-पक्ष सेवाओं के साथ कैसे काम करना है। या इससे भी बेहतर, सीधे वेब सर्वर के अंदर तृतीय-पक्ष सेवाएँ स्थापित करें। उदाहरण के लिए, अपाचे में एक PHP मॉड्यूल के रूप में।
आपकी सभी सेवाएँ कुछ पते और पोर्ट (localgost:5432, localhost:3000, nginx:80, php-fpm:9000) तक पहुंच के माध्यम से एक-दूसरे तक पहुंच योग्य होनी चाहिए, अर्थात, nginx से मैं php-fpm और to दोनों तक पहुंच सकता हूं पोस्टग्रेज, और php-fpm से पोस्टग्रेज और nginx तक और वास्तव में प्रत्येक सेवा से मैं दूसरी सेवा तक पहुंच सकता हूं। इस तरह, किसी सेवा की व्यवहार्यता किसी अन्य सेवा की व्यवहार्यता से जुड़ी नहीं है।

8. समांतरता

एक प्रक्रिया के साथ काम करें, अन्यथा कई प्रक्रियाएं एक-दूसरे के साथ नहीं मिल पाएंगी!

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

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

9. डिस्पोजेबिलिटी

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

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

10. अनुप्रयोग विकास/संचालन समता

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

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

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

11. लॉग

हम फ़ाइलों और डेटाबेस में लॉग लिखते हैं! हम लॉग से फ़ाइलें और डेटाबेस साफ़ नहीं करते हैं। आइए बस 9000 पेटा बाइट्स वाली एक हार्ड ड्राइव खरीदें और यह ठीक है।

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

12. प्रशासन के कार्य

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

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

PHP, Laravel, Laradock, Docker-Compose में उदाहरण कार्यान्वयन

P.S सभी उदाहरण MacOS पर बनाए गए थे। उनमें से अधिकांश लिनक्स के लिए भी उपयुक्त हैं। विंडोज़ उपयोगकर्ताओं, मुझे क्षमा करें, लेकिन मैंने लंबे समय से विंडोज़ के साथ काम नहीं किया है।

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

docker -v && 
docker-compose -v

1. रखो लाराडॉक

git clone https://github.com/Laradock/laradock.git && 
ls

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

2. हमारे एप्लिकेशन को चलाने के लिए लैराडॉक को कॉन्फ़िगर करें।

cd laradock && 
cp env-example .env

2.1. किसी संपादक में habr निर्देशिका (मूल फ़ोल्डर जिसमें लाराडॉक क्लोन किया गया है) खोलें। (मेरे PHPStorm मामले में)

इस स्तर पर हम प्रोजेक्ट को केवल एक नाम देते हैं।

2.2. कार्यक्षेत्र छवि लॉन्च करें. (आपके मामले में, छवियों को बनने में कुछ समय लगेगा)
वर्कस्पेस डेवलपर की ओर से फ्रेमवर्क के साथ काम करने के लिए एक विशेष रूप से तैयार की गई छवि है।

हम उपयोग करके कंटेनर के अंदर जाते हैं

docker-compose up -d workspace && 
docker-compose exec workspace bash

2.3. लारवेल स्थापित करना

composer create-project --prefer-dist laravel/laravel application

2.4. इंस्टालेशन के बाद, हम जांचते हैं कि प्रोजेक्ट के साथ डायरेक्टरी बनाई गई है या नहीं और कंपोज़ को मार दें।

ls
exit
docker-compose down

2.5. आइए PHPStorm पर वापस जाएं और .env फ़ाइल में हमारे लार्वा एप्लिकेशन के लिए सही पथ सेट करें।

3. सभी कोड को Git में जोड़ें।

ऐसा करने के लिए, हम Github (या कहीं और) पर एक रिपॉजिटरी बनाएंगे। आइए टर्मिनल में habr निर्देशिका पर जाएं और निम्नलिखित कोड निष्पादित करें।

echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status

आइए देखें कि क्या सब कुछ क्रम में है।

सुविधा के लिए, मैं Git के लिए कुछ विज़ुअल इंटरफ़ेस का उपयोग करने की अनुशंसा करता हूं, मेरे मामले में यह है GitKraken. (यहां एक रेफरल लिंक है)

4. आइए लॉन्च करें!

शुरू करने से पहले, सुनिश्चित करें कि पोर्ट 80 और 443 पर कुछ भी लटका हुआ नहीं है।

docker-compose up -d nginx php-fpm

इस प्रकार, हमारी परियोजना में 3 अलग-अलग सेवाएँ शामिल हैं:

nginx - वेब सर्वर
php-fpm - वेब सर्वर से अनुरोध प्राप्त करने के लिए php
कार्यक्षेत्र - डेवलपर्स के लिए php

फिलहाल, हमने यह हासिल किया है कि हमने एक ऐसा एप्लिकेशन बनाया है जो 4 में से 12 बिंदुओं को पूरा करता है, अर्थात्:

1. कोडबेस - सभी कोड एक रिपॉजिटरी में हैं (छोटा नोट: लारवेल प्रोजेक्ट के अंदर डॉकर जोड़ना सही हो सकता है, लेकिन यह महत्वपूर्ण नहीं है)।

2. निर्भरता - हमारी सभी निर्भरताएं एप्लिकेशन/कंपोजर.जेसन और प्रत्येक कंटेनर के प्रत्येक डॉकरफाइल में स्पष्ट रूप से लिखी गई हैं।

3. समर्थन सेवाएँ - प्रत्येक सेवा (php-fom, nignx, कार्यक्षेत्र) अपना जीवन जीती है और बाहर से जुड़ी होती है और एक सेवा के साथ काम करने पर दूसरी प्रभावित नहीं होगी।

4. Процессы - प्रत्येक सेवा एक प्रक्रिया है। प्रत्येक सेवा आंतरिक स्थिति को बनाए नहीं रखती है।

5. बंदरगाह की जिल्दबंदी

docker ps

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

6. समानता

डॉकर हमें उनके बीच स्वचालित लोड संतुलन के साथ समान सेवाओं की कई प्रक्रियाओं को उत्पन्न करने की अनुमति देता है।

आइए कंटेनरों को रोकें और उन्हें ध्वज के माध्यम से चलाएं --पैमाना

docker-compose down && 
docker-compose up -d --scale php-fpm=3 nginx php-fpm

जैसा कि हम देख सकते हैं, php-fpm कंटेनर की प्रतियां बनाई गई हैं। हमें इस कंटेनर के साथ काम करने में कुछ भी बदलने की ज़रूरत नहीं है। हम इसे पोर्ट 9000 पर भी एक्सेस करना जारी रखते हैं, और डॉकर हमारे लिए कंटेनरों के बीच लोड को नियंत्रित करता है।

7. प्रयोज्यता - प्रत्येक कंटेनर को दूसरे को नुकसान पहुंचाए बिना मारा जा सकता है। कंटेनर को रोकने या पुनः आरंभ करने से बाद के लॉन्च के दौरान एप्लिकेशन के संचालन पर कोई प्रभाव नहीं पड़ेगा। प्रत्येक कंटेनर को किसी भी समय उठाया भी जा सकता है।

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

9. लॉगिंग - इन कंटेनरों के सभी लॉग स्ट्रीम में जाते हैं और डॉकर कंसोल में दिखाई देते हैं। (इस मामले में, वास्तव में, अन्य घरेलू कंटेनरों के साथ, यदि आप इसकी देखभाल नहीं करते हैं तो ऐसा नहीं हो सकता है)

 docker-compose logs -f

लेकिन इसमें एक दिक्कत है कि PHP और Nginx में डिफ़ॉल्ट मान किसी फ़ाइल में लॉग भी लिखते हैं। 12 कारकों को पूरा करना जरूरी है बंद प्रत्येक कंटेनर के कॉन्फ़िगरेशन में एक फ़ाइल में अलग से लॉग लिखना।

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

10. प्रशासन के कार्य - कारीगर टूल की बदौलत सभी प्रशासन कार्यों को लारवेल द्वारा हल किया जाता है, जैसा कि 12 कारक एप्लिकेशन के निर्माता चाहते हैं।

उदाहरण के तौर पर, मैं दिखाऊंगा कि कुछ कमांड कैसे निष्पादित होते हैं।
हम कंटेनर में जाते हैं।

 
docker-compose exec workspace bash
php artisan list

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

11. विन्यास और 12। निर्माण करें, जारी करें, चलाएं

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

संक्षेप में, यह अवधारणा सीआई/सीडी प्रणालियों पर आधारित है जेनकींस и गिटलैब सीआई. दोनों में, आप किसी विशिष्ट वातावरण से जुड़े पर्यावरण चर सेट कर सकते हैं। तदनुसार, इस स्थिति में, बिंदु c पूरा हो जाएगा विन्यास.

और इसके बारे में बात निर्माण करें, जारी करें, चलाएं नाम के साथ अंतर्निहित फ़ंक्शन द्वारा हल किया जाता है पाइपलाइन.

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

एप्लिकेशन कोड यहां है Github.
इस रिपॉजिटरी की क्लोनिंग करते समय सबमॉड्यूल को इनिशियलाइज़ करना न भूलें।

पी.एस.: इन सभी दृष्टिकोणों का उपयोग किसी भी अन्य उपयोगिताओं और प्रोग्रामिंग भाषाओं के साथ किया जा सकता है। मुख्य बात यह है कि सार भिन्न नहीं है।

स्रोत: www.habr.com

एप्लिकेशन विकास और ब्लू-ग्रीन परिनियोजन, php और docker में उदाहरणों के साथ बारह-फैक्टर ऐप पद्धति पर आधारित है