एप्लिकेसन विकास र निलो-हरियो डिप्लोइमेन्ट, php र डकरमा उदाहरणहरू सहित ट्वेलभ-फ्याक्टर एप पद्धतिमा आधारित

पहिलो, एक सानो सिद्धान्त। के भयो बाह्र-फ्याक्टर एप?

सरल शब्दहरूमा, यो कागजात SaaS अनुप्रयोगहरूको विकासलाई सरल बनाउनको लागि डिजाइन गरिएको हो, विकासकर्ताहरू र DevOps इन्जिनियरहरूलाई आधुनिक अनुप्रयोगहरूको विकासमा प्रायः सामना गर्ने समस्याहरू र अभ्यासहरूको बारेमा जानकारी गराएर।

कागजात Heroku प्लेटफर्म को विकासकर्ता द्वारा बनाईएको थियो।

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

यस पद्धतिमा आधारित कारकहरूको बारेमा छोटकरीमा:

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

तपाईंले निम्न स्रोतहरूबाट १२ कारकहरूको बारेमा थप जानकारी प्राप्त गर्न सक्नुहुन्छ:

• आधिकारिक स्रोत - एक पढ्नै पर्छ
• habr मा लेख। बाह्र-फ्याक्टर एप - आधिकारिक अनुवाद
• habr मा लेख। 7 कारक एपमा 12 हराएको कारकहरू - तिनीहरूलाई सुधार गर्ने उद्देश्यका साथ 12 कारकहरूमा नयाँ नजर।

निलो-हरियो तैनाती के हो?

नीलो-हरियो डिप्लोयमेन्ट एउटा एप डेलिभर गर्ने तरिका हो उत्पादन यस्तो तरिकाले कि अन्तिम ग्राहकले आफ्नो पक्षमा कुनै परिवर्तन देख्दैन। अर्को शब्दमा, शून्यको साथ एप्लिकेसन डिप्लोइ गर्दै डाउनटाइम.

क्लासिक BG डिप्लोय योजना तलको छविमा देखाइएको जस्तो देखिन्छ।

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

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

नराम्रो र राम्रो सल्लाह

त्याग: तलका उदाहरणहरूले मैले प्रयोग गर्ने उपयोगिता/विधिहरू देखाउँछ, तपाईंले समान प्रकार्यहरूसँग कुनै पनि विकल्पहरू प्रयोग गर्न सक्नुहुन्छ।

धेरै जसो उदाहरणहरू कुनै न कुनै रूपमा वेब विकास (यो आश्चर्यचकित हो), PHP र डकरको साथमा काटिनेछ।

तलका अनुच्छेदहरूले विशिष्ट उदाहरणहरू प्रयोग गरेर कारकहरूको प्रयोगको सरल व्यावहारिक विवरण प्रदान गर्दछ; यदि तपाईं यस विषयमा थप सिद्धान्त प्राप्त गर्न चाहनुहुन्छ भने, मूल स्रोतमा माथिको लिङ्कहरू पछ्याउनुहोस्।

1. कोडबेस

सर्भरमा फाइलहरू अपलोड गर्न FTP र FileZilla प्रयोग गर्नुहोस्, उत्पादन सर्भरमा बाहेक अन्य कतै कोड भण्डारण नगर्नुहोस्।

परियोजनामा ​​सधैं एकल कोड आधार हुनुपर्छ, त्यो हो, सबै कोड एकबाट आउँछ Git भण्डार। सर्भरहरू (उत्पादन, स्टेजिङ, test1, test2...) एक साझा भण्डारको शाखाबाट कोड प्रयोग गर्दछ। यसरी हामी कोड स्थिरता प्राप्त गर्छौं।

2. निर्भरता

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

एक परियोजनामा ​​सधैं निर्भरताहरूको स्पष्ट रूपमा बुझ्न योग्य सूची हुनुपर्छ (निर्भरताहरू द्वारा म पनि वातावरणलाई बुझाउँछु)। सबै निर्भरताहरू स्पष्ट रूपमा परिभाषित र अलग हुनुपर्छ।
उदाहरणको रूपमा लिऔं संगीतकार и डकर.

