डॉकर + लारवेल = ara

इस लेख में, मैं एक डॉकर कंटेनर में एक लारवेल एप्लिकेशन "रैपिंग" के अपने अनुभव के बारे में बात करूंगा ताकि फ्रंटएंड और बैकएंड डेवलपर्स स्थानीय रूप से इसके साथ काम कर सकें, और इसे उत्पादन पर लॉन्च करना यथासंभव सरल था। इसके अलावा, CI स्वचालित रूप से स्टैटिक कोड एनालाइज़र, phpunit परीक्षण phpunit और छवियों का निर्माण करेगा।

"और क्या, वास्तव में, जटिलता है?" - आप कह सकते हैं, और आप आंशिक रूप से सही होंगे। तथ्य यह है कि रूसी-भाषी और अंग्रेजी-भाषी समुदायों में काफी चर्चाएं इस विषय के लिए समर्पित हैं, और मैं सशर्त रूप से लगभग सभी अध्ययन किए गए धागे को निम्नलिखित श्रेणियों में विभाजित करूंगा:

• "मैं स्थानीय विकास के लिए docker का उपयोग कर रहा हूँ। मैं लार्डॉक डालता हूँ और मैं परेशानियों को नहीं जानता हूँ।" कूल, लेकिन स्वचालन और उत्पादन लॉन्च के बारे में क्या?
• "मैं fedora:latest पर आधारित एक कंटेनर (मोनोलिथ) इकट्ठा करता हूं fedora:latest (~ 230 एमबी), इसमें सभी सेवाओं (नग्नेक्स, डीबी, कैश, आदि) डालते हैं, पर्यवेक्षक के अंदर सब कुछ चलाते हैं।" इसके अलावा उत्कृष्ट, शुरू करना आसान है, लेकिन "एक कंटेनर - एक प्रक्रिया" की विचारधारा के बारे में क्या? संतुलन और प्रक्रिया प्रबंधन के बारे में क्या? छवि का आकार क्या है?
• "यहां विन्यास के टुकड़े हैं, श-लिपियों के अंश के साथ मौसम, जादू एनवी-मान जोड़ें, इसका उपयोग करें।" धन्यवाद, लेकिन कम से कम एक जीवित उदाहरण के बारे में जो मैं कांटा और पूरी तरह से खेल सकता था?

नीचे आप जो भी पढ़ते हैं वह एक व्यक्तिपरक अनुभव है जो परम सत्य होने का दिखावा नहीं करता है। यदि आपके पास अशुद्धि के संकेत या संकेत हैं - टिप्पणियों में आपका स्वागत है।

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

सैद्धांतिक हिस्सा

हम अपने काम में किन औजारों का इस्तेमाल करेंगे और हम किस पर ध्यान देंगे? सबसे पहले, हमें मेजबान पर स्थापित होने की आवश्यकता है:

• 18.06.1-ce लेखन के समय, मैंने संस्करण 18.06.1-ce उपयोग किया
• docker-compose - यह कंटेनरों को जोड़ने और आवश्यक पर्यावरण मूल्यों को संग्रहीत करने के साथ मुकाबला करता है; संस्करण 1.22.0
• make - आप आश्चर्यचकित हो सकते हैं, लेकिन यह डॉकटर के साथ काम करने के संदर्भ में पूरी तरह से फिट बैठता है

आप कमांड curl -fsSL get.docker.com | sudo sh साथ debian -समान सिस्टम पर curl -fsSL get.docker.com | sudo sh कर सकते हैं curl -fsSL get.docker.com | sudo sh , लेकिन docker-compose pip का उपयोग करके स्थापित करना बेहतर है, क्योंकि हाल के संस्करण इसके रिपॉजिटरी में रहते हैं (एक नियम के रूप apt बहुत पीछे है)।

