लगभग एक महीने पहले, मेरे पास एक विकल्प था: कठपुतली के लिए मॉड्यूल "टेबल पर लिखना" (यानी आंतरिक बुनियादी ढांचे के लिए) या इसे सार्वभौमिक बनाने के लिए, स्रोत को खोलें और इसे कठपुतली फोर्ज पर प्रकाशित करें। बेशक, यह जल्दी और आसानी से अपने लिए 2-3 ग्रेड स्केच करना और शांत करना आसान होगा, लेकिन मॉड्यूल के प्रकाशन के दौरान प्राप्त अनुभव मूल्यवान है और मैं इसे साझा करना चाहता हूं। RuNet में, कठपुतली विकास किट (इसके बाद पीडीके ) के उपयोग के बारे में कोई जानकारी नहीं है, इसलिए आप इसे एक तरह का ट्यूटोरियल मान सकते हैं।

लेख किस बारे में है

एक मॉड्यूल (या बल्कि, दो) के विकास की प्रक्रिया में, मैंने पीडीके की खोज की, जो मॉड्यूल के विकास और रखरखाव दोनों को बहुत सुविधाजनक बनाता है। अर्थात्:

• अंतिम अद्यतन करते समय स्वचालित रूप से metadata.json प्रारूपित करें
• विभिन्न CI सिस्टम के लिए विन्यास पीढ़ी जो निम्न कार्य कर सकती है:
  
  • माणिक कोड के साथ रूबी कोड की जाँच करना
  • रनिंग यूनिट टेस्ट
  • कुछ शर्तों के तहत - कठपुतली फोर्ज काम करने वाले कोड का स्वत: भरना
• यार्ड का उपयोग करते हुए टिप्पणियों में टैग-आधारित प्रलेखन उत्पन्न करना
• कठपुतली फोर्ज पर मॉड्यूल के लिए प्लेट [PDK] । एक तिपहिया, लेकिन अच्छा है!

सभी रुचि रखते हैं मैं एक बिल्ली के लिए पूछना!

उदाहरण के रूप में

यदि आप पढ़ना प्रक्रिया के दौरान क्या देखना और महसूस करना चाहते हैं, तो आप दो (या दोनों) उल्लेखित मॉड्यूलों में से एक को खोल सकते हैं: क्लिकहाउस और xmlsimple । दोनों लेख में वर्णित पीडीके और अन्य उपकरणों का उपयोग करके विकसित किए गए थे।

सामग्री

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

पीडीके क्या है

आधिकारिक दस्तावेज से:

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

मेरे मुफ्त अनुवाद में:

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

अच्छा लगता है? खैर, यह वास्तव में कैसा है। उस समय तक जब मैंने मॉड्यूल पर काम शुरू किया था, जिसे खुले स्रोत के लिए तुरंत लिखने का निर्णय लिया गया था, मुझे इस उपकरण पर संदेह नहीं था, और अब मैं पीडीके का उपयोग करने के लिए पूरे आंतरिक बुनियादी ढांचे को स्थानांतरित करने का इरादा रखता हूं।

मैं इसका वर्णन करूंगा कि इसे कैसे रखा जाए, और इसमें कौन से टूल और कमांड हैं।

स्थापना

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

 gem install pdk 

वास्तव में, पीडीके सिर्फ एक रत्न है, और यह उस तरह से सेट है।

पीडीके सामग्री

सामान्य तौर पर, मॉड्यूल विकास को सुविधाजनक बनाने के लिए पीडीके रत्नों के सेट से ज्यादा कुछ नहीं है। इसमें निम्नलिखित उपकरण शामिल हैं:

एक मॉड्यूल बनाएँ

