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

इस तरह के विषयों पर विचार करें:

• कंटेनर 101
• सॉफ्टवेयर विकास चक्र के विभिन्न चरणों में कंटेनर
• कंटेनरों के साथ सतत वितरण

कंटेनर 101

कंटेनरों और कंटेनरीकरण के बारे में बहुत सारे लेख और किताबें लिखी गई हैं, इसलिए यहां मैं एक छोटा सा परिचय दूंगा, जो कि अंतिम होने का दावा नहीं करता है। तो चलिए शुरू करते हैं।

कंटेनर, तकनीकी रूप से, एक वर्चुअलाइजेशन विधि है जिसमें ऑपरेटिंग सिस्टम का कर्नेल एक के बजाय उपयोगकर्ता स्थान (कंटेनरों) के कई अलग-अलग उदाहरणों का समर्थन करता है। यह नेत्रहीन इस तरह दिखता है:

यह ध्यान रखना महत्वपूर्ण है कि कंटेनर वर्चुअल मशीन नहीं हैं, यहां उनके अंतर के बारे में एक अच्छा लेख है ।

कंटेनर लाभ

कंटेनर का उपयोग करने के कई लाभ हैं:

• पोर्टेबिलिटी
• प्रभावशीलता
• इन्सुलेशन
• लपट
• अचल स्थिति (अचल स्थिति)

पोर्टेबिलिटी

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

साथ ही, पोर्टेबिलिटी इस तथ्य में होती है कि डॉकटर की छवि को इकट्ठा करने के बाद और यह सही ढंग से काम करता है, यह कहीं भी काम करेगा अगर डॉकटर वहां काम करता है यानी। विंडोज, लिनक्स और मैकओएस सर्वर पर।

प्रभावशीलता

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

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

इन्सुलेशन

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

लपट

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

अचल स्थिति (अचल स्थिति)

अपरिवर्तनीय अवसंरचना में अपरिवर्तनीय घटक होते हैं जिन्हें प्रत्येक परिनियोजन के लिए प्रतिस्थापित किया जाता है और अद्यतन नहीं किया जाता है। संगति असंगतता को कम करती है और आपको अपने आवेदन के विभिन्न राज्यों के बीच आसानी से और जल्दी से दोहराने और स्थानांतरित करने की अनुमति देती है। अपरिवर्तनीयता पर अधिक ।

नई सुविधाएँ

ये सभी लाभ आपको नए तरीके से अपने बुनियादी ढांचे और अनुप्रयोगों का प्रबंधन करने की अनुमति देते हैं।

वाद्य-स्थान

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

IoC का उपयोग करते समय, पर्यावरण परिनियोजन टीम हमेशा पर्यावरण की प्रारंभिक स्थिति की परवाह किए बिना, लक्ष्य वातावरण को समान विन्यास में लाती है। यह मौजूदा वातावरण को स्वचालित रूप से सेट करके या स्क्रैच से पर्यावरण को फिर से बनाने के द्वारा प्राप्त किया जाता है।

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

यह सब कंटेनरों के साथ करना बहुत आसान है। कंटेनर को बंद करने और एक नया शुरू करने में कुछ सेकंड लगते हैं, और एक नई वर्चुअल मशीन आवंटित करने में कुछ मिनट लगते हैं।

स्केलिंग

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

सॉफ्टवेयर जीवन चक्र के विभिन्न चरणों में कंटेनर

सॉफ़्टवेयर जीवन चक्र के विभिन्न चरणों में कंटेनरों के लाभों पर विचार करें।

डिज़ाइन

सबसे महत्वपूर्ण लाभ विकास शुरू करने में आसानी है। डॉकर को स्थापित करने के बाद, यह दो कमांड चलाने के लिए पर्याप्त है: छवि को लोड करने के लिए docker run और इसे शुरू करने के लिए docker run लिए। सभी निर्भरताएँ पहले से ही एप्लिकेशन बिल्ड स्टेज पर हल हो जाती हैं।

