Erlang 21 - 11. Release Handling

11 रिलीज हैंडलिंग




erlang

11 रिलीज हैंडलिंग

11.1 रिलीजिंग प्रिंसिपल्स

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

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

रूपरेखा में निम्नलिखित शामिल हैं:

  • ऑफ़लाइन समर्थन - स्क्रिप्ट बनाने और रिलीज़ पैकेज के निर्माण के लिए systools
  • ऑनलाइन समर्थन - रिलीज़ पैकेज को अनपैकिंग और इंस्टॉल करने के लिए release_handler

Erlang / OTP पर आधारित न्यूनतम प्रणाली, रिलीज़ से निपटने को सक्षम करती है, इस प्रकार कर्नेल, STDLIB और SASL अनुप्रयोग होते हैं।

रिलीज हैंडलिंग वर्कफ़्लो

चरण 1 ) एक विज्ञप्ति बनाई गई है जैसा कि Releases में वर्णित है।

चरण 2 ) रिलीज को लक्षित वातावरण में स्थानांतरित और स्थापित किया गया है। पहला लक्ष्य सिस्टम कैसे स्थापित करें, इसकी जानकारी के लिए, सिस्टम सिद्धांत देखें।

चरण 3 ) संशोधन, उदाहरण के लिए, त्रुटि सुधार, विकास पर्यावरण में कोड के लिए किए जाते हैं।

चरण 4 ) कुछ बिंदु पर, रिलीज का नया संस्करण बनाने का समय आ गया है। प्रासंगिक .app फ़ाइलें अद्यतन की जाती हैं और एक नई .rel फ़ाइल लिखी जाती है।

चरण 5 ) प्रत्येक संशोधित आवेदन के लिए, एक application upgrade file , .appup , बनाया जाता है। इस फ़ाइल में, यह वर्णन किया गया है कि आवेदन के पुराने और नए संस्करण के बीच उन्नयन और / या डाउनग्रेड कैसे करें।

चरण 6 ) .appup फ़ाइलों के आधार पर, एक release upgrade file जिसे relup कहा जाता है, बनाई जाती है। यह फ़ाइल वर्णन करती है कि संपूर्ण रिलीज़ के पुराने और नए संस्करण के बीच अपग्रेड और / या डाउनग्रेड कैसे करें।

चरण 7 ) एक नया रिलीज पैकेज बनाया गया है और लक्ष्य प्रणाली में स्थानांतरित किया गया है।

चरण 8 ) रिलीज़ हैंडलर का उपयोग करके नया रिलीज़ पैकेज अनपैक किया गया है।

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

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

रिलीजिंग ऐस्पेक्ट्स

Appup Cookbook में अपग्रेड / डाउनग्रेड के विशिष्ट मामलों के लिए .appup फ़ाइलों के उदाहरण हैं जो सामान्य रूप से रनटाइम में संभालना आसान है। हालाँकि, कई पहलू रिलीज़ हैंडलिंग को जटिल बना सकते हैं, उदाहरण के लिए:

  • जटिल या परिपत्र निर्भरताएं यह तय करना मुश्किल या असंभव भी कर सकती हैं कि किस क्रम में अपग्रेड या डाउनग्रेड के दौरान रनटाइम त्रुटियों को जोखिम में डाले बिना किया जाना चाहिए। निर्भरताएँ हो सकती हैं:

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

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

11.2 आवश्यकताएँ

रिलीज़ हैंडलिंग को ठीक से काम करने के लिए, रनटाइम सिस्टम को इस बारे में जानकारी होनी चाहिए कि वह किस रिलीज़ पर चल रहा है। यह भी बदलने में सक्षम होना चाहिए (रनटाइम में) बूट स्क्रिप्ट और सिस्टम कॉन्फ़िगरेशन फ़ाइल का उपयोग करने के लिए यदि सिस्टम को रिबूट किया जाता है, उदाहरण के लिए, विफलता के बाद heart । इस प्रकार, एरलंग को एक एम्बेडेड सिस्टम के रूप में शुरू किया जाना चाहिए; यह कैसे करें के बारे में जानकारी के लिए, एंबेडेड सिस्टम देखें।

