🐝 🤦🏼 🎱 प्रोजेक्ट डॉकटर के साथ इंफ्रास्ट्रक्चर का निर्माण करें 👩🏿‍🔬 🐳 🅰️

Habr पर पहले से ही सामग्री है कि परियोजना के संकलन के लिए docker- कंटेनर को कैसे कॉन्फ़िगर किया जाए । उदाहरण के लिए, C ++ प्रोजेक्ट बनाने और चलाने के लिए Docker का उपयोग करना । इस आलेख में, पिछले एक के रूप में , परियोजना के निर्माण के मुद्दे पर विचार किया जाएगा, लेकिन यहां मैं ट्यूटोरियल से परे जाना चाहता हूं और ऐसे कार्यों में कंटेनरों के उपयोग के मुद्दों पर अधिक गहराई से विचार करना चाहता हूं, साथ ही डॉक के साथ बिल्ड इंफ्रास्ट्रक्चर का निर्माण करना होगा।

कर्ता के बारे में थोड़ा

आगे की चर्चा की स्पष्टता के लिए, कुछ डॉकटर घटकों का विवरण प्रदान करना आवश्यक है।

छवि

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

उदाहरण के लिए, डॉकरफाइल के लिए :

FROM ubuntu:18.04 ADD app.sh /app ENTRYPOINT /bin/bash /app/app.sh

डॉकटर छवि में निम्नलिखित संरचना होगी:

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

पात्र

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

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

docker run का उपयोग करते समय, हर बार एक नया कंटेनर बनाया जाएगा, जिसमें लेखन के लिए अपनी खुद की परत होगी। निर्माण कार्यों में, इसका मतलब है कि हर बार जब यह शुरू होता है, तो यह एक नया स्वच्छ वातावरण बनाएगा जिसका पिछले निष्पादन के साथ कोई लेना देना नहीं है। बनाए गए कंटेनरों की सूची को कमांड चलाकर देखा जा सकता है: docker container ls -a ।

हम परियोजना को कंटेनर में एकत्र करते हैं

स्पष्टता के लिए, हम एक कंटेनर में एक आवेदन के निर्माण की प्रक्रिया का संक्षेप में वर्णन करते हैं, इस प्रक्रिया को लेख 1 और लेख 2 में अधिक विस्तार से वर्णित किया गया है।

डॉकटर में अनुप्रयोग के निर्माण के लिए योजनाबद्ध रूप से संभव चरणों का प्रतिनिधित्व निम्न प्रकार से किया जा सकता है:

आइए दिखाए गए चरणों का विश्लेषण करें:

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

एक उदाहरण लेख में दिया गया है।

चूंकि docker run का उपयोग यहां किया जाता है, प्रत्येक लॉन्च के लिए लेखन के लिए अपनी परत के साथ एक अलग कंटेनर बनाया जाएगा, इसलिए पिछले विधानसभाओं से अस्थायी फाइलें वर्तमान में नहीं मिलेंगी। बंद कंटेनरों को साफ करना याद रखें।

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

 FROM ubuntu:bionic RUN apt-get update \ && apt-get install -y apt-utils RUN apt-get update \ && apt-get install -y make gcc g++ qt5-default git RUN mkdir -p /app/src WORKDIR /app/build #       ENTRYPOINT git -C /app/src clone https://github.com/sqglobe/SimpleQtProject.git \ && qmake /app/src/SimpleQtProject/SimpleQtProject.pro \ && make \ && cp SimpleQtProject /app/res/SimpleQtProject-ubuntu-bionic

यहां, क्लोनिंग ENTRYPOINT में की ENTRYPOINT , RUN स्टेटमेंट में नहीं, कैशिंग के कारण। कंटेनर शुरू होने पर ENTRYPOINT को हमेशा निष्पादित किया जाता है, और RUN कमांड का परिणाम कैश से लिया जा सकता है।

इन्फ्रास्ट्रक्चर का निर्माण करें

