Erlang 21 - 10. Releases

10 का विमोचन




erlang

10 का विमोचन

इस खंड को systools(3) में rel(4) , systools(3) और script(4) मैनुअल पेज के साथ पढ़ा जाना है।

10.1 रिलीज कॉन्सेप्ट

जब आपने एक या एक से अधिक अनुप्रयोग लिखे हैं, तो आप इन अनुप्रयोगों और Erlang / TTP अनुप्रयोगों के एक सबसेट के साथ एक पूर्ण प्रणाली बनाना चाह सकते हैं। इसे रिलीज कहा जाता है।

ऐसा करने के लिए, एक release resource file जो परिभाषित करती है कि कौन से अनुप्रयोग रिलीज़ में शामिल हैं।

रिलीज़ संसाधन फ़ाइल का उपयोग boot scripts और release packages बनाने के लिए किया जाता release packages । एक प्रणाली जिसे किसी अन्य साइट पर स्थानांतरित और स्थापित किया जाता है उसे लक्ष्य प्रणाली कहा जाता है । किसी लक्ष्य प्रणाली को बनाने के लिए रिलीज़ पैकेज का उपयोग कैसे करें, यह सिस्टम सिद्धांतों में वर्णित है।

10.2 रिलीज़ संसाधन फ़ाइल

रिलीज़ को परिभाषित करने के लिए, रिलीज़ संसाधन फ़ाइल बनाएँ , या संक्षेप में .rel फ़ाइल। फ़ाइल में, रिलीज़ का नाम और संस्करण निर्दिष्ट करें, यह किस ईआरटीएस संस्करण पर आधारित है, और इसमें कौन से अनुप्रयोग शामिल हैं:

{release, {Name,Vsn}, {erts, EVsn},
 [{Application1, AppVsn1},
   ...
  {ApplicationN, AppVsnN}]}.

Name , Vsn , EVsn , और AppVsn तार हैं।

फ़ाइल का नाम Rel.rel होना चाहिए, जहाँ Rel एक अद्वितीय नाम है।

प्रत्येक Application (परमाणु) और AppVsn रिलीज में शामिल एक एप्लिकेशन का नाम और संस्करण है। Erlang / OTP पर आधारित न्यूनतम रिलीज़ में कर्नेल और STDLIB अनुप्रयोग होते हैं, इसलिए इन अनुप्रयोगों को सूची में शामिल किया जाना चाहिए।

यदि रिलीज़ को अपग्रेड किया जाना है, तो इसमें एसएएसएल एप्लिकेशन भी शामिल होना चाहिए।

उदाहरण: ch_app से ch_app रिलीज़ में निम्नलिखित .app फ़ाइल है:

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

.rel फ़ाइल में kernel , stdlib और sasl भी होना चाहिए, क्योंकि ये अनुप्रयोग ch_app द्वारा आवश्यक हैं। फ़ाइल को ch_rel-1.rel कहा जाता है:

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

10.3 बूट लिपियों का निर्माण

systools में systools में रिलीज को बनाने और जांचने के उपकरण शामिल हैं। फ़ंक्शंस पढ़ने और .app फ़ाइलों को पढ़ने और वाक्यविन्यास और निर्भरता जाँच करता है। systools:make_script/1,2 फ़ंक्शन का उपयोग बूट स्क्रिप्ट उत्पन्न करने के लिए किया जाता है (सिस्टम सिद्धांत देखें):

1> systools:make_script("ch_rel-1", [local]).
ok

यह बूट स्क्रिप्ट बनाता है, दोनों पठनीय संस्करण, ch_rel-1.script , और बाइनरी संस्करण, ch_rel-1.boot , रनटाइम सिस्टम द्वारा उपयोग किया जाता है।

  • "ch_rel-1" .rel फ़ाइल का नाम है, विस्तार को .rel
  • local एक विकल्प है जिसका अर्थ है कि निर्देशिकाएं जहां एप्लिकेशन पाई जाती हैं, उनका उपयोग बूट स्क्रिप्ट में किया जाता है, बजाय $ROOT/lib ( $ROOT इंस्टॉल किए गए रिलीज़ की रूट निर्देशिका है)।

