डॉकर क्या है: इतिहास और बुनियादी सार में एक संक्षिप्त भ्रमण

10 अगस्त को स्लम में शुरू हुआ डॉकर वीडियो कोर्स, जिसमें हम इसका पूरी तरह से विश्लेषण करते हैं - बुनियादी अमूर्त से लेकर नेटवर्क पैरामीटर तक।

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

डॉकर क्या है

आइए विकिपीडिया से डॉकर की परिभाषा देखें।

डॉकर कंटेनरीकृत वातावरण में अनुप्रयोगों की तैनाती और प्रबंधन को स्वचालित करने के लिए सॉफ्टवेयर है।

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

अखंड युग

अखंड युग 2000 के दशक की शुरुआत है, जब सभी अनुप्रयोग निर्भरता के समूह के साथ अखंड थे। विकास में काफी समय लगा। उसी समय, बहुत सारे सर्वर नहीं थे; हम सभी उन्हें नाम से जानते थे और उनकी निगरानी करते थे। ऐसी ही एक मजेदार तुलना है:

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

हाइपरवाइज़र-आधारित वर्चुअलाइजेशन सिस्टम

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

कर्नेल-स्तरीय वर्चुअलाइजेशन सिस्टम

कर्नेल-स्तरीय वर्चुअलाइजेशन OpenVZ, Systemd-nspawn, LXC सिस्टम द्वारा समर्थित है। ऐसे वर्चुअलाइजेशन का एक आकर्षक उदाहरण एलएक्ससी (लिनक्स कंटेनर्स) है।

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

मूलतः LXC कंटेनर बनाता है। वर्चुअल मशीन और कंटेनर के बीच क्या अंतर है?

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

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

यदि आप वास्तव में किसी चीज़ को अलग करना चाहते हैं तो हार्डवेयर हाइपरवाइज़र अच्छे हैं। क्योंकि मेमोरी पेज और प्रोसेसर के स्तर पर अलग करना संभव है।

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

कर्नेल स्तर पर कंटेनरीकरण के लिए किसका उपयोग किया जाता है?

मुख्य प्रौद्योगिकियाँ जो आपको अन्य प्रक्रियाओं से अलग कंटेनर बनाने की अनुमति देती हैं, वे हैं नेमस्पेस और कंट्रोल ग्रुप।

नामस्थान: पीआईडी, नेटवर्किंग, माउंट और उपयोगकर्ता। और भी हैं, लेकिन समझने में आसानी के लिए हम इन पर ध्यान केंद्रित करेंगे।

पीआईडी ​​नेमस्पेस प्रक्रियाओं को सीमित करता है। उदाहरण के लिए, जब हम एक पीआईडी ​​नेमस्पेस बनाते हैं और वहां एक प्रक्रिया रखते हैं, तो यह पीआईडी ​​1 के साथ बन जाता है। आमतौर पर सिस्टम में पीआईडी ​​1 सिस्टमड या इनिट होता है। तदनुसार, जब हम किसी प्रक्रिया को नए नेमस्पेस में रखते हैं, तो उसे PID 1 भी प्राप्त होता है।

नेटवर्किंग नेमस्पेस आपको नेटवर्क को सीमित/पृथक करने और अपने स्वयं के इंटरफेस को अंदर रखने की अनुमति देता है। माउंट एक फ़ाइल सिस्टम सीमा है. उपयोगकर्ता—उपयोगकर्ताओं पर प्रतिबंध।

नियंत्रण समूह: मेमोरी, सीपीयू, आईओपीएस, नेटवर्क - कुल मिलाकर लगभग 12 सेटिंग्स। अन्यथा इन्हें सीग्रुप्स ("सी-ग्रुप्स") भी कहा जाता है।

नियंत्रण समूह एक कंटेनर के लिए संसाधनों का प्रबंधन करते हैं। नियंत्रण समूहों के माध्यम से हम कह सकते हैं कि कंटेनर को एक निश्चित मात्रा से अधिक संसाधनों का उपभोग नहीं करना चाहिए।

कंटेनरीकरण को पूरी तरह से काम करने के लिए, अतिरिक्त प्रौद्योगिकियों का उपयोग किया जाता है: क्षमताएं, कॉपी-ऑन-राइट और अन्य।

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

