Rebar और GProc का उपयोग करना

रेबार का उपयोग करना

इस ट्यूटोरियल में पुरानी जानकारी हो सकती है, क्योंकि पिछले संस्करणों के साथ संगतता बनाए बिना रेबार बहुत सक्रिय रूप से विकसित हो रहा है।



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



आप रेगर को hg.basho.com/rebar/downloads/rebar पर डाउनलोड कर सकते हैं। यह एक एकल फ़ाइल है जिसमें कई बीम-मॉड्यूल हैं। इसे किसी भी सुविधाजनक स्थान पर रखा जाना चाहिए जो PATH निष्पादनयोग्य के लिए खोज पथ में प्रवेश करता है, उदाहरण के लिए, ~/bin/



or /usr/local/bin/



।

चलिए प्रोजेक्ट के लिए नीचे आते हैं।

सबसे पहले, एक निर्देशिका बनाएं जिसमें हमारी परियोजना स्थित होगी ( gpt



) और उस पर जाएं:

 $ mkdir gpt && cd gpt

इसमें, एक उपनिर्देशिका बनाएं जहां हम अपने एप्लिकेशन के स्रोत फ़ाइलों को सीधे सहेजेंगे:

 $ mkdir -p apps / gpt && cd apps / gpt

आवेदन कंकाल बनाना:

 $ rebar बनाने-ऐप appid = gpt

एपिड पैरामीटर हमारे एप्लिकेशन के नाम को परिभाषित करता है और, तदनुसार, स्रोत फ़ाइलों का उपसर्ग।

 $ ls -1 src
 gpt_app.erl
 gpt.app.src
 gpt_sup.erl

.App फ़ाइल ( src/gpt.app.src



) के लिए रिक्त करने के लिए gproc पर एप्लिकेशन विवरण और निर्भरता जोड़ें:

   {विवरण, "GProc ट्यूटोरियल"},
   ...
   {अनुप्रयोग,
    [
     गिरी,
     stdlib,
     gproc% <--- अनुप्रयोग gproc पर निर्भर करता है
    ]}
   ...

शीर्ष-स्तर निर्देशिका पर वापस जाएं जहां हमारी परियोजना संग्रहीत है, इसमें rel



subdirectory बनाएँ और वहां जाएं:

 $ cd ../../
 $ mkdir rel && cd rel

Rel में रिलीज़ बनाने के लिए आवश्यक फ़ाइलें होंगी - जो कि प्रोजेक्ट को चलाने के लिए आवश्यक है, इसके सभी रनटाइम निर्भरताएँ।

rebar



का उपयोग करते हुए rebar



नोड पैरामीटर में अपना नाम पास करके नोड के लिए एक रिक्त बनाएं:

 $ rebar create-node नोडिड = gptnode

reltool.config