PDK स्थापित है, अब आप चारों ओर खेल सकते हैं। सबसे सरल pdk help कमांड उपलब्ध कमांड pdk help प्रदर्शित pdk help । मान लीजिए कि हम उस फ़ोल्डर में हैं जहां आपके पास अन्य सभी मॉड्यूल हैं। तो चलो एक नया बनाएँ:

 $ pdk new module --template-url=https://github.com/puppetlabs/pdk-templates.git *** We need to create the metadata.json file for this module, so we're going to ask you 5 questions. *** [Q 1/5] If you have a name for your module, add it here. --> dummy [Q 2/5] If you have a Puppet Forge username, add it here. --> felixoid [Q 3/5] Who wrote this module? --> Mikhail f. Shiryaev [Q 4/5] What license does this module code fall under? --> MIT [Q 5/5] What operating systems does this module support? --> RedHat based Linux, Debian based Linux, Windows Metadata will be generated based on this information, continue? Yes pdk (INFO): Module 'dummy' generated at path '/tmp/dummy', from template 'https://github.com/puppetlabs/pdk-templates.git'. 

उपयोगिता मेटाडेटा.जेसन फ़ाइल में भरने के लिए सवाल पूछती है, और आउटपुट में ठीक वही दर्शाया गया है: गिट से टेम्पलेट्स से संकलित मॉड्यूल और सहायक फाइलें।

एक छोटी सी टिप्पणी - मंदिरों में अक्सर बदलाव होते हैं, जिनमें कुछ महत्वपूर्ण कीड़े भी शामिल हैं जिन्हें हाल ही में ठीक किया गया है। इसलिए, स्थापित पीडीके से चूक नहीं, बल्कि नवीनतम संस्करण का उपयोग करना बेहतर है। यह सच है कि इसका एक दूसरा पक्ष भी है: --template-url तर्क का उपयोग करते समय, PDK इस पैरामीटर को ~.pdk/cache/answers.json जोड़ता है और, किसी भी pdk कमांड के आगे निष्पादन में देरी को देखते हुए, यह उन्हें डाउनलोड करने का प्रयास करता है। तो या तो इस पैरामीटर को answers.json से निकालें, या मॉड्यूल बनाते समय इसका उपयोग न करें और इसे metadata.json . metadata.json में बदलें।

आइए आगे के चरणों के माध्यम से चलते हैं जो पीडीके का उपयोग करके किया जा सकता है।

नया वर्ग

 $ pdk new class dummy::class pdk (INFO): Creating '/tmp/dummy/manifests/class.pp' from template. pdk (INFO): Creating '/tmp/dummy/spec/classes/class_spec.rb' from template. $ cat manifests/class.pp # A description of what this class does # # @summary A short summary of the purpose of this class # # @example # include dummy::class class dummy::class { } $ cat spec/classes/class_spec.rb require 'spec_helper' describe 'dummy::class' do on_supported_os.each do |os, os_facts| context "on #{os}" do let(:facts) { os_facts } it { is_expected.to compile } end end end 

यह कमांड 2 फाइलें बनाता है: कक्षा के लिए स्वयं प्रकट होता है और परीक्षण के लिए कल्पना-फ़ाइल। मैं बाद में और अधिक विस्तार से प्रलेखन के लिए टैग पर ध्यान केंद्रित करूंगा।

नई निर्धारित_प्रकार

 $ pdk new defined_type type pdk (INFO): Creating '/tmp/dummy/manifests/type.pp' from template. pdk (INFO): Creating '/tmp/dummy/spec/defines/type_spec.rb' from template. 

सभी समान: संसाधन प्रकार और युक्ति फ़ाइल के लिए प्रकट।

नया प्रदाता और कार्य

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

कठपुतली-तारों के साथ प्रलेखन उत्पन्न करना

मुझे वास्तव में समझ नहीं आया कि puppet strings पीडीके टूलकिट का हिस्सा क्यों नहीं है, लेकिन यह एक ला होड़ है। यदि विकास के दौरान आपने यार्ड के लिए टैग सही तरीके से रखे हैं, तो उपयोगकर्ता को दस्तावेज़ प्रदान करने के 2 मुख्य तरीके हैं:

• इसे HTML / Markdown / JSON के रूप में जनरेट करें और कोड के बगल में रखें। यह puppet string generate [--format FORMAT] कमांड के साथ किया जाता है, जहां प्रारूप को छोड़ा जा सकता है या इसे json / markdown सेट किया जा सकता है।
  
  • यह डॉक्यूमेंट्री मानक के रूप में रिपॉजिटरी की जड़ में REFERENCE.md फाइल रखने के लिए प्रथागत है, जो puppet strings generate --format markdown द्वारा puppet strings generate --format markdown ।
• कोड के साथ रिपॉजिटरी में प्रकाशित करें (बशर्ते कि यह जीथब पर हो) जीथब-पेज। यह काफी सरल है, आपको 3 कमांड की आवश्यकता है:
  

   #  Gemfile.lock,    PDK rm -f Gemfile.lock #     Gemfile   bundle bundle install --path vendor/bundle #   gh-pages   rake-task bundle exec rake strings:gh_pages:update 

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

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

खाका अनुकूलन

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

मैं बहुत जल्दी उन कुछ मापदंडों का वर्णन करता हूं जो मैंने ऊपर उदाहरण से .sync.yml का उपयोग करके बदला है:

• Gemfile : दो Gemfile को विभिन्न समूहों में निर्भरता के रूप में जोड़ा गया: विकास समूह में Gemfile ; निर्भरता समूह में xml- सरल। परीक्षण शुरू करते समय, system_tests समूह स्थापित नहीं होता है, इसलिए मैं दूसरे समूह पर निर्भरता जोड़ता हूं।
• spec/spec_helper.rb : spec/spec_helper.rb विधि को बदल दिया गया है, न्यूनतम परीक्षण कवरेज थ्रेशोल्ड जोड़ा गया है, जिसके नीचे परीक्षण विफल माना जाता है।
• .travis.yml : इस फाइल को लंबे समय से पॉलिश किया गया है, क्योंकि इसका उपयोग कोड बेस की जांच करने और कठपुतली-फोर्ज पर तैयार मॉड्यूल को लोड करने के लिए किया जाता है। परिवर्तन:
  
  • कठपुतली-फोर्ज पर मॉड्यूल को भरने के लिए उपयोगकर्ता और एन्क्रिप्टेड पासवर्ड। आप यहां ट्रैविस के साथ कठपुतली-फोर्ज की तैनाती के बारे में अधिक पढ़ सकते हैं।
  • परीक्षणों का एक क्रम बनाया गया था → केवल सफल परीक्षणों के साथ उत्तरार्द्ध के प्रक्षेपण के साथ तैनाती।
  • मॉड्यूल को कठपुतली-फोर्ज में तैनात करने के चरण को जोड़ा गया, बशर्ते कि सीआई को वर्ण "v" से शुरू होने वाले टैग से लॉन्च किया गया हो।
• Rakefile : लिंटर के लिए कुछ अपवाद जोड़े।

विभिन्न सीआई चल रहे हैं

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

बोनस: हम कक्षाओं, प्रकारों और कार्यों के लिए इकाई परीक्षण लिखते हैं

यह बिंदु उस मूल सामग्री से काफी आगे निकल जाता है जिसे मैंने वर्णन करने की योजना बनाई थी, लेकिन यह मुझे बहुत उपयोगी लगती है।

इसलिए, हमारे पास एक मॉड्यूल है जिसमें मैनिफ़ेस्ट्स और एक लाइब्रेरी है, जो बदले में, कक्षाएं, प्रकार और फ़ंक्शन शामिल हैं (हम कार्यों और प्रदाताओं के बारे में भी नहीं भूलते हैं, लेकिन मुझे इस भाग में कोई विशेषज्ञता नहीं है)। चूंकि किसी भी कोड को बदलने के उद्देश्य से मौजूद है, यह अच्छा होगा, जाहिर है, यह सुनिश्चित करने के लिए परीक्षण के साथ ओवरले करना होगा कि 2 चीजें सुनिश्चित करें:

• परिवर्तन वर्तमान व्यवहार को नहीं तोड़ते (या परीक्षणों के साथ व्यवहार में परिवर्तन)
• आपके मैनिफ़ेस्ट वही करते हैं जो आप अपेक्षा करते हैं और आपके द्वारा अपेक्षित सभी संसाधनों का उपयोग करते हैं।

कठपुतली-कठपुतलियों को कठपुतली- rspec नामक rspec ढांचे के लिए एक विस्तार प्रदान करता है। परीक्षण वर्गों , प्रकारों और कार्यों के लिए प्रलेखन के लिए लिंक। निकट से देखने के लिए बहुत आलसी मत बनो, अन्य अनुभाग हैं।

रूबी को जानने के बिना, इसका उपयोग करना शुरू करना काफी सरल है। यदि कक्षाएं या प्रकार बनाए गए थे, जैसा कि ऊपर दिखाया गया है, तो pdk new <thing> का उपयोग करके, फिर *_spec.rb फ़ाइल पहले से मौजूद है। तो, मान लीजिए कि हमारे पास एक dummy::class । इसका परीक्षण करने के लिए, एक spec/classes/class_spec.rb फ़ाइल को निम्नलिखित सामग्री के साथ बनाया जाना चाहिए:

 require 'spec_helper' describe 'dummy::class' do on_supported_os.each do |os, os_facts| context "on #{os}" do let(:facts) { os_facts } it { is_expected.to compile } end end end 

आप मॉड्यूल की रूट डायरेक्टरी से pdk test unit चलाकर सत्यापित कर सकते हैं।

हमें इसकी लगभग आवश्यकता है अब यह उचित शर्तों के साथ आवश्यक is_expected class_spec.rb को पूरक करने के लिए बना हुआ है। उदाहरण के लिए, यह जांचने के लिए कि कक्षा में file {'/file/path': } कुछ मापदंडों के साथ संसाधन, आप यह कर सकते हैं:

 it do is_expected.to contain_file('/file/path').with( 'ensure' => 'file', 'mode' => '0644' ) end 

आप let(:params) { {'param1' => 'value'} } का उपयोग करके कक्षा के पैरामीटर सेट कर सकते हैं, यह context 'some description' {} के चयनित खंडों context 'some description' {} अंदर प्रत्येक को रखकर विभिन्न इनपुट परिस्थितियों में परीक्षण करना संभव है। आप संसाधनों के बीच और कक्षाओं के बीच दोनों निर्भरता की जांच कर सकते हैं: यदि यह माना जाता है, उदाहरण के लिए, कि कक्षा की घोषणा में inherits , तो आप is_expected.to contain_class('parent_class_name') जोड़ सकते हैं। is_expected.to contain_class('parent_class_name') । विभिन्न ओएस में व्यवहार की जांच करने की आवश्यकता है? यह भी संभव है: हम केवल एक अलग संदर्भ में आवश्यक तथ्यों को इंगित करते हैं:

 context 'with Debian' do let(:facts) do { os: { architecture: 'amd64', distro: { codename: 'stretch', id: 'Debian', release: { full: '9.6', major: '9', minor: '6', }, }, family: 'Debian', name: 'Debian', release: { full: '9.6', major: '9', minor: '6', }, selinux: { enabled: false, }, }, osfamily: 'Debian', } end it { is_expected.to something } end 

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

आउटपुट के बजाय

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

बिना विकास दाढ़ी PDK	पीडीके विकास

कोशिश करो, रखो, अपने और अपने सहयोगियों के लिए जीवन आसान बनाओ। मुझे संभावित सवालों के जवाब देने में खुशी होगी।

हो सकता है परमाणुकरण हमारे साथ हो!