डिबगिंग

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

परीक्षण / क्यूए

एक त्रुटि की स्थिति में, त्रुटि पर्यावरण और त्रुटि को पुन: पेश करने के लिए शर्तों को कंटेनर के साथ स्थानांतरित किया जा सकता है। सभी अवसंरचना परिवर्तन "प्रलेखित" हैं। चरों की संख्या कम हो रही है - पुस्तकालयों, चौखटों, ओएस के संस्करणों ... परीक्षणों को समानांतर बनाने के लिए कई कंटेनरों को चलाना संभव है।

वितरण

कंटेनरों का उपयोग करने से आपको एक बार निर्माण करने की अनुमति मिलती है, कंटेनरों का उपयोग करने के अलावा आपको विधानसभा और तैनाती प्रक्रियाओं के उच्च स्तर के स्वचालन की आवश्यकता होती है। अतिरिक्त अलगाव के कारण किसी एप्लिकेशन का कंटेनर वितरण अधिक सुरक्षित हो सकता है।

निरंतर वितरण

सिद्धांत से अभ्यास की ओर बढ़ते हैं। यहाँ हमारे विधानसभा और वितरण स्वचालन समाधान का एक सामान्य दृश्य है:

तीन मुख्य चरणों को प्रतिष्ठित किया जा सकता है:

• सभा
• वितरण
• लांच

सभा

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

वितरण

हमारी छवि को संकलित और परीक्षण करने के बाद, इसे डॉकर रजिस्ट्री पर अपलोड किया जाता है, जो डॉकटर छवि की मेजबानी के लिए एक विशेष एप्लिकेशन है। वहां वह पिछली छवि को उसी नाम (टैग) से बदल सकता है। उदाहरण के लिए, मास्टर शाखा के लिए एक नई प्रतिबद्धता के कारण, हमने एक नई छवि ( MyProject/MyApp:master ) इकट्ठी की है, और यदि परीक्षण पास हो जाते हैं, तो हम डॉकर रजिस्ट्री में छवि को अपडेट कर सकते हैं और जो कोई भी MyProject/MyApp:master डाउनलोड करता है, उसे एक नया संस्करण मिलेगा।

लांच

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

इन चरणों को समझाते हुए वेबिनार देखें।

वैकल्पिक रूप से, प्रतिबद्ध के संदर्भ में:

हमारे सतत वितरण विन्यास में, हम:

• GitLab रिपॉजिटरी के लिए प्रतिबद्ध कोड
• हम छवि एकत्र करते हैं
• इसका परीक्षण कर रहे हैं
• हमारी डॉकर रजिस्ट्री में एक नई छवि प्रकाशित करें
• डॉकर रजिस्ट्री से पुराने कंटेनर को नए संस्करण में अपडेट करें

इसके लिए हमें चाहिए:

• डाक में काम करनेवाला मज़दूर
• डॉकटर रजिस्ट्री
• पंजीकृत डोमेन (वैकल्पिक, लेकिन वांछनीय)
• जीयूआई उपकरण (वैकल्पिक)

डाक में काम करनेवाला मज़दूर

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

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

डॉकटर रजिस्ट्री

यह पहला कंटेनर है जिसे हमें चलाने की आवश्यकता है, यह एक स्टैंडअलोन एप्लिकेशन है जो हमें डॉकर छवियों को स्टोर और वितरित करने की अनुमति देता है। यदि आप चाहते हैं तो आपको डोकर रजिस्ट्री का उपयोग करने की आवश्यकता है:

• नियंत्रण करें कि आपकी छवियां कहां संग्रहीत हैं
• स्वयं एक छवि वितरण सर्वर
• छवि भंडारण और वितरण को विकास प्रक्रिया में एकीकृत करें

यहां डॉकर रजिस्ट्री को लॉन्च करने और कॉन्फ़िगर करने के बारे में दस्तावेज है ।

