DevOps कार्यप्रणाली में मीडिया पहचान मुद्दों को हल करना

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

चूंकि यह एक कार्यशील उदाहरण है, मैं इस समस्या को हल करते समय निर्धारित सीमाओं का तुरंत वर्णन करूंगा:

• एक बड़े समुदाय के साथ लोकप्रिय आरपीएम-आधारित वितरण का एक स्थिर संस्करण, जहां वे ओएस से जुड़ी सामान्य समस्याओं को हल करने में मदद करेंगे। CentOS को चुना गया, क्योंकि यह वर्तमान में सबसे लोकप्रिय आरपीएम-आधारित वितरण है।
• पर्यावरण को संस्करण देने की क्षमता। प्रोग्रामर एक बार में CentOS 5 और CentOS 6 पर उत्पाद के कई कांटे विकसित कर रहे हैं।
• उत्पाद के सही संचालन और तैनाती के लिए सॉफ्टवेयर का एक आवश्यक सेट (यह एक उदाहरण है, वास्तव में, सूची बहुत बड़ी थी):
  CentOS 5 के लिए:
  
  • अजगर => २.४
  • अजगर-IPY
  • अजगर-simplejson
  • mysql-server> = 5.0
  
  CentOS 6 के लिए:
  
  • अजगर => २.६
  • अजगर-IPY
  • अजगर-simplejson
  • mysql-server> = 5.1
  
  

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

इस समाधान को एकजुट करने के लिए, मैंने बिल्ड-टूल्स यूटिलिटी https://github.com/scopenco/build-tools विकसित किया है, जो आपको मेटा-पैकेज (प्रोजेक्ट पैकेज, XML विनिर्देशों (उर्फ भूमिकाओं) पर आधारित) के साथ RHEL , CentOS , Fedora , वैज्ञानिक यम रिपॉजिटरी बनाने की अनुमति देता है। । रोल्स आवश्यक पैकेज और रिपॉजिटरी के एक सेट का वर्णन करते हैं, जहां से ये पैकेज निर्भरता के साथ, स्थानीय यम रिपॉजिटरी (उर्फ बिल्ड) में डाउनलोड किए जाते हैं। इस भंडार का उपयोग उत्पाद के लिए पैकेज बेस के रूप में किया जाता है।

इसलिए, बिल्ड-टूल्स को स्थापित करना बहुत सरल है और README में वर्णित है।
चलो परियोजनाओं के विनिर्देशों पर चलते हैं।
केंटोस 5 के लिए विशिष्टता उदाहरण:

<?xml version="1.0" encoding="UTF-8"?> <project name="myproject" summary="My First Project" repository="http://repo.domain.com/pub/repo/" version="0.1" > <!-- role with minimal set of packages --> <role path="roles/centos-5-minimal.xml" /> <!-- python packages --> <package name="python" version="2.4.3" /> <package name="python-IPy" /> <package name="python-simplejson" /> <!-- mysql packages --> <package name="mysql-server" version="5.0.95" /> <!-- yum repos --> <role path="repos/centos-5-base.xml" /> <role path="repos/centos-5-updates.xml" /> <role path="repos/centos-5-epel.xml" /> </project> 

केंटोस 6 के लिए विशिष्टता उदाहरण:

 <?xml version="1.0" encoding="UTF-8"?> <project name="myproject" summary="My First Project" repository="http://repo.domain.com/pub/repo/" version="0.2" > <!-- role with minimal set of packages --> <role path="roles/centos-6-minimal.xml" /> <!-- python packages --> <package name="python" version="2.6.6" /> <package name="python-IPy" /> <package name="python-simplejson" /> <!-- mysql packages --> <package name="mysql-server" version="5.1.71" /> <!-- yum repos --> <role path="repos/centos-6-base.xml" /> <role path="repos/centos-6-updates.xml" /> <role path="repos/centos-6-epel.xml" /> </project> 

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

 cd src cp ../repository . ./build-el5.sh ./build-el6.sh 

CentOS 5 पर असेंबलिंग रिपॉजिटरी का होना अनिवार्य है। इसका कारण यह है कि yum बैकवर्ड कम्पैटिबल नहीं है और CentOS 6 के yum API के माध्यम से निर्मित रिपॉजिटरी CentOS 5 मशीनों पर स्थापित नहीं होगी, जबकि CentOS 5 पर निर्मित रिपॉजिटरी CentOS 6, फेडोरा पर स्थापित हैं 13 और ऊपर, वैज्ञानिक 5 और ऊपर।

क्रैश शुरू करने के बाद, आउटपुट 2 रिपॉजिटरी है जिसमें से आप किकस्टार्ट के माध्यम से भौतिक और वर्चुअल सर्वर अपलोड कर सकते हैं। यह सॉफ्टवेयर के एक सेट को ठीक करता है जिसे कॉर्पोरेट रिपॉजिटरी में संग्रहीत किया जा सकता है और उत्पाद को तैनात करने के लिए उपयोग किया जाता है।

आप वातावरण को अनुकूलित करने के लिए सार्वजनिक यम भंडार और संकुल के साथ नई भूमिकाएँ बना सकते हैं।
कई लोकप्रिय विकल्पों पर विचार करें:

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

विशेषताओं का विस्तृत विवरण विकि बिल्ड-टूल्स में पाया जा सकता है।

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

परिणाम:
इस प्रकार, बिल्ड-टूल्स का उपयोग करके मैं सफल हुआ:

1. पहचान विकास, परीक्षण, उत्पादन वातावरण की समस्या को हल करना
2. पूरे प्रोजेक्ट में पर्यावरण और सॉफ्टवेयर अनुकूलता के लिए व्यापक अवसर प्रदान करने वाले डेवलपर्स प्रदान करें