यह निर्भरता की सूची को पूरा करता है। आप स्रोत कोड के साथ काम करने के लिए क्या उपयोग करेंगे - phpstorm , netbeans या मृत vim - यह आपके ऊपर है।

इसके बाद ( छवि से मैं इस शब्द से नहीं डरता)

• प्रश्न: मूल छवि - कौन सा चुनना बेहतर है?

  
  

• एक: एक है कि "पतली", कोई तामझाम है। alpine (~ 5 एमबी) के आधार पर , आप अपनी दिल की इच्छाओं को जो भी इकट्ठा कर सकते हैं, लेकिन सबसे अधिक संभावना है कि आपको स्रोत से सेवाओं की विधानसभा के साथ खेलना होगा। एक विकल्प के रूप में - jessie-slim (~ 30 एमबी) । या उस का उपयोग करें जो आपकी परियोजनाओं पर सबसे अधिक बार उपयोग किया जाता है।

  
  

• प्रश्न: छवि वजन महत्वपूर्ण क्यों है?

  
  

• उ: ट्रैफ़िक की मात्रा में कमी, डाउनलोड करते समय त्रुटि की संभावना में कमी (कम डेटा - कम संभावना), उपभोग किए गए स्थान में कमी। नियम "गुरुत्वाकर्षण विश्वसनीय है" (© "स्नैच") यहां बहुत अच्छी तरह से काम नहीं करता है।

  
  

• प्रश्न: लेकिन मेरे दोस्त %friend_name% कहना है कि सभी-सभी निर्भरताओं के साथ एक "अखंड" छवि सबसे अच्छा तरीका है।

  
  

• A: चलो बस गिनती करते हैं। आवेदन में 3 निर्भरताएं हैं - पीजी, रेडिस, पीएचपी। और आप परीक्षण करना चाहते थे कि यह इन निर्भरताओं के विभिन्न संस्करणों के बंडलों में कैसे व्यवहार करेगा। पीजी - संस्करण 9.6 और 10, रेडिस - 3.2 और 4.0, पीएचपी - 7.0 और 7.2। यदि प्रत्येक व्यसन एक अलग छवि है - तो आपको उनमें से 6 की आवश्यकता है, जिसे आपको एकत्र करने की भी आवश्यकता नहीं है - सब कुछ तैयार है और hub.docker.com पर hub.docker.com । यदि, वैचारिक कारणों से, सभी निर्भरताएं एक कंटेनर में "पैक" की जाती हैं, तो आपको इसे पेन के साथ फिर से इकट्ठा करना होगा ... 8 बार? अब उस स्थिति को जोड़ें जो आप अभी भी opcache साथ खेलना चाहते हैं। अपघटन के मामले में, यह केवल इस्तेमाल की गई छवियों के टैग में बदलाव है। एक मोनोलिथ चलाना और रखरखाव करना आसान है, लेकिन यह कहीं नहीं है।

  
  

• क्यू: कंटेनर में पर्यवेक्षक बुराई क्यों है?

  
  

• A: क्योंकि PID 1 । यदि आप ज़ोंबी प्रक्रियाओं के साथ समस्याओं का एक बहुतायत नहीं चाहते हैं और जहां आवश्यक हो - लचीले ढंग से "क्षमता जोड़ने" की क्षमता है - प्रति कंटेनर एक प्रक्रिया को चलाने का प्रयास करें। एक अजीब अपवाद अपने श्रमिकों और php-fpm साथ nginx , जो प्रक्रियाओं का उत्पादन करने की क्षमता रखते हैं, लेकिन इसे (इसके अलावा, उन्हें SIGTERM पर प्रतिक्रिया देने में बुरा नहीं है, काफी सही ढंग से "अपने श्रमिकों को मारना")। पर्यवेक्षक के रूप में सभी राक्षसों को लॉन्च करके, आप लगभग निश्चित रूप से समस्याओं के लिए खुद को पूरा कर रहे हैं। हालांकि, कुछ मामलों में, इसके बिना करना मुश्किल है, लेकिन ये पहले से ही अपवाद हैं।

  
  

