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

प्रथम, एक छोटा सिद्धांत. काय झाले बारा-फॅक्टर अॅप?

सोप्या शब्दात सांगायचे तर, हा दस्तऐवज SaaS ऍप्लिकेशन्सचा विकास सुलभ करण्यासाठी डिझाइन केला आहे, विकासक आणि DevOps अभियंत्यांना आधुनिक ऍप्लिकेशन्सच्या विकासामध्ये ज्या समस्या आणि पद्धतींचा सामना करावा लागतो त्याबद्दल माहिती देऊन मदत करणे.

दस्तऐवज हेरोकू प्लॅटफॉर्मच्या विकसकांनी तयार केले होते.

ट्वेल्व्ह-फॅक्टर अॅप कोणत्याही प्रोग्रामिंग भाषेत लिहिलेल्या आणि बॅकिंग सेवांच्या कोणत्याही संयोजनाचा वापर करून (डेटाबेस, संदेश रांगा, कॅशे इ.) अनुप्रयोगांवर लागू केले जाऊ शकते.

ही पद्धत ज्या घटकांवर आधारित आहे त्याबद्दल थोडक्यात:

1. कोडबेस - आवृत्ती नियंत्रणामध्ये ट्रॅक केलेला एक कोडबेस - एकाधिक उपयोजन
2. अवलंबित्व - अवलंबित्व स्पष्टपणे घोषित करा आणि वेगळे करा
3. कॉन्फिगरेशन - रनटाइममध्ये कॉन्फिगरेशन जतन करा
4. बॅकिंग सेवा - बॅकिंग सेवांचा प्लग-इन संसाधने म्हणून विचार करा
5. तयार करा, सोडा, चालवा - असेंबली आणि अंमलबजावणीचे टप्पे काटेकोरपणे वेगळे करा
6. प्रक्रिया - अर्ज एक किंवा अधिक स्टेटलेस प्रक्रिया म्हणून चालवा
7. पोर्ट बंधनकारक - पोर्ट बाइंडिंगद्वारे सेवा निर्यात करा
8. समांतरता - प्रक्रिया वापरून तुमचा अर्ज स्केल करा
9. डिस्पोजेबिलिटी - जलद स्टार्टअप आणि क्लीन शटडाउनसह विश्वासार्हता वाढवा
10. अनुप्रयोग विकास/ऑपरेशन समता - तुमचा विकास, स्टेजिंग आणि उत्पादन वातावरण शक्य तितके समान ठेवा
11. लॉगिंग - इव्हेंटचा प्रवाह म्हणून लॉग पहा
12. प्रशासन कार्ये - तदर्थ प्रक्रिया वापरून प्रशासन/व्यवस्थापन कार्ये करा

आपण खालील संसाधनांमधून 12 घटकांबद्दल अधिक माहिती मिळवू शकता:

• अधिकृत स्रोत - जरूर वाचावे
• habr वर लेख. बारा-फॅक्टर अॅप - अधिकृत भाषांतर
• habr वर लेख. 7 फॅक्टर अॅपमध्ये 12 गहाळ घटक - त्यांना सुधारण्याच्या उद्देशाने 12 घटकांवर एक नवीन देखावा.

ब्लू-ग्रीन डिप्लॉयमेंट म्हणजे काय?

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

क्लासिक बीजी डिप्लॉय स्कीम खालील इमेजमध्ये दाखवल्याप्रमाणे दिसते.

• सुरुवातीला 2 भौतिक सर्व्हर आहेत ज्यामध्ये पूर्णपणे समान कोड, अनुप्रयोग, प्रकल्प आहे आणि एक राउटर (बॅलन्सर) आहे.
• राउटर सुरुवातीला सर्व विनंत्या एका सर्व्हरकडे निर्देशित करतो (हिरवा).
• या क्षणी जेव्हा आपल्याला पुन्हा रिलीज करण्याची आवश्यकता असते, तेव्हा संपूर्ण प्रकल्प दुसर्या सर्व्हरवर अद्यतनित केला जातो (निळा), जे सध्या कोणत्याही विनंत्यांवर प्रक्रिया करत नाही.
• कोड चालू झाल्यानंतर निळा सर्व्हर पूर्णपणे अद्ययावत झाला आहे, राउटरला येथून स्विच करण्याची आज्ञा दिली आहे हिरवा वर निळा सर्व्हर
• आता सर्व क्लायंट यासह चालत असलेल्या कोडचा परिणाम पाहतात निळा सर्व्हर
• काही काळ, हिरवा वर अयशस्वी तैनातीच्या बाबतीत सर्व्हर बॅकअप प्रत म्हणून काम करतो निळा सर्व्हर आणि अयशस्वी आणि बगच्या बाबतीत, राउटर वापरकर्ता प्रवाह परत स्विच करतो हिरवा जुन्या स्थिर आवृत्तीसह सर्व्हर, आणि नवीन कोड पुनरावृत्ती आणि चाचणीसाठी पाठविला जातो.
• आणि प्रक्रियेच्या शेवटी, ते त्याच प्रकारे अद्यतनित केले जाते हिरवा सर्व्हर आणि ते अद्यतनित केल्यानंतर, राउटर विनंती प्रवाह परत स्विच करतो हिरवा सर्व्हर

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