स्थानीय स्तर पर जनरेट बूट स्क्रिप्ट का परीक्षण करने के लिए यह एक उपयोगी तरीका है।

जब बूट स्क्रिप्ट का उपयोग करके .rel / ओटीपी शुरू किया जाता है, .rel फ़ाइल से सभी एप्लिकेशन स्वचालित रूप से लोड हो जाते हैं और शुरू होते हैं:

% erl -boot ch_rel-1
Erlang (BEAM) emulator version 5.3

Eshell V5.3  (abort with ^G)
1> 
=PROGRESS REPORT==== 13-Jun-2003::12:01:15 ===
          supervisor: {local,sasl_safe_sup}
             started: [{pid,<0.33.0>},
                       {name,alarm_handler},
                       {mfa,{alarm_handler,start_link,[]}},
                       {restart_type,permanent},
                       {shutdown,2000},
                       {child_type,worker}]

...

=PROGRESS REPORT==== 13-Jun-2003::12:01:15 ===
         application: sasl
          started_at: [email protected]

...
=PROGRESS REPORT==== 13-Jun-2003::12:01:15 ===
         application: ch_app
          started_at: [email protected]

10.4 रिलीज़ पैकेज बनाना

systools:make_tar/1,2 फ़ंक्शन इनपुट के रूप में एक .rel फ़ाइल लेता है और निर्दिष्ट अनुप्रयोगों के लिए कोड के साथ ज़िपित टार फ़ाइल बनाता है, एक रिलीज़ पैकेज :

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

डिफ़ॉल्ट रूप से रिलीज़ पैकेज में शामिल हैं:

  • .app फ़ाइलें
  • .rel फ़ाइल
  • सभी अनुप्रयोगों के लिए ऑब्जेक्ट कोड, application directory structure अनुसार application directory structure
  • बाइनरी बूट स्क्रिप्ट का नाम बदलकर start.boot
% tar tf ch_rel-1.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-1/ebin/ch_app.app
lib/ch_app-1/ebin/ch_app.beam
lib/ch_app-1/ebin/ch_sup.beam
lib/ch_app-1/ebin/ch3.beam
releases/A/start.boot
releases/A/ch_rel-1.rel
releases/ch_rel-1.rel

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

रिलीज़ संसाधन फ़ाइल mysystem.rel को टार फ़ाइल में डुप्लिकेट किया गया है। मूल रूप से, यह फ़ाइल केवल releases निर्देशिका में संग्रहीत की गई थी ताकि release_handler लिए यह फ़ाइल अलग से निकालना संभव हो सके। टार फ़ाइल को अनपैक करने के बाद, release_handler स्वचालित रूप से फ़ाइल को releases/FIRST कॉपी कर देगा। हालाँकि, कभी-कभी टार्क फ़ाइल बिना release_handler (उदाहरण के लिए, जब पहला टार्गेट सिस्टम अनपैक करते समय) को शामिल किए बिना अनपैक कर दिया जाता है और इसलिए फ़ाइल को अब टार फ़ाइल में डुप्लिकेट किया जाता है, इसलिए कोई मैन्युअल प्रतिलिपि आवश्यक नहीं है।

यदि कोई relup फ़ाइल और / या sys.config , या sys.config नामक सिस्टम कॉन्फ़िगरेशन फ़ाइल पाई जाती है, तो ये फ़ाइलें रिलीज़ पैकेज में भी शामिल होती हैं। Release Handling देखें।

रिलीज़ पैकेज बनाने के लिए विकल्प सेट किए जा सकते हैं जिसमें स्रोत कोड और ERTS बाइनरी भी शामिल हैं।

रिलीज़ पैकेज का उपयोग करके पहले लक्ष्य प्रणाली को कैसे स्थापित किया जाए, इसकी जानकारी के लिए, सिस्टम सिद्धांत देखें। मौजूदा सिस्टम में नया रिलीज़ पैकेज कैसे स्थापित करें, इसकी जानकारी के लिए, Release Handling देखें।

10.5 निर्देशिका संरचना