सिस्टम रिबूट को ठीक से काम करने के लिए, यह भी आवश्यक है कि सिस्टम को दिल की धड़कन की निगरानी के साथ शुरू किया गया है, erl(1) में erl(1) मैनुअल पेज और कर्नेल में heart(3) मैनुअल पेज देखें

अन्य आवश्यकताएं:

  • रिलीज़ पैकेज में शामिल बूट स्क्रिप्ट को उसी .rel फ़ाइल से रिलीज़ पैकेज के रूप में जनरेट किया जाना चाहिए।

    अपग्रेड या डाउनग्रेड होने पर एप्लिकेशन की जानकारी स्क्रिप्ट से प्राप्त होती है।

  • सिस्टम को केवल एक सिस्टम कॉन्फ़िगरेशन फ़ाइल का उपयोग करके कॉन्फ़िगर किया जाना चाहिए, जिसे sys.config कहा जाता है।

    यदि पाया जाता है, तो यह फ़ाइल स्वचालित रूप से शामिल होती है जब एक रिलीज़ पैकेज बनाया जाता है।

  • रिलीज़ के सभी संस्करणों, पहले वाले को छोड़कर, एक relup फ़ाइल होनी चाहिए।

    यदि पाया जाता है, तो यह फ़ाइल स्वचालित रूप से शामिल होती है जब एक रिलीज़ पैकेज बनाया जाता है।

11.3 वितरित सिस्टम

यदि सिस्टम में कई एरलंग नोड्स होते हैं, तो प्रत्येक नोड रिलीज़ के अपने संस्करण का उपयोग कर सकता है। रिलीज हैंडलर एक स्थानीय रूप से पंजीकृत प्रक्रिया है और इसे प्रत्येक नोड पर बुलाया जाना चाहिए जहां अपग्रेड या डाउनग्रेड की आवश्यकता होती है। एक रिलीज़ हैंडलिंग निर्देश, sync_nodes , का उपयोग कई नोड्स में रिलीज़ हैंडलर प्रक्रियाओं को सिंक्रनाइज़ करने के लिए किया जा सकता है, sync_nodes में appup(4) मैनुअल पेज देखें।

11.4 रिलीजिंग निर्देश

OTP .appup फ़ाइल बनाते समय उपयोग किए जाने वाले रिलीज़ हैंडलिंग निर्देशों के एक सेट का समर्थन करता है। रिलीज़ हैंडलर इनमें से सबसे निचले स्तर के निर्देशों को समझता है। उपयोगकर्ता के लिए इसे आसान बनाने के लिए, कई उच्च-स्तरीय निर्देश भी हैं, जिनका अनुवाद systools:make_relup द्वारा निम्न-स्तरीय निर्देशों में किया systools:make_relup

इस अनुभाग में कुछ सबसे अधिक बार उपयोग किए जाने वाले निर्देशों का वर्णन किया गया है। निर्देशों की पूरी सूची appup(4) में appup(4) मैनुअल पेज में शामिल है।

सबसे पहले, कुछ परिभाषाएँ:

  • निवास मॉड्यूल - वह मॉड्यूल जहां एक प्रक्रिया में इसकी पूंछ-पुनरावर्ती लूप फ़ंक्शन (एस) होते हैं। यदि इन कार्यों को कई मॉड्यूल में लागू किया जाता है, तो वे सभी मॉड्यूल प्रक्रिया के लिए निवास मॉड्यूल हैं।
  • कार्यात्मक मॉड्यूल - एक मॉड्यूल जो किसी भी प्रक्रिया के लिए एक निवास मॉड्यूल नहीं है।

एक ओटीपी व्यवहार का उपयोग करके लागू की गई प्रक्रिया के लिए, व्यवहार मॉड्यूल उस प्रक्रिया का निवास मॉड्यूल है। कॉलबैक मॉड्यूल एक कार्यात्मक मॉड्यूल है।

load_module

यदि एक कार्यात्मक मॉड्यूल के लिए एक सरल विस्तार किया गया है, तो यह सिस्टम में मॉड्यूल के नए संस्करण को लोड करने और पुराने संस्करण को हटाने के लिए पर्याप्त है। इसे सरल कोड प्रतिस्थापन कहा जाता है और इसके लिए निम्न निर्देश का उपयोग किया जाता है:

{load_module, Module}

अद्यतन करें

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

  • मॉड्यूल का उपयोग करके प्रक्रियाओं को निलंबित करें (इससे बचने के लिए कि वे कोड प्रतिस्थापन पूरा होने से पहले किसी भी अनुरोध को संभालने की कोशिश करें)।
  • उनसे आंतरिक स्थिति प्रारूप को बदलने और मॉड्यूल के नए संस्करण पर स्विच करने के लिए कहें।
  • पुराना संस्करण निकालें।
  • प्रक्रियाओं को फिर से शुरू करें।

इसे सिंक्रनाइज़ कोड प्रतिस्थापन कहा जाता है और इसके लिए निम्न निर्देशों का उपयोग किया जाता है:

{update, Module, {advanced, Extra}}
{update, Module, supervisor}

तर्क के साथ update {advanced,Extra} का उपयोग किसी व्यवहार की आंतरिक स्थिति को बदलते समय किया जाता है जैसा कि ऊपर वर्णित है। यह कॉलबैक फ़ंक्शन code_change को कॉल करने के लिए व्यवहार प्रक्रियाओं का कारण बनता है, Extra शब्द और कुछ अन्य जानकारी को तर्कों के रूप में पारित करना। संबंधित व्यवहारों और Appup Cookbook लिए मैनुअल पेज देखें।

तर्क supervisor साथ update का उपयोग तब किया जाता है जब supervisor के प्रारंभ विनिर्देश को बदलते हैं। Appup Cookbook देखें।

जब एक मॉड्यूल को अपडेट किया जाना है, तो रिलीज हैंडलर को पता चलता है कि कौन सी प्रक्रियाएं हैं जो प्रत्येक चल रहे एप्लिकेशन के पर्यवेक्षण ट्री को ट्रैवर्स करके और सभी चाइल्ड विनिर्देशों की जांच करके मॉड्यूल का उपयोग कर रही हैं:

{Id, StartFunc, Restart, Shutdown, Type, Modules}

एक प्रक्रिया एक मॉड्यूल का उपयोग करती है यदि प्रक्रिया के लिए बच्चे के विनिर्देश में नाम Modules में सूचीबद्ध है।

यदि Modules=dynamic , जो इवेंट मैनेजरों के लिए मामला है, तो इवेंट मैनेजर प्रक्रिया रिलीज़ हैंडलर को वर्तमान में स्थापित ईवेंट हैंडलर ( gen_event ) की सूची के बारे में सूचित करती है, और यह जाँच की जाती है कि क्या मॉड्यूल का नाम इस सूची में है।

रिलीज़ हैंडलर निलंबित करता है, कोड परिवर्तन के लिए पूछता है, और फ़ंक्शंस को कॉल करके प्रक्रियाओं को फिर से शुरू करता है sys:suspend/1,2 , sys:change_code/4,5 , और sys:resume/1,2

add_module और delete_module

यदि एक नया मॉड्यूल पेश किया जाता है, तो निम्न निर्देश का उपयोग किया जाता है:

{add_module, Module}

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

add_module का विपरीत add_module है, जो एक मॉड्यूल को add_module है:

{delete_module, Module}

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

आवेदन निर्देश

निम्नलिखित एक आवेदन जोड़ने के लिए निर्देश है:

{add_application, Application}

किसी एप्लिकेशन को जोड़ने का मतलब है कि .app फ़ाइल में modules कुंजी द्वारा परिभाषित modules कई add_module निर्देशों का उपयोग करके लोड किए गए हैं, और फिर एप्लिकेशन शुरू किया गया है।

निम्नलिखित एक आवेदन को हटाने के लिए निर्देश है:

{remove_application, Application}

किसी एप्लिकेशन को हटाने का मतलब है कि एप्लिकेशन को रोक दिया गया है, मॉड्यूल कई delete_module निर्देशों का उपयोग करके अनलोड किया जाता है, और फिर एप्लिकेशन विनिर्देश एप्लिकेशन नियंत्रक से अनलोड किया जाता है।

