यह पोस्ट उन श्रमिकों के अनुरोध पर लिखी गई है, जो समय-समय पर "डॉक्यूमेंट में इल्यूमिनेट / सिम्फनी / मायऑन Psr7 एप्लिकेशन को कैसे चलाते हैं" के बारे में पूछते हैं। मुझे ऐसा नहीं लगता कि पहले लिखी गई पोस्ट का लिंक दिया गया है, क्योंकि समस्या को हल करने के बारे में मेरे विचार काफी बदल गए हैं।

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

मैं लारवेल को एक एप्लिकेशन के रूप में भी उपयोग करूंगा, क्योंकि यह मेरे लिए सबसे अधिक परिचित है और काफी व्यापक है। अन्य PSR-7 आधारित फ्रेम / घटकों के लिए अनुकूलन संभव है, लेकिन यह कहानी उस बारे में नहीं है।

हैंडलिंग में त्रुटि

मैं पिछले लेख के संदर्भ में "सर्वोत्तम प्रथाओं" नहीं होने के साथ शुरू करना चाहता हूं:

• रिपॉजिटरी में फाइलों की संरचना को बदलने की आवश्यकता
• FPM का उपयोग करना। यदि हम अपने अनुप्रयोगों से प्रदर्शन चाहते हैं, तो शायद प्रौद्योगिकी चयन के स्तर पर भी सबसे अच्छा समाधानों में से एक इसे तेजी से कुछ के पक्ष में छोड़ना होगा और इस तथ्य को "अनुकूलित" किया जाएगा कि स्मृति लीक हो सकती है। ^{Lachezis द्वारा} रोडरनर यहाँ के रूप में पहले कभी नहीं है
• स्रोत और संपत्ति के साथ एक अलग छवि। इस तथ्य के बावजूद कि इस दृष्टिकोण का उपयोग करते हुए, हम आने वाले अनुरोधों के एक अधिक जटिल मार्ग के निर्माण के लिए उसी छवि का पुन: उपयोग कर सकते हैं (स्थैतिक उत्पादन के लिए सामने की तरफ nginx; गतिशीलता के लिए अनुरोध एक अन्य कंटेनर द्वारा सेवा की जाती है जिसमें समान स्रोतों से वॉल्यूम फेंका जाता है - के लिए बेहतर स्केलिंग) - यह योजना उत्पाद संचालन में बल्कि जटिल साबित हुई है। और क्या अधिक है, आरआर खुद ही पूरी तरह से स्टैटिक्स का प्रतिपादन करता है, और यदि बहुत सी स्टैटिक्स हैं (या संसाधन उपयोगकर्ता-जनित सामग्री को लोड और प्रदर्शित कर सकते हैं) - हम इसे सीडीएन (एस 3 + क्लाउडफ्रॉस्ट + क्लाउडफेयर बंडल काम करता है) के लिए बाहर ले जाते हैं और सिद्धांत रूप में इस समस्या के बारे में भूल जाते हैं।
• जटिल CI। यह एक वास्तविक समस्या बन गई जब विधानसभा और स्वचालित परीक्षण के चरणों में सक्रिय "निर्माण मांस" की अवधि शुरू हुई। एक दोस्त जो पहले इस सीआई का समर्थन नहीं करता था, कुछ भी तोड़ने के डर के बिना इसमें परिवर्तन करना बहुत मुश्किल हो जाता है।

अब, यह जानते हुए कि किन समस्याओं को ठीक करने की आवश्यकता है और यह कैसे करना है इसकी समझ के साथ, मैं उनके उन्मूलन के साथ आगे बढ़ने का प्रस्ताव करता हूं। "डेवलपर टूल" का सेट नहीं बदला है - यह वही docker-ce , docker-compose और शक्तिशाली Makefile ।

नतीजतन, हम प्राप्त करते हैं:

• अतिरिक्त वॉल्यूम को माउंट करने की आवश्यकता के बिना एक आवेदन के साथ एक स्टैंडअलोन कंटेनर
• गिट-हुक का उपयोग करने का एक उदाहरण - हम आवश्यक निर्भरता को git pull बाद स्वचालित रूप से डाल देंगे और कोड को धकेलने पर रोक लगाएंगे यदि परीक्षण विफल होते हैं (हुक को गिट के नीचे संग्रहीत किया जाएगा, स्वाभाविक रूप से)
• रोडरनर HTTP (एस) अनुरोधों को संभाल लेगा
• डेवलपर्स अभी भी डीबगिंग के लिए dd(..) और dump(..) निष्पादित कर पाएंगे, जबकि उनके ब्राउज़र में कुछ भी क्रैश नहीं होगा
• टेस्ट सीधे PHPStorm IDE से चलाए जा सकते हैं, जबकि उन्हें एप्लिकेशन के साथ कन्टेनर में चलाया जाएगा
• नया एप्लिकेशन संस्करण टैग प्रकाशित करते समय CI हमारे लिए छवियां एकत्र करेगा
• चलिए CHANGELOG.md और ENVIRONMENT.md फ़ाइलों को बनाए रखने का सख्त नियम लेते हैं

