हाई-लोड की स्थितियों में PHP-code को तैनात करने के 5 तरीके

अगर स्कूल में हाईरोड पढ़ाया जाता, तो इस विषय की पाठ्यपुस्तक में ऐसा काम होता। “एन सोशल नेटवर्क में 2,000 सर्वर हैं, जिस पर प्रत्येक PHP कोड के लिए 900 एमबी की 150,000 फाइलें और 50 मशीनों के लिए एक स्टेजिंग क्लस्टर है। कोड को सर्वर पर दिन में 2 बार तैनात किया जाता है, स्टेजिंग क्लस्टर पर कोड को हर कुछ मिनटों में अपडेट किया जाता है, और अतिरिक्त "हॉटफ़िक्स" होते हैं - फ़ाइलों के छोटे सेट जो कि पूर्ण गणना की प्रतीक्षा किए बिना, सभी या सर्वरों के चयनित भाग पर आउट ऑफ टर्न आउट किए जाते हैं। प्रश्न: क्या ऐसी स्थितियों को उच्च भार माना जाता है और उन्हें कैसे तैनात किया जाता है? कम से कम 5 परिनियोजन विकल्प लिखें। " हम केवल हाईलोड समस्या पुस्तक के बारे में सपना देख सकते हैं, लेकिन पहले से ही अब हम जानते हैं कि यूरी नसेरदतिनोव ( youROCK ) निश्चित रूप से इस समस्या को हल करेगा और "पांच" प्राप्त करेगा।


यूरी एक सरल समाधान पर नहीं रुका, बल्कि इसके अलावा एक रिपोर्ट बनाई जिसमें उन्होंने "कोड तैनाती" की अवधारणा का खुलासा किया, बड़े पैमाने पर PHP की तैनाती के लिए क्लासिक और वैकल्पिक समाधानों के बारे में बात की, उनके प्रदर्शन का विश्लेषण किया और एमडीके तैनाती प्रणाली प्रस्तुत की।

"तैनात कोड" की अवधारणा

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

तैनाती की प्रक्रिया में आमतौर पर कई चरण होते हैं।

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

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

बेत में पुरानी तैनाती प्रणाली

यदि आपके पास फ़ाइल सिस्टम छवि के साथ एक फ़ाइल है, तो इसे कैसे माउंट करें? लिनक्स में, आपको एक इंटरमीडिएट लूप डिवाइस बनाने की जरूरत है , एक फाइल को इसमें संलग्न करें, और उसके बाद यह ब्लॉक डिवाइस पहले से ही माउंट किया जा सकता है।

लूप डिवाइस एक बैसाखी है जिसे लिनक्स को फाइल सिस्टम इमेज को माउंट करने की आवश्यकता होती है। ऐसे ओएस हैं जिनमें इस बैसाखी की आवश्यकता नहीं है।



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

अन्य मौजूदा समाधान

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



मैंने परंपरागत रूप से PHP कोड को 4 श्रेणियों में तैनात करने के तरीकों को विभाजित किया है।

• संस्करण नियंत्रण प्रणाली के आधार पर : svn अप, गिट पुल, एचजी अप।
• Rsync उपयोगिता के आधार पर - एक नई निर्देशिका या "शीर्ष पर"।
• एक फ़ाइल परिनियोजित करें - चाहे कोई भी हो: phar, hhbc, loop।
• Rasmus Lerdorf ने जिस विशेष तरीके का सुझाव दिया है वह rsync, 2 निर्देशिका और realpath_root है ।

प्रत्येक विधि में पेशेवरों और विपक्ष दोनों हैं, जिसके कारण हमने उन्हें छोड़ दिया। इन 4 तरीकों पर अधिक विस्तार से विचार करें।

Svn अप संस्करण नियंत्रण प्रणाली पर आधारित तैनाती

मैंने संयोग से एसवीएन नहीं चुना - मेरी टिप्पणियों के अनुसार, इस रूप में एसवीएन के मामले में तैनाती ठीक-ठीक मौजूद है। सिस्टम काफी हल्का है , यह आपको जल्दी और आसानी से तैनात करने की अनुमति देता है - बस svn अप चलाएं और आपका काम हो गया।

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

Rsync उपयोगिता के आधार पर परिनियोजन

ऐसा करने के लिए दो विकल्प हैं: उपयोगिता के साथ सर्वर पर सीधे फाइल अपलोड करें और "शीर्ष पर" अपलोड करें - अपडेट।