मुख्य दृष्टिकोणों पर निर्णय लेने के बाद, अपने आवेदन पर चलते हैं। यह करने में सक्षम होना चाहिए:

• web|api - nginx के साथ स्थैतिक दे, और fpm साथ गतिशील सामग्री उत्पन्न fpm
• scheduler - मूल कार्य अनुसूचक चलाते हैं
• queue - queue से नौकरियों की प्रक्रिया

एक मूल सेट जिसे यदि आवश्यक हो तो विस्तारित किया जा सकता है। अब हम उन छवियों को आगे बढ़ाते हैं जिन्हें हमें अपने आवेदन के लिए "टेक ऑफ" के लिए इकट्ठा करना है (उनके कोड नाम कोष्ठक में दिए गए हैं):

• PHP + PHP-FPM ( ऐप ) - वह वातावरण जिसमें हमारा कोड निष्पादित किया जाएगा। चूंकि PHP और FPM के संस्करण हमारे लिए समान होंगे - हम उन्हें एक छवि में एकत्र करते हैं। इसलिए कॉन्फ़िगरेशन के साथ प्रबंधन करना आसान है, और संकुल की संरचना समान होगी। बेशक - एफपीएम और आवेदन प्रक्रिया विभिन्न कंटेनरों में चलेगी
• nginx ( nginx ) - जो कि nginx के लिए कॉन्फ़िगर और वैकल्पिक मॉड्यूल के वितरण से परेशान नहीं होगा - हम इसके साथ एक अलग छवि एकत्र करेंगे। चूंकि यह एक अलग सेवा है, इसकी अपनी डॉक फ़ाइल और इसका संदर्भ है
• एप्लिकेशन के स्रोत ( स्रोत ) - स्रोत को एक अलग छवि का उपयोग करके वितरित किया जाएगा, ऐप के साथ एक कंटेनर में उनके साथ बढ़ते volume । आधार छवि alpine , अंदर केवल स्थापित निर्भरता वाले स्रोत हैं और वेबपैक परिसंपत्तियों (बिल्ड कलाकृतियों) का उपयोग करके एकत्र किया गया है

अन्य विकास सेवाओं को कंटेनर में लॉन्च किया जाता है, उन्हें hub.docker.com से hub.docker.com ; उत्पादन पर, दूसरी ओर - वे अलग-अलग सर्वरों पर चल रहे हैं, क्लस्टर किए गए हैं। हमारे लिए जो कुछ भी रहता है वह है आवेदन को (पर्यावरण के माध्यम से) उस पते / बंदरगाहों पर और किन विवरणों के साथ उन पर दस्तक देना आवश्यक है। यहां तक ​​कि कूलर को इस उद्देश्य के लिए सेवा-खोज का उपयोग करना है, लेकिन इस समय के बारे में नहीं।

सैद्धांतिक भाग पर निर्णय लेने के बाद, मैं अगले भाग पर जाने का प्रस्ताव करता हूं।

व्यावहारिक हिस्सा है

मेरा सुझाव है कि रिपॉजिटरी में फाइल का आयोजन निम्नानुसार है:

 . ├── docker #    -   │  ├── app │  │  ├── Dockerfile │  │  └── ... │  ├── nginx │  │  ├── Dockerfile │  │  └── ... │  └── sources │    ├── Dockerfile │    └── ... ├── src #   │ ├── app │ ├── bootstrap │ ├── config │ ├── artisan │ └── ... ├── docker-compose.yml # Compose-    ├── Makefile ├── CHANGELOG.md └── README.md 

आप इस लिंक पर क्लिक करके अपने आप को संरचना और फ़ाइलों से परिचित कर सकते हैं।

