डकर खेलौना हो कि होइन? वा यो अझै पनि सत्य हो?

नमस्कार!

म साँच्चै विषयवस्तुमा पुग्न चाहन्छु, तर यो मेरो कथाको बारेमा थोरै बताउन अझ सही हुनेछ:

प्रवेश

म सर्भरमा फ्रन्टएन्ड एकल पृष्ठ अनुप्रयोगहरू, स्काला/जाभा र नोडजहरू विकास गर्ने अनुभव भएको प्रोग्रामर हुँ।

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

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

प्रयोगको लागि कारणहरू

मैले किन डकर प्रयोग गरें? सायद निम्न कारणहरूको लागि:

• डाटाबेस सुरुवात, 99% अनुप्रयोगहरूले तिनीहरूलाई प्रयोग गर्छन्
• फ्रन्टएन्ड वितरणको लागि nginx सुरु गर्दै र ब्याकइन्डमा प्रोक्सी गर्दै
• तपाईले अनुप्रयोगलाई डकर छविमा प्याकेज गर्न सक्नुहुन्छ, यस तरिकाले मेरो अनुप्रयोगले काम गर्नेछ जहाँ डकर अवस्थित छ, वितरण समस्या तुरुन्तै हल हुन्छ।
• बक्स बाहिर सेवा खोज, तपाईं microservices सिर्जना गर्न सक्नुहुन्छ, प्रत्येक कन्टेनर (सामान्य नेटवर्कमा जडान) सजिलै एक उपनाम मार्फत अर्को पुग्न सक्छ, धेरै सुविधाजनक
• कन्टेनर बनाउन र यसमा "खेल्नु" रमाइलो छ।

मलाई सधैं डकरको बारेमा के मन पर्दैन:

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

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

Ansible को परिचय

भर्खरै (तीन महिना अघि), मैले एक DevOps टोलीसँग काम गरें, जसको लगभग प्रत्येक सदस्यको डकरप्रति नकारात्मक दृष्टिकोण थियो। कारणहरूको लागि:

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

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

डाटाबेस जस्ता तेस्रो-पक्ष कम्पोनेन्टहरू चलाउनका लागि डकर

म भर्खरै ssh टनेलहरूसँग परिचित भएँ। यो बाहिर भयो कि यो एक स्थानीय पोर्टमा टाढाको सर्भरको पोर्ट "फर्वार्ड" गर्न धेरै सजिलो छ। रिमोट सर्भर या त क्लाउडमा रहेको मेसिन वा VirtualBox मा चलिरहेको भर्चुअल मेसिन हुन सक्छ। यदि मेरो सहकर्मी वा मलाई डाटाबेस (वा केहि अन्य तेस्रो-पक्ष कम्पोनेन्ट) चाहिन्छ भने, हामी केवल यो कम्पोनेन्टको साथ सर्भर सुरु गर्न सक्छौं र सर्भर आवश्यक नभएको बेला यसलाई बन्द गर्न सक्छौं। पोर्ट फर्वार्डिङले डकर कन्टेनरमा चलिरहेको डाटाबेस जस्तै प्रभाव दिन्छ।

यो आदेशले मेरो स्थानीय पोर्टलाई postgresql चलिरहेको रिमोट सर्भरमा फर्वार्ड गर्छ:

ssh -L 9000:localhost:5432 [ईमेल सुरक्षित]

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

मैले भर्खरै पढें कि SSH टनेलहरू नियमित VPN को सीमित कार्यक्षमता हुन्! तपाईं केवल OpenVPN वा अन्य VPN कार्यान्वयनहरू स्थापना गर्न सक्नुहुन्छ, पूर्वाधार सेटअप गर्नुहोस् र विकासकर्ताहरूलाई प्रयोगको लागि दिन सक्नुहुन्छ। यो धेरै राम्रो छ!