एक नई निर्देशिका के लिए rsync

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

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

शीर्ष पर rsync

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

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

हमारी स्थितियों में, इस प्रक्रिया में लगभग 3 एमबी ट्रैफ़िक और प्रोसेसर के 1 सेकंड का समय लगता है । ऐसा लगता है कि यह बहुत अधिक नहीं है, लेकिन हमारे पास 2,000 सर्वर हैं, और सब कुछ कम से कम एक मिनट के प्रोसेसर समय में बदल जाता है। यह इतनी त्वरित विधि नहीं है, लेकिन निश्चित रूप से rsync के माध्यम से पूरी चीज़ भेजने से बेहतर है। यह किसी तरह से परमाणु की समस्या को हल करने के लिए बनी हुई है और लगभग सही होगी।

एक फ़ाइल तैनात करें

आप जो भी एकल फ़ाइल अपलोड करते हैं, वह बिटटोरेंट या यूएफटीपी उपयोगिता का उपयोग करना अपेक्षाकृत सरल है। एक फ़ाइल को अनज़िप करना आसान है, यूनिक्स पर अनधिकृत रूप से प्रतिस्थापित किया जा सकता है, और बिल्ड सर्वर पर उत्पन्न फ़ाइल की अखंडता की जांच करना आसान है और फ़ाइल से एमडी 5 या एसएचए -1 मात्रा की गणना करके गंतव्य मशीनों को वितरित किया जाता है (rsync के मामले में, आपको पता नहीं है कि गंतव्य सर्वर पर क्या है? )।

हार्ड ड्राइव के लिए, अनुक्रमिक रिकॉर्डिंग एक बड़ा प्लस है - एक 900 एमबी फाइल लगभग 10 सेकंड में एक बिना हार्ड ड्राइव पर लिखी जाएगी। लेकिन फिर भी आपको इन 900 एमबी को रिकॉर्ड करने और नेटवर्क पर स्थानांतरित करने की आवश्यकता है।

UFTP के बारे में गीतात्मक विषयांतर

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

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

एकल फ़ाइल परिनियोजन विकल्प

tar.gz

एक विकल्प जो दोनों दृष्टिकोणों के नुकसान को जोड़ता है। इतना ही नहीं आपको क्रमिक रूप से डिस्क पर 900 एमबी लिखना है, उसके बाद आपको रैंडम रीड-राइट द्वारा उसी 900 एमबी को फिर से लिखना होगा और 150,000 फाइलें बनानी होंगी। यह विधि rsync की तुलना में प्रदर्शन में और भी खराब है।

phar

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

hhbc

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

इस पद्धति के लिए इसे eval और डायनामिक शामिल करने से मना किया जाता है। यह ऐसा है, लेकिन काफी नहीं है। Eval का उपयोग किया जा सकता है, लेकिन यदि यह नई कक्षाएं या फ़ंक्शंस नहीं बनाता है, और शामिल नहीं किया जा सकता है जो इस संग्रह के बाहर हैं।

पाश

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

लेकिन लूप के पास विपक्ष है। पहले, यह डॉकटर के साथ अजीब तरह से काम करता है। मैं इस बारे में थोड़ी देर बाद बात करूंगा।

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

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

डॉकटर के साथ समस्या

यदि आप एक डॉकटर कंटेनर बनाते हैं और उसके अंदर एक फ़ोल्डर फेंकते हैं जिसमें "लूप्स" या अन्य ब्लॉक डिवाइस माउंट किए जाते हैं, तो एक ही बार में दो समस्याएं होती हैं: नए माउंट पॉइंट डॉकटर कंटेनर में नहीं आते हैं, और वे "लूप" जो निर्माण के समय थे एक डॉक कंटेनर को अनमाउंट नहीं किया जा सकता है क्योंकि वे डॉक कंटेनर द्वारा कब्जा कर लिए जाते हैं।

स्वाभाविक रूप से, यह आमतौर पर तैनाती के साथ असंगत है, क्योंकि लूप उपकरणों की संख्या सीमित है, और यह स्पष्ट नहीं है कि नए कोड को कंटेनर में कैसे गिरना चाहिए।