एक नए दृष्टिकोण का दृश्य परिचय

एक अच्छे प्रदर्शन के लिए, मैं पूरी प्रक्रिया को कई चरणों में तोड़ दूंगा, जिसमें बदलाव अलग एमआर के रूप में किए जाएंगे (विलय के बाद, सभी ब्रंच जगह पर रहेंगे, "चरण" के शीर्षक में एमआर के लिंक;) प्रारंभिक बिंदु composer create-project laravel/laravel का उपयोग करके बनाए गए एप्लिकेशन का लारवेल कंकाल है:

 $ docker run \ --rm -i \ -v "$(pwd):/src" \ -u "$(id -u):$(id -g)" \ composer composer create-project --prefer-dist laravel/laravel \ /src/laravel-in-docker-with-rr "5.8.*" 

चरण 1 - डॉकिंग + आरआर

पहला कदम कंटेनर में चलाने के लिए एप्लिकेशन को सिखाना है। ऐसा करने के लिए, हमें " docker-compose.yml उठाने और लिंक करने के तरीके" और एक या दो आदेशों के लिए पहले से ही सरलीकृत प्रक्रिया को कम करने के लिए एक Dockerfile , Dockerfile docker-compose.yml आवश्यकता है।

Dockerfile

मूल छवि जो मैं php:XXX-alpine उपयोग करता हूं php:XXX-alpine सबसे आसान है और इसमें वह है जो आपको चलाने की आवश्यकता है। इसके अलावा, दुभाषिया के सभी बाद के अपडेट केवल इस पंक्ति में मूल्य बदलने के लिए कम हो गए हैं (PHP को अपडेट करना अब पहले से आसान है)।

संगीतकार और रोडरनर बाइनरी फ़ाइल को मल्टीस्टेज और COPY --from=... का उपयोग करके कंटेनर तक पहुंचाया जाता है - - यह बहुत सुविधाजनक है, और संस्करणों से जुड़े सभी मान "बिखरे हुए" नहीं हैं, लेकिन फ़ाइल की शुरुआत में हैं। यह तेजी से काम करता है, और curl / git clone पर निर्भरता के बिना / make build । 512k / roadrunner चित्र मेरे द्वारा समर्थित हैं , यदि आप चाहें - तो आप स्वयं बाइनरी फ़ाइल को इकट्ठा कर सकते हैं।

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

Dockerfile मैं आने वाले HTTPS अनुरोधों के लिए इसका उपयोग करने के लिए एक स्व-हस्ताक्षरित SSL प्रमाणपत्र बनाना शुरू करता हूं। स्वाभाविक रूप से - कुछ भी "सामान्य" प्रमाण पत्र के उपयोग को रोकता नहीं है।

मैं इसके बारे में भी कहना चाहूंगा:

 COPY ./composer.* /app/ RUN set -xe \ && composer install --no-interaction --no-ansi --no-suggest --prefer-dist \ --no-autoloader --no-scripts \ && composer install --no-dev --no-interaction --no-ansi --no-suggest \ --prefer-dist --no-autoloader --no-scripts 

यहाँ अर्थ निम्नलिखित है - composer.lock और composer.json फ़ाइलों को एक अलग परत में छवि में वितरित किया जाता है, जिसके बाद उनमें वर्णित सभी निर्भरताएं स्थापित की जाती हैं। ऐसा इसलिए किया जाता है ताकि बाद में --cache-from का उपयोग करके छवि के निर्माण के दौरान, यदि स्थापित निर्भरता की संरचना और संस्करण नहीं बदले हैं, तो composer install निष्पादित नहीं किया जाता है, इस परत को कैश से लेते हैं, जिससे बिल्ड टाइम और ट्रैफ़िक की बचत होती है (विचार के लिए धन्यवाद) जेटजीओ )।

composer install को दो बार निष्पादित किया जाता है - (दूसरी बार- --no-dev ) देव निर्भरता के कैश को "वार्म अप" करने के लिए, ताकि जब हम परीक्षणों को चलाने के लिए CI पर सभी निर्भरताएं डालते हैं, तो उन्हें संगीतकार कैश से डाला जाता है, जो पहले से ही छवि में है, और नहीं दूर की आकाशगंगाओं से फैला है।