डॉकटर रजिस्ट्री और गिटलैब कनेक्ट करें

डॉकटर रजिस्ट्री को गिटलैब से जोड़ने के लिए, आपको डॉकटर रजिस्ट्री को एचटीटीपीएस समर्थन के साथ चलाने की आवश्यकता है। मैं प्रमाणपत्र प्राप्त करने के लिए Let’s Encrypt का उपयोग करता हूं, और मैंने प्रमाणपत्र प्राप्त करने के लिए इस निर्देश का पालन किया है। यह सत्यापित करने के बाद कि डॉकटर रजिस्ट्री HTTPS के माध्यम से सुलभ है (आप इसे ब्राउज़र में देख सकते हैं), डॉकटर रजिस्ट्री को गिटलैब से जोड़ने के लिए इन निर्देशों का पालन करें। ये निर्देश आपके GitLab इंस्टॉलेशन और आपके द्वारा आवश्यक कॉन्फ़िगरेशन के आधार पर भिन्न होते हैं। मेरे मामले में, सेटअप को डॉकर रजिस्ट्री प्रमाणपत्र और /etc/gitlab/ssl , और इन पंक्तियों को /etc/gitlab/gitlab.rb :

 registry_external_url 'https://docker.domain.com' gitlab_rails ['registry_api_url'] = "https://docker.domain.com" 

GitLab को पुन: कॉन्फ़िगर करने के बाद, एक नया रजिस्ट्री टैब दिखाई दिया, जो कि बनाई गई छवियों को सही ढंग से नाम देने के बारे में जानकारी प्रदान करता है ताकि वे यहां दिखाई दें।

डोमेन

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

• <featureName>.docker.domain.com पर कई <featureName>.docker.domain.com शाखाएँ
• master.docker.domain.com पर परीक्षण संस्करण
• preprod.docker.domain.com पर preprod.docker.domain.com संस्करण
• प्रोडक्ट वर्जन prod.docker.domain.com

ऐसा करने के लिए, हमें एक डोमेन नाम और वाइल्डकार्ड DNS रिकॉर्ड की आवश्यकता होती है जो * .docker.domain.com के IP पते पर * .docker.domain.com अनुरोधों को रीडायरेक्ट करता है। वैकल्पिक रूप से, आप विभिन्न बंदरगाहों का उपयोग कर सकते हैं।

nginx

चूंकि हमारे पास कई वातावरण हैं, इसलिए हमें स्वचालित रूप से सही कंटेनर में उप-डोमेन के अनुरोधों को पुनर्निर्देशित करना होगा। इसके लिए, हम Nginx को रिवर्स प्रॉक्सी के रूप में उपयोग कर सकते हैं। यहाँ एक गाइड है ।

जीयूआई उपकरण

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

• क्षेत्र लगानेवाला
• MicroBadger
• Portainer
• सरल कर्ता उई
• ...

वे आपको कंटेनर बनाने और CLI के बजाय GUI से प्रबंधित करने की अनुमति देते हैं। यहाँ है क्या Rancher की तरह लग रहा है:

गिटलब रनर

पहले की तरह, अन्य सर्वरों पर स्क्रिप्ट चलाने के लिए, हमें GitLab धावक को स्थापित करना होगा। इस प्रश्न का पिछले लेख में विस्तार से वर्णन किया गया है।

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

सतत वितरण विन्यास

अब जब सभी आवश्यक घटक कॉन्फ़िगर किए गए हैं, तो आप एक सतत वितरण कॉन्फ़िगरेशन बनाना शुरू कर सकते हैं।

सभा

सबसे पहले, हमें एक छवि को इकट्ठा करने की आवश्यकता है।

हमारा कोड, हमेशा की तरह, रिपॉजिटरी में संग्रहित होता है, सीडी का विन्यास gitlab-ci.yml , लेकिन इसके अलावा (सुरक्षा में सुधार के लिए) हम बिल्ड सर्वर पर छवि से संबंधित कई फाइलों को संग्रहीत करेंगे।

