ड्रैगन को कैसे हराया जाए: गोलंग पर अपने कार्यक्रम को फिर से लिखें

ऐसा हुआ कि आपका कार्यक्रम एक पटकथा भाषा में लिखा गया था - उदाहरण के लिए, रूबी में - और इसे गोलंग में फिर से लिखने की आवश्यकता थी।

एक वाजिब सवाल: आखिरकार आपको ऐसे कार्यक्रम को फिर से लिखने की आवश्यकता क्यों है जो पहले से ही लिखा गया है और ठीक काम करता है?

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

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

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

एनबी : जैसा कि हमारे ब्लॉग के नियमित पाठकों ने अनुमान लगाया था, लेख हमारे डैप उत्पाद को फिर से लिखने के अनुभव पर आधारित है, जो अब है - अभी तक आधिकारिक तौर पर (अभी तक) आधिकारिक तौर पर वेयरफ के रूप में नहीं जाना जाता है। इसके बारे में अधिक जानकारी के लिए लेख का अंत देखें।

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

• रूबी में कार्यक्रम का वर्तमान संस्करण लगातार सुधार और सुधार की आवश्यकता है:
  
  • कीड़े तब होते हैं जब उनका उपयोग किया जाता है और उन्हें तुरंत ठीक किया जाना चाहिए;
  • आप छह महीने के लिए नई सुविधाओं को शामिल नहीं कर सकते, क्योंकि इन सुविधाओं को अक्सर ग्राहकों / उपयोगकर्ताओं द्वारा आवश्यक होता है।
• एक ही समय में 2 कोडबेस बनाए रखना मुश्किल और महंगा है:
  
  • 2-3 लोगों की कुछ टीमें हैं, जिन्हें इस रूबी कार्यक्रम के अलावा अन्य परियोजनाओं की उपस्थिति दी गई है।
• नए संस्करण का परिचय:
  
  • फ़ंक्शन में कोई महत्वपूर्ण गिरावट नहीं होनी चाहिए;
  • आदर्श रूप से, यह निर्बाध और निर्बाध होना चाहिए।

एक सतत पोर्टिंग प्रक्रिया की आवश्यकता है। लेकिन अगर गोलंग संस्करण को एक स्टैंडअलोन प्रोग्राम के रूप में विकसित किया जा रहा है तो मैं यह कैसे कर सकता हूं?

हम एक साथ दो भाषाओं में लिखते हैं

लेकिन क्या होगा यदि आप नीचे से ऊपर तक गोलांग के घटकों को स्थानांतरित करते हैं? हम निम्न-स्तरीय चीजों के साथ शुरू करते हैं, फिर सार पर जाते हैं।

कल्पना करें कि आपके कार्यक्रम में निम्नलिखित घटक शामिल हैं:

 lib/ config.rb build/ image.rb git_repo/ base.rb local.rb remote.rb docker_registry.rb builder/ base.rb shell.rb ansible.rb stage/ base.rb from.rb before_install.rb git.rb install.rb before_setup.rb setup.rb deploy/ kubernetes/ client.rb manager/ base.rb job.rb deployment.rb pod.rb 

पोर्ट घटक सुविधाओं के साथ

एक साधारण मामला। हम एक मौजूदा घटक लेते हैं जो बाकी हिस्सों से काफी अलग-थलग है - उदाहरण के लिए, config ( lib/config.rb )। इस घटक में, केवल Config::parse फ़ंक्शन को परिभाषित किया गया है, जो कि कॉन्फिगर को पथ पर ले जाता है, इसे पढ़ता है, और एक आबादी वाली संरचना का उत्पादन करता है। गोलांग config पर एक अलग बाइनरी और इसके कार्यान्वयन के लिए संबंधित पैकेज config जिम्मेदार होगा:

 cmd/ config/ main.go pkg/ config/ config.go 

गोलंग बाइनरी JSON फ़ाइल से तर्क प्राप्त करता है और परिणाम JSON फ़ाइल के लिए आउटपुट करता है।

 config -args-from-file args.json -res-to-file res.json 

यह config कि config संदेश stdout / stderr को आउटपुट कर सकता है (हमारे रूबी प्रोग्राम में, आउटपुट हमेशा stdout / stderr पर जाता है, इसलिए यह सुविधा पैरामीटर नहीं है)।