सेवा बनाने के लिए, आप कमांड का उपयोग कर सकते हैं:

 $ docker build \ --tag %local_image_name% \ -f ./docker/%service_directory%/Dockerfile ./docker/%service_directory% 

अंतर केवल सूत्रों के साथ छवि की असेंबली होगा - इसके लिए, विधानसभा संदर्भ (चरम तर्क) को ./src सेट किया ./src चाहिए।

स्थानीय रजिस्ट्री में छवियों के नामकरण के नियम उन लोगों का उपयोग करने की सलाह देते हैं, जो डिफ़ॉल्ट रूप से %root_directory_name%_%service_name% docker-compose का उपयोग करते हैं, जैसे: %root_directory_name%_%service_name% । यदि प्रोजेक्ट डायरेक्टरी को my-awesome-project कहा जाता है, और सेवा को redis नाम दिया redis , तो छवि का नाम (स्थानीय) क्रमशः my-awesome-project_redis चुनने के लिए बेहतर है।

बिल्ड प्रक्रिया को तेज करने के लिए, आप पहले से इकट्ठे की गई छवि के कैश का उपयोग करने के लिए डॉकटर को बता सकते हैं, और इसके लिए, लॉन्च --cache-from %full_registry_name% । इस प्रकार, डॉकर डेमॉन डॉकरफाइल में एक विशेष निर्देश शुरू करने से पहले देखेंगे - क्या यह बदल गया है? और यदि नहीं (हैश अभिसरण) - यह छवि से पहले से तैयार परत का उपयोग करके, अनुदेश को छोड़ देगा, जिसे आप इसे कैश के रूप में उपयोग करने के लिए कहेंगे। यह बात बुरी नहीं है इसलिए यह इस प्रक्रिया का पुनर्निर्माण करेगा, खासकर अगर कुछ भी नहीं बदला है :)

एप्लिकेशन कंटेनरों को लॉन्च करने के लिए ENTRYPOINT स्क्रिप्ट पर ध्यान ENTRYPOINT ।

एप्लिकेशन (ऐप) लॉन्च करने के लिए पर्यावरण की छवि को इस तथ्य को ध्यान में रखते हुए एकत्र किया गया था कि यह न केवल उत्पादन पर काम करेगा, बल्कि स्थानीय रूप से भी, डेवलपर्स को इसके साथ प्रभावी ढंग से बातचीत करने की आवश्यकता है। composer निर्भरता को स्थापित करना और हटाना, unit परीक्षण, tail लॉग्स और परिचित उपनामों का उपयोग करना ( php /app/artisan → art , composer → c ) बिना किसी असुविधा के होना चाहिए। इसके अलावा - यह सीआई पर unit टेस्ट और स्टेटिक कोड एनालाइजर (हमारे मामले में phpstan ) चलाने के लिए भी इस्तेमाल किया जाएगा। यही कारण है कि इसके डॉकफाइल में, उदाहरण के लिए, xdebug इंस्टॉलेशन xdebug , लेकिन मॉड्यूल स्वयं सक्षम नहीं है (यह केवल CI का उपयोग करके सक्षम है)।

composer hirak/prestissimo पैकेज hirak/prestissimo से hirak/prestissimo , जो सभी निर्भरता की स्थापना को बहुत बढ़ाता है।