GitLab.xml

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

iris.key

लाइसेंस कुंजी। इसे कंटेनर की असेंबली के दौरान लोड किया जा सकता है, और सर्वर पर संग्रहीत नहीं किया जाता है। भंडार में कुंजी को संग्रहीत करना सुरक्षित नहीं है। आप WRC पर एक परीक्षण कुंजी प्राप्त कर सकते हैं या InterSystems IRIS अनुभव की कोशिश कर सकते हैं।

pwd.txt

डिफ़ॉल्ट पासवर्ड वाली फ़ाइल। फिर से, रिपॉजिटरी में पासवर्ड स्टोर करना असुरक्षित है।

load_ci.script

एक स्क्रिप्ट जो:

• InterSystems IRIS में OS प्रमाणीकरण शामिल है
• भार GitLab.xml
• GitLab कॉलबैक सेटिंग को प्रारंभ करता है
• भार कोड

 set sc = ##Class(Security.System).Get("SYSTEM",.Properties) write:('sc) $System.Status.GetErrorText(sc) set AutheEnabled = Properties("AutheEnabled") set AutheEnabled = $ZBOOLEAN(+AutheEnabled,16,7) set Properties("AutheEnabled") = AutheEnabled set sc = ##Class(Security.System).Modify("SYSTEM",.Properties) write:('sc) $System.Status.GetErrorText(sc) zn "USER" do ##class(%SYSTEM.OBJ).Load(##class(%File).ManagerDirectory() _ "GitLab.xml","cdk") do ##class(isc.git.Settings).setSetting("hooks", "MyApp/Hooks/") do ##class(isc.git.Settings).setSetting("tests", "MyApp/Tests/") do ##class(isc.git.GitLab).load() halt 

ध्यान दें कि पहली पंक्ति जानबूझकर खाली छोड़ी गई है। यदि यह प्रारंभिक स्क्रिप्ट हमेशा समान होती है, तो आप इसे केवल रिपॉजिटरी में सहेज सकते हैं।

gitlab-ci.yml

अब, निरंतर वितरण विन्यास पर चलते हैं:

 build image: stage: build tags: - test script: - cp -r /InterSystems/mount ci - cd ci - echo 'SuperUser' | cat - pwd.txt load_ci.script > temp.txt - mv temp.txt load_ci.script - cd .. - docker build --build-arg CI_PROJECT_DIR=$CI_PROJECT_DIR -t docker.domain.com/test/docker:$CI_COMMIT_REF_NAME . 

यहाँ क्या हो रहा है?

सबसे पहले, चूंकि छवि असेंबली प्रक्रिया केवल बेस डायरेक्टरी की उपनिर्देशिकाओं तक पहुंच सकती है - हमारे मामले में, रिपॉजिटरी की मूल निर्देशिका, आपको "गुप्त" निर्देशिका (जिसमें GitLab.xml , iris.key , pwd.txt और load_ci.skript ) की प्रतिलिपि बनाने की आवश्यकता है क्लोन रिपोजिटरी।

इसके अलावा, टर्मिनल तक पहुंचने के लिए एक उपयोगकर्ता / पासवर्ड की आवश्यकता होती है, इसलिए हम उन्हें load_ci.script जोड़ देंगे (इसके लिए हमें load_ci.script की शुरुआत में एक खाली लाइन की load_ci.script )।

अंत में, हम एक डॉकर छवि बनाते हैं और इसे नाम देते हैं: docker.domain.com/test/docker:$CI_COMMIT_REF_NAME

जहां $CI_COMMIT_REF_NAME शाखा का नाम है। कृपया ध्यान दें: छवि टैग का पहला भाग GitLab में रिपॉजिटरी के नाम से मेल खाना चाहिए ताकि इसे रजिस्ट्री टैब पर देखा जा सके (सही टैगिंग के लिए अधिक पूर्ण निर्देश वहां उपलब्ध हैं)।