निम्नलिखित एक आवेदन को फिर से शुरू करने के लिए निर्देश है:

{restart_application, Application}

किसी एप्लिकेशन को पुनरारंभ करने का अर्थ है कि एप्लिकेशन को रोक दिया गया है और फिर निर्देश remove_application और add_application को अनुक्रम में उपयोग करने के समान फिर से शुरू किया गया है।

लागू करें (निम्न-स्तर)

रिलीज हैंडलर से एक मनमाना कार्य करने के लिए, निम्न निर्देश का उपयोग किया जाता है:

{apply, {M, F, A}}

रिलीज हैंडलर के उत्थान apply(M, F, A)

पुनरारंभ_new_emulator (निम्न-स्तर)

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

इस निर्देश की आवश्यकता है कि सिस्टम को दिल की धड़कन की निगरानी के साथ शुरू किया गया है, erl(1) में erl(1) मैनुअल पेज और कर्नेल में heart(3) मैनुअल पेज देखें।

restart_new_emulator इंस्ट्रक्शन हमेशा एक रिलअप में पहला इंस्ट्रक्शन होना चाहिए। यदि रस्टअप सिस्टल्स द्वारा उत्पन्न होता है systools:make_relup/3,4 , तो यह स्वतः सुनिश्चित हो जाता है।

जब रिलीज़ हैंडलर निर्देश का सामना करता है, तो यह पहले एक अस्थायी बूट फ़ाइल बनाता है, जो एमुलेटर और कोर अनुप्रयोगों के नए संस्करणों और अन्य सभी अनुप्रयोगों के पुराने संस्करण को शुरू करता है। फिर यह init:reboot() को कॉल करके वर्तमान एमुलेटर को बंद कर देता है init:reboot() , कर्नेल में init(3) मैनुअल पेज देखें। सभी प्रक्रियाओं को इनायत से समाप्त किया जाता है और सिस्टम को अस्थायी बूट फ़ाइल का उपयोग करके, heart कार्यक्रम द्वारा रिबूट किया जाता है। रिबूट के बाद, अन्य रिलैप निर्देशों को निष्पादित किया जाता है। यह अस्थायी बूट स्क्रिप्ट के एक भाग के रूप में किया जाता है।

चेतावनी

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

नवीनीकरण पूर्ण होने पर एक सूचना रिपोर्ट लिखी जाती है। release_handler:which_releases(current) यह पता लगाने के लिए कि क्या अपग्रेड पूरा हो गया है, release_handler:which_releases(current) कॉल करें release_handler:which_releases(current) और जांचें कि क्या यह अपेक्षित रिटर्न (यानी, नया) जारी करता है।

नया एमुलेटर चालू होने पर नया रिलीज़ संस्करण स्थायी होना चाहिए। अन्यथा, एक नया सिस्टम रिबूट होने पर पुराने संस्करण का उपयोग किया जाएगा।

UNIX पर, रिलीज़ हैंडलर heart कार्यक्रम को बताता है जो सिस्टम को रिबूट करने के लिए उपयोग करता है। पर्यावरण चर HEART_COMMAND , आमतौर पर heart कार्यक्रम द्वारा उपयोग किया जाता है, इस मामले में नजरअंदाज कर दिया जाता है। इसके बजाय कमांड $ROOT/bin/start को डिफॉल्ट करता है। start_prg कॉन्फ़िगरेशन पैरामीटर start_prg का उपयोग करके एक और कमांड सेट किया जा सकता है, sasl(6) मैनुअल पेज देखें।

restart_emulator (निम्न-स्तर)

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

एक रिलैप स्क्रिप्ट में केवल एक restart_emulator निर्देश हो सकता है और इसे हमेशा अंत में रखा जाना चाहिए। यदि रस्टअप सिस्टल्स द्वारा उत्पन्न होता है systools:make_relup/3,4 , तो यह स्वतः सुनिश्चित हो जाता है।

जब रिलीज हैंडलर निर्देश का सामना करता है, तो यह एमिटर को इनिट कहकर बंद करता है init:reboot() , कर्नेल में init(3) मैनुअल पेज देखें। सभी प्रक्रियाओं को इनायत से समाप्त कर दिया जाता है और फिर सिस्टम को नए रिलीज़ संस्करण का उपयोग करके heart कार्यक्रम द्वारा रिबूट किया जा सकता है। पुनरारंभ के बाद कोई और अधिक नवीनीकरण निर्देश निष्पादित नहीं किया गया है।