संगीतकार - एक प्याकेज प्रबन्धक जसले तपाईंलाई PHP मा पुस्तकालयहरू स्थापना गर्न अनुमति दिन्छ। कम्पोजरले तपाईंलाई कडा वा ढिलो रूपमा संस्करणहरू निर्दिष्ट गर्न र तिनीहरूलाई स्पष्ट रूपमा परिभाषित गर्न अनुमति दिन्छ। त्यहाँ सर्भरमा 20 विभिन्न परियोजनाहरू हुन सक्छन् र प्रत्येकसँग प्याकेज र पुस्तकालयहरूको व्यक्तिगत सूची अर्कोबाट स्वतन्त्र हुनेछ।

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

3. कन्फिगरेसन

कन्फिगहरू सिधै कोडमा स्थिरहरूको रूपमा भण्डार गर्नुहोस्। परीक्षण सर्भरको लागि अलग स्थिरांक, उत्पादनको लागि अलग। परियोजनाको व्यवसायिक तर्कमा सीधा वातावरणमा निर्भर गर्दै अनुप्रयोगको सञ्चालनलाई यदि अन्य निर्माणहरू प्रयोग गरी बाँध्नुहोस्।

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

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

4. तेस्रो पक्ष सेवाहरू

वातावरणमा कडाईका साथ बाँध्नुहोस्, निश्चित वातावरणमा समान सेवाहरूको लागि विभिन्न जडानहरू प्रयोग गर्नुहोस्।

वास्तवमा, यो बिन्दु कन्फिगरेसनको बारेमा बिन्दुसँग दृढतापूर्वक ओभरल्याप हुन्छ, किनकि यो बिन्दु बिना, सामान्य कन्फिगरेसन डाटा बनाउन सकिँदैन र, सामान्यमा, कन्फिगर गर्ने क्षमता केही पनि घट्नेछ।

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

5. निर्माण, जारी, कार्यान्वयन

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

परिनियोजनका सबै चरणहरू एकअर्काबाट अलग हुनुपर्छ।

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

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

6. प्रक्रियाहरू

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

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

7. पोर्ट बाध्यकारी

केवल वेब सर्भरले तेस्रो-पक्ष सेवाहरूसँग कसरी काम गर्ने भनेर जान्नुपर्दछ। वा अझ राम्रो, वेब सर्भर भित्र सीधा तेस्रो-पक्ष सेवाहरू स्थापना गर्नुहोस्। उदाहरण को लागी, Apache मा PHP मोड्युल को रूप मा।
तपाईंका सबै सेवाहरू केही ठेगाना र पोर्ट (localgost:5432, localhost:3000, nginx:80, php-fpm:9000) को पहुँच मार्फत एक अर्कामा पहुँचयोग्य हुनुपर्दछ, अर्थात्, nginx बाट म php-fpm र to दुवै पहुँच गर्न सक्छु। postgres, र php-fpm देखि postgres र nginx सम्म र वास्तवमा प्रत्येक सेवाबाट म अर्को सेवा पहुँच गर्न सक्छु। यसरी, सेवाको व्यवहार्यता अर्को सेवाको व्यवहार्यतासँग जोडिएको छैन।

8. समानान्तरता

एक प्रक्रिया संग काम गर्नुहोस्, अन्यथा धेरै प्रक्रियाहरु एक अर्का संग प्राप्त गर्न सक्षम हुनेछैन!

स्केलिंगको लागि कोठा छोड्नुहोस्। डकर झुण्ड यसको लागि उत्कृष्ट छ।
डकर स्वार्म एउटै मेसिनमा विभिन्न मेसिनहरू र कन्टेनरहरूको गुच्छा दुवै बीच कन्टेनरहरूको क्लस्टरहरू सिर्जना र व्यवस्थापन गर्ने उपकरण हो।

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

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

प्रक्रिया र डेटा संग काम गर्न लाम प्रयोग नगर्नुहोस्। एउटा प्रक्रियालाई मार्दा सम्पूर्ण अनुप्रयोगलाई असर गर्नुपर्छ। एउटै सेवा घट्यो भने सबै खत्तम हुन्छ ।

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

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

अनुप्रयोगको उत्पादन, स्टेजिङ र स्थानीय संस्करण फरक हुनुपर्छ। उत्पादनमा हामी Yii Lite फ्रेमवर्क प्रयोग गर्छौं, र स्थानीय रूपमा Yii, ताकि यसले उत्पादनमा छिटो काम गर्छ!

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

डकरले हामीलाई यसमा मद्दत गर्दछ। यदि सबै अघिल्लो बिन्दुहरू अवलोकन गरिएमा, डकरको प्रयोगले वातावरणलाई उत्पादन र स्थानीय मेसिनमा एक वा दुई आदेशहरू प्रविष्ट गर्न प्रयोग गर्ने प्रक्रिया ल्याउनेछ।