वाईट आणि चांगला सल्ला

जबाबदारी नाकारणे: खालील उदाहरणे मी वापरत असलेल्या उपयुक्तता/पद्धती दाखवतात, तुम्ही समान फंक्शन्ससह कोणतेही पर्याय वापरू शकता.

बहुतेक उदाहरणे PHP आणि डॉकरसह वेब डेव्हलपमेंटला (हे आश्चर्यचकित करणारे) एक प्रकारे किंवा दुसर्या प्रकारे छेदतील.

खालील परिच्छेद विशिष्ट उदाहरणे वापरून घटकांच्या वापराचे साधे व्यावहारिक वर्णन देतात; जर तुम्हाला या विषयावर अधिक सिद्धांत मिळवायचा असेल, तर मूळ स्त्रोताच्या वरील लिंकचे अनुसरण करा.

1. कोडबेस

सर्व्हरवर एकावेळी फाइल अपलोड करण्यासाठी FTP आणि FileZilla वापरा, कोड प्रोडक्शन सर्व्हर व्यतिरिक्त कोठेही स्टोअर करू नका.

प्रकल्पामध्ये नेहमी एकच कोड बेस असावा, म्हणजेच सर्व कोड एकाकडून येतात Git भांडार. सर्व्हर (उत्पादन, स्टेजिंग, चाचणी1, चाचणी2...) एका सामान्य भांडाराच्या शाखांमधील कोड वापरतात. अशा प्रकारे आम्ही कोडची सुसंगतता प्राप्त करतो.

2. अवलंबित्व

फोल्डरमधील सर्व लायब्ररी थेट प्रोजेक्टच्या रूटवर डाउनलोड करा. लायब्ररीच्या वर्तमान आवृत्तीसह फोल्डरमध्ये नवीन कोड हस्तांतरित करून फक्त अद्यतने करा. सर्व आवश्यक उपयुक्तता थेट होस्ट सर्व्हरवर स्थापित करा जेथे आणखी 20 सेवा चालू आहेत.

प्रकल्पामध्ये नेहमी अवलंबित्वांची स्पष्टपणे समजण्याजोगी यादी असावी (अवलंबनातून मला पर्यावरणाचाही अर्थ आहे). सर्व अवलंबित्व स्पष्टपणे परिभाषित आणि वेगळे केले पाहिजेत.
उदाहरण म्हणून घेऊ संगीतकार и गोदी कामगार.

संगीतकार — एक पॅकेज व्यवस्थापक जो तुम्हाला PHP मध्ये लायब्ररी स्थापित करण्याची परवानगी देतो. संगीतकार तुम्हाला आवृत्त्या काटेकोरपणे किंवा सैलपणे निर्दिष्ट करण्याची आणि त्यांना स्पष्टपणे परिभाषित करण्याची परवानगी देतो. सर्व्हरवर 20 वेगवेगळे प्रकल्प असू शकतात आणि प्रत्येकाकडे पॅकेजेस आणि लायब्ररींची वैयक्तिक यादी इतरांपेक्षा स्वतंत्र असेल.