विभिन्न ऑपरेटिंग सिस्टम या लिनक्स वितरण के लिए एक प्रोजेक्ट बनाने के लिए, सर्वरों का एक निश्चित कॉन्फ़िगरेशन (बिल्ड मशीन, एक संस्करण नियंत्रण प्रणाली, आदि के साथ सर्वर) का उपयोग किया जा सकता है। व्यवहार में, मुझे निम्नलिखित बुनियादी ढांचे से निपटना था:

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

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

Minuses में से - संपूर्ण बुनियादी ढांचे को बनाए रखना, कई सर्वरों को प्रबंधित करना, स्क्रिप्ट और वेब अनुप्रयोगों में बग को समाप्त करना आदि।

कर्ता के साथ सरलीकरण करें

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

एक सामान्य Qt प्रोजेक्ट पर विचार करें जो qmake - SimpleQtProject का उपयोग करके बनाया गया है। निर्दिष्ट प्रोजेक्ट के डॉक फ़ोल्डर में कई फाइलें हैं:

centos7.docker - CentOS 7 के लिए एक परियोजना के निर्माण के लिए एक कंटेनर का वर्णन करता है;
ubuntu-bionic.docker - उबंटू 18.04 के तहत निर्माण के लिए एक कंटेनर;
ubuntu-xenial.docker - Ubuntu 16.04 के तहत निर्माण के लिए एक कंटेनर का वर्णन करता है।

ये फाइलें कंटेनर के अंदर सोर्स कोड के क्लोनिंग के विचार को लागू करती हैं।

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

 %: %.docker docker build -t simple-qt-$(strip $(subst .docker,, $< )) --file $< . docker run --mount type=bind,source=$(RELEASE_DIR),target=/app/res simple-qt-$(strip $(subst .docker,, $< ))

असेंबली के इस चरण में, कंटेनर की एक छवि उपसर्ग सरल-क्यूटी- और सिस्टम के नाम से मिलकर नाम के साथ बनाई गई है ( सेंटोस 7 के लिए यह सरल-क्यूटी-सेंटोस 7 होगा)। Dockerfile के रूप में, .docker अनुमति के साथ संबंधित फ़ाइल का उपयोग किया जाता है । अगला, कंटेनर निर्मित छवि के आधार पर लॉन्च किया गया है, और असेंबली कलाकृतियों की प्रतिलिपि बनाने के लिए उस पर एक फ़ोल्डर लगाया गया है।

Docker निर्देशिका में make चलाने के बाद, docker / release फ़ोल्डर में कई प्लेटफ़ॉर्म के लिए बिल्ड परिणाम होंगे।

इस प्रकार, SimpleQtProject के निर्माण के लिए हमारा बुनियादी ढांचा इस तरह दिखेगा:

इस विन्यास के लाभ:

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

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

बंद कंटेनरों को साफ करने के लिए याद रखना भी आवश्यक है।

निष्कर्ष

अंत में, मैं यह नोट करना चाहूंगा कि docker केवल कंटेनरीकरण तकनीक नहीं है। लेकिन कुछ विशेषताएं हैं जो इसे समान LXC से विधानसभा कार्यों के लिए अनुकूल रूप से अलग करती हैं:

आप एक पाठ Dockerfile का उपयोग करके एक कंटेनर बना सकते हैं। यह सरल वाक्यविन्यास के साथ एक फाइल है, आप इसे प्रोजेक्ट रिपॉजिटरी (जैसा कि मैं हमेशा करता हूं) में जोड़ सकते हैं और इसे लगातार हाथ में रख सकते हैं।
हर बार, docker run साथ डॉक कंटेनर को लॉन्च करने से docker run हमें एक स्वच्छ वातावरण मिलता है, जैसे कि हम पहली बार सब कुछ कर रहे थे। असेंबलियों के बीच अस्थायी फ़ाइलें सहेजे नहीं जाते हैं।
कंटेनर पूरे ऑपरेटिंग सिस्टम को लॉन्च नहीं करता है, लेकिन केवल आवश्यक विधानसभा प्रक्रिया है।

प्रोजेक्ट डॉकटर के साथ इंफ्रास्ट्रक्चर का निर्माण करें