Dockerfile

Docker छवि Dockerfile का उपयोग करके बनाई गई है, यहाँ यह है:

 FROM docker.intersystems.com/intersystems/iris:2018.1.1.613.0 ENV SRC_DIR=/tmp/src ENV CI_DIR=$SRC_DIR/ci ENV CI_PROJECT_DIR=$SRC_DIR COPY ./ $SRC_DIR RUN cp $CI_DIR/iris.key $ISC_PACKAGE_INSTALLDIR/mgr/ \ && cp $CI_DIR/GitLab.xml $ISC_PACKAGE_INSTALLDIR/mgr/ \ && $ISC_PACKAGE_INSTALLDIR/dev/Cloud/ICM/changePassword.sh $CI_DIR/pwd.txt \ && iris start $ISC_PACKAGE_INSTANCENAME \ && irissession $ISC_PACKAGE_INSTANCENAME -U%SYS < $CI_DIR/load_ci.script \ && iris stop $ISC_PACKAGE_INSTANCENAME quietly 

निम्नलिखित क्रियाएं की जाती हैं:

• हम आधार के रूप में इंटरसिस्टम आईआरआईएस की छवि लेते हैं। यह आपके डॉकर रजिस्ट्री में होना चाहिए। यदि आपने पहले डॉकटर के साथ काम नहीं किया है, तो फ़र्स्ट लुक आज़माएँ : डॉकर , जो बताता है कि इंटरसिस्टम IRIS इमेज कैसे प्राप्त करें, इसे डॉकर रजिस्ट्री में जोड़ें और मैन्युअल रूप से लॉन्च करें।
• सबसे पहले, कंटेनर के अंदर हमारी रिपॉजिटरी (और "गुप्त" निर्देशिका) की प्रतिलिपि बनाएँ।
• GitLab.xml निर्देशिका के लिए लाइसेंस कुंजी और GitLab.xml प्रतिलिपि बनाएँ।
• पासवर्ड को pwd.txt से मान में pwd.txt । ध्यान दें कि इस ऑपरेशन के दौरान pwd.txt को हटा दिया गया है।
• इंटरसिस्टम IRIS शुरू करता है।
• load_ci.script ।
• InterSystems IRIS बंद हो जाता है।

 Running with gitlab-runner 10.6.0 (a3543a27) on docker 7b21e0c4 Using Shell executor... Running on docker... Fetching changes... Removing ci/ Removing temp.txt HEAD is now at 5ef9904 Build load_ci.script From http://gitlab.eduard.win/test/docker 5ef9904..9753a8d master -> origin/master Checking out 9753a8db as master... Skipping Git submodules setup $ cp -r /InterSystems/mount ci $ cd ci $ echo 'SuperUser' | cat - pwd.txt load_ci.script > temp.txt $ mv temp.txt load_ci.script $ cd .. $ docker build --build-arg CI_PROJECT_DIR=$CI_PROJECT_DIR -t docker.eduard.win/test/docker:$CI_COMMIT_REF_NAME . Sending build context to Docker daemon 401.4kB Step 1/6 : FROM docker.intersystems.com/intersystems/iris:2018.1.1.613.0 ---> cd2e53e7f850 Step 2/6 : ENV SRC_DIR=/tmp/src ---> Using cache ---> 68ba1cb00aff Step 3/6 : ENV CI_DIR=$SRC_DIR/ci ---> Using cache ---> 6784c34a9ee6 Step 4/6 : ENV CI_PROJECT_DIR=$SRC_DIR ---> Using cache ---> 3757fa88a28a Step 5/6 : COPY ./ $SRC_DIR ---> 5515e13741b0 Step 6/6 : RUN cp $CI_DIR/iris.key $ISC_PACKAGE_INSTALLDIR/mgr/ && cp $CI_DIR/GitLab.xml $ISC_PACKAGE_INSTALLDIR/mgr/ && $ISC_PACKAGE_INSTALLDIR/dev/Cloud/ICM/changePassword.sh $CI_DIR/pwd.txt && iris start $ISC_PACKAGE_INSTANCENAME && irissession $ISC_PACKAGE_INSTANCENAME -U%SYS < $CI_DIR/load_ci.script && iris stop $ISC_PACKAGE_INSTANCENAME quietly ---> Running in 86526183cf7c . Waited 1 seconds for InterSystems IRIS to start This copy of InterSystems IRIS has been licensed for use exclusively by: ISC Internal Container Sharding Copyright (c) 1986-2018 by InterSystems Corporation Any other use is a violation of your license agreement %SYS> 1 %SYS> Using 'iris.cpf' configuration file This copy of InterSystems IRIS has been licensed for use exclusively by: ISC Internal Container Sharding Copyright (c) 1986-2018 by InterSystems Corporation Any other use is a violation of your license agreement 1 alert(s) during startup. See messages.log for details. Starting IRIS Node: 39702b122ab6, Instance: IRIS Username: Password: Load started on 04/06/2018 17:38:21 Loading file /usr/irissys/mgr/GitLab.xml as xml Load finished successfully. USER> USER> [2018-04-06 17:38:22.017] Running init hooks: before [2018-04-06 17:38:22.017] Importing hooks dir /tmp/src/MyApp/Hooks/ [2018-04-06 17:38:22.374] Executing hook class: MyApp.Hooks.Global [2018-04-06 17:38:22.375] Executing hook class: MyApp.Hooks.Local [2018-04-06 17:38:22.375] Importing dir /tmp/src/ Loading file /tmp/src/MyApp/Tests/TestSuite.cls as udl Compilation started on 04/06/2018 17:38:22 with qualifiers 'c' Compilation finished successfully in 0.194s. Load finished successfully. [2018-04-06 17:38:22.876] Running init hooks: after [2018-04-06 17:38:22.878] Executing hook class: MyApp.Hooks.Local [2018-04-06 17:38:22.921] Executing hook class: MyApp.Hooks.Global Removing intermediate container 39702b122ab6 ---> dea6b2123165 [Warning] One or more build-args [CI_PROJECT_DIR] were not consumed Successfully built dea6b2123165 Successfully tagged docker.domain.com/test/docker:master Job succeeded 