रिलीज़ पैकेज से रिलीज़ हैंडलर द्वारा स्थापित कोड के लिए निर्देशिका संरचना निम्नानुसार है:

$ROOT/lib/App1-AVsn1/ebin
                    /priv
         /App2-AVsn2/ebin
                    /priv
         ...
         /AppN-AVsnN/ebin
                    /priv
     /erts-EVsn/bin
     /releases/Vsn
     /bin
  • lib - अनुप्रयोग निर्देशिकाएं
  • erts-EVsn/bin - erts-EVsn/bin रनटाइम सिस्टम एक्जीक्यूटिव
  • releases/Vsn - .rel फ़ाइल और बूट स्क्रिप्ट start.boot ; यदि रिलीज़ पैकेज में मौजूद है, तो relup और / या sys.config या sys.config.src
  • bin - शीर्ष-स्तर एर्लांग रनटाइम सिस्टम निष्पादनयोग्य

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

$SECOND_ROOT/.../SApp1-SAVsn1/ebin
                             /priv
                /SApp2-SAVsn2/ebin
                             /priv
                ...
                /SAppN-SAVsnN/ebin
                             /priv

$THIRD_ROOT/TApp1-TAVsn1/ebin
                        /priv
           /TApp2-TAVsn2/ebin
                        /priv
           ...
           /TAppN-TAVsnN/ebin
                        /priv

$SECOND_ROOT और $THIRD_ROOT को systools:make_script/2 फ़ंक्शन के लिए कॉल में variables रूप में पेश किया जाता है।

डिस्क-कम और / या केवल-पढ़ने के लिए ग्राहक

यदि एक पूर्ण सिस्टम में डिस्क-कम और / या केवल-पढ़ने वाले ग्राहक नोड होते हैं, तो clients निर्देशिका को $ROOT निर्देशिका में जोड़ा जाना है। रीड-ओनली नोड, रीड-ओनली फाइल सिस्टम वाला नोड है।

clients निर्देशिका को प्रति समर्थित क्लाइंट नोड में एक उपनिर्देशिका है। प्रत्येक क्लाइंट डायरेक्टरी का नाम संबंधित क्लाइंट नोड का नाम है। न्यूनतम के रूप में, प्रत्येक क्लाइंट निर्देशिका में bin को शामिल करना और उपनिर्देशिका releases । इन निर्देशिकाओं का उपयोग इंस्टॉल किए गए रिलीज़ के बारे में जानकारी संग्रहीत करने और क्लाइंट को वर्तमान रिलीज़ को नियुक्त करने के लिए किया जाता है। $ROOT निर्देशिका में निम्नलिखित शामिल हैं:

$ROOT/...
    /clients/ClientName1/bin
                        /releases/Vsn
            /ClientName2/bin
                        /releases/Vsn
            ...
            /ClientNameN/bin
                        /releases/Vsn

यदि सभी क्लाइंट एक ही प्रकार की एर्लांग मशीन चला रहे हों तो इस संरचना का उपयोग किया जाना है। यदि ग्राहक विभिन्न प्रकार की Erlang मशीनें चला रहे हैं, या विभिन्न ऑपरेटिंग सिस्टम पर, clients निर्देशिका को एक उपनिर्देशिका प्रति Erlang मशीन में विभाजित किया जा सकता है। वैकल्पिक रूप से, प्रति मशीन एक $ROOT स्थापित किया जा सकता है। प्रत्येक प्रकार के लिए, $ROOT निर्देशिका के लिए निर्दिष्ट कुछ निर्देशिकाओं को शामिल किया जाना है:

$ROOT/...
    /clients/Type1/lib
                  /erts-EVsn
                  /bin
                  /ClientName1/bin
                              /releases/Vsn
                  /ClientName2/bin
                              /releases/Vsn
                  ...
                  /ClientNameN/bin
                              /releases/Vsn
            ...
            /TypeN/lib
                  /erts-EVsn
                  /bin
                  ...

इस संरचना के साथ, Type1 क्लाइंट के लिए रूट डायरेक्टरी $ROOT/clients/Type1