हमने अजीब चीजें करने की कोशिश की, उदाहरण के लिए, स्थानीय एनएफएस सर्वर को बढ़ाने या एसएसएचएफएस का उपयोग करके एक निर्देशिका को माउंट करने के लिए, लेकिन किसी कारण से यह हमारे साथ जड़ नहीं लेता था। नतीजतन, क्रॉन में, हमने वर्तमान निर्देशिका में अंतिम "लूप" से rsync पंजीकृत किया, और यह कमांड को एक मिनट पहले चलाया:

rsync /var/loop/<N>/ /var/www/ 

यहाँ /var/www/ निर्देशिका है जिसे कंटेनर में प्रचारित किया जाता है। लेकिन जिन मशीनों में डॉकटर कंटेनर होते हैं, हमें अक्सर PHP स्क्रिप्ट चलाने की आवश्यकता नहीं होती है, इसलिए rsync परमाणु नहीं था, जो हमारे अनुकूल था। लेकिन फिर भी, यह विधि बहुत खराब है, निश्चित रूप से। मैं एक तैनाती प्रणाली बनाना चाहूंगा जो डॉकटर के साथ अच्छा काम करे।

rsync, 2 निर्देशिका और realpath_root

इस विधि को PHP के लेखक रैसमस लेरडॉर्फ द्वारा प्रस्तावित किया गया था, और वह जानता है कि कैसे तैनात किया जाए।

एक परमाणु की तैनाती कैसे करें, और किसी भी तरीके से, जिसके बारे में मैंने बात की थी? सिमिंक लें और इसे document_root के रूप में पंजीकृत करें। समय के प्रत्येक बिंदु पर, सिम्लिंक दो निर्देशिकाओं में से एक को इंगित करता है, और आप rsync को एक पड़ोसी निर्देशिका में बनाते हैं, अर्थात, जिस कोड को इंगित नहीं करता है।



लेकिन समस्या यह उत्पन्न होती है: PHP कोड यह नहीं जानता है कि यह किस निर्देशिका में लॉन्च किया गया था। इसलिए, आपको उपयोग करने की आवश्यकता है, उदाहरण के लिए, एक चर जिसे आप कॉन्फ़िगरेशन में शुरुआत में कहीं लिखेंगे - यह तय करेगा कि कोड किस निर्देशिका से चलाया गया था और जिसमें से नई फाइलें शामिल होनी चाहिए। एक स्लाइड पर, इसे ROOT_DIR कहा जाता है।

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



लेकिन इसके लिए कोड लिखना होगा। सभी परियोजनाएं इसके लिए तैयार नहीं हैं।

Rasmus शैली

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



Document_root के लिए, नवीनतम संस्करण के लिए सिमलिंक निर्दिष्ट करें। यदि आपके पास नगनेक्स है, तो आप root $realpath_root को पंजीकृत कर सकते हैं, अपाचे के लिए आपको सेटिंग्स के साथ एक अलग मॉड्यूल की आवश्यकता होगी जो स्लाइड पर देखी जा सकती है। यह इस तरह से काम करता है - जब कोई अनुरोध आता है, तो एक बार nginx या Apache एक बार रास्ते से realpath () पर विचार करता है, इसे सहानुभूति से बचाता है, और इस पथ को document_root के रूप में पास करता है। इस मामले में, document_root हमेशा सहानुभूति के बिना एक नियमित निर्देशिका को इंगित करेगा, और आपके PHP कोड को यह नहीं सोचना पड़ सकता है कि इसे किस निर्देशिका से कहा जाता है।

इस विधि के रोचक फायदे हैं - असली रास्ते ओपचे PHP में आते हैं, उनमें सिम्लिंक नहीं होते हैं। यहां तक ​​कि पहली फ़ाइल जो अनुरोध के लिए आई थी, वह पहले से ही पूरी हो जाएगी, और OPCache के साथ कोई समस्या नहीं होगी। चूंकि document_root का उपयोग किया जाता है, यह किसी भी PHP परियोजना के साथ काम करता है। आपको कुछ भी अनुकूलित करने की आवश्यकता नहीं है।

इसे fpm पुनः लोड करने की आवश्यकता नहीं है, तैनाती के दौरान OPCache को रीसेट करने की कोई आवश्यकता नहीं है, यही कारण है कि प्रोसेसर सर्वर बहुत व्यस्त है, क्योंकि इसे फिर से सभी फाइलों को पार्स करना होगा। मेरे प्रयोग में, ओपचे को 2 मिनट के कारक से लगभग आधे मिनट की वृद्धि हुई प्रोसेसर की खपत को रीसेट करना। इसका पुन: उपयोग करना अच्छा होगा और यह विधि आपको इसे करने की अनुमति देती है।