11.5 आवेदन अपग्रेड फ़ाइल

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

{Vsn,
 [{UpFromVsn1, InstructionsU1},
  ...,
  {UpFromVsnK, InstructionsUK}],
 [{DownToVsn1, InstructionsD1},
  ...,
  {DownToVsnK, InstructionsDK}]}.
  • Vsn , एक स्ट्रिंग, अनुप्रयोग का वर्तमान संस्करण है, जैसा कि .app फ़ाइल में परिभाषित किया गया है।
  • प्रत्येक UpFromVsn अपग्रेड करने के लिए एप्लिकेशन का पिछला संस्करण है।
  • प्रत्येक DownToVsn को डाउनग्रेड करने के लिए एप्लिकेशन का एक पिछला संस्करण है।
  • प्रत्येक Instructions रिलीज़ हैंडलिंग निर्देशों की एक सूची है।

.appup फ़ाइल के सिंटैक्स और सामग्री के बारे में जानकारी के लिए, SASL में appup(4) मैनुअल पेज देखें।

Appup Cookbook में विशिष्ट अपग्रेड / डाउनग्रेड मामलों के लिए .appup फ़ाइलों के उदाहरण शामिल हैं।

उदाहरण: विमोचन से ch_rel-1 जारी करें। मान लें कि आप available/0 फ़ंक्शन available/0 को सर्वर ch3 जोड़ना चाहते हैं, जो उपलब्ध चैनलों की संख्या लौटाता है (उदाहरण का प्रयास करते समय, मूल निर्देशिका की एक प्रति में परिवर्तन, ताकि पहले संस्करण अभी भी उपलब्ध हों):

-module(ch3).
-behaviour(gen_server).

-export([start_link/0]).
-export([alloc/0, free/1]).
-export([available/0]).
-export([init/1, handle_call/3, handle_cast/2]).

start_link() ->
    gen_server:start_link({local, ch3}, ch3, [], []).

alloc() ->
    gen_server:call(ch3, alloc).

free(Ch) ->
    gen_server:cast(ch3, {free, Ch}).

available() ->
    gen_server:call(ch3, available).

init(_Args) ->
    {ok, channels()}.

handle_call(alloc, _From, Chs) ->
    {Ch, Chs2} = alloc(Chs),
    {reply, Ch, Chs2};
handle_call(available, _From, Chs) ->
    N = available(Chs),
    {reply, N, Chs}.

handle_cast({free, Ch}, Chs) ->
    Chs2 = free(Ch, Chs),
    {noreply, Chs2}.

ch_app.app फ़ाइल का नया संस्करण अब बनाया जाना चाहिए, जहाँ संस्करण अद्यतन किया गया है:

{application, ch_app,
 [{description, "Channel allocator"},
  {vsn, "2"},
  {modules, [ch_app, ch_sup, ch3]},
  {registered, [ch3]},
  {applications, [kernel, stdlib, sasl]},
  {mod, {ch_app,[]}}
 ]}.

ch_app को "1" से "2" अपग्रेड करने के लिए (और "2" से "1" डाउनग्रेड करने के लिए), आपको केवल ch3 कॉलबैक मॉड्यूल के नए (पुराने) संस्करण को लोड करना होगा। ebin निर्देशिका में एप्लिकेशन अपग्रेड फ़ाइल ch_app.appup बनाएं:

{"2",
 [{"1", [{load_module, ch3}]}],
 [{"1", [{load_module, ch3}]}]
}.

11.6 अपग्रेड फ़ाइल रिलीज़ करें

रिलीज के नए संस्करण और पिछले संस्करणों के बीच अपग्रेड / डाउनग्रेड करने के तरीके को परिभाषित करने के लिए, एक रिलीज अपग्रेड फ़ाइल , या शॉर्ट relup फ़ाइल में बनाया जाना है।

