वयस्क कंटेनर (भाग 01): शब्दावली के लिए एक व्यावहारिक गाइड

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



इसलिए, शब्दावली को जानने के बिना, यह समझना मुश्किल होगा कि डॉक सीआरआई-ओ, रेक या एलएक्सएक्स / एलएक्सडी से कैसे भिन्न है; या कंटेनर कंटेनरों के मानकीकरण में ओपन कंटेनर इनिशिएटिव की भूमिका का मूल्यांकन करें।

परिचय

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

• कंटेनर (कंटेनर)
• छवि (छवि)
• कंटेनर छवि
• छवि परत
• रजिस्ट्री (रजिस्ट्री)
• भंडार (भंडार)
• टैग (टैग)
• आधार छवि
• प्लेटफ़ॉर्म छवि
• लेयर (लेयर)

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

कंटेनर: मूल बातें

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

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

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

कंटेनर छवि प्रारूप और OCI मानक के कंटेनर निष्पादन वातावरण की विशिष्टताओं का समर्थन करने वाले उपकरण विभिन्न कंटेनर प्लेटफार्मों, कंटेनर इंजनों के पारिस्थितिक तंत्र के भीतर और विभिन्न क्लाउड प्लेटफार्मों और ऑन-प्रिमाइसेस आर्किटेक्चर पर सहायक उपकरण प्रदान करते हैं। कंटेनर सिस्टम की शब्दावली, मानकों और वास्तुकला को समझना आपको अन्य विशेषज्ञों के साथ फलने-फूलने और स्केलेबल और समर्थित कंटेनरीकृत अनुप्रयोगों और वातावरण को डिजाइन करने की अनुमति देगा जो आने वाले वर्षों के लिए कंटेनर के कुशल उपयोग को सुनिश्चित करते हैं।

मूल शब्दावली

कंटेनर छवि

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

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

इसके अलावा, कंटेनर छवि की अवधारणा का तात्पर्य ऐसी छवि के लिए एक प्रारूप के अस्तित्व से है।

कंटेनर छवि प्रारूप

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

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

कंटेनर इंजन

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

एक स्तर से नीचे जाने पर, हम यह कह सकते हैं कि अधिकांश कंटेनर इंजन वास्तव में स्वयं कंटेनर शुरू नहीं करते हैं, लेकिन एक ओसीआई-संगत रनटाइम के माध्यम से, जैसे कि आरसीसी। आमतौर पर, एक कंटेनर रनटाइम निम्नलिखित चीजें करता है:

• मापदंडों, उपयोगकर्ता इनपुट संभालती है
• एपीआई के माध्यम से पारित मापदंडों को संभालता है (सबसे अधिक बार कंटेनर आर्केस्ट्रा सिस्टम)
• रजिस्ट्री सर्वर से कंटेनर छवियों को डाउनलोड करें
• ग्राफ़ चालक का उपयोग करके डिस्क पर कंटेनर छवि को अनपैक और सहेजता है (ड्राइवर के आधार पर ब्लॉक या फ़ाइल)
• कंटेनर के लिए एक माउंट पॉइंट तैयार करता है, आमतौर पर कॉपी-ऑन-राइट स्टोरेज में (फिर से, ब्लॉक या फ़ाइल, ड्राइवर पर निर्भर करता है)
• मेटाडेटा तैयार करता है जो कंटेनर को सही ढंग से चलाने के लिए रनटाइम के लिए पारित किया जाएगा:
  
  • विशिष्ट डिफ़ॉल्ट सेटिंग्स जो कंटेनर छवि के लिए निहित हैं (उदाहरण के लिए, ArchX86 )
  • कंटेनर इनपुट में निहित डिफ़ॉल्ट मानों को ओवरराइड करने के लिए उपयोगकर्ता इनपुट (उदाहरण के लिए, CMD, ENTRYPOINT)
  • कंटेनर छवि द्वारा निर्दिष्ट डिफ़ॉल्ट पैरामीटर (उदाहरण के लिए, SECCOM नियम)
• कंटेनर क्रम चलता है

पात्र