गोदी कामगार — एक उपयुक्तता जी तुम्हाला ॲप्लिकेशन ज्या वातावरणात चालेल ते परिभाषित आणि वेगळे करण्याची परवानगी देते. त्यानुसार, संगीतकाराप्रमाणेच, परंतु अधिक तपशीलवार, आम्ही अनुप्रयोग कशासह कार्य करतो हे निर्धारित करू शकतो. PHP ची विशिष्ट आवृत्ती निवडा, अतिरिक्त काहीही न जोडता केवळ प्रकल्प कार्य करण्यासाठी आवश्यक असलेली पॅकेजेस स्थापित करा. आणि सर्वात महत्त्वाचे म्हणजे, होस्ट मशीन आणि इतर प्रकल्पांच्या पॅकेजेस आणि वातावरणात हस्तक्षेप न करता. म्हणजेच, डॉकरद्वारे चालणार्‍या सर्व्हरवरील सर्व प्रकल्प कोणत्याही पॅकेजचा संच आणि पूर्णपणे भिन्न वातावरण वापरू शकतात.

3. कॉन्फिगरेशन

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

कॉन्फिग्युरासी - हा एकमेव मार्ग आहे की प्रकल्प उपयोजनांमध्ये फरक असावा. तद्वतच, कॉन्फिगरेशन पर्यावरण व्हेरिएबल्स (env vars) मधून पास केले पाहिजेत.

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

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

पर्यावरणाशी काटेकोरपणे बांधले जा, विशिष्ट वातावरणात समान सेवांसाठी भिन्न कनेक्शन वापरा.

खरं तर, हा बिंदू कॉन्फिगरेशनच्या बिंदूसह जोरदारपणे ओव्हरलॅप होतो, कारण या बिंदूशिवाय, सामान्य कॉन्फिगरेशन डेटा बनविला जाऊ शकत नाही आणि सर्वसाधारणपणे, कॉन्फिगर करण्याची क्षमता कमी होणार नाही.

बाह्य सेवांचे सर्व कनेक्शन, जसे की रांग सर्व्हर, डेटाबेस, कॅशिंग सेवा, स्थानिक वातावरण आणि तृतीय-पक्ष/उत्पादन वातावरण दोन्हीसाठी समान असणे आवश्यक आहे. दुसऱ्या शब्दांत, कोणत्याही वेळी, कनेक्शन स्ट्रिंग बदलून, मी अनुप्रयोग कोड न बदलता बेस # 1 सह बेस # 2 वर कॉल बदलू शकतो. किंवा, पुढे पाहताना, उदाहरण म्हणून, सेवेचे स्केलिंग करताना, तुम्हाला अतिरिक्त कॅशे सर्व्हरसाठी कोणत्याही विशेष प्रकारे कनेक्शन निर्दिष्ट करावे लागणार नाही.

5. तयार करा, सोडा, कार्यान्वित करा

सर्व्हरवर कोडची फक्त अंतिम आवृत्ती ठेवा, रिलीझ परत आणण्याची कोणतीही शक्यता नाही. डिस्क जागा भरण्याची गरज नाही. ज्याला असे वाटते की ते कोड उत्पादनात त्रुटीसह सोडू शकतात तो एक वाईट प्रोग्रामर आहे!

तैनातीचे सर्व टप्पे एकमेकांपासून वेगळे करणे आवश्यक आहे.

परत फिरण्याची संधी आहे. ऍप्लिकेशनच्या जुन्या प्रतींसह रिलीझ तयार करा (आधीच एकत्रित केलेल्या आणि लढाईसाठी तयार) द्रुत प्रवेशामध्ये जतन करा, जेणेकरून त्रुटींच्या बाबतीत तुम्ही जुनी आवृत्ती पुनर्संचयित करू शकता. म्हणजेच, सशर्त एक फोल्डर आहे रिलीज आणि फोल्डर वर्तमान, आणि यशस्वी उपयोजन आणि फोल्डर असेंब्ली नंतर वर्तमान आत असलेल्या नवीन रिलीझच्या प्रतिकात्मक दुव्याद्वारे जोडलेले रिलीज प्रकाशन क्रमांकाच्या पारंपारिक नावासह.

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

6. प्रक्रिया

ऍप्लिकेशन स्टेट डेटा थेट ऍप्लिकेशनमध्येच स्टोअर करा. अनुप्रयोगाच्या RAM मध्येच सत्रे वापरा. शक्य तितक्या तृतीय-पक्ष सेवांमध्ये सामायिकरण वापरा. अनुप्रयोगात फक्त एक प्रक्रिया असू शकते आणि स्केलिंगसाठी परवानगी देऊ नका या वस्तुस्थितीवर विश्वास ठेवा.