कॉपी-ऑन-राइट प्रणाली हमें डॉकर छवियों के साथ काम करने और उन्हें अधिक कुशलता से उपयोग करने की अनुमति देती है।

डॉकर के पास वर्तमान में Cgroups v2 के साथ संगतता समस्याएँ हैं, इसलिए यह आलेख विशेष रूप से Cgroups v1 पर केंद्रित है।

लेकिन चलिए इतिहास पर वापस आते हैं।

जब वर्चुअलाइजेशन सिस्टम कर्नेल स्तर पर दिखाई दिए, तो उनका सक्रिय रूप से उपयोग किया जाने लगा। हाइपरवाइज़र पर ओवरहेड गायब हो गया, लेकिन कुछ समस्याएं बनी रहीं:

• बड़ी छवियाँ: वे एक ऑपरेटिंग सिस्टम, लाइब्रेरीज़, विभिन्न सॉफ़्टवेयर के एक समूह को एक ही OpenVZ में धकेलते हैं, और अंत में छवि अभी भी काफी बड़ी हो जाती है;
• पैकेजिंग और डिलीवरी के लिए कोई सामान्य मानक नहीं है, इसलिए निर्भरता की समस्या बनी रहती है। ऐसी स्थितियाँ होती हैं जब कोड के दो टुकड़े एक ही लाइब्रेरी का उपयोग करते हैं, लेकिन विभिन्न संस्करणों के साथ। उनके बीच टकराव हो सकता है.

इन सभी समस्याओं के समाधान के लिए अगला युग आ गया है।

कंटेनर युग

जब कंटेनरों का युग आया, तो उनके साथ काम करने का दर्शन बदल गया:

• एक प्रक्रिया - एक कंटेनर.
• हम प्रक्रिया के लिए आवश्यक सभी निर्भरताएँ उसके कंटेनर तक पहुँचाते हैं। इसके लिए मोनोलिथ को माइक्रोसर्विसेज में काटने की आवश्यकता है।
• छवि जितनी छोटी होगी, उतना बेहतर होगा - संभावित कमजोरियाँ कम होंगी, यह तेजी से सामने आएगी, इत्यादि।
• घटनाएँ क्षणभंगुर हो जाती हैं।

याद रखें मैंने पालतू जानवर बनाम मवेशियों के बारे में क्या कहा था? पहले, उदाहरण घरेलू जानवरों की तरह थे, लेकिन अब वे मवेशियों की तरह हो गए हैं। पहले, एक मोनोलिथ था - एक अनुप्रयोग। अब यह 100 माइक्रोसर्विसेज, 100 कंटेनर हैं। कुछ कंटेनरों में 2-3 प्रतिकृतियाँ हो सकती हैं। हमारे लिए हर कंटेनर को नियंत्रित करना कम महत्वपूर्ण हो जाता है। हमारे लिए जो अधिक महत्वपूर्ण है वह सेवा की उपलब्धता है: कंटेनरों का यह सेट क्या करता है। इससे निगरानी के दृष्टिकोण में बदलाव आता है।

2014-2015 में, डॉकर फला-फूला - वह तकनीक जिसके बारे में हम अब बात करेंगे।

डॉकर ने दर्शन को बदल दिया और एप्लिकेशन पैकेजिंग को मानकीकृत किया। डॉकर का उपयोग करके, हम किसी एप्लिकेशन को पैकेज कर सकते हैं, उसे रिपॉजिटरी में भेज सकते हैं, वहां से डाउनलोड कर सकते हैं और तैनात कर सकते हैं।

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

उपरिव्यय के बारे में विषयांतर

ओवरहेड्स को लेकर हमेशा विवाद होते रहते हैं। कुछ लोगों का मानना ​​है कि डॉकर कोई अतिरिक्त भार नहीं उठाता है, क्योंकि यह लिनक्स कर्नेल और कंटेनरीकरण के लिए आवश्यक सभी प्रक्रियाओं का उपयोग करता है। जैसे, "यदि आप कहते हैं कि डॉकर ओवरहेड है, तो लिनक्स कर्नेल ओवरहेड है।"