उत्पादन पर, हम छवि से स्रोतों / स्रोतों के साथ /src निर्देशिका की सामग्री को इसके अंदर /app निर्देशिका में माउंट करते हैं। विकास के लिए, हम आवेदन स्रोतों ( -v "$(pwd)/src:/app:rw" साथ स्थानीय निर्देशिका "रोल ओवर" करते हैं।

और यहां एक जटिलता निहित है - ये कंटेनर से बनाई गई फ़ाइलों तक पहुंच अधिकार हैं। तथ्य यह है कि डिफ़ॉल्ट रूप से कंटेनर के अंदर चलने वाली प्रक्रियाएं रूट ( root:root ) से शुरू होती हैं, इन प्रक्रियाओं (कैश, लॉग, सत्र, आदि) द्वारा बनाई गई फाइलें - भी, और परिणामस्वरूप - आपके पास उनके साथ "स्थानीय रूप से" कुछ भी नहीं है। आप इसे sudo chown -R $(id -u):$(id -g) /path/to/sources को निष्पादित किए बिना कर सकते हैं।

एक समाधान के रूप में, फिक्सड का उपयोग करें , लेकिन यह समाधान सीधा है। सबसे अच्छा तरीका मुझे कंटेनर के अंदर स्थानीय USER_ID और इसके GROUP_ID को USER_ID और इन मूल्यों के साथ प्रक्रिया शुरू करना GROUP_ID हुआ। डिफ़ॉल्ट रूप से, मान 1000:1000 (पहले स्थानीय उपयोगकर्ता के लिए डिफ़ॉल्ट मान) को प्रतिस्थापित करने से कॉल $(id -u):$(id -g) से छुटकारा मिल जाता है, और यदि आवश्यक हो, तो आप हमेशा उन्हें ( $ USER_ID=666 docker-compose up -d ओवरराइड कर सकते $ USER_ID=666 docker-compose up -d ) या .env फाइल में .env - .env फाइल .env ।

इसके अलावा, जब php-fpm स्थानीय रूप php-fpm लॉन्च किया जाता है php-fpm opcache से opcache को निष्क्रिय php-fpm न भूलें - अन्यथा "हाँ क्या है!" आपको प्रदान किया जाएगा।

रेडिस और पोस्टग्रेज के "प्रत्यक्ष" कनेक्शन के लिए, मैंने अतिरिक्त पोर्ट्स को "आउट" ( 15432 और 15432 क्रमशः) फेंक दिया, इसलिए सिद्धांत रूप में "क्या और कैसे यह वास्तव में है" को जोड़ने और देखने के साथ कोई समस्या नहीं है।

मैं app को सुविधाजनक पहुंच के उद्देश्य से कंटेनर को कोड नाम app चला रहा --command keep-alive.sh ( --command keep-alive.sh ) --command keep-alive.sh ।

docker-compose साथ रोजमर्रा की समस्याओं को हल करने के कुछ उदाहरण यहां दिए गए हैं:

आप सभी लॉन्च विवरण docker-compose.yml फ़ाइल में पा सकते हैं।

चोई ज़िंदा है!

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

इस पर पूर्ण रूसी-भाषा मैनुअल आप इस लिंक पर पा सकते हैं।

आइए देखें कि make रन रिपॉजिटरी की जड़ में कैसे दिखता है:

 [user@host ~/projects/app] $ make help Show this help app-pull Application - pull latest Docker image (from remote registry) app Application - build Docker image locally app-push Application - tag and push Docker image into remote registry sources-pull Sources - pull latest Docker image (from remote registry) sources Sources - build Docker image locally sources-push Sources - tag and push Docker image into remote registry nginx-pull Nginx - pull latest Docker image (from remote registry) nginx Nginx - build Docker image locally nginx-push Nginx - tag and push Docker image into remote registry pull Pull all Docker images (from remote registry) build Build all Docker images push Tag and push all Docker images into remote registry login Log in to a remote Docker registry clean Remove images from local registry --------------- --------------- up Start all containers (in background) for development down Stop all started for development containers restart Restart all started for development containers shell Start shell into application container install Install application dependencies into application container watch Start watching assets for changes (node) init Make full application initialization (install, seed, build assets) test Execute application tests Allowed for overriding next properties: PULL_TAG - Tag for pulling images before building own ('latest' by default) PUBLISH_TAGS - Tags list for building and pushing into remote registry (delimiter - single space, 'latest' by default) Usage example: make PULL_TAG='v1.2.3' PUBLISH_TAGS='latest v1.2.3 test-tag' app-push 

वह नशे की लत के लक्ष्यों में बहुत अच्छे हैं। उदाहरण के लिए, watch ( docker-compose run --rm node npm run watch ) को docker-compose run --rm node npm run watch , आपको एप्लिकेशन को "उठाया" करने की आवश्यकता है - आपको केवल up टारगेट को निर्भर के रूप में निर्दिष्ट करने की आवश्यकता है - और आपको कॉल watch से पहले यह करने के लिए भूलने की चिंता करने की ज़रूरत नहीं है। - अपने आप को आप के लिए सब कुछ कर देगा। वही, रनिंग टेस्ट और स्टैटिक एनालाइज़र पर लागू होता है, उदाहरण के लिए, बदलाव करने से पहले - एक make test चलाएं और आपके लिए सारा जादू हो जाएगा!

कहने की जरूरत नहीं है, आपको छवियों को इकट्ठा करने, उन्हें डाउनलोड करने, निर्दिष्ट करने --cache-from और हर चीज के बारे में चिंता करने की ज़रूरत नहीं है?

आप इस लिंक पर Makefile की सामग्री देख सकते हैं।

ऑटो वाला

आइए इस लेख के अंतिम भाग पर जाएं - यह डॉकर रजिस्ट्री में छवियों को अपडेट करने की प्रक्रिया का स्वचालन है। हालांकि मेरे उदाहरण में GitLab CI का उपयोग किया जाता है - विचार को किसी अन्य एकीकरण सेवा में स्थानांतरित करने के लिए, मुझे लगता है कि यह काफी संभव होगा।

सबसे पहले, हम प्रयुक्त इमेज टैग्स के नामकरण का निर्धारण करेंगे:

रिलीज़ vX.XX प्रारूप vX.XX में एक टैग प्रकाशित करके होता है।

बिल्ड को गति देने के लिए, निर्देशिकाओं का कैशिंग ./src/vendor और ./src/node_modules + --cache-from docker build , और इसमें निम्न चरण होते हैं:

latest और master टैग के साथ push वाली master शाखा पर विधानसभा

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

आप इस लिंक पर कलेक्टर की कॉन्फ़िगरेशन ( .gitlab-ci.yml ) की सामग्री से खुद को परिचित कर सकते हैं।

एक निष्कर्ष के बजाय

जैसा कि आप देख सकते हैं, डॉकर का उपयोग करके php एप्लिकेशन (उदाहरण के रूप में लारवेल का उपयोग करके) के साथ काम को व्यवस्थित करना इतना मुश्किल नहीं है। एक परीक्षण के रूप में, आप रिपॉजिटरी को कांटा कर सकते हैं, और अपने साथ tarampampam/laravel-in-docker की सभी घटनाओं को tarampampam/laravel-in-docker कर सकते हैं, सब कुछ अपने आप जीने की कोशिश कर सकते हैं।

स्थानीय लॉन्च के लिए - केवल 2 कमांड चलाएं:

 $ git clone https://gitlab.com/tarampampam/laravel-in-docker.git ./laravel-in-docker && cd $_ $ make init 

फिर अपने पसंदीदा ब्राउज़र में http://127.0.0.1:9999 खोलें।

... अवसर को जब्त करना

फिलहाल मैं टीएल परियोजना "ऑटोकोड" पर काम कर रहा हूं, और हम प्रतिभाशाली पीएचपी-डेवलपर्स और सिस्टम एडमिनिस्ट्रेटर (विकास कार्यालय येकातेरिनबर्ग में स्थित है) की तलाश कर रहे हैं। यदि आप अपने आप को पहला या दूसरा मानते हैं - "मैं एक विकास टीम बनना चाहता हूं, फिर से शुरू करें: ईमेल hr@avtocod.ru पर ईमेल hr@avtocod.ru :% link_on_summary%" को फिर से शुरू करें, हम स्थानांतरण के साथ मदद करते हैं।