बिना किसी डाउनटाइम के वेब ऐप अपडेट करना

Question

यह एक PHP ऐप है। संपूर्ण कोडबेस को अपडेट करते समय मैं डाउनटाइम को कैसे कम कर सकता हूं?

Answer 1

हम आम तौर पर काम पर क्या करते हैं:

• इससे पहले कि हम अपडेट करें, सर्वर का डॉक्यूमेंट रूट है:
  • में /www/app-2009-09-01
  • लेकिन एक प्रतीकात्मक लिंक के माध्यम से पहुँचा है, कहा जाता है /www/application
• हमने पूरा नया कोड आधार को रखा /www/app-2009-09-08
• एक बार पूरा कोड आधार होने के बाद:
  • हम पुराने प्रतीकात्मक लिंक को हटा देते हैं
  • हम एक नया प्रतीकात्मक लिंक बनाते हैं, जिसे अभी भी कहा जाता है /www/application, लेकिन जो नए स्रोतों की ओर इशारा करता है:/www/app-2009-09-08
• हम संशोधन को खाते में ले जाने के लिए बाध्य करने के लिए पुनः लोड करते हैं।

यह सारी प्रक्रिया एक स्वचालित लिपि के माध्यम से की जाती है (आवश्यकता न होने पर केवल स्वचालित चीज ही हमें लॉन्च कर रही है)। इसका मतलब है की :

• सब कुछ तेजी से होता है (विशेषकर प्रतीकात्मक लिंक का स्विचिंग, जो महत्वपूर्ण हिस्सा है)
• त्रुटि करने का कोई जोखिम नहीं: स्क्रिप्ट को अच्छी तरह से परीक्षण किया गया है, और महीनों / वर्षों के लिए काम कर रहा है

इस प्रतीकात्मक लिंक पूर्वता का एक और लाभ यह है कि एक अद्यतन "रोलबैक" करना बहुत आसान है अगर हम उत्पादन के स्रोतों के नए संस्करण को डालने के बाद ही एक भयावह बग को नोटिस करते हैं: हमें केवल प्रतीकात्मक लिंक को स्विच करना होगा।

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

---

यहाँ कुछ त्वरित उदाहरण है: मान लीजिए कि मेरे अपाचे विन्यास में यह वर्चुअलोस्ट है:

<VirtualHost *>
        ServerName example.com
        DocumentRoot /www/application
        <Directory /www/application>
            # Whatever you might need here (this example is copy-pasted from a test server and test application ^^ )
            Options Indexes FollowSymLinks MultiViews +SymLinksIfOwnerMatch
            AllowOverride All
            php_value   error_reporting 6135
            php_value short_open_tag  on
        </Directory>
</VirtualHost>

सुंदर "मानक" ... केवल एक चीज /www/applicationवास्तविक निर्देशिका नहीं है: यह स्रोतों के वर्तमान संस्करण का सिर्फ एक प्रतीकात्मक लिंक है।
इसका मतलब है कि जब आपने सर्वर पर स्रोत डाल दिए हैं, लेकिन अभी तक स्विच नहीं किया है, तो आपके पास कुछ इस तरह होगा:

root@shark:/www
# ll
total 8
drwxr-xr-x 2 root root 4096 2009-09-08 22:07 app-2009-09-01
drwxr-xr-x 2 root root 4096 2009-09-08 22:07 app-2009-09-08
lrwxrwxrwx 1 root root   19 2009-09-08 22:08 application -> /www/app-2009-09-01

ध्यान दें कि सिमिलिनक "पुराने संस्करण" की ओर इशारा करता है

अब, नया संस्करण पूरी तरह से सर्वर पर अपलोड हो गया है, चलो स्विच करते हैं:

root@shark:/www
# rm /www/application
root@shark:/www
# ln -s /www/app-2009-09-08 /www/application

और, अब, /www/applicationसूत्रों के नए संस्करण के लिए अंक:

root@shark:/www
# ll
total 8
drwxr-xr-x 2 root root 4096 2009-09-08 22:07 app-2009-09-01
drwxr-xr-x 2 root root 4096 2009-09-08 22:07 app-2009-09-08
lrwxrwxrwx 1 root root   19 2009-09-08 22:09 application -> /www/app-2009-09-08

और हमें बस अपाचे को पुनः आरंभ करना होगा:

root@shark:/www
# /etc/init.d/apache2 restart
 * Restarting web server apache2

तीन चरणों " लिंक को हटा दें; नया लिंक बनाएं; अपाचे को पुनरारंभ करें " जल्दी से बनाया जाना चाहिए; अर्थात, एक स्वचालित लिपि द्वारा, और मनुष्य द्वारा नहीं।

इस समाधान का उपयोग करना:

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