इस फ़ाइल को मैन्युअल रूप से बनाने की आवश्यकता नहीं है, इसे systools:make_relup/3,4 द्वारा बनाया जा सकता है systools:make_relup/3,4 .rel फ़ाइल, .app फ़ाइलों और .appup फ़ाइलों के प्रासंगिक संस्करणों को इनपुट के रूप में उपयोग किया जाता है। यह घटाया जाता है कि कौन से एप्लिकेशन जोड़े और हटाए जाने हैं, और कौन से एप्लिकेशन अपग्रेड और / या डाउनग्रेड किए जाने चाहिए। इसके लिए निर्देश .appup फ़ाइलों से प्राप्त किए जाते हैं और सही क्रम में निम्न-स्तरीय निर्देशों की एकल सूची में बदल जाते हैं।

यदि relup फ़ाइल अपेक्षाकृत सरल है, तो इसे मैन्युअल रूप से बनाया जा सकता है। यह केवल निम्न-स्तरीय निर्देशों को समाहित करता है।

रिलीज़ उन्नयन फ़ाइल के सिंटैक्स और सामग्री के बारे में विवरण के लिए, relup(4) में relup(4) मैनुअल पेज देखें।

उदाहरण, पिछले अनुभाग से जारी: आपके पास ch_app का नया संस्करण "2" और .appup फ़ाइल है। .rel फ़ाइल का एक नया संस्करण भी आवश्यक है। इस बार फ़ाइल को ch_rel-2.rel कहा जाता है और रिलीज़ संस्करण स्ट्रिंग को "A" से "B" में बदल दिया जाता है:

{release,
 {"ch_rel", "B"},
 {erts, "5.3"},
 [{kernel, "2.9"},
  {stdlib, "1.12"},
  {sasl, "1.10"},
  {ch_app, "2"}]
}.

अब relup फ़ाइल जेनरेट की जा सकती है:

1> systools:make_relup("ch_rel-2", ["ch_rel-1"], ["ch_rel-1"]).
ok

यह संस्करण "ए" ("ch_rel-1") से संस्करण "बी" ("ch_rel-2") में अपग्रेड कैसे करें और संस्करण "बी" से संस्करण "ए" में कैसे डाउनग्रेड किया जाए, इसके निर्देश के साथ एक relup फ़ाइल बनाता है।

.rel और .rel फ़ाइलों के पुराने और नए दोनों संस्करणों को कोड पथ में होना चाहिए, साथ ही .appup (नया) .beam फ़ाइलें। विकल्प path का उपयोग करके कोड पथ को बढ़ाया जा सकता है:

1> systools:make_relup("ch_rel-2", ["ch_rel-1"], ["ch_rel-1"],
[{path,["../ch_rel-1",
"../ch_rel-1/lib/ch_app-1/ebin"]}]).
ok

11.7 एक रिलीज स्थापित करना

जब आपने रिलीज़ का नया संस्करण बनाया है, तो रिलीज़ पैकेज को इस नए संस्करण के साथ बनाया जा सकता है और लक्ष्य वातावरण में स्थानांतरित किया जा सकता है।

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

यह मानते हुए कि इंस्टॉलेशन रूट डायरेक्टरी $ROOT साथ एक ऑपरेशनल टारगेट सिस्टम है, रिलीज़ के नए संस्करण के साथ रिलीज़ पैकेज को $ROOT/releases कॉपी किया जाना है।

सबसे पहले, रिलीज पैकेज को अनपैक करें। फाइलें तब पैकेज से निकाली जाती हैं:

release_handler:unpack_release(ReleaseName) => {ok, Vsn}
  • ReleaseName .tar.gz एक्सटेंशन को छोड़कर रिलीज़ पैकेज का नाम है।
  • Vsn का संस्करण है, जैसा कि इसकी .rel फ़ाइल में परिभाषित किया गया है।

एक निर्देशिका $ROOT/lib/releases/Vsn बनाई गई है, जहां .rel फ़ाइल, बूट स्क्रिप्ट start.boot , सिस्टम कॉन्फ़िगरेशन फ़ाइल sys.config और relup रखा गया है। नए संस्करण संख्याओं वाले अनुप्रयोगों के लिए, एप्लिकेशन निर्देशिकाओं को $ROOT/lib तहत रखा गया है। अपरिवर्तित अनुप्रयोग प्रभावित नहीं होते हैं।