अब अंत। चूंकि आप OPCache का पुन: उपयोग नहीं करते हैं, और आपके पास 2 निर्देशिकाएं हैं, इसलिए आपको प्रत्येक निर्देशिका के लिए स्मृति में फ़ाइल की एक प्रति संग्रहीत करने की आवश्यकता है - OPCache के तहत, 2 गुना अधिक मेमोरी की आवश्यकता होती है।

एक और सीमा है जो अजीब लग सकती है - आप हर एक से अधिक max_execution_time को तैनात नहीं कर सकते । अन्यथा, एक ही समस्या उत्पन्न होगी, क्योंकि rsync निर्देशिकाओं में से एक में जा रहा है, लेकिन इससे अनुरोध अभी भी संसाधित किए जा सकते हैं।

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

रासमस कहता है कि प्रणाली अच्छी है और मैं आपको भी इसकी सलाह देता हूं। 99% परियोजनाओं के लिए, यह नई परियोजनाओं के लिए और मौजूदा वाले दोनों के लिए उपयुक्त है। लेकिन, निश्चित रूप से, हम ऐसे नहीं हैं और अपना फैसला लिखने का फैसला किया है।

नई प्रणाली - एमडीके

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

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

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

संभावित समाधान:

• लूप xN (-स्टेजिंग, -docker; -opcache);
• rsync xN (-प्रदान, -opcache xN);
• एसवीएन एक्सएन (-प्रोडक्शन, -ओपचेस एक्सएन)।

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

इसलिए, हम एक नई प्रणाली के साथ आए और इसे एमडीके कहा । यह मल्टीवर्जन डिप्लॉयमेंट किट , एक बहु-संस्करण परिनियोजन उपकरण के लिए है। हमने इसे निम्नलिखित मान्यताओं के आधार पर किया था।

हमने Git से ट्री स्टोरेज आर्किटेक्चर लिया। हमें कोड का एक सुसंगत संस्करण होना चाहिए जिसमें स्क्रिप्ट काम करती है, यानी हमें स्नैपशॉट चाहिए। स्नैपशॉट को LVM द्वारा समर्थित किया जाता है, लेकिन वहां उन्हें Btrfs और Git जैसी प्रयोगात्मक फ़ाइल प्रणालियों द्वारा अक्षम रूप से लागू किया जाता है। हमने गिट से स्नैपशॉट का कार्यान्वयन लिया।

फ़ाइल.php से file.php। <संस्करण> के लिए सभी फ़ाइलों का नाम बदला। चूँकि हमारे पास मौजूद सभी फाइलें केवल डिस्क पर संग्रहीत होती हैं, तो यदि हम उसी फ़ाइल के कई संस्करणों को संग्रहीत करना चाहते हैं, तो हमें संस्करण के साथ एक प्रत्यय जोड़ना होगा।

मुझे गो से प्यार है, इसलिए गति के लिए मैंने गो पर एक प्रणाली लिखी।

मल्टीवर्सन डिप्लॉयमेंट किट कैसे काम करता है

हमने गिट से स्नैपशॉट का विचार लिया। मैंने इसे थोड़ा सरल किया और आपको बताता हूं कि इसे एमडीके में कैसे लागू किया जाता है।

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



मान लीजिए कि हमारे पास कुछ फाइलों का पदानुक्रम है, जिसमें रूट मैप अन्य मैप्स से फाइलों के कुछ संस्करणों को संदर्भित करता है , और वे बदले में, अन्य फाइलों और मानचित्रों को संदर्भित करते हैं, और कुछ संस्करणों को ठीक करते हैं। हम किसी प्रकार की फ़ाइल को बदलना चाहते हैं।



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

लिंक उन्हीं फाइलों पर बने रहते हैं, जैसे वे थीं। यह किसी भी तरह से स्नैपशॉट बनाने का मुख्य विचार है, उदाहरण के लिए, ZFS में इसे लगभग उसी तरह से लागू किया जाता है।

MDK एक डिस्क पर कैसे निहित है