और अगर 0 पर स्टेटस ऑप्शन के साथ एपीसी जैसे कुछ ओपकोड-कैश का उपयोग किया जाता है, तो इसका मतलब डाउनटाइम का कम जोखिम हो सकता है, मुझे लगता है।

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

आशा है कि यह अधिक स्पष्ट है :-)

Comments

यह एक तरह का सर्वर स्वैपिंग भी है। :-)

— दस ब्रिंक

mod_rewrite प्रतीकात्मक लिंक प्रबंधित करने के लिए?

@gAMBOOKa: नहीं: अपाचे के डॉक्यूमेंटRoot (या VirtualHost DocumentRoot) की बात है, जो / www / एप्लिकेशन है ;; यानी, प्रतीकात्मक लिंक - कोई फर्क नहीं पड़ता कि वह कहाँ इंगित करता है।

बहुत बढ़िया जवाब। एक और टिप, हालांकि: आप इसे लिंक किए बिना प्रतीकात्मक लिंक बना सकते हैं। जैसा कि उद्धृत किया गया है: "तीन चरणों ... को जल्दी से बनाया जाना चाहिए; अर्थात एक स्वचालित स्क्रिप्ट द्वारा, और एक इंसान द्वारा नहीं।" Mv कमांड एक परमाणु ऑपरेशन है, जिससे आप 'ln -s / www / app-2011-01-28 / www / application-temp' जैसे सिम्लिंक बना सकते हैं और फिर 'mv -T / www / application-temp' कर सकते हैं / www / आवेदन '।

कुछ हैं जो सिमलिंक विधि द्वारा कवर नहीं किए गए थे। आपका तरीका Apache + mod_php के साथ काम करता है लेकिन यह lighttpd + fastcgi पर विफल हो सकता है। एक उच्च यातायात वेबसाइट में, लिंक को स्वैप करने के बीच में अनुरोध किया जाएगा कि, php कोड निर्भरता मिश्रित संस्करण के साथ विफल हो जाएगी।

— डेनिस सी

Answer 2

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

Answer 3

अपडेट किए गए कोडबेस के साथ एक दूसरा सर्वर सेट करें और उन्हें जितनी जल्दी हो सके स्विच करें। :-)

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

Comments

चूंकि ऐप को खंडित मॉड्यूल के साथ परीक्षण नहीं किया गया है, इसलिए इसका परिणाम अप्रत्याशित परिदृश्यों में हो सकता है।

जिसका मतलब है कि इस अपडेट के बाद यह आपके ToDo की सूची में होगा। :-) इसे और अधिक मॉड्यूलर बनाएं और आप प्रति मॉड्यूल अपडेट कर सकते हैं।

— दस ब्रिंक

यह ToDo सूची में है, लेकिन एक दीर्घकालिक लक्ष्य है। हम एक युवा स्टार्टअप हैं, इसलिए देव टीम के भीतर संगठन स्वाभाविक रूप से थोड़ी देर लगेगा। = डी

Answer 4

सबसे पहले, मैं अक्सर पास्कल मार्टिन की प्रतिक्रिया के समान एक विधि का उपयोग करता हूं और पसंद करता हूं।

एक और तरीका जो मुझे भी पसंद है वह है मेरे SCM का उपयोग नए कोड को पुश करने के लिए। सटीक प्रक्रिया आपके प्रकार के SCM (git vs svn vs ...) पर निर्भर करती है। यदि आप svn का उपयोग कर रहे हैं, तो मैं एक "ऑनलाइन" या "प्रोडक्शन" शाखा बनाना पसंद करता हूं जिसे मैं सर्वर पर दस्तावेज़ रूट के रूप में चेकआउट करता हूं। फिर, जब भी मैं किसी अन्य शाखा / टैग / ट्रंक से नए कोड को पुश करना चाहता हूं, तो मैं नए कोड को "ऑनलाइन" शाखा में भेज देता हूं और दस्तावेज़ रूट में svn अपडेट चलाता हूं। यह बहुत आसान रोलबैक के लिए अनुमति देता है क्योंकि सर्वर के ऊपर / नीचे जाने का पूरा संशोधन लॉग होता है और यह किसने और कब किया। आप टेस्ट बॉक्स पर उस "ऑनलाइन" शाखा को आसानी से चला सकते हैं, जिससे आप उस ऐप को वीटी कर सकते हैं जिसे आप पुश करने वाले हैं।

प्रक्रिया एससीएम की अन्य शैलियों के लिए समान है, बस उनकी कार्यशैली के लिए और अधिक प्राकृतिक होने के लिए संशोधित किया गया है।

अपडेट पुश करने के बजाय पुल / पोल करना चाहते हैं? बस एक क्रॉन नौकरी या अन्य है, होशियार तंत्र स्वचालित रूप से svn अद्यतन चलाते हैं।

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

Answer 5

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