यूनिक्स बायनेरिज़ के करीब अन्य भाषाओं की तुलना में जावा का उपयोग करते समय डॉकर का उपयोग करने के विकास लाभ उपेक्षित हैं?


53

मेरा एक दोस्त था जिसने कहा था:

डॉकर अद्भुत है। आप इसका उपयोग अपने स्थानीय मशीन पर उत्पादन और उसके सभी quirks को दोहराने के लिए कर सकते हैं । फिर आप उस उदाहरण को सभी स्टेजिंग वर्कफ़्लोज़ सुपर- क्विक के माध्यम से सीधे परिनियोजित कर सकते हैं ।

अब यह सच होगा यदि डेवलपर्स रूबी, पीएचपी या गो लिख रहे थे - जहां ऑपरेटिंग सिस्टम के लिए एक दिशा बाइनरी लिंक था।

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

यकीनन, इस मामले में, उत्पादन पर्यावरण को दोहराने के लिए स्थानीय रूप से डेवलपर्स के लिए डॉकर चलाने के लाभों को नकार दिया जाता है । (रूबी, पीएचपी या गो की तुलना में)।

मैं इस पर चर्चा करने के लिए खुला हूं और एक विवादास्पद बिंदु (सबूत के साथ) सुनने के लिए उत्सुक हूं।

यूनिक्स बायनेरिज़ के करीब अन्य भाषाओं की तुलना में जावा का उपयोग करते समय डॉकर का उपयोग करने के विकास लाभ उपेक्षित हैं?


34
आपको क्या लगता है रूबी और php बाइनरी क्यों हैं? रूबी और php जावा की तुलना में तकनीकी रूप से और भी अधिक आभासी हैं - जावा में आपको पहले अपने प्रोग्राम को एक वर्चुअल मशीन में निष्पादित करना होगा। रूबी और php में आप सोर्स कोड को शिप करते हैं और वर्चुअल मशीन सीधे सोर्स को पढ़ती है।
स्लीवेटमैन

12
"लेकिन जावा का उपयोग करते समय - ऑपरेशन सिस्टम और भाषा के बीच पहले से ही एक आभासी परत होती है, जो अंतर्निहित ऑपरेटिंग सिस्टम की परवाह किए बिना ऑपरेशन की निरंतरता बना रही है।" जावा ने आविष्कार किया "एक बार लिखो, हर जगह परीक्षण करो।"
एंडी

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

1
"अंतर्निहित ऑपरेटिंग सिस्टम की परवाह किए बिना ऑपरेशन की निरंतरता बनाना" ध्यान दें कि भाषा रनटाइम बनाने से लगातार व्यवहार होता है इस तथ्य को नकारना नहीं है कि आपके पास अभी भी कुछ बाहरी निर्भरताएं हैं। अपने लॉग के लिए एक विशेष फ़ाइल पथ का उपयोग करते हुए कुछ सरल हो सकता है।
jpmc26

जवाबों:


86

हर्गिज नहीं।

कल्पना करें कि आप अपने विकास मशीन और सर्वर दोनों पर जावा का संस्करण 1.8.0 चला रहे हैं। वैसे, आप दो परियोजनाओं पर एक साथ काम कर रहे हैं, दोनों जावा का उपयोग कर रहे हैं।

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

अब, कम से कम एक परियोजना के लिए, आप जावा का एक अलग संस्करण चला रहे हैं।

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

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


20
इसके अलावा इस तरह की बात बड़ी कंपनियों में हर समय होती है। यह सिर्फ एक सैद्धांतिक बात नहीं है।
एंडरलैंड

5
जब आप डॉकर में बग खोजते हैं तो आप क्या करते हैं?
ओवेन

इसके अलावा जावा 9 चीजों को तोड़ देगा। काफी कुछ प्रयास की जरूरत होगी।
थोर्बोजर्न रावन एंडरसन

8
@ जब आप जावा में बग ढूंढते हैं तो वही काम करते हैं। या {लिनक्स, विंडोज} में। या अपने सीपीयू में
क्रोल्टन

1
@ सूचना: हां, हालांकि कंपनी डेवलपर्स द्वारा ब्लॉग पोस्ट के रूप में ज्यादातर। उस ने कहा, docker.com/customers पर कोई भी "अधिक जानें" लिंक ऐसी समस्याओं को हल करने के लिए docker का उपयोग करके बड़ी कंपनियों के उदाहरण प्रदान करेगा। उस ने कहा, आम तौर पर ऐसी कंपनियां इसे इस बात के लिए ले रही थीं कि उन्हें उत्पादन और विकास के बीच एक परिपूर्ण मैच की जरूरत है, और वीएम के साथ इसे पूरा किया। बाद में, उन्होंने महसूस किया, "हे, डोकर वीएम के रूप में एक ही समस्या को हल करता है, सिवाय इसके कि यह तेजी से चलता है और इसका उपयोग तैनाती को बनाए रखने के लिए किया जा सकता है।"
ब्रायन

35

आप शायद ही कभी एक "जावा ऐप" तैनात करते हैं। आपके जावा एप्लिकेशन में इसके चारों ओर बहुत सारे विभिन्न सहायता कार्यक्रम हैं। हम Apache HTTPD, Apache Tomcat, मैसेजिंग के लिए ActiveMQ, एक FTP Deamon, MySQL और एक मुट्ठी भर कस्टम सेवाओं को उन प्रोग्रामों के साथ एकीकृत करने के लिए उपयोग करते हैं जो जावा के साथ सीधे काम नहीं करते हैं।