अंतिम RUN निर्देश के साथ, हम निर्मित लॉग में इतिहास के लिए स्थापित सॉफ़्टवेयर और PHP मॉड्यूल की संरचना के संस्करणों को प्रदर्शित करते हैं और यह सुनिश्चित करने के लिए कि "यह कम से कम मौजूद है और किसी तरह शुरू होता है।"

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

RoadRunner

रोडरनर को लारवेल एप्लिकेशन के साथ एकीकृत करने के लिए, एक पैकेज लिखा गया था, जो शेल में कमांड के एक जोड़े के लिए सभी एकीकरण को कम करता है ( docker-compose run app sh ):

 $ composer require avto-dev/roadrunner-laravel "^2.0" $ ./artisan vendor:publish --provider='AvtoDev\RoadRunnerLaravel\ServiceProvider' --tag=rr-config 

APP_FORCE_HTTPS=true ./docker/docker-compose.env फ़ाइल में जोड़ें, और .rr*.yaml में कंटेनर में SSL प्रमाणपत्र के लिए पथ निर्दिष्ट .rr*.yaml ।

dump(..) और dd(..) का उपयोग करने में सक्षम होने के लिए और सब कुछ काम करेगा, एक और पैकेज है - avto-dev/stacked-dumper-laravel । इन सभी सहायकों को क्रमशः \dev\dd(..) और \dev\dump(..) dp \dev\dd(..) लिए एक pefix जोड़ना आवश्यक है। इसके बिना, आप फ़ॉर्म की एक त्रुटि देखेंगे:

 worker error: invalid data found in the buffer (possible echo) 

सभी जोड़तोड़ के बाद, do docker-compose up -d और voila करें:

PostgeSQL डेटाबेस, रेडिस, और रोडरनर कार्यकर्ता सफलतापूर्वक कंटेनरों में चले गए।

चरण 2 - मेकफाइल और टेस्ट

जैसा कि मैंने पहले लिखा था, एक मेकफाइल एक बहुत ही कम कीमत की वस्तु है। आश्रित लक्ष्य, आपकी स्वयं की संश्लिष्ट चीनी, 99% संभावना है कि वह पहले से ही लिनक्स / मैक डेवलपमेंट मशीन पर खड़ा है, स्वतः पूर्ण "बॉक्स से बाहर" - इसके फायदे की एक छोटी सूची।

इसे हमारी परियोजना में जोड़ना और मापदंडों के बिना make , हम देख सकते हैं:

यूनिट टेस्ट चलाने के लिए, हम या तो एक make test कर सकते हैं, या एप्लिकेशन ( make shell ) के साथ कंटेनर के अंदर एक शेल प्राप्त कर सकते हैं, composer phpunit चला composer phpunit । एक कवरेज रिपोर्ट प्राप्त करने के लिए, बस make test-cover बनाते make test-cover , और परीक्षण चलाने से पहले, अपनी निर्भरता वाले xdebug को कंटेनर में वितरित किया जाएगा और परीक्षण लॉन्च किए जाएंगे (चूंकि यह प्रक्रिया अक्सर नहीं की जाती है और CI द्वारा नहीं - यह समाधान सभी के साथ एक अलग छवि रखने से बेहतर लगता है देव-लोशन)।

गिट हुक

हमारे मामले में हुक 2 महत्वपूर्ण भूमिकाएँ पूरी करेंगे - कोड को उस मूल में धकेलने की अनुमति न देना जिसके परीक्षण सफल नहीं हैं; और स्वचालित रूप से सभी आवश्यक निर्भरताएं डाल देता है, यदि आपकी मशीन पर परिवर्तनों को खींचता है, तो यह पता चलता है कि composer.lock बदल गया है। Makefile , इसके लिए एक अलग लक्ष्य है:

 cwd = $(shell pwd) git-hooks: ## Install (reinstall) git hooks (required after repository cloning) -rm -f "$(cwd)/.git/hooks/pre-push" "$(cwd)/.git/hooks/pre-commit" "$(cwd)/.git/hooks/post-merge" ln -s "$(cwd)/.gitlab/git-hooks/pre-push.sh" "$(cwd)/.git/hooks/pre-push" ln -s "$(cwd)/.gitlab/git-hooks/pre-commit.sh" "$(cwd)/.git/hooks/pre-commit" ln -s "$(cwd)/.gitlab/git-hooks/post-merge.sh" "$(cwd)/.git/hooks/post-merge" 