सत्रांबाबत, डेटा केवळ तृतीय-पक्ष सेवा (मेमकॅशेड, रेडिस) द्वारे नियंत्रित केलेल्या कॅशेमध्ये संग्रहित करा, त्यामुळे तुमच्याकडे 20 ऍप्लिकेशन प्रक्रिया चालू असल्या तरीही, त्यापैकी कोणतीही, कॅशेमध्ये प्रवेश केल्यावर, क्लायंटसह कार्य करणे सुरू ठेवण्यास सक्षम असेल. त्याच स्थितीत ज्यामध्ये वापरकर्ता दुसर्‍या प्रक्रियेत अनुप्रयोगासह कार्य करत होता. या दृष्टिकोनासह, हे दिसून येते की आपण तृतीय-पक्ष सेवांच्या कितीही प्रती वापरल्या तरीही, सर्वकाही सामान्यपणे कार्य करेल आणि डेटामध्ये प्रवेश करण्यात समस्या न येता.

7. पोर्ट बंधनकारक

तृतीय-पक्ष सेवांसह कसे कार्य करावे हे केवळ वेब सर्व्हरला माहित असले पाहिजे. किंवा अजून चांगले, तृतीय-पक्ष सेवा थेट वेब सर्व्हरमध्ये स्थापित करा. उदाहरणार्थ, Apache मध्ये PHP मॉड्यूल म्हणून.
तुमच्या सर्व सेवा काही पत्त्यावर आणि पोर्टवर (localgost:5432, localhost:3000, nginx:80, php-fpm:9000) द्वारे एकमेकांना प्रवेश करण्यायोग्य असणे आवश्यक आहे, म्हणजेच nginx वरून मी php-fpm आणि ते दोन्हीमध्ये प्रवेश करू शकतो. postgres, आणि php-fpm पासून postgres आणि nginx पर्यंत आणि प्रत्यक्षात प्रत्येक सेवेतून मी दुसऱ्या सेवेत प्रवेश करू शकतो. अशा प्रकारे, सेवेची व्यवहार्यता दुसर्‍या सेवेच्या व्यवहार्यतेशी जोडलेली नाही.

8. समांतरता

एका प्रक्रियेसह कार्य करा, अन्यथा अनेक प्रक्रिया एकमेकांशी मिळू शकणार नाहीत!

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

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

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

प्रक्रिया आणि डेटासह कार्य करण्यासाठी रांग वापरू नका. एक प्रक्रिया मारल्याने संपूर्ण अर्जावर परिणाम झाला पाहिजे. एक सेवा कमी झाली तर सर्व काही कमी होते.

प्रत्येक प्रक्रिया आणि सेवा कधीही बंद केली जाऊ शकते आणि याचा इतर सेवांवर परिणाम होऊ नये (अर्थातच, याचा अर्थ असा नाही की सेवा दुसर्‍या सेवेसाठी अनुपलब्ध असेल, परंतु यानंतर दुसरी सेवा बंद होणार नाही). सर्व प्रक्रिया कृपापूर्वक संपुष्टात आल्या पाहिजेत, जेणेकरुन ते संपुष्टात आणल्यावर, कोणताही डेटा खराब होणार नाही आणि पुढील वेळी जेव्हा तुम्ही ती चालू कराल तेव्हा सिस्टम योग्यरित्या कार्य करेल. म्हणजेच, आणीबाणीच्या समाप्तीच्या परिस्थितीतही, डेटाचे नुकसान होऊ नये (व्यवहार यंत्रणा येथे योग्य आहे, डेटाबेसमधील क्वेरी केवळ गटांमध्ये कार्य करतात आणि गटातील किमान एक क्वेरी अयशस्वी झाल्यास किंवा कार्यान्वित झाल्यास त्रुटी, नंतर गटातील इतर कोणतीही क्वेरी शेवटी अपयशी ठरत नाही).

10. ऍप्लिकेशन डेव्हलपमेंट/ऑपरेशन पॅरिटी

अनुप्रयोगाचे उत्पादन, स्टेजिंग आणि स्थानिक आवृत्ती भिन्न असणे आवश्यक आहे. उत्पादनामध्ये आम्ही Yii Lite फ्रेमवर्क वापरतो, आणि स्थानिक पातळीवर Yii, जेणेकरून ते उत्पादनात जलद कार्य करते!