config बाइनरी को कॉल करना config घटक के कुछ फ़ंक्शन को कॉल करने के बराबर है। args.json फ़ाइल के माध्यम से तर्क फ़ंक्शन और उसके मापदंडों के नाम का संकेत देते हैं। res.json फ़ाइल के माध्यम से आउटपुट पर, res.json फ़ंक्शन का परिणाम मिलता है। यदि फ़ंक्शन को कुछ वर्ग का ऑब्जेक्ट वापस करना चाहिए, तो इस वर्ग के ऑब्जेक्ट का डेटा JSON क्रमबद्ध रूप में वापस किया जाता है।

उदाहरण के लिए, Config::parse फ़ंक्शन को कॉल करने के लिए, निम्न args.json निर्दिष्ट करें:

 { "command": "Parse", "configPath": "path-to-config.yaml" } 

हमें res.json में परिणाम res.json :

 { "config": { "Images": [{"Name": "nginx"}, {"Name": "rails"}], "From": "ubuntu:16.04" }, } 

config फ़ील्ड में, हमें JSON में क्रमबद्ध Config::Config ऑब्जेक्ट का राज्य मिलता है। इस राज्य से, रूबी में कॉलर पर, आपको एक Config::Config ऑब्जेक्ट का निर्माण करना होगा।

प्रदान की गई त्रुटि के मामले में, बाइनरी निम्नलिखित JSON को वापस कर सकती है:

 { "error": "no such file path-to-config.yaml" } 

error फ़ील्ड को कॉलर द्वारा नियंत्रित किया जाना चाहिए।

रूबी से गोलंग को बुलाना

रूबी की तरफ, हम एक रैपर में Config::parse(config_path) को चालू करते हैं, जो हमारे Config::parse(config_path) को कॉल करता है, परिणाम मिलता है, सभी संभावित त्रुटियों को प्रोसेस करता है। यहाँ सरलीकरण के साथ एक उदाहरण रूबी स्यूडोकोड है:

 module Config def parse(config_path) call_id = get_random_number args_file = "#{get_tmp_dir}/args.#{call_id}.json" res_file = "#{get_tmp_dir}/res.#{call_id}.json" args_file.write(JSON.dump( "command" => "Parse", "configPath" => config_path, )) system("config -args-from-file #{args_file} -res-to-file #{res_file}") raise "config failed with unknown error" if $?.exitstatus != 0 res = JSON.load_file(res_file) raise ParseError, res["error"] if res["error"] return Config.new_from_state(res["config"]) end end 

बाइनरी नोनज़रो के साथ दुर्घटनाग्रस्त हो सकती है, अप्रत्याशित कोड - यह एक असाधारण स्थिति है। या प्रदान किए गए कोड के साथ - इस मामले में हम error और config फ़ील्ड की उपस्थिति के लिए res.json फ़ाइल को res.json हैं और परिणामस्वरूप हम क्रमिक config फ़ील्ड से Config::Config ऑब्जेक्ट को वापस करते हैं।

उपयोगकर्ता के दृष्टिकोण से, Config::Parse फ़ंक्शन नहीं बदला है।

पोर्ट घटक वर्ग

उदाहरण के लिए, वर्ग पदानुक्रम lib/git_repo । 2 कक्षाएं हैं: GitRepo::Local और GitRepo::Remote । यह एक एकल git_repo बाइनरी में उनके कार्यान्वयन को संयोजित करने के लिए समझ में आता है और, तदनुसार, git_repo में पैकेज git_repo।

 cmd/ git_repo/ main.go pkg/ git_repo/ base.go local.go remote.go 

git_repo बाइनरी के लिए एक कॉल GitRepo::Local की कुछ विधि से मेल खाती है GitRepo::Local या GitRepo::Remote वस्तु। ऑब्जेक्ट में एक स्थिति होती है और यह एक विधि कॉल के बाद बदल सकती है। इसलिए, तर्कों में, हम वर्तमान स्थिति को JSON में क्रमबद्ध करते हैं। और आउटपुट पर, हमें हमेशा ऑब्जेक्ट की नई स्थिति मिलती है - JSON में भी।