कंटेनर ऑपरेटिंग सिस्टम में काफी समय से मौजूद हैं, क्योंकि वास्तव में यह कंटेनर इमेज का सिर्फ एक चालू उदाहरण है। एक कंटेनर एक मानक लिनक्स प्रक्रिया है जो आमतौर पर कांटा () या निष्पादन () के बजाय क्लोन () सिस्टम कॉल का उपयोग करके बनाई जाती है। इसके अलावा, अतिरिक्त अलगाव उपायों को अक्सर कंटेनरों में सेग्रुप्स , SELinux, या AppArmor का उपयोग करके लागू किया जाता है।

कंटेनर होस्ट

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

आप यह निर्धारित कर सकते हैं कि कौन सी रिपॉजिटरी निम्नलिखित कमांड का उपयोग करके स्थानीय कैश के साथ सिंक्रनाइज़ की गई हैं:

  [रूट @ rhel7 ~] # docker की छवियाँ

 रिपोजिटरी टाग इमेज आईडी सृजित वायरल आकार
 रजिस्ट्री .access.redhat.com/rhel7 नवीनतम 6883d5422f4e 3 सप्ताह पहले 201.7 एमबी 

रजिस्ट्री सर्वर

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

यदि docker डेमन को स्थानीय कैश में रिपॉजिटरी की एक प्रति नहीं मिलती है, तो यह स्वचालित रूप से रजिस्ट्री सर्वर से इसे डाउनलोड करता है। अधिकांश लिनक्स वितरण पर, docker daemon इसके लिए docker.io साइट का उपयोग करेगा, लेकिन कुछ वितरणों पर इसे अपने तरीके से कॉन्फ़िगर किया जा सकता है। उदाहरण के लिए, Red Hat Enterprise Linux पहले रजिस्ट्री.access.redhat.com से डाउनलोड करने का प्रयास करता है, और उसके बाद ही docker.io (Docker Hub) से।

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

Red Hat Enterprise Linux आपको डिफ़ॉल्ट डॉक रजिस्ट्री को कॉन्फ़िगर करने की अनुमति देता है। इसके अलावा, RHEL7 और RHEL7 परमाणु आपको कॉन्फ़िगरेशन फ़ाइल के माध्यम से रजिस्ट्री सर्वर को जोड़ने या लॉक करने की अनुमति देते हैं:

  vi / etc / sysconfig / docker

RHEL7 और RHEL 7 परमाणु डिफ़ॉल्ट रूप से Red Hat रजिस्ट्री सर्वर का उपयोग करते हैं:

  ADD_REGISTRY = '- ऐड-रजिस्ट्री रजिस्ट्री .access.redhat.com'

कुछ मामलों में, सुरक्षा कारणों से, यह सार्वजनिक डॉकटर रजिस्ट्रियों को ब्लॉक करने के लिए समझ में आता है, जैसे कि डॉकहॉब:

  # BLOCK_REGISTRY = '- ब्लॉक-रजिस्ट्री'

Red Hat अपने एकीकृत रजिस्ट्री सर्वर को OpenShift कंटेनर प्लेटफ़ॉर्म के भाग के साथ-साथ स्टैंड-अलोन कॉर्पोरेट रजिस्ट्री सर्वर Quay Enterprise और क्लाउड, निजी और सार्वजनिक रिपॉजिटरी Quay.io के रूप में भी प्रस्तुत करता है।

कंटेनर ऑर्केस्ट्रेशन

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

कंटेनर ऑर्केस्ट्रेशन सिस्टम केवल दो चीजों को लागू करता है:

1. गतिशील रूप से क्लस्टर कंप्यूटरों में कंटेनर लोड भेजते हैं (इसे अक्सर "वितरित कंप्यूटिंग" के रूप में जाना जाता है)
2. एक मानक अनुप्रयोग विवरण फ़ाइल प्रदान करता है (क्यूब यामल, डॉकटर कम्पोज़ इत्यादि)

ये दो चीजें वास्तव में कई लाभ प्रदान करती हैं:

1. कंटेनरों को प्रबंधित करने की क्षमता, जो एक दूसरे से स्वतंत्र रूप से आवेदन करते हैं, जो आपको निम्नलिखित कार्यों को प्रभावी ढंग से हल करने की अनुमति देता है:
   
   • बड़े कंटेनर होस्ट क्लस्टर का निपटान
   • व्यक्तिगत कंटेनरों के स्तर पर विफलता (अब कोई प्रतिक्रिया देने वाली प्रक्रिया नहीं, स्मृति का थकावट)
   • कंटेनर होस्ट स्तर पर विफलता (ड्राइव, नेटवर्क, रिबूट)
   • कंटेनर इंजन स्तर पर विफलता (क्षति, पुनः आरंभ)
   • कंटेनरों का अलग-अलग स्केलिंग ऊपर और नीचे
2. उदाहरण के लिए, क्लाउड और पारंपरिक दोनों में नए परिवेश में एक ही एप्लिकेशन के नए उदाहरणों को तैनात करना आसान है:
   
   • एक आर्केस्ट्रा सिस्टम द्वारा नियंत्रित डेवलपर मशीनों पर
   • एक निजी नाम स्थान में साझा विकास के माहौल में
   • दृश्यता और परीक्षण प्रदर्शन सुनिश्चित करने के लिए एक आंतरिक सार्वजनिक नाम स्थान में एक सामान्य विकास के माहौल में
   • QA के आंतरिक वातावरण में
   • एक परीक्षण भार वातावरण में गतिशील रूप से प्रदान किया गया और क्लाउड में रद्द कर दिया गया
   • उत्पादन परिवेश के साथ संगतता को सत्यापित करने के लिए एक संदर्भ वातावरण में
   • उत्पादन के माहौल में
   • एक आपदा वसूली वातावरण में
   • अद्यतन कंटेनर होस्ट, कंटेनर इंजन या ऑर्केस्ट्रेशन टूल वाले नए उत्पादन वातावरण में
   • नए उत्पादन वातावरण में, जो मुख्य से अलग नहीं है, लेकिन एक अलग क्षेत्र में स्थित है

ओपन सोर्स समुदाय और सॉफ्टवेयर विक्रेता कई अलग-अलग ऑर्केस्ट्रेशन टूल प्रदान करते हैं। प्रारंभ में, इन उपकरणों में से तीन में झुंड , मेसोस और कुबेरनेट शामिल थे, लेकिन आज कुबेरनेट्स वास्तव में उद्योग मानक बन गए हैं, क्योंकि यहां तक ​​कि डॉकर और मेसोस्फीयर ने अपने समर्थन की घोषणा की है, लगभग सभी प्रमुख तकनीकी प्रदाताओं का उल्लेख नहीं किया है। हालाँकि, यदि आप एक कॉर्पोरेट ऑर्केस्ट्रेशन सिस्टम की तलाश कर रहे हैं, तो हम सुझाव देते हैं कि आप Red Hat OpenShift पर अधिक ध्यान दें ।

उन्नत शब्दकोश

कंटेनर रनटाइम

कंटेनर रनटाइम एक निम्न-स्तरीय घटक है जो आमतौर पर कंटेनर इंजन के हिस्से के रूप में उपयोग किया जाता है, लेकिन कंटेनर का परीक्षण करने के लिए मैन्युअल रूप से भी उपयोग किया जा सकता है। OCI मानक रनटाइम के संदर्भ कार्यान्वयन को परिभाषित करता है जिसे रनक के रूप में जाना जाता है। यह सबसे व्यापक रूप से इस्तेमाल किया जाने वाला कार्यान्वयन है, लेकिन अन्य ओसीआई-संगत रनटाइम्स जैसे क्रून , रेलकार और कटाकॉनटेनर हैं । Docker, CRI-O, और कई अन्य कंटेनर इंजन runc का उपयोग करते हैं।

कंटेनर रनटाइम निम्नलिखित चीजों के लिए जिम्मेदार है:

• कंटेनर इंजन द्वारा प्रदान किए गए कंटेनर का माउंट बिंदु हो जाता है (परीक्षण के लिए, यह सिर्फ एक निर्देशिका हो सकता है)
• कंटेनर मेटाडेटा को कंटेनर इंजन द्वारा प्रदान किया जाता है (परीक्षण के दौरान, यह मैन्युअल रूप से इकट्ठे config.json फ़ाइल हो सकता है)
• कंटेनरीकृत प्रक्रियाओं (क्लोन सिस्टम कॉल के माध्यम से) लॉन्च करने के लिए ओएस कर्नेल के साथ संचार करता है
• Cgroups कॉन्फ़िगर करता है
• SELinux नीति को कॉन्फ़िगर करता है
• App कवच नियमों को कॉन्फ़िगर करता है

थोड़ा ऐतिहासिक विषयांतर: जब डॉकर इंजन पहली बार दिखाई दिया, तो इसने LXC का उपयोग एक रनटाइम वातावरण के रूप में किया। डॉकर डेवलपर्स ने तब अपने स्वयं के पुस्तकालय को लाइबोनटेनर नामक कंटेनर चलाने के लिए लिखा था। यह गोलांग भाषा में लिखा गया था और यह डॉकटर इंजन का हिस्सा बन गया। ओसीआई संगठन की स्थापना के बाद, डॉकर ने इस परियोजना में स्रोत कोड libcontainer पेश किया और इस लाइब्रेरी को एक अलग उपयोगिता के रूप में जारी किया, जिसे रनसी कहा जाता है, जो तब OCI मानक के भीतर कंटेनर रनटाइम का संदर्भ कार्यान्वयन बन गया और इसका उपयोग अन्य सीआरआई इंजन जैसे CRI-O में किया जाता है । Runc एक बहुत ही सरल उपयोगिता है जो बस एक माउंट पॉइंट (डायरेक्टरी) और मेटाडेटा (config.json) की प्रतीक्षा करता है। रनक के बारे में अधिक जानकारी यहां पाई जा सकती है ।

एक गहरी समझ के लिए, कंटेनर मानकों और कंटेनर रनटाइम को समझना देखें।

छवि परतों

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

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

docker run --rm --privileged -v /var/run/docker.sock:/var/run/docker.sock nate / dockviz images -t

  ├─2332d8973c93 वर्चुअल आकार: 187.7 एमबी
  │ │ea358092da77 आभासी आकार: 187.9 एमबी
  │ │a467a7c6794f आभासी आकार: 187.9 एमबी
  │ │ca4d7b1b9a51 आभासी आकार: 187.9 एमबी
  │ :4084976dd96d आभासी आकार: 384.2 एमबी
  │ │943128b20e28 वर्चुअल आकार: 386.7 एमबी
  │ │db20cc018f56 वर्चुअल आकार: 386.7 एमबी
  │ │45b3c59b9130 वर्चुअल आकार: 398.2 एमबी
  7 │91275de1a5d7 वर्चुअल आकार: 422.8 एमबी
  : │e7a97058d51f आभासी आकार: 422.8 एमबी
  B │d5c963edfcb2 वर्चुअल आकार: 422.8 एमबी
  : │5cfc0ce98e02 वर्चुअल आकार: 422.8 एमबी
  : Virtual7728f71a4bcd वर्चुअल साइज़: 422.8 MB
  : │0542f67da01b वर्चुअल आकार: 422.8 एमबी टैग: docker.io/registry:atest

जैसा कि आप देख सकते हैं, docker.io/registry रिपॉजिटरी में वास्तव में कई परतें शामिल हैं। हालांकि, अधिक महत्वपूर्ण बात, उपयोगकर्ता, सिद्धांत रूप में, इस चरण सीढ़ी में किसी भी चरण से कंटेनर को "शुरू" कर सकता है, उदाहरण के लिए, नीचे कमांड दर्ज करके (यह पूरी तरह से सही है, लेकिन कोई भी गारंटी नहीं दे सकता है कि यह परीक्षण किया गया था या सही ढंग से काम करेगा)। एक नियम के रूप में, छवि कलेक्टर टैग (नाम बनाता है) उन परतों को जिनका उपयोग प्रारंभिक बिंदु के रूप में किया जाना चाहिए:

  docker रन -it 45b3c59b9130 बैश

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