प्रत्यक्षात, कोडसह सर्व उपयोजन आणि कार्य जवळजवळ समान वातावरणात असावे (आम्ही भौतिक हार्डवेअरबद्दल बोलत नाही). तसेच, कोणत्याही विकास कर्मचार्‍याने आवश्यक असल्यास कोड उत्पादनासाठी उपयोजित करण्यास सक्षम असावे, आणि काही विशेष प्रशिक्षित डेव्हॉप्स विभाग नाही, जे केवळ विशेष सामर्थ्यामुळे अनुप्रयोग उत्पादनात वाढवू शकतात.

डॉकर देखील यामध्ये आम्हाला मदत करतो. मागील सर्व मुद्द्यांचे निरीक्षण केल्यास, डॉकर वापरल्याने उत्पादन आणि स्थानिक मशीनवर वातावरण तैनात करण्याची प्रक्रिया एक किंवा दोन कमांड प्रविष्ट करण्यासाठी आणली जाईल.

11. नोंदी

आम्ही फायली आणि डेटाबेसवर लॉग लिहितो! आम्ही लॉगमधून फाइल्स आणि डेटाबेस साफ करत नाही. चला फक्त 9000 पेटा बाइट्स असलेली हार्ड ड्राइव्ह खरेदी करूया आणि ते ठीक आहे.

सर्व नोंदी इव्हेंटचा प्रवाह मानल्या पाहिजेत. अनुप्रयोग स्वतः लॉग प्रक्रिया करण्यात गुंतलेला नसावा. लॉग एकतर stdout वर आउटपुट केले जावे किंवा udp सारख्या प्रोटोकॉलद्वारे पाठवले जावे, जेणेकरून लॉगसह कार्य केल्याने अनुप्रयोगासाठी कोणतीही समस्या निर्माण होणार नाही. ग्रेलॉग यासाठी चांगले आहे. udp द्वारे सर्व लॉग प्राप्त करणारा ग्रेलॉग (या प्रोटोकॉलला पॅकेटच्या यशस्वी रिसेप्शनबद्दल प्रतिसादाची प्रतीक्षा करण्याची आवश्यकता नाही) अनुप्रयोगामध्ये कोणत्याही प्रकारे व्यत्यय आणत नाही आणि केवळ स्ट्रक्चरिंग आणि प्रोसेसिंग लॉगशी संबंधित आहे. अशा पद्धतींसह कार्य करण्यासाठी अनुप्रयोग तर्क बदलत नाही.

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

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

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

PHP, Laravel, Laradock, Docker-Compose मधील उदाहरण अंमलबजावणी

PS सर्व उदाहरणे MacOS वर तयार केली गेली. त्यापैकी बहुतेक लिनक्ससाठी देखील योग्य आहेत. विंडोज वापरकर्त्यांनो, मला माफ करा, परंतु मी बर्याच काळापासून विंडोजवर काम केले नाही.

चला अशा परिस्थितीची कल्पना करूया जिथे आमच्या PC वर PHP ची कोणतीही आवृत्ती स्थापित केलेली नाही आणि काहीही नाही.
डॉकर आणि डॉकर-कंपोजच्या नवीनतम आवृत्त्या स्थापित करा. (हे इंटरनेटवर आढळू शकते)

docker -v && 
docker-compose -v

1. आम्ही ठेवले लॅराडॉक

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

लाराडॉकबद्दल, मी म्हणेन की ही एक अतिशय छान गोष्ट आहे, ज्यामध्ये बरेच कंटेनर आणि सहायक गोष्टी आहेत. परंतु मी लॅराडॉक वापरण्याची शिफारस करणार नाही कारण उत्पादनात बदल न करता त्याच्या अनावश्यकतेमुळे. लॅराडॉकमधील उदाहरणांवर आधारित आपले स्वतःचे कंटेनर तयार करणे चांगले आहे, हे अधिक ऑप्टिमाइझ केले जाईल, कारण कोणालाही एकाच वेळी तेथे असलेल्या प्रत्येक गोष्टीची आवश्यकता नसते.

2. आमचा अनुप्रयोग चालविण्यासाठी Laradock कॉन्फिगर करा.

cd laradock && 
cp env-example .env

२.१. काही एडिटरमध्ये habr डिरेक्टरी (मूळ फोल्डर ज्यामध्ये laradock क्लोन केलेले आहे) उघडा. (माझ्या PHPStorm प्रकरणात)