11. लगहरू

हामी फाइलहरू र डाटाबेसहरूमा लगहरू लेख्छौं! हामी लगहरूबाट फाइलहरू र डाटाबेसहरू सफा गर्दैनौं। 9000 पेटा बाइट्स भएको हार्ड ड्राइभ मात्र किन्नुहोस् र त्यो ठीक छ।

सबै लगहरू घटनाहरूको स्ट्रिमको रूपमा विचार गर्नुपर्छ। आवेदन आफैं प्रशोधन लग मा संलग्न हुनु हुँदैन। लगहरू या त stdout मा आउटपुट हुनुपर्छ वा udp जस्ता प्रोटोकल मार्फत पठाइन्छ, ताकि लगहरूसँग काम गर्दा अनुप्रयोगको लागि कुनै समस्याहरू सिर्जना गर्दैन। graylog यसको लागि राम्रो छ। udp मार्फत सबै लगहरू प्राप्त गर्ने ग्रेलग (यस प्रोटोकलले प्याकेटको सफल रिसेप्शनको बारेमा प्रतिक्रियाको लागि पर्खनु आवश्यक पर्दैन) कुनै पनि हिसाबले अनुप्रयोगमा हस्तक्षेप गर्दैन र केवल संरचना र प्रशोधन लगहरूसँग मात्र व्यवहार गर्दछ। अनुप्रयोग तर्क यस्तो दृष्टिकोण संग काम गर्न परिवर्तन गर्दैन।

12. प्रशासन कार्यहरू

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

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

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

PS सबै उदाहरणहरू MacOS मा बनाइएका थिए। ती मध्ये धेरै लिनक्सका लागि पनि उपयुक्त छन्। विन्डोज प्रयोगकर्ताहरू, मलाई माफ गर्नुहोस्, तर मैले लामो समयदेखि विन्डोजसँग काम गरेको छैन।

एउटा अवस्थाको कल्पना गरौं जहाँ हामीसँग हाम्रो पीसीमा PHP को कुनै संस्करण स्थापित छैन र केहि पनि छैन।
डकर र डकर-कम्पोजको नवीनतम संस्करणहरू स्थापना गर्नुहोस्। (यो इन्टरनेटमा फेला पार्न सकिन्छ)

docker -v && 
docker-compose -v

1. राख्नुहोस् लाराडोक

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

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

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

सबै कुरा ठीक छ कि छैन जाँच गरौं।

सुविधाको लागि, म Git को लागी केहि भिजुअल इन्टरफेस प्रयोग गर्न सिफारिस गर्दछु, मेरो मामला मा यो हो GitKraken। (यहाँ रेफरल लिङ्क छ)

4. सुरु गरौं!

सुरु गर्नु अघि, सुनिश्चित गर्नुहोस् कि पोर्ट 80 र 443 मा केहि पनि ह्याङ्ग छैन।

docker-compose up -d nginx php-fpm

तसर्थ, हाम्रो परियोजनाले 3 अलग सेवाहरू समावेश गर्दछ:

• nginx - वेब सर्भर
• php-fpm - वेब सर्भरबाट अनुरोधहरू प्राप्त गर्नका लागि php
• कार्यक्षेत्र - विकासकर्ताहरूको लागि php

हाल, हामीले प्राप्त गरेका छौं कि हामीले एउटा अनुप्रयोग सिर्जना गरेका छौं जसले 4 मध्ये 12 बिन्दुहरू पूरा गर्दछ, अर्थात्:

1. कोडबेस - सबै कोड एक भण्डारमा छ (सानो नोट: यो laravel परियोजना भित्र डकर थप्न सही हुन सक्छ, तर यो महत्त्वपूर्ण छैन)।

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 पूरा हुनेछ कन्फिगरेसनहरू.

र बिन्दु बारे निर्माण, जारी, चलाउनुहोस् नाम संग निर्मित प्रकार्यहरु द्वारा हल गरिएको छ पाइपलाइन.

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

आवेदन कोड मा छ Github.
यो भण्डार क्लोन गर्दा सबमोड्युल प्रारम्भ गर्न नबिर्सनुहोस्।

PS: यी सबै दृष्टिकोणहरू कुनै पनि अन्य उपयोगिताहरू र प्रोग्रामिङ भाषाहरूसँग प्रयोग गर्न सकिन्छ। मुख्य कुरा सार फरक छैन भन्ने छ।

स्रोत: www.habr.com