उदाहरण के लिए, local_repo.commit_exists?(commit) विधि को कॉल करने के लिए, हम निम्नलिखित args.json निर्दिष्ट करते हैं:

 { "localGitRepo": { "name": "my_local_git_repo", "path": "path/to/git" }, "method": "IsCommitExists", "commit": "e43b1336d37478282693419e2c3f2d03a482c578" } 

आउटपुट res.json :

 { "localGitRepo": { "name": "my_local_git_repo", "path": "path/to/git" }, "result": true, } 

localGitRepo फ़ील्ड में, ऑब्जेक्ट का एक नया राज्य प्राप्त होता है (जो परिवर्तित नहीं हो सकता है)। हमें इस राज्य को वैसे भी वर्तमान रूबी-वस्तु local_git_repo में रखना चाहिए।

रूबी से गोलंग को बुलाना

रूबी की तरफ, हम GitRepo::Base की प्रत्येक विधि GitRepo::Base , GitRepo::Local , GitRepo::Remote रैपर में GitRepo::Remote जो हमारे git_repo कॉल करते हैं, परिणाम प्राप्त करते हैं, git_repo की वस्तु की नई स्थिति सेट करते हैं GitRepo::Local या GitRepo::Remote वर्ग।

अन्यथा, सब कुछ एक साधारण फ़ंक्शन को कॉल करने के समान है।

बहुरूपता और आधार वर्गों से कैसे निपटा जाए

सबसे आसान तरीका गोलंग से बहुरूपता का समर्थन नहीं करना है। यानी सुनिश्चित करें कि git_repo बाइनरी को कॉल हमेशा स्पष्ट रूप से एक विशिष्ट कार्यान्वयन के लिए संबोधित किया जाता है (यदि localGitRepo तर्कों में निर्दिष्ट किया localGitRepo , तो कॉल GitRepo::Local से आया था GitRepo::Local वर्ग ऑब्जेक्ट; यदि remoteGitRepo निर्दिष्ट किया remoteGitRepo - तो GitRepo::Remote और बॉयलरप्लेट की एक छोटी मात्रा की नकल करके प्राप्त करें) cmd में कोड। सब के बाद, वैसे भी, इस कोड को गोलंग के कदम के पूरा होते ही बाहर फेंक दिया जाएगा ।

किसी अन्य वस्तु की स्थिति को कैसे बदलना है

ऐसी परिस्थितियाँ होती हैं जब कोई ऑब्जेक्ट किसी अन्य ऑब्जेक्ट को एक पैरामीटर के रूप में प्राप्त करता है और एक ऐसी विधि कहता है जो इस दूसरी वस्तु की स्थिति को बदल देता है।

इस मामले में, आपको चाहिए:

1. जब एक द्विआधारी कहा जाता है, तो उस वस्तु की क्रमबद्ध स्थिति के अलावा, जिसे विधि कहा जाता है, सभी पैरामीटर ऑब्जेक्ट की क्रमबद्ध स्थिति को प्रसारित करें।
2. कॉल के बाद, जिस ऑब्जेक्ट को कॉल किया गया था उस ऑब्जेक्ट की स्थिति को रीसेट करें, और उन सभी ऑब्जेक्ट्स की स्थिति भी रीसेट करें जो पैरामीटर के रूप में पारित किए गए थे।

अन्यथा, सब कुछ समान है।

यह क्या है?

हम एक घटक, पोर्ट को गोलंग ले जाते हैं, एक नया संस्करण जारी करते हैं।

मामले में जब अंतर्निहित घटक पहले से ही पोर्ट किए जाते हैं और उनका उपयोग करने वाला उच्च-स्तरीय घटक स्थानांतरित किया जाता है, तो यह घटक इन अंतर्निहित लोगों को "ले" सकता है । इस स्थिति में, संबंधित अतिरिक्त बायनेरिज़ पहले ही अनावश्यक के रूप में हटाए जा सकते हैं।

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

इस राक्षस को कैसे वितरित करें?

अच्छा: अब हमारे पास धीरे-धीरे सभी घटकों को पोर्ट करने का एक तरीका है। प्रश्न: ऐसे कार्यक्रम को 2 भाषाओं में कैसे वितरित करें?

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

जब हम 2 भाषाओं में अपने कार्यक्रम की नई रिलीज़ करते हैं, तो हमें यह करना होगा:

1. एक निश्चित होस्टिंग के लिए सभी बाइनरी निर्भरताओं को इकट्ठा करें और अपलोड करें।
2. एक नया रूबी जेम वर्जन बनाएं।

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

दृष्टिकोण का नुकसान

जाहिर है, system / exec माध्यम से लगातार बाहरी कार्यक्रमों को कॉल करने का ओवरहेड exec ।

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

हमें वस्तुओं की स्थिति को गोलंग में स्थानांतरित करना और कॉल के बाद इसे सही तरीके से बहाल करना नहीं भूलना चाहिए।

गोलंग पर द्विआधारी निर्भरता बहुत अधिक स्थान लेती है । गोलंग पर एक कार्यक्रम - एक एकल 30 एमबी बाइनरी होने पर यह एक बात है। एक और बात, जब आपने ~ 10 घटकों को पोर्ट किया था, जिनमें से प्रत्येक का वजन 30 एमबी है, तो हमें प्रत्येक संस्करण के लिए 300 एमबी फाइलें मिलती हैं। इस वजह से, बाइनरी होस्टिंग और होस्ट मशीन पर जगह, जहां आपका प्रोग्राम काम करता है और लगातार अपडेट होता है, जल्दी से निकल जाता है। हालाँकि, समस्या महत्वपूर्ण नहीं है यदि आप समय-समय पर पुराने संस्करणों को हटाते हैं।

यह भी ध्यान दें कि कार्यक्रम के प्रत्येक अद्यतन के साथ द्विआधारी निर्भरता डाउनलोड करने में कुछ समय लगेगा।

दृष्टिकोण के लाभ

सभी उल्लिखित नुकसान के बावजूद, यह दृष्टिकोण आपको किसी अन्य भाषा में पोर्टिंग की एक सतत प्रक्रिया को व्यवस्थित करने और एक विकास टीम के साथ प्राप्त करने की अनुमति देता है।

सबसे महत्वपूर्ण लाभ नए कोड पर त्वरित प्रतिक्रिया प्राप्त करने, परीक्षण करने और इसे स्थिर करने की क्षमता है।

इस मामले में, आप अन्य चीजों के अलावा, अपने प्रोग्राम में नई सुविधाएँ जोड़ सकते हैं, वर्तमान संस्करण में बग्स को ठीक कर सकते हैं।

गोलंग पर अंतिम तख्तापलट कैसे करें

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

इस स्तर पर, यह केवल पुराने के साथ अपने नए सीएलआई की संगतता समस्याओं को हल करने के लिए बनी हुई है।

हुर्रे, कॉमरेड्स! क्रांति सच हो गई।

हमने गोलंग पर डैप को कैसे लिखा

Dapp एक उपयोगिता है जिसे Flant द्वारा CI / CD प्रक्रिया को व्यवस्थित करने के लिए विकसित किया गया है। यह रूबी में ऐतिहासिक कारणों से लिखा गया था:

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

लेख में वर्णित दृष्टिकोण को गोलंग पर डैप को फिर से लिखने के लिए लागू किया गया था। नीचे दिया गया ग्राफ अच्छा (गोलंग, नीला) और बुराई (रूबी, लाल) के बीच संघर्ष के कालक्रम को दर्शाता है:

रूबी बनाम भाषाओं में एक डैप / वेयरफ परियोजना में कोड की मात्रा गोलंग रिलीज के दौरान

फिलहाल, आप अल्फा संस्करण 1.0 डाउनलोड कर सकते हैं, जिसमें रूबी नहीं है। हमने भी नाम बदलकर werf कर दिया, लेकिन यह एक और कहानी है ... जल्द ही werf 1.0 के पूर्ण रिलीज की प्रतीक्षा करें!

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

पुनश्च

हमारे ब्लॉग में भी पढ़ें:

• " कुबेरनेट्स संसाधनों पर नज़र रखने के लिए कुबेदोग पुस्तकालय का परिचय। "
• "हम आधिकारिक तौर पर डैप - DevOps उपयोगिता को CI / CD बनाए रखने के लिए पेश कर रहे हैं।"
• " रुको: डैप में YAML और Ansible (कोई गाय नहीं) के लिए समर्थन ।"
• " डब और GitLab CI का उपयोग करके कुबेरनेट्स में एप्लिकेशन बनाएं और स्थापित करें ।"