लांच

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

सबसे पहले, पुराने कंटेनर को हटाने के लिए स्क्रिप्ट।

 destroy old: stage: destroy tags: - test script: - docker stop iris-$CI_COMMIT_REF_NAME || true - docker rm -f iris-$CI_COMMIT_REF_NAME || true 

यह स्क्रिप्ट चल रहे कंटेनर को नष्ट कर देती है और हमेशा सफल होती है (डिफ़ॉल्ट रूप से, डॉकर एक त्रुटि देता है जब कोई भी नॉनवेज कंटेनर को रोकने / हटाने की कोशिश करता है)।

उसके बाद, हम एक नया कंटेनर लॉन्च करते हैं और इसे पर्यावरण के रूप में पंजीकृत करते हैं।

 run image: stage: run environment: name: $CI_COMMIT_REF_NAME url: http://$CI_COMMIT_REF_SLUG.docker.eduard.win/index.html tags: - test script: - docker run -d --expose 52773 --volume /InterSystems/durable/$CI_COMMIT_REF_SLUG:/data --env ISC_DATA_DIRECTORY=/data/sys --env VIRTUAL_HOST=$CI_COMMIT_REF_SLUG.docker.eduard.win --name iris-$CI_COMMIT_REF_NAME docker.eduard.win/test/docker:$CI_COMMIT_REF_NAME --log $ISC_PACKAGE_INSTALLDIR/mgr/messages.log 