या टप्प्यावर आम्ही प्रकल्पाला फक्त एक नाव देतो.

२.२. कार्यक्षेत्र प्रतिमा लाँच करा. (तुमच्या बाबतीत, प्रतिमा तयार होण्यास थोडा वेळ लागेल)
वर्कस्पेस ही डेव्हलपरच्या वतीने फ्रेमवर्कसह काम करण्यासाठी खास तयार केलेली प्रतिमा आहे.

आम्ही वापरून कंटेनर आत जातो

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

२.३. Laravel स्थापित करत आहे

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

२.४. इन्स्टॉलेशननंतर, आम्ही प्रोजेक्टसह डिरेक्टरी तयार केली आहे की नाही ते तपासतो आणि कंपोझ मारतो.

ls
exit
docker-compose down

२.५. चला PHPStorm वर परत जाऊ आणि .env फाईलमध्ये आमच्या laravel ऍप्लिकेशनसाठी योग्य मार्ग सेट करू.

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

सर्वकाही व्यवस्थित आहे का ते तपासूया.

सोयीसाठी, मी गिटसाठी काही व्हिज्युअल इंटरफेस वापरण्याची शिफारस करतो, माझ्या बाबतीत ते आहे गिटक्रॅकेन. (येथे रेफरल लिंक आहे)

4. चला लॉन्च करूया!

सुरू करण्यापूर्वी, पोर्ट 80 आणि 443 वर काहीही लटकत नाही याची खात्री करा.

docker-compose up -d nginx php-fpm

अशा प्रकारे, आमच्या प्रकल्पात 3 स्वतंत्र सेवा आहेत:

• nginx - वेब सर्व्हर
• php-fpm - वेब सर्व्हरकडून विनंत्या प्राप्त करण्यासाठी php
• कार्यक्षेत्र - विकसकांसाठी php

या क्षणी, आम्ही असे साध्य केले आहे की आम्ही एक अनुप्रयोग तयार केला आहे जो 4 पैकी 12 गुण पूर्ण करतो, म्हणजे:

1. कोडबेस — सर्व कोड एका रेपॉजिटरीमध्ये आहे (लहान टीप: लारेव्हल प्रोजेक्टमध्ये डॉकर जोडणे योग्य असू शकते, परंतु हे महत्त्वाचे नाही).

2. अवलंबित्व — आमचे सर्व अवलंबित्व स्पष्टपणे application/composer.json मध्ये आणि प्रत्येक कंटेनरच्या प्रत्येक डॉकरफाइलमध्ये लिहिलेले आहे.

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

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

10. प्रशासन कार्ये — 12 फॅक्टर ऍप्लिकेशनच्या निर्मात्यांना आवडेल त्याप्रमाणे सर्व प्रशासकीय कार्ये कारागीर टूलच्या सहाय्याने laravel द्वारे सोडवली जातात.

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

 
docker-compose exec workspace bash
php artisan list

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

11. कॉन्फिग्युरासी आणि 12. तयार करा, सोडा, चालवा

मला हा भाग ब्लू-ग्रीन डिप्लॉयमेंटला समर्पित करायचा होता, परंतु या लेखासाठी तो खूप विस्तृत असल्याचे दिसून आले. मी याबद्दल स्वतंत्र लेख लिहीन.

थोडक्यात, ही संकल्पना CI/CD प्रणालींवर आधारित आहे जेनकिन्स и Gitlab CI. दोन्हीमध्ये, तुम्ही विशिष्ट वातावरणाशी संबंधित पर्यावरणीय चल सेट करू शकता. त्यानुसार, या परिस्थितीत, बिंदू c पूर्ण होईल कॉन्फिगरेशन.

आणि मुद्दा तयार करा, सोडा, चालवा नावासह अंगभूत फंक्शन्सद्वारे निराकरण केले जाते पाइपलाइन.

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

अर्ज कोड येथे आहे जिथूब.
या भांडाराचे क्लोनिंग करताना सबमॉड्यूल सुरू करण्यास विसरू नका.

PS: या सर्व पद्धती इतर कोणत्याही उपयुक्तता आणि प्रोग्रामिंग भाषांमध्ये वापरल्या जाऊ शकतात. मुख्य गोष्ट अशी आहे की सार भिन्न नाही.

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