make git-hooks से मौजूदा हुक दूर हो जाते हैं और वे अपने स्थान पर .gitlab/git-hooks निर्देशिका में रख देते हैं। उनके स्रोत को इस लिंक पर देखा जा सकता है।

PhpStorm से परीक्षण चल रहा है

इस तथ्य के बावजूद कि यह काफी सरल और सुविधाजनक है - मैंने इसे लंबे समय तक उपयोग किया ./vendor/bin/phpunit --group=foo सीधे इसके बजाय एक परीक्षण या कोड लिखते समय हॉटकी को सीधे दबाने के बजाय ./vendor/bin/phpunit --group=foo ।

File > Settings > Languages & Frameworks > PHP > CLI interpreter > [...] > [+] > From Docker, Vargant, VM, Remote । डॉकर कंपोज़ , और ऐप सेवा नाम का चयन करें।

दूसरा चरण कंटेनर से दुभाषिया का उपयोग करने के लिए फ़पुनिट को बताने के लिए है: File > Settings > Test frameworks > [+] > PHPUnit by remote interpreter और पहले बनाए File > Settings > Test frameworks > [+] > PHPUnit by remote interpreter का चयन करें। Path to script /app/vendor/autoload.php , /app/vendor/autoload.php निर्दिष्ट करें, और Path mappings प्रोजेक्ट की रूट डायरेक्टरी को /app में माउंट किए गए के रूप में निर्दिष्ट करते हैं।

और अब हम आईडीई से सीधे आवेदन के साथ छवि के अंदर दुभाषिया का उपयोग करके परीक्षण चला सकते हैं, (डिफ़ॉल्ट रूप से, लिनक्स) Ctrl + Shift + F10 दबाकर।

चरण 3 - स्वचालन

हमारे लिए जो कुछ भी करना बाकी है वह है परीक्षण चलाने और छवि को इकट्ठा करने की प्रक्रिया को स्वचालित करना। ऐसा करने के लिए, .gitlab-ci.yml को एप्लिकेशन की रूट डायरेक्टरी में .gitlab-ci.yml , इसे निम्नलिखित सामग्रियों .gitlab-ci.yml । इस कॉन्फ़िगरेशन का मुख्य विचार जितना संभव हो उतना सरल होना है, लेकिन एक ही समय में कार्यक्षमता खोना नहीं है।

छवि को प्रत्येक वचन पर, प्रत्येक ब्रंच पर इकट्ठा किया जाता है। का उपयोग करना - --cache-from फिर से प्रतिबद्ध पर एक छवि कोडांतरण बहुत तेज है। पुनर्निर्माण की आवश्यकता इस तथ्य के कारण है कि प्रत्येक ब्रंच पर हमारे पास इस ब्रंच के हिस्से के रूप में किए गए परिवर्तनों के साथ एक छवि है, और इसके परिणामस्वरूप, कुछ भी हमें "लाइव" बनाने के लिए झुंड / k8s / etc को रोल करने से रोकता है। यह सब कुछ काम करता है, और master लाइट के साथ विलय से पहले भी काम करता है।

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

"रिलीज़ की रिलीज़" के लिए - बस फॉर्म का एक टैग प्रकाशित करें vX.XX (यदि आप अभी भी सिमेंटिक संस्करण से चिपके रहते हैं - यह बहुत अच्छा होगा) - सीआई छवि को इकट्ठा करेगा, परीक्षण चलाएगा, और उन कार्यों को करेगा जो आप deploy to somewhere निर्दिष्ट करते हैं।

केवल "रिलीज़ रिलीज़" की अनुमति देने वाले व्यक्तियों को टैग प्रकाशित करने की क्षमता को सीमित करने के लिए परियोजना सेटिंग्स (यदि संभव हो तो) को मत भूलना।

CHANGELOG.md और ENVIRONMENT.md

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

निष्कर्ष

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

रिपॉजिटरी को क्लोन करने के बाद, डेवलपर्स को make git-hooks && make install && make up और उपयोगी कोड लिखना शुरू make git-hooks && make install && make up । कॉमरेड्स * ऑप्स-हूँ - वांछित टैग के साथ छवि लें और इसे उनके समूहों पर रोल करें।

स्वाभाविक रूप से - यह योजना भी सरल है, और "मुकाबला" परियोजनाओं पर मैं बहुत अधिक लपेट रहा हूं, लेकिन यदि लेख में वर्णित दृष्टिकोण किसी की मदद करता है, तो मुझे पता चलेगा कि मैंने अपना समय बर्बाद किया है।