फ़ाइल का संपादन:

   ...
   {lib_dirs, ["../deps", "../apps"atalogatalog,% <--- इन निर्देशिकाओं में, reltool भी हमारे आवेदन में निर्भरता की तलाश करेगा
   {rel, "gptnode", "1",
    [
     गिरी,
     stdlib,
     SASL,
     gproc,% <--- gproc अनुप्रयोग
     gpt% <--- हमारा आवेदन
    ]}
   ...

अगला, आप files/vm.args



को संपादित कर सकते हैं, बदल सकते हैं, कह सकते हैं, नोड का नाम:

 -नाम gptnode@127.0.0.1

पर

 -sname gptnode @ localhost

आइए शीर्ष स्तर की निर्देशिका पर वापस जाएं:

 $ cd ../

और निम्नलिखित सामग्री के साथ एक rebar.config



फ़ाइल बनाएँ:

 %% डिपेंडेंसी यहाँ पड़ेगी
 {deps_dir, ["deps"]}।

 %% उपनिर्देशिकाएँ जिसमें rebar दिखना चाहिए
 {उप_डिर्स, ["rel", "ऐप्स / gpt"]}।

 %% संकलक विकल्प
 {erl_opts, [debug_info, fail_on_warning]}।

 %% निर्भरता सूची
 %% संबंधित गिट रिपॉजिटरी की मास्टर ब्रांच को gproc डायरेक्टरी में क्लोन किया जाएगा।
 {Deps,
  [
   {gproc, "। *", {git, "http://github.com/esl/gproc.git", "मास्टर"}}
  ]}।

अब हम एक रिलीज बनाने के लिए तैयार हैं। चलो कुछ rebar



कमांड निष्पादित करते हैं (कमांड आउटपुट छोड़ा गया है):

 $ रिबर गेट-डिप्स
 $ रिबर संकलन
 $ rebar उत्पन्न

get-deps



कमांड निर्भरताओं को डाउनलोड करता है। हमारे मामले में, यह gproc एप्लिकेशन है। compile



आदेश स्पष्ट रूप से सभी स्रोत फ़ाइलों को संकलित करता है, और एक रिलीज़ बनाता है।

rel/gptnode



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

 (cd rel / gptnode && sh bin / gptnode कंसोल)

सुनिश्चित करें कि सभी आवश्यक एप्लिकेशन चल रहे हैं:

 (gptnode @ localhost) 1> आवेदन: who_applications ()।
 [{sasl, "SASL CXC 138 11", "2.1.9.2"},
  {gpt, "GProc ट्यूटोरियल", "1"},
  {gproc, "GPROC", "0.01"},
  {stdlib, "ERTS CXC 138 10", "1.17.2"},
  {कर्नेल, "ERTS CXC 138 10", "2.14.2"}]

हम gpt और gproc में रुचि रखते हैं। जैसा कि आप देख सकते हैं, वे इस सूची में हैं।

Gproc का उपयोग करना

इसलिए, हमने इसे rebar



साथ लगा लिया, सीखा कि कैसे एक साधारण प्रोजेक्ट बनाया जाए और उसके साथ काम किया जाए। चलो gproc के लिए नीचे उतरो।

जैसा कि आप जानते हैं, इरलांग में, एक नियम के रूप में, संदेशों का आदान-प्रदान करने वाली कई प्रक्रियाओं से मिलकर बनता है।

किसी संदेश को किसके पास भेजा जाए, यह जानने के लिए प्रक्रियाओं के लिए एक रजिस्ट्रार का होना आवश्यक है जो कुछ निर्देशकों को प्रक्रिया अन्वेषक में परिवर्तित करता है। डिफ़ॉल्ट रूप से, Erlang / OTP परमाणु नाम के तहत प्रक्रिया पंजीकरण प्रदान करता है। यह बेकार है, क्योंकि कचरा संग्रहकर्ता द्वारा परमाणुओं को एकत्र नहीं किया जाता है, और, एक बार बनाए जाने के बाद, वे पूरे नोड के संचालन के पूरा होने तक रहते हैं, जो आवश्यक रूप से सभी मेमोरी की थकावट को जन्म देगा, यदि आवश्यक हो, तो अद्वितीय नामों के तहत प्रक्रियाओं को पंजीकृत करें। इसके अलावा, ऐसा दृष्टिकोण असुविधाजनक है, क्योंकि किसी को अलग-अलग शब्दों को एक परमाणु में बदलना होगा, इसके लिए कुछ नियमों की रचना करनी होगी, इसके अलावा, एक प्रक्रिया को केवल एक नाम के तहत पंजीकृत किया जा सकता है। erlang:register/2



का उपयोग करके परमाणु नाम के तहत प्रक्रियाओं को erlang:register/2



फ़ंक्शन केवल लंबे समय तक रहने वाली प्रक्रियाओं की एक छोटी संख्या के लिए मान्य है जिनके नाम में परिवर्तन नहीं होना चाहिए, एनालॉग अनिवार्य प्रोग्रामिंग भाषाओं में वैश्विक चर है।

इन प्रतिबंधों को दरकिनार करने के लिए, निम्नलिखित योजना का उपयोग अक्सर किया जाता है:

1. रजिस्ट्रार प्रक्रिया शुरू की गई है, जिससे ईटीएस टेबल बनाई जा रही है और इसके मालिक हैं;
2. जब पंजीकृत होने वाली प्रक्रियाओं को शुरू करना होता है, तो वे रजिस्ट्रार को एक संदेश भेजते हैं जिसमें पंजीकरण के लिए निर्देशांक (कोई इरलांग अवधि) और उनके पहचानकर्ता होते हैं;
3. रजिस्ट्रार इस मैपिंग को ईटीएस टेबल पर लिखता है और erlang:monitor/2
   
   
   
   साथ प्रक्रिया की निगरानी करने में सक्षम बनाता है erlang:monitor/2
   
   
   
   ;
4. पंजीकृत प्रक्रिया, पूरा होने पर, या तो स्पष्ट रूप से अपने डेरेगग्रेशन के बारे में एक संदेश भेजता है, या रजिस्ट्रार को एक 'DOWN'
   
   
   
   संदेश प्राप्त होता है, जब यह प्रक्रिया क्रैश हो जाती है, जिसके बाद वह अपना रिकॉर्ड ets टेबल से हटा देता है;

यह योजना बहुत बार उपयोग की जाती है, लगभग हर एप्लिकेशन का अपना कार्यान्वयन होता है, अपनी विशेषताओं और बग के साथ। बेशक, कि इस रजिस्ट्रार को किसी अनोखी चीज़ से बदलने की स्वाभाविक इच्छा है। और समस्या का हल डेवलपर उल्फ विगर और उनके gproc एप्लिकेशन (https://github.com/esl/gproc) के रूप में आया।

आवेदन एपीआई github.com/esl/gproc/blob/master/doc/gproc.md पर पाया जा सकता है।

स्थानीय पंजीकरण

एक सरल अवधि में एक प्रक्रिया के स्थानीय (वर्तमान नोड पर) पंजीकरण पर विचार करें।

उदाहरण के लिए स्रोत कोड यहां लिया जा सकता है: github.com/Zert/gproc-tutorial.git

प्रक्रियाओं के लिए कोड जिसे हम gproc के माध्यम से पंजीकृत करेंगे gpt_proc.erl



फ़ाइल में है। gpt_sup.erl



में इस प्रक्रिया समूह के लिए पर्यवेक्षक कोड होता है। जब gpt_sup:start_worker/1



फ़ंक्शन को कॉल किया जाता है, तो हमारी प्रक्रिया उस नाम के तहत शुरू और पंजीकृत होगी जो फ़ंक्शन को केवल तर्क के रूप में पारित किया जाता है। इस मामले में, यह एक संख्या है।

हमने उपरोक्त कमांड का उपयोग करके नोड शुरू किया है और इसमें विभिन्न पहचानकर्ताओं के साथ लॉन्च की गई श्रृंखला की एक श्रृंखला का प्रदर्शन किया है:

 (gptnode @ localhost) 1> [gpt_sup: start_worker (Id) ||  Id <- सूचियाँ: seq (1,3)]।
 (gpt_proc: 29) प्रक्रिया प्रारंभ करें: 1
 (gpt_proc: 29) प्रक्रिया प्रारंभ करें: 2
 (gpt_proc: 29) प्रक्रिया प्रारंभ करें: 3
 [{ठीक है, <0.61.0>}, {ठीक है, <0.62.0>}, {ठीक है, <0.63.0>}]

gproc:add_local_name(Name)



फ़ंक्शन के लिए एक कॉल gproc:add_local_name(Name)



तहत कॉल करने की प्रक्रिया को पंजीकृत करता है Name



(यह फ़ंक्शन gproc:reg({n,l,Name})



पर सिर्फ एक आवरण है gproc:reg({n,l,Name})



, जहां n



name



, l



local



)। उसके बाद, gproc:lookup_local_name(Name)



फ़ंक्शन प्रक्रिया पहचानकर्ता को वापस कर देगा।

अब एक प्रक्रिया बताएं कि नाम के साथ प्रक्रिया शुरू करने और पंजीकरण करने की प्रतीक्षा करना शुरू करें। इसके लिए जिम्मेदार कोड है:

 handle_info ({प्रतीक्षा, आईडी},
             #स्टेट {आईडी = MyId} = राज्य) ->
     gproc: प्रतीक्षा करें ({n, l, Id}),
     ? DBG ("MyId: ~ p। ~ NNewId: ~ p।", [MyId, Id],)
     {noreply, State};

यहाँ gproc:await/1



फ़ंक्शन को निम्न रूप के तर्क के साथ कहा जाता है: {n, l, Id}



। किसी कारण के लिए, यह एक आवरण नहीं है, लेकिन ओह अच्छी तरह से।

 (gptnode @ localhost) 2> gproc: looking_local_name (1)!  {प्रतीक्षा, ४}।
 {प्रतीक्षा, ४}

पहचानकर्ता 4 के साथ प्रक्रिया शुरू करना, हम पहले इसे एक संदेश देखेंगे, और फिर पहली प्रतीक्षा प्रक्रिया से:

 (gptnode @ localhost) 3> gpt_sup: start_worker (4)।
 (gpt_proc: 29) प्रक्रिया प्रारंभ करें: 4
 (gpt_proc: 45) MyId: 1।
 न्यूआईड: 4
 {ठीक है, <0.66.0>}

चलो stop



संदेश प्राप्त करने की प्रक्रिया को stop



:

 handle_info (स्टॉप, स्टेट) ->
     {रोक, सामान्य, राज्य};

और इसे रोकें:

 (gptnode @ localhost) 4> gproc: looking_local_name (1)!  बंद करो।
 बंद

उसके बाद, प्रक्रिया स्वचालित रूप से रजिस्ट्रार डेटाबेस से हटा दी जाती है:

 (gptnode @ localhost) 5> gproc: looking_local_name (1)।
 अपरिभाषित

वैश्विक पंजीकरण

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

क्लस्टर में किसी भी नोड के लिए अपनी प्रक्रियाओं को पंजीकृत करने में सक्षम होने के लिए ताकि वे अन्य नोड्स से सुलभ हों, एक वैश्विक पंजीकरण होता है। GProc एक कॉल को gproc पर लागू करता है gproc:add_global_name/1



, जो इस क्रिया को करने की अनुमति देता है। एक उदाहरण पर विचार करें।

सबसे पहले, हम एक क्लस्टर में संयुक्त दो नोड्स का निर्माण करेंगे, और rebar



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

• नोड्स के लिए समान कुकी मान सेट करें
• उन्हें अलग-अलग नाम दें।
• प्रत्येक नोड पर आवश्यक kernel
  
  
  
  अनुप्रयोग के लिए उपयुक्त पैरामीटर पास करें
• GProc का उपयोग करते समय, वांछित नोड रोल्स को पास करें।

पहले दो आइटम files/vm.args



में सेट किए गए हैं:

 ## नोड का नाम
 -sname {{नोड}}

 ## वितरित इलंग के लिए कुकी
 -सेटकी सूक्ति

यहां {{node}}



प्लेसहोल्डर है जो रिलीज होने पर पॉप्युलेट हो जाएगा। -setcookie



वर्चुअल मशीन -setcookie



इस नोड के लिए कुकी मान सेट करता है; क्लस्टर में सभी नोड्स में समान मान होना चाहिए।

दूसरे दो बिंदु files/app.config



में सेट किए गए हैं। प्लेसहोल्डर्स का उपयोग यहां भी किया जाएगा:

  %% जीपोक
  {gproc, {{gproc_params}}},

 %% कर्नेल
  {कर्नेल, {{कर्नेल_परम्स}}},

प्लेसहोल्डर्स को भरने के लिए, हम reltool.config



फ़ाइल में इंगित करते हैं कि पिछली दो फ़ाइलों को टेम्प्लेट के रूप में संसाधित किया जाना चाहिए:

   {टेम्पलेट, "फाइलें / app.config", "etc / app.config"},
   {टेम्पलेट, "फाइलें / vm.args", "etc / vm.args"}

हम दो कॉन्फ़िगरेशन फ़ाइल बनाते हैं, प्रत्येक नोड के लिए: vars/dev1_vars.config



और vars/dev2_vars.config



। निम्नलिखित प्लेसहोल्डर मान dev1_vars.config फ़ाइल में होंगे:

 %% आदि / app.config
 {Gproc_params,
 "[
   {gproc_dist, {['gpt1 @ localhost'],
                 [{कार्यकर्ता, ['gpt2 @ localhost']}]}}
  ] ”}।

 {Kernel_params,
 "[
   {Sync_nodes_mandatory, ['gpt2 @ localhost']},
   {Sync_nodes_time, 15000}
  ] ”}।

 %% आदि / vm.args
 {नोड, "gpt1 @ localhost"}।

dev2_vars.config



फ़ाइल के लिए dev2_vars.config



sync_nodes_mandatory



और node



पैरामीटर स्वैप किए जाएंगे। आइए उनका अधिक विस्तार से विश्लेषण करें।

gproc_dist



पैरामीटर gproc एप्लिकेशन को संदर्भित करता है; यह दो सूचियों का एक समूह है। पहली सूची में नोड्स होते हैं जो एक लीडर (मास्टर) बनने में सक्षम होते हैं, दूसरी सूची में कुंजी-मूल्य ट्यूपल्स होते हैं, अब तक हमें केवल एक कुंजी की आवश्यकता होती है - workers



, जो नोड्स की एक सूची सेट करते हैं जो क्लस्टर (दास) के सरल सदस्य हैं।

कर्नेल अनुप्रयोग के दो पैरामीटर हैं। पहला, sync_nodes_mandatory



नोड्स की एक सूची है जो क्लस्टर में मौजूद होना चाहिए। दूसरा, sync_nodes_timeout



/ sync_nodes_timeout



मिलीसेकंड में समय है कि प्रत्येक नोड पिछली सूची से नोड्स के आने की प्रतीक्षा करेगा। यदि इस समय के दौरान नोड्स प्रकट नहीं हुए, तो नोड बंद हो जाएगा। चलो इसे दोनों हाथों से शुरू करने के लिए समय के लिए 15 सेकंड का मूल्य दें।

node



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

अब Makefile से निम्न नियम का उपयोग करके दो रिलीज़ बनाएँ:

 देव १ देव २:
     mkdir -p देव
     (cd rel && rebar उत्पन्न target_dir = .. / dev / $ @ overlay_vars=vars/$@_vars.config)

dev/dev1



, दूसरी टर्मिनल विंडो लॉन्च करें (या स्क्रीन में एक नई विंडो बनाएं ),



dev / dev2 निर्देशिका पर जाएं .



.



।/bin/gptnode कंसोल '। आइए पहले एरलैंग शेल में उपलब्ध नोड्स की सूची देखें:

 (gpt1 @ localhost) 1> नोड्स ()।
 [gpt2 @ localhost]

हम देखते हैं कि दूसरा नोड सामान्य रूप से शुरू हुआ और क्लस्टर से जुड़ा। लंबे समय तक बुद्धिमान न होने के लिए, हम कुछ शब्द के तहत विश्व स्तर पर वर्तमान शेल की प्रक्रिया को पंजीकृत करेंगे:

 (gpt1 @ localhost) 2> gproc: add_global_name ({शेल, 1})।
 सच

किसी अन्य विंडो में, इस शब्द के लिए प्रक्रिया पहचानकर्ता से अनुरोध करने का प्रयास करें:

 (gpt2 @ localhost) 2> gproc: लुकअप_ग्लोबल_नाम ({शेल, 1})।
 <3358.70.0>

जैसा कि आप देख सकते हैं, सफलतापूर्वक। इस प्रक्रिया को एक संदेश भेजकर, हम इसे पहले नोड पर प्राप्त कर सकते हैं:

 (gpt2 @ localhost) 3> gproc: लुकअप_ग्लोबल_नाम ({शेल, 1})!  {संदेश,}।
 संदेश

हम इसे flush()



कमांड के साथ पहले नोड पर पढ़ते हैं:

 (gpt1 @ localhost) 3> फ्लश ()।
 शेल को {संदेश, संदेश} मिला
 ठीक

निष्कर्ष

वह सब है। मैंने अपने लिए एक लेख लिखना शुरू किया, क्योंकि rebar पर प्रलेखन बहुत दुर्लभ है और अगले उपयोग के बाद लगातार भुला दिया जाता है। रास्ते के साथ, मैंने gproc का उपयोग करना शुरू कर दिया, और दो बार नहीं उठने के लिए, मैंने एक लेख में सब कुछ रखा।