Nginx कंटेनर स्वचालित रूप से निर्दिष्ट पोर्ट में VIRTUAL_HOST पर्यावरण VIRTUAL_HOST का उपयोग करके अनुरोधों को पुनर्निर्देशित करता है - इस मामले में, 52773।

चूंकि InterSystems IRIS में होस्ट पर कुछ डेटा (पासवर्ड,% SYS, एप्लिकेशन डेटा) स्टोर करना आवश्यक है, इसलिए टिकाऊ% SYS कार्यक्षमता है जो आपको होस्ट पर डेटा संग्रहीत करने की अनुमति देती है जैसे:

• iris.cpf मुख्य विन्यास फाइल है।
• वेब अनुप्रयोग फ़ाइलों के साथ /csp ।
• निजी Apache सर्वर कॉन्फ़िगरेशन के साथ /httpd/httpd.conf ।
• /mgr निर्देशिका जिसमें संग्रहीत हैं:
  
  • डेटाबेस IRISSYS , IRISTEMP , IRISAUDIT , IRIS , USER ।
  • IRIS.WIJ ।
  • निर्देशिका /journal भंडारण पत्रिका।
  • अस्थायी फ़ाइलों के लिए /temp निर्देशिका।
  • SystemMonitor.log , journal.log , SystemMonitor.log ।

टिकाऊ% SYS को सक्षम करने के लिए, volume तर्क निर्दिष्ट किया जाता है ISC_DATA_DIRECTORY होस्ट डायरेक्टरी को ISC_DATA_DIRECTORY और ISC_DATA_DIRECTORY वैरिएबल टिकाऊ% SYS फ़ाइलों को संग्रहीत करने के लिए निर्देशिका सेट करता है। यह निर्देशिका मौजूद नहीं होनी चाहिए, यह स्वचालित रूप से बनाई जाएगी।

इस प्रकार, हमारे कंटेनरीकृत अनुप्रयोग की वास्तुकला इस प्रकार है:

इस तरह के एक अनुप्रयोग का निर्माण करने के लिए, हमें कम से कम एक अतिरिक्त डेटाबेस (एप्लिकेशन कोड को बचाने के लिए) बनाना होगा और एप्लिकेशन क्षेत्र में इसकी मैपिंग बनाना होगा। मैंने एप्लिकेशन डेटा को संग्रहीत करने के लिए USER गुंजाइश का उपयोग किया, क्योंकि यह दायरा डिफ़ॉल्ट रूप से टिकाऊ% SYS में जोड़ा गया था। एप्लिकेशन कोड एक कंटेनर में संग्रहीत किया जाता है ताकि इसे अपडेट किया जा सके।

पूर्वगामी के आधार पर, % इंस्टॉलर चाहिए:

• APP क्षेत्र / डेटाबेस बनाएँ
• APP क्षेत्र में कोड अपलोड करें
• USER क्षेत्र में हमारे एप्लिकेशन की मैपिंग कक्षाएं बनाएं
• अन्य कॉन्फ़िगरेशन करें (मैंने एक CSP वेब एप्लिकेशन और एक REST वेब एप्लिकेशन बनाया)

 Class MyApp.Hooks.Local { Parameter Namespace = "APP"; /// See generated code in zsetup+1^MyApp.Hooks.Local.1 XData Install [ XMLNamespace = INSTALLER ] { <Manifest> <Log Text="Creating namespace ${Namespace}" Level="0"/> <Namespace Name="${Namespace}" Create="yes" Code="${Namespace}" Ensemble="" Data="IRISTEMP"> <Configuration> <Database Name="${Namespace}" Dir="/usr/irissys/mgr/${Namespace}" Create="yes" MountRequired="true" Resource="%DB_${Namespace}" PublicPermissions="RW" MountAtStartup="true"/> </Configuration> <Import File="${Dir}Form" Recurse="1" Flags="cdk" IgnoreErrors="1" /> </Namespace> <Log Text="End Creating namespace ${Namespace}" Level="0"/> <Log Text="Mapping to USER" Level="0"/> <Namespace Name="USER" Create="no" Code="USER" Data="USER" Ensemble="0"> <Configuration> <Log Text="Mapping Form package to USER namespace" Level="0"/> <ClassMapping From="${Namespace}" Package="Form"/> <RoutineMapping From="${Namespace}" Routines="Form" /> </Configuration> <CSPApplication Url="/" Directory="${Dir}client" AuthenticationMethods="64" IsNamespaceDefault="false" Grant="%ALL" Recurse="1" /> </Namespace> </Manifest> } /// This is a method generator whose code is generated by XGL. /// Main setup method /// set vars("Namespace")="TEMP3" /// do ##class(MyApp.Hooks.Global).setup(.vars) ClassMethod setup(ByRef pVars, pLogLevel As %Integer = 0, pInstaller As %Installer.Installer) As %Status [ CodeMode = objectgenerator, Internal ] { Quit ##class(%Installer.Manifest).%Generate(%compiledclass, %code, "Install") } /// Entry point ClassMethod onAfter() As %Status { try { write "START INSTALLER",! set vars("Namespace") = ..#Namespace set vars("Dir") = ..getDir() set sc = ..setup(.vars) write !,$System.Status.GetErrorText(sc),! set sc = ..createWebApp() } catch ex { set sc = ex.AsStatus() write !,$System.Status.GetErrorText(sc),! } quit sc } /// Modify web app REST ClassMethod createWebApp(appName As %String = "/forms") As %Status { set:$e(appName)'="/" appName = "/" _ appName #dim sc As %Status = $$$OK new $namespace set $namespace = "%SYS" if '##class(Security.Applications).Exists(appName) { set props("AutheEnabled") = $$$AutheUnauthenticated set props("NameSpace") = "USER" set props("IsNameSpaceDefault") = $$$NO set props("DispatchClass") = "Form.REST.Main" set props("MatchRoles")=":" _ $$$AllRoleName set sc = ##class(Security.Applications).Create(appName, .props) } quit sc } ClassMethod getDir() [ CodeMode = expression ] { ##class(%File).NormalizeDirectory($system.Util.GetEnviron("CI_PROJECT_DIR")) } } 

मैं ध्यान देता हूं कि होस्ट पर डेटाबेस नहीं बनाने के लिए, मैं निर्देशिका का उपयोग करता हूं /usr/irissys/mgr , क्योंकि कॉल ##class(%File).ManagerDirectory() टिकाऊ% SYS के लिए निर्देशिका का पथ देता है।

परीक्षण

अब परीक्षण चलाते हैं।

 test image: stage: test tags: - test script: - docker exec iris-$CI_COMMIT_REF_NAME irissession iris -U USER "##class(isc.git.GitLab).test()" 

वितरण

परीक्षण पारित कर दिए गए हैं, हम अपनी छवि डोकर रजिस्ट्री में प्रकाशित करेंगे।

 publish image: stage: publish tags: - test script: - docker login docker.domain.com -u user -p pass - docker push docker.domain.com/test/docker:$CI_COMMIT_REF_NAME 

लॉगिन / पासवर्ड गुप्त चर का उपयोग करके पारित किया जा सकता है।

अब छवि GitLab पर प्रदर्शित होती है।

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

निष्कर्ष

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

कंटेनरीकरण प्रौद्योगिकियों के उपयोग से अनुप्रयोग विकास और परिनियोजन प्रक्रियाओं को अनुकूलित करने में मदद मिलेगी। वातावरण के बीच विसंगतियों को दूर करने से परीक्षण और डीबग करना आसान हो जाता है। ऑर्केस्ट्रेशन आपको स्केलेबल एप्लिकेशन बनाने की अनुमति देता है।

संदर्भ

• पिछला लेख
• InterSystems सामुदायिक श्रृंखला
• कोड
• गिथब कोड