एक अनपैक्ड रिलीज़ स्थापित किया जा सकता है । रिलीज़ हैंडलर तब relup में दिए गए निर्देशों का मूल्यांकन करता है, स्टेप बाय स्टेप:

release_handler:install_release(Vsn) => {ok, FromVsn, []}

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

डिफ़ॉल्ट संस्करण बनाने के लिए, नई स्थापित रिलीज़ को स्थायी बनाया जाना चाहिए, जिसका अर्थ है कि पिछला संस्करण पुराना हो गया है:

release_handler:make_permanent(Vsn) => ok

सिस्टम जानकारी रखता है कि कौन से संस्करण पुराने हैं और स्थायी हैं $ROOT/releases/start_erl.data और $ROOT/releases/start_erl.data

Vsn से Vsn डाउनग्रेड करने के लिए, install_release को फिर से बुलाया जाना चाहिए:

release_handler:install_release(FromVsn) => {ok, Vsn, []}

एक स्थापित, लेकिन स्थायी नहीं, रिलीज को हटाया जा सकता है । रिलीज़ के बारे में जानकारी $ROOT/releases/RELEASES से हटा दी जाती है और रिलीज़-विशिष्ट कोड, यानी नए एप्लिकेशन डायरेक्टरीज़ और $ROOT/releases/Vsn डायरेक्टरी को हटा दिया जाता है।

release_handler:remove_release(Vsn) => ok

उदाहरण (पिछले अनुभागों से जारी)

चरण 1) एक लक्ष्य प्रणाली बनाएं जैसा कि पहले संस्करण "A" के सिस्टम सिद्धांतों में वर्णित है। इस बार sys.config को रिलीज़ पैकेज में शामिल किया जाना चाहिए। यदि कोई कॉन्फ़िगरेशन की आवश्यकता नहीं है, तो फ़ाइल में खाली सूची है:

[].

चरण 2) सिस्टम को एक साधारण लक्ष्य प्रणाली के रूप में शुरू करें। वास्तव में, इसे एक एम्बेडेड सिस्टम के रूप में शुरू किया जाना है। हालाँकि, सही बूट स्क्रिप्ट और कॉन्फिग फाइल के साथ erl का उपयोग चित्रण प्रयोजनों के लिए पर्याप्त है:

% cd $ROOT
% bin/erl -boot $ROOT/releases/A/start -config $ROOT/releases/A/sys
...

$ROOT लक्ष्य प्रणाली की स्थापना निर्देशिका है।

चरण 3) एक और एर्लांग खोल में, स्क्रिप्ट शुरू करें और नए संस्करण "B" लिए एक रिलीज़ पैकेज बनाएं। (संभावित अद्यतन) sys.config और relup फ़ाइल को शामिल करना याद रखें, Release Upgrade File

1> systools:make_script("ch_rel-2").
ok
2> systools:make_tar("ch_rel-2").
ok

नए रिलीज़ पैकेज में अब ch_app का संस्करण "2" और relup फ़ाइल शामिल है:

% tar tf ch_rel-2.tar 
lib/kernel-2.9/ebin/kernel.app
lib/kernel-2.9/ebin/application.beam
...
lib/stdlib-1.12/ebin/stdlib.app
lib/stdlib-1.12/ebin/beam_lib.beam
...      
lib/sasl-1.10/ebin/sasl.app
lib/sasl-1.10/ebin/sasl.beam
...
lib/ch_app-2/ebin/ch_app.app
lib/ch_app-2/ebin/ch_app.beam
lib/ch_app-2/ebin/ch_sup.beam
lib/ch_app-2/ebin/ch3.beam
releases/B/start.boot
releases/B/relup
releases/B/sys.config
releases/B/ch_rel-2.rel
releases/ch_rel-2.rel

चरण 4) रिलीज़ पैकेज ch_rel-2.tar.gz को $ROOT/releases डायरेक्टरी में कॉपी करें।

चरण 5) चल रहे लक्ष्य प्रणाली में, रिलीज़ पैकेज को अनपैक करें:

1> release_handler:unpack_release("ch_rel-2").
{ok,"B"}

नया एप्लिकेशन संस्करण ch_app-2 ch_app-1 बगल में $ROOT/lib तहत स्थापित किया गया है। kernel , stdlib और sasl निर्देशिका प्रभावित नहीं हैं, क्योंकि वे नहीं बदले हैं।

$ROOT/releases तहत, एक नई निर्देशिका B बनाई जाती है, जिसमें ch_rel-2.rel , start.boot , sys.config और relup

चरण 6) जांचें कि क्या फ़ंक्शन ch3:available/0 उपलब्ध है:

2> ch3:available().
** exception error: undefined function ch3:available/0

चरण 7) नई रिलीज स्थापित करें। $ROOT/releases/B/relup में दिए गए निर्देशों को एक-एक करके निष्पादित किया जाता है, जिसके परिणामस्वरूप ch3 का नया संस्करण लोड हो रहा है। फ़ंक्शन ch3:available/0 अब उपलब्ध है:

3> release_handler:install_release("B").
{ok,"A",[]}
4> ch3:available().
3
5> code:which(ch3).
".../lib/ch_app-2/ebin/ch3.beam"
6> code:which(ch_sup).
".../lib/ch_app-1/ebin/ch_sup.beam"

ch_app में प्रक्रियाएँ ch_app लिए कोड अपडेट नहीं किया गया है, उदाहरण के लिए, पर्यवेक्षक, अभी भी ch_app-1 से कोड का मूल्यांकन कर रहे हैं।

चरण 8) यदि लक्ष्य प्रणाली को अब रिबूट किया गया है, तो यह फिर से "ए" संस्करण का उपयोग करता है। "बी" संस्करण को स्थायी बनाया जाना चाहिए, जब सिस्टम रिबूट किया जाता है।

7> release_handler:make_permanent("B").
ok

11.8 अद्यतन अनुप्रयोग विनिर्देश

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

ध्यान दें

रिलीज़ पैकेज में शामिल बूट स्क्रिप्ट से नए एप्लिकेशन विनिर्देशों के बारे में जानकारी प्राप्त होती है। इस प्रकार, यह महत्वपूर्ण है कि बूट स्क्रिप्ट उसी .rel फ़ाइल से उत्पन्न होती है, जिसका उपयोग रिलीज़ पैकेज बनाने के लिए किया जाता है।

विशेष रूप से, एप्लिकेशन कॉन्फ़िगरेशन पैरामीटर स्वचालित रूप से (प्राथमिकता के बढ़ते क्रम में) के अनुसार अपडेट किए जाते हैं:

  • बूट स्क्रिप्ट में डेटा, नए एप्लिकेशन संसाधन फ़ाइल App.app से प्राप्त किया गया
  • नई sys.config
  • कमांड-लाइन तर्क -App Par Val

इसका अर्थ है कि अन्य सिस्टम कॉन्फ़िगरेशन फ़ाइलों में सेट किए गए पैरामीटर मान और application:set_env/3 का उपयोग करके सेट किए गए मान application:set_env/3 हैं।

जब एक स्थापित रिलीज़ को स्थायी किया जाता है, तो सिस्टम प्रक्रिया init को नए sys.config को इंगित करने के लिए सेट किया जाता है।

स्थापना के बाद, अनुप्रयोग नियंत्रक सभी चल रहे अनुप्रयोगों के लिए पुराने और नए कॉन्फ़िगरेशन मापदंडों की तुलना करता है और कॉलबैक फ़ंक्शन को कॉल करता है:

Module:config_change(Changed, New, Removed)
  • Module .app फ़ाइल में mod कुंजी द्वारा परिभाषित अनुप्रयोग कॉलबैक मॉड्यूल है।
  • Changed और New क्रमशः, सभी परिवर्तित और जोड़े गए कॉन्फ़िगरेशन मापदंडों के लिए {Par,Val} की सूची हैं।
  • Removed सभी पैरामीटर्स की एक सूची है जिन्हें हटा दिया गया है।

फ़ंक्शन वैकल्पिक है और अनुप्रयोग कॉलबैक मॉड्यूल को लागू करते समय छोड़ा जा सकता है।