डॉकर एक खिलौना है या नहीं? या यह अभी भी सच है?

सभी को नमस्कार!

मैं वास्तव में सीधे विषय पर आना चाहता हूं, लेकिन अपनी कहानी के बारे में थोड़ा बताना अधिक सही होगा:

प्रवेश

मैं एक प्रोग्रामर हूं जिसके पास सर्वर पर फ्रंटएंड सिंगल पेज एप्लिकेशन, स्कैला/जावा और नोडज विकसित करने का अनुभव है।

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

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

उपयोग के कारण

मैंने डॉकर का उपयोग क्यों किया? संभवतः निम्नलिखित कारणों से:

• डेटाबेस लॉन्च, 99% एप्लिकेशन उनका उपयोग करते हैं
• फ्रंटएंड वितरण और बैकएंड पर प्रॉक्सी के लिए nginx लॉन्च करना
• आप एप्लिकेशन को डॉकर छवि में पैकेज कर सकते हैं, इस तरह जहां भी डॉकर मौजूद है मेरा एप्लिकेशन काम करेगा, वितरण समस्या तुरंत हल हो जाएगी
• बॉक्स से बाहर सेवा खोज, आप माइक्रोसर्विसेज बना सकते हैं, प्रत्येक कंटेनर (एक सामान्य नेटवर्क से जुड़ा) आसानी से एक उपनाम के माध्यम से दूसरे तक पहुंच सकता है, बहुत सुविधाजनक
• एक कंटेनर बनाना और उसमें "खेलना" मज़ेदार है।

डॉकर के बारे में मुझे हमेशा क्या पसंद नहीं है:

• मेरे एप्लिकेशन को काम करने के लिए, मुझे सर्वर पर स्वयं डॉकर की आवश्यकता है। यदि मेरे एप्लिकेशन jre या nodejs पर चलते हैं और उनके लिए वातावरण पहले से ही सर्वर पर है तो मुझे इसकी आवश्यकता क्यों है?
• यदि मैं अपनी (निजी) स्थानीय रूप से निर्मित छवि को किसी दूरस्थ सर्वर पर चलाना चाहता हूं, तो मुझे अपने स्वयं के डॉकर रिपॉजिटरी की आवश्यकता है, मुझे कहीं काम करने के लिए रजिस्ट्री की आवश्यकता है और मुझे https को कॉन्फ़िगर करने की भी आवश्यकता है, क्योंकि डॉकर सीएलआई केवल https पर काम करता है। ओह लानत है... बेशक, छवि को स्थानीय रूप से सहेजने के विकल्प मौजूद हैं docker save और केवल एससीपी के माध्यम से छवि भेजें... लेकिन यह शरीर की बहुत सी गतिविधियाँ हैं। और इसके अलावा, यह एक "बैसाखी" समाधान जैसा दिखता है जब तक कि आपका अपना भंडार प्रकट न हो जाए
• docker-compose. इसकी आवश्यकता केवल कंटेनरों को चलाने के लिए होती है। बस इतना ही। वह और कुछ नहीं कर सकता. Docker-compose इसकी फ़ाइलों के कई संस्करण हैं, इसका अपना सिंटैक्स है। इससे कोई फर्क नहीं पड़ता कि यह कितना घोषणात्मक है, मैं उनके दस्तावेज़ पढ़ना नहीं चाहता। मुझे इसकी कहीं और जरूरत नहीं पड़ेगी.
• एक टीम में काम करते समय, अधिकांश लोग डॉकरफ़ाइल को बहुत टेढ़े-मेढ़े तरीके से लिखते हैं, समझ नहीं पाते हैं कि इसे कैसे कैश किया जाता है, छवि में वह सब कुछ जोड़ देते हैं जिसकी उन्हें आवश्यकता होती है और जिसकी उन्हें आवश्यकता नहीं है, उन छवियों से विरासत में लेते हैं जो डॉकरहब या निजी रिपॉजिटरी में नहीं हैं, कुछ बनाते हैं docker-compose डेटाबेस वाली फ़ाइलें और कुछ भी नहीं रहता है। उसी समय, डेवलपर्स गर्व से घोषणा करते हैं कि डॉकर अच्छा है, उनके लिए सब कुछ स्थानीय रूप से काम करता है, और एचआर महत्वपूर्ण रूप से रिक्ति में लिखते हैं: "हम डॉकर का उपयोग करते हैं और हमें ऐसे कार्य अनुभव वाले उम्मीदवार की आवश्यकता है।"
• मैं डॉकर में सब कुछ बढ़ाने के विचारों से लगातार परेशान रहता हूं: पोस्टग्रेस्क्ल, काफ्का, रेडिस। यह अफ़सोस की बात है कि सब कुछ कंटेनरों में काम नहीं करता है, सब कुछ कॉन्फ़िगर करना और चलाना आसान नहीं है। यह तीसरे पक्ष के डेवलपर्स द्वारा समर्थित है, न कि स्वयं विक्रेताओं द्वारा। और वैसे, सवाल तुरंत उठता है: विक्रेताओं को डॉकर में अपने उत्पादों को बनाए रखने की चिंता नहीं है, ऐसा क्यों है, शायद वे कुछ जानते हैं?
• कंटेनर डेटा की दृढ़ता के बारे में हमेशा सवाल उठता है। और फिर आप सोचते हैं, क्या मुझे सिर्फ होस्ट डायरेक्टरी को माउंट करना चाहिए या एक डॉकर वॉल्यूम बनाना चाहिए या एक डेटा कंटेनर बनाना चाहिए जो अभी है deprecated? यदि मैं एक निर्देशिका माउंट करता हूं, तो मुझे यह सुनिश्चित करना होगा कि कंटेनर में उपयोगकर्ता का यूआईडी और जीआईडी ​​कंटेनर लॉन्च करने वाले उपयोगकर्ता की आईडी से मेल खाता है, अन्यथा कंटेनर द्वारा बनाई गई फाइलें रूट अधिकारों के साथ बनाई जाएंगी। अगर मैं उपयोग करता हूँ volume तो डेटा बस कुछ में बनाया जाएगा /usr/* और यूआईडी और जीआईडी ​​के साथ भी वही कहानी होगी जो पहले मामले में थी। यदि आप एक तृतीय-पक्ष घटक लॉन्च कर रहे हैं, तो आपको दस्तावेज़ पढ़ना होगा और प्रश्न का उत्तर ढूंढना होगा: "घटक किस कंटेनर निर्देशिका में फ़ाइलें लिखता है?"

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

अन्सिबल का परिचय

हाल ही में (तीन महीने पहले), मैंने एक DevOps टीम के साथ काम किया, जिसके लगभग हर सदस्य का डॉकर के प्रति नकारात्मक रवैया था। कारणों से:

• डॉकर नियम iptables (हालाँकि आप इसे daemon.json में अक्षम कर सकते हैं)
• डॉकर छोटी गाड़ी है और हम इसे उत्पादन में नहीं चलाएंगे
• यदि डॉकर डेमॉन दुर्घटनाग्रस्त हो जाता है, तो बुनियादी ढांचे वाले सभी कंटेनर तदनुसार दुर्घटनाग्रस्त हो जाते हैं
• डोकर की कोई जरूरत नहीं
• अगर Ansible और वर्चुअल मशीनें हैं तो docker क्यों?

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

डेटाबेस जैसे तृतीय-पक्ष घटकों को चलाने के लिए डॉकर

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

यह आदेश मेरे स्थानीय पोर्ट को पोस्टग्रेस्क्ल चलाने वाले दूरस्थ सर्वर पर अग्रेषित करता है:

एसएसएच -एल 9000:लोकलहोस्ट:5432 [ईमेल संरक्षित]

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

मैंने हाल ही में पढ़ा है कि SSH सुरंगें एक नियमित वीपीएन की सीमित कार्यक्षमता हैं! आप बस ओपनवीपीएन या अन्य वीपीएन कार्यान्वयन स्थापित कर सकते हैं, बुनियादी ढांचा स्थापित कर सकते हैं और इसे डेवलपर्स को उपयोग के लिए दे सकते हैं। यह बहुत अच्छा है!

सौभाग्य से, AWS, GoogleCloud और अन्य आपको एक वर्ष का निःशुल्क उपयोग देते हैं, इसलिए उनका उपयोग करें! यदि आप उपयोग में न होने पर उन्हें बंद कर दें तो वे सस्ते हैं। मैं हमेशा सोचता था कि मुझे gcloud जैसे रिमोट सर्वर की आवश्यकता क्यों होगी, ऐसा लगता है कि मुझे वह मिल गया।

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

निचली पंक्ति: आप दूरस्थ सर्वर या वर्चुअलबॉक्स पर डेटाबेस और अन्य बुनियादी ढाँचे को चला सकते हैं और चलाना भी चाहिए। मुझे इन उद्देश्यों के लिए डॉकर की आवश्यकता नहीं है।

डॉकर छवियों और वितरण के बारे में थोड़ा

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

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

सामान्य तौर पर, आप इसे आसानी से tgz में संग्रहीत कर सकते हैं, यदि किसी को इसे docker में चलाने की आवश्यकता है, तो उन्हें Dockerfile में tgz जोड़ने दें, वांछित वातावरण से प्राप्त करें और अतिरिक्त बन्स बनाएं जो एप्लिकेशन को tgz में नहीं बदलते हैं। जो कोई भी डॉकर छवि बनाएगा उसे पता होगा कि tgz क्या है और उसे क्या काम करने की आवश्यकता है। इस प्रकार मैं डॉकर का उपयोग करता हूं यहां

निचली पंक्ति: मुझे डॉकर रजिस्ट्री की आवश्यकता नहीं है, मैं किसी प्रकार के S3 या Google ड्राइव/ड्रॉपबॉक्स जैसे फ़ाइल संग्रहण का उपयोग करूंगा

सीआई में डोकर

मैंने जिन कंपनियों के लिए काम किया है वे सभी एक जैसी हैं। वे आम तौर पर किराना सामान होते हैं। यानी, उनके पास एक एप्लिकेशन, एक टेक्नोलॉजी स्टैक (ठीक है, शायद कुछ या तीन प्रोग्रामिंग भाषाएं) हैं।

ये कंपनियाँ अपने सर्वर पर docker का उपयोग करती हैं जहाँ CI प्रक्रिया चलती है। प्रश्न: आपको अपने सर्वर पर डॉकर कंटेनर में प्रोजेक्ट बनाने की आवश्यकता क्यों है? क्यों न केवल निर्माण के लिए एक वातावरण तैयार किया जाए, उदाहरण के लिए, एक Ansible प्लेबुक लिखें जो नोडज, php, jdk, कॉपी ssh कुंजियों आदि के आवश्यक संस्करणों को उस सर्वर पर स्थापित करेगा जिसमें निर्माण होगा?

अब मैं समझ गया हूं कि यह अपने पैरों पर कुल्हाड़ी मारने जैसा है, क्योंकि डॉकर अपने अलगाव से कोई लाभ नहीं लाता है। डॉकर में सीआई के साथ मुझे जिन समस्याओं का सामना करना पड़ा:

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

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

उत्पादन

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

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

जब डॉकर की जरूरत हो: मैं इस निष्कर्ष पर पहुंचा कि डॉकर किसी दी गई प्रक्रिया को अनुकूलित करने में बहुत अच्छा है, लेकिन बुनियादी कार्यक्षमता के निर्माण में नहीं

यदि आप अभी भी डॉकर का उपयोग करने का निर्णय लेते हैं, तो:

• अत्यधिक सावधान रहें
• डेवलपर्स को डॉकर का उपयोग करने के लिए बाध्य न करें
• इसके उपयोग को एक ही स्थान पर स्थानीयकृत करें, इसे सभी डॉकफ़ाइल और डॉकर-कंपोज़ रिपॉजिटरी में न फैलाएं

पुनश्च:

• हाल ही में मेरी मुलाकात हुई लपेटनेवाला और वे कहते हैं कि यह Ansible के साथ बहुत अच्छी तरह से काम करता है और आपको छवियों के निर्माण की प्रक्रिया को एकीकृत करने की अनुमति देता है (डॉकर छवि सहित)
• डॉकर के बारे में भी, दिलचस्प लेख

पढ़ने के लिए धन्यवाद, मैं आपके मामलों में पारदर्शी निर्णयों और उत्पादक कार्य दिवसों की कामना करता हूँ!

स्रोत: www.habr.com