सामान्य रूप से और रूबी ऑन रेल्स में फ्लाई (शून्य-डाउनटाइम परिनियोजन) पर अपडेट

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

इसकी आवश्यकता क्यों है? यदि आप यह प्रश्न पूछ रहे हैं - तो आपको इसकी आवश्यकता नहीं है। एक संकेत लटकाओ, रात के खाने के लिए बैठो।

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

सामान्य निर्णय

सामान्य शब्दों में, समाधान निम्नानुसार तैयार किया जा सकता है: संस्करण N + 1 के कोड की अनुकूलता सुनिश्चित करने के लिए आवश्यक है संस्करण N और N + 1 की स्थिति के साथ, फिर राज्य को N + 1 में अपडेट करें।

व्यवहार में, इस तरह की संगतता से बड़ी संख्या में (स्पष्ट और ऐसा नहीं) कठिनाइयों का परिणाम होता है। आइए रूबी ऑन रेल एप्लिकेशन में विशिष्ट मामलों को देखें।

डेटाबेस स्कीमा बदलें

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

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

एक फ़ील्ड का नाम बदलना थोड़ा अधिक जटिल है:
- एक नए नाम के साथ एक फ़ील्ड बनाएं
- हम एक इंटरमीडिएट के कोड को अपडेट करते हैं, जो a) दोनों (पुराने और नए) फ़ील्ड्स के डेटा को पढ़ता है b) दोनों क्षेत्रों के डेटा को लिखता है
- हम पुराने फ़ील्ड से नए में डेटा माइग्रेट करते हैं
- यह पुराने क्षेत्र को सही ढंग से हटाने के लिए बना हुआ है, पिछले पैराग्राफ को देखें।

अनुक्रमणिका जोड़ना और निकालना कोड के पिछले संस्करण के साथ संगत है, अगर a) स्पष्ट सूचकांक के साथ संकेत का उपयोग नहीं कर रहा है b) सूचकांक को हटाने से पुराने कोड का निष्पादन धीमा नहीं होगा।

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

क्लाइंट-सर्वर इंटरैक्शन बदलें

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

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

किसी एप्लिकेशन के कुछ पृष्ठों / कार्यों के पते बदलना हमेशा पिछड़े संगत होना चाहिए। पुराने मार्गों को छोड़ दें, उन्हें पुनर्निर्देशित करें, जो भी हो। वेब एप्लिकेशन में URL सिस्टम का सबसे स्थिर हिस्सा होना चाहिए: यह आपका सार्वजनिक API है जिसका उपयोग आपके उपयोगकर्ता और खोज इंजन करते हैं जो आपके उपयोगकर्ताओं को लाते हैं। इस प्रकार, आपको इस लेख द्वारा वर्णित भाग में समस्याएं नहीं होंगी।

परिसंपत्ति पाइपलाइन का उपयोग करने के मामले में , आपको कोड के पिछले संस्करण से संपत्ति निकालने की आवश्यकता नहीं है। यह सरल है।

पुनः आरंभ

कोड संगतता सब कुछ नहीं है। आप कार्य में नया कोड कैसे दर्ज करते हैं? आपके पास कितने वेब या ऐप सर्वर हैं? विकल्पों पर विचार करें।

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

यदि आपके पास Nginx या Apache httpd के पीछे एक पैसेंजर सर्वर है, तो आपको यूनिकॉर्न में जाना होगा। यहां तक ​​कि पैसेंजर 3, जिसमें शून्य-डाउन रिस्टार्ट घोषित किया गया है, इसे पर्याप्त अनुभवहीन बनाता है: पहले यह पुराने श्रमिकों को मारता है, फिर यह नया करता है। नतीजतन, आगंतुकों को एक लंबी प्रतिक्रिया समय मिलता है, कम से कम आपके आवेदन के शुरुआती समय से कम नहीं।

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

युक्ति: preload_app true विकल्प का उपयोग करें, भले ही आप रूबी एंटरप्राइज़ संस्करण पर न हों - अन्यथा आपको बहुत देर हो जाएगी कि एक त्रुटि के कारण नए कर्मचारी स्टार्टअप पर आते हैं।

निष्कर्ष

फिर से सोचें: क्या आपको वास्तव में यह सब चाहिए? वास्तव में? हो सकता है कि सभी समान हों, बस स्टूल पेज में नवीनतम +100500 TED अंक डालें, cap deploy और चाय पिएं? अरे हाँ ... उपयोगकर्ताओं, बिक्री, लाभ ...