टैग

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

, – latest, , . , , .

, ( jq ):

 curl -s registry.access.redhat.com/v1/repositories/rhel7/tags | jq
 {
 "7.0-21": "e1f5733f050b2488a17b7630cb038bfbea8b7bdfa9bdfb99e63a33117e28d02f",
 "7.0-23": "bef54b8f8a2fdd221734f1da404d4c0a7d07ee9169b1443a338ab54236c8c91a",
 "7.0-27": "8e6704f39a3d4a0c82ec7262ad683a9d1d9a281e3c1ebbb64c045b9af39b3940",
 "7.1-11": "d0a516b529ab1adda28429cae5985cab9db93bfd8d301b3a94d22299af72914b",
 "7.1-12": "275be1d3d0709a06ff1ae38d0d5402bc8f0eeac44812e5ec1df4a9e99214eb9a",
 "7.1-16": "82ad5fa11820c2889c60f7f748d67aab04400700c581843db0d1e68735327443",
 "7.1-24": "c4f590bbcbe329a77c00fea33a3a960063072041489012061ec3a134baba50d6",
 "7.1-4": "10acc31def5d6f249b548e01e8ffbaccfd61af0240c17315a7ad393d022c5ca2",
 "7.1-6": "65de4a13fc7cf28b4376e65efa31c5c3805e18da4eb01ad0c8b8801f4a10bc16",
 "7.1-9": "e3c92c6cff3543d19d0c9a24c72cd3840f8ba3ee00357f997b786e8939efef2f",
 "7.2": "6c3a84d798dc449313787502060b6d5b4694d7527d64a7c99ba199e3b2df834e",
 "7.2-2": "58958c7fafb7e1a71650bc7bdbb9f5fd634f3545b00ec7d390b2075db511327d",
 "7.2-35": "6883d5422f4ec2810e1312c0e3e5a902142e2a8185cd3a1124b459a7c38dc55b",
 "7.2-38": "6c3a84d798dc449313787502060b6d5b4694d7527d64a7c99ba199e3b2df834e",
 "latest": "6c3a84d798dc449313787502060b6d5b4694d7527d64a7c99ba199e3b2df834e"
 }

docker , . , «rhel7» – .

 docker pull rhel7

:

 docker pull registry.access.redhat.com/rhel7:latest

, . , , , docker images. , , , «» (manifest.json):

 docker images

REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
 registry.access.redhat.com/rhel7 latest 6883d5422f4e 4 weeks ago 201.7 MB
 registry.access.redhat.com/rhel latest 6883d5422f4e 4 weeks ago 201.7 MB
 registry.access.redhat.com/rhel6 latest 05c3d56ba777 4 weeks ago 166.1 MB
 registry.access.redhat.com/rhel6/rhel latest 05c3d56ba777 4 weeks ago 166.1 MB
  ...

, . docker ( , ) , «rhel7» .

, docker URL. , , URL .



, :

 REGISTRY/NAMESPACE/REPOSITORY[:TAG]

URL , , , . URL , docker , . , : :

 docker pull registry.access.redhat.com/rhel7/rhel:latest
 docker pull registry.access.redhat.com/rhel7/rhel
 docker pull registry.access.redhat.com/rhel7
 docker pull rhel7/rhel:latest

– . DockerHub , , .

Red Hat , Red Hat Federated Registry . registry.access.redhat.com . , . , Red Hat , - :

 registry.access.redhat.com/rhel7/rhel
registry.access.redhat.com/openshift3/mongodb-24-rhel7
registry.access.redhat.com/rhscl/mongodb-26-rhel7
registry.access.redhat.com/rhscl_beta/mongodb-26-rhel7
registry-mariadbcorp.rhcloud.com/rhel7/mariadb-enterprise-server:10.0

, URL . . fedora, latest. :

 docker pull fedora
docker pull docker.io/fedora
docker pull docker.io/library/fedora:latest

, , . , , , , , . , , , . .

Bash Enter, Bash Linux- exec() . , , docker, docker , clone() . clone () , , , , , ..

, Linux - , clone ().


…