सौभाग्यवश, AWS, GoogleCloud र अरूले तपाईंलाई एक वर्षको निःशुल्क प्रयोग दिन्छ, त्यसैले तिनीहरूलाई प्रयोग गर्नुहोस्! तिनीहरू सस्तो छन् यदि तपाइँ तिनीहरूलाई प्रयोगमा नभएको बेला बन्द गर्नुहुन्छ। म सधैं सोच्थें किन मलाई gcloud जस्तै रिमोट सर्भर चाहिन्छ, यस्तो देखिन्छ कि मैले तिनीहरूलाई फेला पारे।

स्थानीय भर्चुअल मेसिनको रूपमा, तपाईंले उही अल्पाइन प्रयोग गर्न सक्नुहुन्छ, जुन सक्रिय रूपमा डकर कन्टेनरहरूमा प्रयोग गरिन्छ। ठीक छ, वा केहि अन्य हल्का वितरणहरू मेसिन बुट छिटो बनाउन।

तल्लो रेखा: तपाईले डाटाबेसहरू र अन्य पूर्वाधार सामानहरू रिमोट सर्भर वा भर्चुअलबक्समा चलाउन सक्नुहुन्छ र चलाउनु पर्छ। मलाई यी उद्देश्यका लागि डकर आवश्यक पर्दैन।

डकर छविहरू र वितरणको बारेमा थोरै

मैले पहिले नै लेखेको छु लेख जसमा म यो बताउन चाहन्छु कि डकर छविहरू प्रयोग गर्दा कुनै ग्यारेन्टी प्रदान गर्दैन। डकर कन्टेनर सिर्जना गर्न डकर छविहरू मात्र आवश्यक छ। यदि तपाइँ डकर छविमा अपग्रेड गर्दै हुनुहुन्छ भने, तपाइँ डकर कन्टेनरहरू प्रयोग गर्न अपग्रेड गर्दै हुनुहुन्छ र तपाइँ तिनीहरूलाई मात्र प्रयोग गर्नुहुनेछ।

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

सामान्यतया, तपाइँ यसलाई tgz मा भण्डारण गर्न सक्नुहुन्छ, यदि कसैले यसलाई डकरमा चलाउन आवश्यक छ भने, त्यसपछि उनीहरूलाई डकरफाइलमा tgz थप्न दिनुहोस्, इच्छित वातावरणबाट इनहेरिट गर्नुहोस् र थप बनहरू सिर्जना गर्नुहोस् जसले tgz मा अनुप्रयोग परिवर्तन गर्दैन। डकर छवि सिर्जना गर्ने जो कोहीले tgz के हो र उसले काम गर्न आवश्यक छ भनेर थाहा पाउनेछ। यसरी म डकर प्रयोग गर्छु यहाँ

तल्लो रेखा: मलाई डकर रेजिस्ट्री चाहिँदैन, म केहि प्रकारको S3 वा केवल फाइल भण्डारण जस्तै गुगल ड्राइभ/ड्रपबक्स प्रयोग गर्नेछु।

CI मा डकर

मैले काम गरेको सबै कम्पनीहरू समान छन्। तिनीहरू सामान्यतया किराना हुन्। त्यो हो, तिनीहरूसँग एउटा अनुप्रयोग छ, एउटा प्रविधि स्ट्याक (राम्रो, हुनसक्छ दुई वा तीन प्रोग्रामिङ भाषाहरू)।

यी कम्पनीहरूले उनीहरूको सर्भरमा डकर प्रयोग गर्छन् जहाँ CI प्रक्रिया चल्छ। प्रश्न: तपाइँ किन तपाइँको सर्भरहरूमा डकर कन्टेनरमा परियोजनाहरू निर्माण गर्न आवश्यक छ? किन निर्माणको लागि वातावरण तयार नगर्ने, उदाहरणका लागि, एउटा उत्तरदायी प्लेबुक लेख्नुहोस् जसले निर्माण हुने सर्भरमा nodejs, php, jdk, प्रतिलिपि ssh कुञ्जीहरू, आदि को आवश्यक संस्करणहरू स्थापना गर्नेछ?

अब म बुझ्छु कि यो आफैलाई खुट्टामा गोली हानेको छ, किनकि डकरले यसको अलगाव संग कुनै लाभ ल्याउँदैन। डकरमा CI सँग मैले सामना गरेको समस्याहरू:

• फेरि तपाईंलाई निर्माण गर्न डकर छवि चाहिन्छ। तपाईंले छवि खोज्न वा आफ्नै डकरफाइल लेख्न आवश्यक छ।
• 90% जुन तपाइँले केहि ssh कुञ्जीहरू फर्वार्ड गर्न आवश्यक छ, गोप्य डाटा जुन तपाइँ डकर छविमा लेख्न चाहनुहुन्न।
• कन्टेनर बनाइन्छ र मर्छ, सबै क्यासहरू सँगै हराउँछन्। अर्को निर्माणले सबै परियोजना निर्भरताहरू पुन: डाउनलोड गर्नेछ, जुन समय खपत र अप्रभावी छ, र समय पैसा हो।

विकासकर्ताहरूले डकर कन्टेनरहरूमा परियोजनाहरू निर्माण गर्दैनन् (म एक पटक यस्तो प्रशंसक थिएँ, वास्तवमा, म विगतको xD मा मेरो लागि दु: खी छु)। जाभामा धेरै संस्करणहरू हुन सम्भव छ र तिनीहरूलाई एउटा आदेशको साथ तपाईलाई अहिले चाहिनेमा परिवर्तन गर्नुहोस्। यो nodejs मा समान छ, त्यहाँ nvm छ।

निष्कर्षमा

मलाई विश्वास छ कि डकर एक धेरै शक्तिशाली र लचिलो उपकरण हो, यो यसको कमजोरी हो (अनौठो लाग्छ, हो)। यसको मद्दतले, कम्पनीहरूले यसलाई सजिलैसँग जोड्न सक्छन् र यसलाई आवश्यक र आवश्यक नभएको ठाउँमा प्रयोग गर्न सक्छन्। विकासकर्ताहरूले तिनीहरूका कन्टेनरहरू, तिनीहरूका केही वातावरणहरू सुरू गर्छन्, त्यसपछि यो सबै सहज रूपमा CI र उत्पादनमा प्रवाह हुन्छ। DevOps टोलीले यी कन्टेनरहरू चलाउनको लागि केही प्रकारको कोड लेखिरहेको छ।

डकर मात्र प्रयोग गर्नुहोस् सबैभन्दा हालको तपाईंको कार्यप्रवाहको चरणमा, यसलाई सुरुमा परियोजनामा ​​तान्नुहोस्। यसले तपाईंको व्यापार समस्याहरू समाधान गर्दैन। उसले समस्यालाई अर्को तहमा लैजान्छ र आफ्नै समाधान दिन्छ, तपाईले दोहोरो काम गर्नुहुनेछ।

जब डकर आवश्यक छ: म निष्कर्षमा पुगें कि डकर दिइएको प्रक्रियालाई अनुकूलन गर्न धेरै राम्रो छ, तर आधारभूत कार्यक्षमता निर्माण गर्न होइन।

यदि तपाइँ अझै पनि डकर प्रयोग गर्ने निर्णय गर्नुहुन्छ भने, त्यसपछि:

• धेरै सावधान रहनुहोस्
• विकासकर्ताहरूलाई डकर प्रयोग गर्न बाध्य नगर्नुहोस्
• यसको प्रयोगलाई एकै ठाउँमा स्थानीयकरण गर्नुहोस्, यसलाई सबै डकफाइल र डकर-कम्पोज रिपोजिटरीहरूमा नफैलाउनुहोस्

PS:

• मैले भर्खरै भेटें प्याकर र तिनीहरू भन्छन् कि यसले उत्तरदायीसँग धेरै राम्रोसँग काम गर्दछ र तपाईंलाई छविहरू निर्माण गर्ने प्रक्रियालाई एकताबद्ध गर्न अनुमति दिन्छ (डकर छवि सहित)
• डकरको बारेमा पनि, रोचक लेख

पढ्नु भएकोमा धन्यवाद, म तपाईका मामिलाहरूमा पारदर्शी निर्णयहरू र उत्पादक कार्य दिनहरूको कामना गर्दछु!

स्रोत: www.habr.com