यह विकास सॉफ़्टवेयर में भी नहीं जाता है जो इसके साथ जाता है - ग्रहण, चींटी, एडोब फ्लेक्स, ग्रूवी, फ़ायरफ़ॉक्स और तोड़फोड़ (मैं काफी कुछ छोड़ रहा हूं)

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

इस तथ्य का उल्लेख नहीं करने के लिए कि जब हम तैनात करते हैं तो हमें ऊपर - 20 सर्वरों को बनाए रखने की आवश्यकता होती है; डॉकर एक बहुत अच्छा सौदा की तरह लग रहा है!

(20 ऐसा लगता है कि एक ऐप के लिए बहुत दर्दनाक है जो केवल एक समय में एक सर्वर पर चलता है ... लेकिन यह कि क्लस्टर (x2), परीक्षण / मंचन / ठेस (x3), आंतरिक / बाहरी (x2) और प्राथमिक साइट द्वारा एक सर्वर को गुणा करें / बैकअप साइट (x2) और आप वहां बहुत जल्दी पहुंच जाते हैं)


चित्र क्यों नहीं बनाये?
दिमित्री कुदरियात्सेव

हम आशा करते है। हम एक छोटी सी टीम का उपयोग कर रहे हैं जो बहुत अधिक उपयोग / महत्वपूर्ण प्रणाली में सुविधाओं को जोड़ने की कोशिश कर रहा है और उनकी तैनाती तय करने के लिए सर्वर पर पर्याप्त नियंत्रण नहीं है। हालांकि देव के लिए इसका इस्तेमाल किया जा सकता है, हम पहले से ही 32mb RAM पर पहले से ही विवश हैं - मुझे लगता है कि डॉक इमेज से चलने से कुछ ओवरहेड होगा ... लेकिन हमारी योजना उस दिशा में आगे बढ़ने की है।
बिल के।

मैं कार्यस्थलों के लिए था
दिमित्री कुदरियात्सेव

समय और स्मृति - हमें पहले से ही अपने 32gb कार्यस्थानों में चलाने के लिए टुकड़ों को छोड़ना होगा (64gb सर्वर इसे सभी ठीक चलाते हैं)। हमने हालांकि थोड़ा प्रयोग किया है और अगली बार जब हमें एक नया देव कार्य केंद्र बनाने की आवश्यकता होती है, तो हम इसे आजमा सकते हैं।
बिल के

8

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

यहाँ जवाब देने के लिए दो बिंदु हैं:

एक: वहाँ एक बेहतर तरीका है , और वहाँ है: आप सिर्फ स्थापित वातावरण का उपयोग कर छोटे (और अधिक कुशल) docker कंटेनरों का निर्माण कर सकते हैं, जो कि गोलंग-के-पर्यावरण बनाम गोलंग-बस के मामले में समान फायदे की ओर जाता है -बच्चे कंटेनर। जावा के मामले में, आप एक मोटी जार या एक इंस्टॉल करने योग्य ऐप बना सकते हैं जिसमें सभी लाइब्रेरी जार और एक शेल स्क्रिप्ट शामिल है; पायथन के मामले में, आप स्व-निहित पहियों के निर्माण के लिए ऑडिटव्हील का उपयोग कर सकते हैं जो बिल्ड पर्यावरण से स्वतंत्र हैं (और आप लगभग उसी प्रभाव के साथ स्थैतिक लिंकिंग के साथ C ++ का उपयोग कर सकते हैं)।

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

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


5

यह एक बहुत अच्छा सवाल है, लेकिन डॉकर के साथ काम करने के बाद, मैं इसे घुमा दूंगा:

क्या JVM के लाभ को कंटेनरीकरण (जैसे डोकर) से नकारा जाता है?

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

मैंने हाल ही में जावा और डॉकर के साथ एक प्रोटोटाइप एप्लिकेशन बनाया है जो अनिवार्य रूप से जीसी घटनाओं को देखता था और जब ढेर का पुराना हिस्सा थ्रेशोल्ड प्रतिशत से टकराता था, तो यह अपने आप बंद हो जाता था। डॉकर (झुंड मोड) फिर एक नया स्पिन करेगा। अनिवार्य रूप से, इसने JVM में प्रमुख GC-cycles की आवश्यकता को समाप्त कर दिया और docker को उनका प्रबंधन करने दिया। यह काम नहीं करता था और साथ ही मुझे उम्मीद थी कि (ग्राहकों ने बंद का कुछ असर देखा होगा) लेकिन यह एक भीड़ के लिए लाइव डेमो करने के लिए पर्याप्त कार्यात्मक था।

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


"... लेकिन कम से कम एक अन्य व्यवहार्य विकल्प है जो सभी के लिए अच्छा है" तो क्या यह एक अन्य व्यवहार्य विकल्प हो सकता है?
ट्रिलियनियन

@ ट्रिलियन रेक (या रॉकेट) । यह फिलहाल डॉकर के साथ कुबेरनेट्स द्वारा समर्थित है।
जिमीजम्स
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.