दूसरी ओर, यदि आप गहराई में जाएं, तो डॉकर में वास्तव में कई चीजें हैं, जिन्हें खिंचाव के साथ, ओवरहेड कहा जा सकता है।

पहला है PID नेमस्पेस. जब हम किसी प्रोसेस को नेमस्पेस में रखते हैं, तो उसे PID 1 असाइन किया जाता है। साथ ही, इस प्रोसेस में एक और PID होता है, जो कंटेनर के बाहर होस्ट नेमस्पेस पर स्थित होता है। उदाहरण के लिए, हमने Nginx को एक कंटेनर में लॉन्च किया, यह PID 1 (मास्टर प्रोसेस) बन गया। और होस्ट पर इसका पीआईडी ​​12623 है। और यह कहना मुश्किल है कि यह कितना ओवरहेड है।

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

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

डॉकर अवधारणा के बारे में

डॉकर में कई घटक होते हैं:

1. डॉकर डेमॉन वही कंटेनर इंजन है; कंटेनर लॉन्च करता है।
2. डॉकर सीआईआई एक डॉकर प्रबंधन उपयोगिता है।
3. Dockerfile - छवि बनाने के तरीके पर निर्देश।
4. छवि - वह छवि जिससे कंटेनर को बाहर निकाला जाता है।
5. कंटेनर।
6. डॉकर रजिस्ट्री एक छवि भंडार है।

योजनाबद्ध रूप से यह कुछ इस तरह दिखता है:

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

आइए प्रत्येक घटक के बारे में जानें।

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

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

बुनियादी आदेश:

डॉकर पीएस - उन कंटेनरों को दिखाएं जो वर्तमान में डॉकर होस्ट पर चल रहे हैं।
डॉकर छवियां - स्थानीय रूप से डाउनलोड की गई छवियां दिखाएं।
डॉकर खोज <> - रजिस्ट्री में एक छवि खोजें।
डॉकर पुल <> - रजिस्ट्री से मशीन पर एक छवि डाउनलोड करें।
डॉकर बिल्ड < > - छवि एकत्रित करें.
डॉकर रन <> - कंटेनर लॉन्च करें।
docker rm <> - कंटेनर हटाएँ।
डॉकर लॉग <> - कंटेनर लॉग
डॉकर स्टार्ट/स्टॉप/रीस्टार्ट <> - कंटेनर के साथ काम करना

यदि आप इन आदेशों में महारत हासिल करते हैं और उनका उपयोग करने में आश्वस्त हैं, तो उपयोगकर्ता स्तर पर डॉकर में खुद को 70% कुशल मानें।

Dockerfile - एक छवि बनाने के लिए निर्देश. लगभग हर निर्देश कमांड एक नई परत है। आइए एक उदाहरण देखें.

डॉकरफ़ाइल इस तरह दिखती है: बाईं ओर आदेश, दाईं ओर तर्क। प्रत्येक कमांड जो यहां है (और आम तौर पर डॉकरफाइल में लिखा जाता है) छवि में एक नई परत बनाता है।

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

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

छवि Dockerfile के निर्देशों के अनुसार बनाई गई है। Dockerfile का प्रत्येक निर्देश एक नई परत बनाता है। परतों का पुन: उपयोग किया जा सकता है.

डॉकर रजिस्ट्री एक डॉकर छवि भंडार है। ओएस के समान, डॉकर के पास एक सार्वजनिक मानक रजिस्ट्री है - डॉकरहब। लेकिन आप अपनी खुद की रिपॉजिटरी, अपनी खुद की डॉकर रजिस्ट्री बना सकते हैं।

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

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

पाठ्यक्रम की विशेषताओं और संपूर्ण कार्यक्रम का अधिक विस्तार से अध्ययन करने के लिए, कृपया लिंक का अनुसरण करें: "डॉकर वीडियो कोर्स'.

लेखक: मार्सेल इब्रेव, प्रमाणित कुबेरनेट्स प्रशासक, साउथब्रिज में प्रैक्टिसिंग इंजीनियर, स्लम पाठ्यक्रमों के वक्ता और डेवलपर।

स्रोत: www.habr.com