हमारे पास डिस्क पर है: नवीनतम रूट मैप के लिए सिमलिंक - कोड जो वेब से प्राप्त किया जाएगा, रूट मैप के कई संस्करण, कई फाइलें, संभवत: विभिन्न संस्करणों के साथ, और उपनिर्देशिकाओं में संबंधित निर्देशिकाओं के लिए नक्शे हैं।

मैं इस सवाल का जवाब देता हूं: " और यह वेब अनुरोध को कैसे संसाधित करता है? उपयोगकर्ता कोड में कौन सी फाइलें आएंगी? "

हां, मैंने आपको धोखा दिया है - संस्करणों के बिना भी फाइलें हैं, क्योंकि यदि आपको index.php के लिए अनुरोध प्राप्त होता है, और आपके पास निर्देशिका में नहीं है, तो साइट काम नहीं करेगी।



सभी PHP फ़ाइलों में फाइलें होती हैं, जिन्हें हम स्टब्स कहते हैं, क्योंकि उनमें दो लाइनें होती हैं: फाइल से उस फ़ंक्शन की आवश्यकता होती है जिसमें यह पता चलता है कि इन कार्डों के साथ कैसे काम करना है, घोषित किया गया है और फ़ाइल के वांछित संस्करण से आवश्यकता होती है।

 <?php require_once "mdk.inc"; require mdk_resolve_path("a.php"); 

ऐसा इसलिए किया गया है, और नवीनतम संस्करण से सहानुभूति नहीं है, क्योंकि यदि आप एक संस्करण के बिना a.php फ़ाइल से b.php को बाहर करते हैं, तो चूंकि आवश्यकता_ लिखी गई है, इसलिए सिस्टम को याद होगा कि यह किस रूट कार्ड से शुरू हुआ था, वह इसका उपयोग करेगा, और फ़ाइलों का एक सुसंगत संस्करण प्राप्त करें।

बाकी फाइलों के लिए, हमारे पास केवल नवीनतम संस्करण के लिए सहानुभूति है।

एमडीके का उपयोग करके कैसे तैनात किया जाए

मॉडल गिट पुश के समान है।

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

उदाहरण

मान लीजिए कि सर्वर पर "एक" नामक एक फ़ाइल है। इसे रूट मैप भेजें।



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



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



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

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

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

आप आसानी से परिवर्तनों को वापस ले सकते हैं , क्योंकि सभी पुराने कार्ड जगह में हैं। हम सिर्फ कार्ड फेंक सकते हैं, सब कुछ वहीं होगा।

मेरे लिए, प्लस तथ्य यह है कि एमडीके गो में लिखा है इसका मतलब है कि यह जल्दी से काम करता है।

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

हमने फाइलों को संपादित करने के लिए विशेष उपयोगिताओं को लिखा है - असली वाले, स्टब्स नहीं, उदाहरण के लिए, mdk-vim। आप फ़ाइल निर्दिष्ट करते हैं, यह वांछित संस्करण पाता है और इसे संपादित करता है।

संख्या में एमडीके

हमारे पास मंचन पर 50 सर्वर हैं, जिस पर हम 3-5 एस के लिए तैनात हैं । Rsync को छोड़कर हर चीज की तुलना में यह बहुत तेज है। उत्पादन पर हम लगभग 2 मिनट , छोटे पैच तैनात करते हैं - 5-10 एस ।

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

यह प्रणाली ओपन सोर्स में नहीं है, लेकिन यदि आप रुचि रखते हैं, तो टिप्पणियों में लिखें - यह निर्धारित किया जा सकता है ( भविष्य से यूरी: सिस्टम अभी भी इस लेखन के समय ओपन सोर्स में नहीं है )।

निष्कर्ष

रासमस को सुनो, वह झूठ नहीं बोल रहा है । मेरी राय में, realpath_root के साथ मिलकर इसका rsync तरीका सबसे अच्छा है, हालांकि लूप भी काफी अच्छा काम करते हैं।

अपने सिर के साथ सोचें : ठीक से देखें कि आपकी परियोजना को क्या चाहिए, और एक स्पेसशिप बनाने की कोशिश न करें जहां पर्याप्त "मकई" हो। लेकिन अगर आपके पास अभी भी समान आवश्यकताएं हैं, तो एमडीके के समान एक प्रणाली आपके अनुरूप होगी।

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

टेलीग्राम चैनल को कॉन्फ्रेंस प्रोग्राम अपडेट के साथ सब्सक्राइब करें और 17 मई को देखें।