डकर भनेको के हो: इतिहास र आधारभूत अमूर्तहरूमा संक्षिप्त भ्रमण

Slurm मा अगस्त 10 मा सुरु भयो डकर भिडियो कोर्स, जसमा हामी यसलाई पूर्ण रूपमा विश्लेषण गर्छौं - आधारभूत एब्स्ट्र्याक्सनबाट नेटवर्क प्यारामिटरहरूमा।

यस लेखमा हामी डकरको इतिहास र यसको मुख्य सारहरूको बारेमा कुरा गर्नेछौं: छवि, क्लाइ, डकरफाइल। व्याख्यान शुरुआतीहरूको लागि हो, त्यसैले यो अनुभवी प्रयोगकर्ताहरूको लागि चासोको सम्भावना छैन। त्यहाँ रगत, एपेन्डिक्स वा गहिरो विसर्जन हुनेछैन। धेरै आधारभूत।

Docker के हो

विकिपिडियाबाट डकरको परिभाषा हेरौं।

डकर कन्टेनराइज्ड वातावरणमा अनुप्रयोगहरूको डिप्लोइमेन्ट र व्यवस्थापनको लागि सफ्टवेयर हो।

यस परिभाषाबाट केही स्पष्ट छैन। यो विशेष गरी अस्पष्ट छ कि "वातावरणहरूमा जसले कन्टेनराइजेशनलाई समर्थन गर्दछ" भनेको के हो। जान्नको लागि, समयमै फर्कौं। त्यो युगबाट सुरु गरौं जसलाई म परम्परागत रूपमा "मोनोलिथिक युग" भन्छु।

मोनोलिथिक युग

मोनोलिथिक युग प्रारम्भिक 2000 को हो, जब सबै अनुप्रयोगहरू निर्भरताहरूको गुच्छाको साथ, मोनोलिथिक थिए। विकासले लामो समय लियो। एकै समयमा, त्यहाँ धेरै सर्भरहरू थिएनन्; हामी सबैले तिनीहरूलाई नामबाट चिन्थ्यौं र तिनीहरूलाई निगरानी गर्यौं। त्यहाँ यस्तो हास्यास्पद तुलना छ:

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

हाइपरभाइजर-आधारित भर्चुअलाइजेशन प्रणाली

सबैजनाले भर्चुअलाइजेशन प्रणालीहरूको बारेमा सुनेका छन्: VMware, VirtualBox, Hyper-V, Qemu KVM, आदि। तिनीहरूले अनुप्रयोग अलगाव र स्रोत व्यवस्थापन प्रदान गर्छन्, तर तिनीहरूका बेफाइदाहरू पनि छन्। भर्चुअलाइजेशन गर्न, तपाईंलाई हाइपरवाइजर चाहिन्छ। र हाइपरवाइजर एक स्रोत ओभरहेड हो। र भर्चुअल मेसिन आफैंमा सामान्यतया पूर्ण कोलोसस हुन्छ - अपरेटिङ सिस्टम, Nginx, Apache, र सम्भवतः MySQL समावेश भएको भारी छवि। छवि ठूलो छ र भर्चुअल मेसिन सञ्चालन गर्न असुविधाजनक छ। नतिजाको रूपमा, भर्चुअल मेसिनहरूसँग काम ढिलो हुन सक्छ। यो समस्या समाधान गर्न, भर्चुअलाइजेशन प्रणाली कर्नेल स्तरमा सिर्जना गरिएको थियो।

कर्नेल-स्तर भर्चुअलाइजेशन प्रणाली

कर्नेल-स्तर भर्चुअलाइजेशन OpenVZ, Systemd-nspawn, LXC प्रणालीहरू द्वारा समर्थित छ। यस्तो भर्चुअलाइजेशन को एक उल्लेखनीय उदाहरण LXC (Linux कन्टेनर) हो।

LXC एकल नोडमा लिनक्स अपरेटिङ सिस्टमको धेरै पृथक उदाहरणहरू चलाउनको लागि अपरेटिङ सिस्टम-स्तर भर्चुअलाइजेशन प्रणाली हो। LXC ले भर्चुअल मेसिनहरू प्रयोग गर्दैन, तर आफ्नै प्रक्रिया स्पेस र नेटवर्क स्ट्याकको साथ भर्चुअल वातावरण सिर्जना गर्दछ।

अनिवार्य रूपमा LXC कन्टेनरहरू सिर्जना गर्दछ। भर्चुअल मेसिन र कन्टेनरहरू बीच के भिन्नता छ?

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

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

यदि तपाई साँच्चै केहि अलग गर्न चाहनुहुन्छ भने हार्डवेयर हाइपरभाइजरहरू राम्रो छन्। किनभने यो मेमोरी पृष्ठहरू र प्रोसेसरहरूको स्तरमा अलग गर्न सम्भव छ।

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

कर्नेल स्तरमा कन्टेनराइजेशनको लागि के प्रयोग गरिन्छ

मुख्य प्रविधिहरू जसले तपाईंलाई अन्य प्रक्रियाहरूबाट अलग गरिएको कन्टेनर सिर्जना गर्न अनुमति दिन्छ नामस्पेसहरू र नियन्त्रण समूहहरू हुन्।

नेमस्पेसहरू: PID, नेटवर्किङ, माउन्ट र प्रयोगकर्ता। त्यहाँ धेरै छन्, तर बुझ्नको लागि हामी यी कुराहरूमा ध्यान केन्द्रित गर्नेछौं।

PID नेमस्पेस प्रक्रियाहरू सीमित गर्दछ। जब, उदाहरणका लागि, हामीले PID नेमस्पेस सिर्जना गर्छौं र त्यहाँ प्रक्रिया राख्छौं, यो PID 1 सँग बन्छ। सामान्यतया प्रणालीहरूमा PID 1 systemd वा init हुन्छ। तदनुसार, जब हामी नयाँ नेमस्पेसमा प्रक्रिया राख्छौं, यसले PID 1 पनि प्राप्त गर्दछ।

नेटवर्किङ नेमस्पेसले तपाईंलाई नेटवर्कलाई सीमित/पृथक गर्न र आफ्नो इन्टरफेसहरू भित्र राख्न अनुमति दिन्छ। माउन्ट फाइल प्रणाली सीमा हो। प्रयोगकर्ता - प्रयोगकर्ताहरूमा प्रतिबन्ध।

नियन्त्रण समूहहरू: मेमोरी, CPU, IOPS, नेटवर्क - कुलमा लगभग 12 सेटिङहरू। अन्यथा तिनीहरूलाई Cgroups ("C-groups") पनि भनिन्छ।

कन्ट्रोल समूहहरूले कन्टेनरका लागि स्रोतहरू व्यवस्थापन गर्छन्। नियन्त्रण समूहहरू मार्फत हामी भन्न सक्छौं कि कन्टेनरले निश्चित मात्रा भन्दा बढी स्रोतहरू उपभोग गर्नु हुँदैन।

कन्टेनराइजेशन पूर्ण रूपमा काम गर्नको लागि, अतिरिक्त प्रविधिहरू प्रयोग गरिन्छ: क्षमताहरू, प्रतिलिपि-अन-लेखन र अन्य।

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

प्रतिलिपि-अन-राइट प्रणालीले हामीलाई डकर छविहरूसँग काम गर्न र तिनीहरूलाई अझ प्रभावकारी रूपमा प्रयोग गर्न अनुमति दिन्छ।

डकरमा हाल Cgroups v2 सँग अनुकूलता समस्याहरू छन्, त्यसैले यो लेख विशेष रूपमा Cgroups v1 मा केन्द्रित छ।

तर इतिहासमा फर्कौं।

जब भर्चुअलाइजेशन प्रणाली कर्नेल स्तरमा देखा पर्यो, तिनीहरू सक्रिय रूपमा प्रयोग हुन थाले। हाइपरभाइजरमा ओभरहेड गायब भयो, तर केही समस्याहरू बाँकी छन्:

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

यी सबै समस्या समाधान गर्न अर्को युग आएको छ ।

कन्टेनर युग

जब कन्टेनरहरूको युग आयो, तिनीहरूसँग काम गर्ने दर्शन परिवर्तन भयो:

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

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

2014-2015 मा, डकर फस्ट्यो - टेक्नोलोजी जुन हामी अहिले कुरा गर्नेछौं।

डकरले दर्शन र मानकीकृत अनुप्रयोग प्याकेजिङ्ग परिवर्तन गर्यो। डकर प्रयोग गरेर, हामी एउटा अनुप्रयोग प्याकेज गर्न सक्छौं, यसलाई भण्डारमा पठाउन सक्छौं, त्यहाँबाट डाउनलोड गर्न सक्छौं, र यसलाई प्रयोग गर्न सक्छौं।

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

ओभरहेडको बारेमा डिग्रेशन

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

अर्कोतर्फ, यदि तपाईं गहिराइमा जानुहुन्छ भने, त्यहाँ वास्तवमा डकरमा धेरै चीजहरू छन् जुन स्ट्रेचको साथ, ओभरहेड भन्न सकिन्छ।

पहिलो PID नेमस्पेस हो। जब हामीले एउटा प्रक्रियालाई नेमस्पेसमा राख्छौं, यसलाई PID 1 तोकिएको हुन्छ। एकै समयमा, यो प्रक्रियामा अर्को PID हुन्छ, जुन कन्टेनर बाहिर होस्ट नेमस्पेसमा अवस्थित हुन्छ। उदाहरणका लागि, हामीले कन्टेनरमा Nginx सुरु गर्‍यो, यो PID 1 (मास्टर प्रक्रिया) भयो। र होस्टमा यसको PID 12623 छ। र यो कति ओभरहेड हो भन्न गाह्रो छ।

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

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

डकर अवधारणाको बारेमा

डकरमा धेरै कम्पोनेन्टहरू हुन्छन्:

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

योजनाबद्ध रूपमा यो यस्तो देखिन्छ:

डकर डेमन डकर_होस्टमा चल्छ र कन्टेनरहरू लन्च गर्दछ। त्यहाँ एक ग्राहक छ जसले आदेशहरू पठाउँछ: छवि निर्माण गर्नुहोस्, छवि डाउनलोड गर्नुहोस्, कन्टेनर सुरू गर्नुहोस्। डकर डेमन रजिस्ट्रीमा जान्छ र तिनीहरूलाई कार्यान्वयन गर्दछ। डकर क्लाइन्टले स्थानीय रूपमा (युनिक्स सकेटमा) र टाढाको होस्टबाट TCP मार्फत पहुँच गर्न सक्छ।

प्रत्येक घटक मार्फत जाऔं।

डकर डेमन - यो सर्भर भाग हो, यसले होस्ट मेसिनमा काम गर्दछ: छविहरू डाउनलोड गर्दछ र तिनीहरूबाट कन्टेनरहरू लन्च गर्दछ, कन्टेनरहरू बीच नेटवर्क सिर्जना गर्दछ, लगहरू सङ्कलन गर्दछ। जब हामी "छवि बनाउनुहोस्" भन्दछौं, भूतले पनि त्यसै गरिरहेको हुन्छ।

डकर CLI - डकर क्लाइन्ट भाग, डेमनसँग काम गर्नको लागि कन्सोल उपयोगिता। म दोहोर्याउँछु, यसले स्थानीय रूपमा मात्र होइन, नेटवर्कमा पनि काम गर्न सक्छ।

आधारभूत आदेशहरू:

डकर पीएस - हाल डकर होस्टमा चलिरहेको कन्टेनरहरू देखाउनुहोस्।
डकर छविहरू - स्थानीय रूपमा डाउनलोड गरिएका छविहरू देखाउनुहोस्।
डकर खोज <> - रजिस्ट्रीमा छवि खोज्नुहोस्।
डकर पुल <> - मेसिनमा रजिस्ट्रीबाट छवि डाउनलोड गर्नुहोस्।
डकर निर्माण < > - छवि सङ्कलन।
डकर रन <> - कन्टेनर सुरु गर्नुहोस्।
डकर आरएम <> - कन्टेनर हटाउनुहोस्।
डकर लगहरू <> - कन्टेनर लगहरू
डकर स्टार्ट/स्टप/रिस्टार्ट <> - कन्टेनरसँग काम गर्दै

यदि तपाइँ यी आदेशहरू मास्टर गर्नुहुन्छ र तिनीहरूलाई प्रयोग गर्नमा विश्वस्त हुनुहुन्छ भने, आफैलाई प्रयोगकर्ता स्तरमा डकरमा 70% निपुण मान्नुहोस्।

डकरफाइल - छवि सिर्जना गर्न निर्देशन। लगभग हरेक निर्देशन आदेश नयाँ तह हो। एउटा उदाहरण हेरौं।

यो डकरफाइल जस्तो देखिन्छ: बायाँमा आदेशहरू, दायाँमा तर्कहरू। यहाँ छ (र सामान्यतया डकरफाइलमा लेखिएको) प्रत्येक आदेशले छविमा नयाँ तह सिर्जना गर्दछ।

बायाँ छेउमा हेर्दा पनि के भइरहेको छ भन्ने कुरा बुझ्न सकिन्छ। हामी भन्छौं: "हाम्रो लागि फोल्डर सिर्जना गर्नुहोस्" - यो एउटा तह हो। "फोल्डरलाई काम गर्न बनाउनुहोस्" अर्को तह हो, र यस्तै। लेयर केकले जीवनलाई सजिलो बनाउँछ। यदि मैले अर्को डकरफाइल सिर्जना गर्छु र अन्तिम लाइनमा केहि परिवर्तन गर्छु भने - म "python" "main.py" बाहेक केहि चलाउँछु, वा अर्को फाइलबाट निर्भरताहरू स्थापना गर्छु - त्यसपछि अघिल्लो तहहरू क्यासको रूपमा पुन: प्रयोग गरिनेछ।

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

छवि Dockerfile बाट निर्देशन अनुसार बनाइएको छ। डकरफाइलबाट प्रत्येक निर्देशनले नयाँ तह सिर्जना गर्दछ। तहहरू पुन: प्रयोग गर्न सकिन्छ।

डकर रजिस्ट्री डकर छवि भण्डार हो। ओएस जस्तै, डकरसँग सार्वजनिक मानक रजिस्ट्री छ - dockerhub। तर तपाइँ तपाइँको आफ्नै भण्डार, तपाइँको आफ्नै डकर रजिस्ट्री निर्माण गर्न सक्नुहुन्छ।

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

"एक कन्टेनर, एक प्रक्रिया" आवश्यकता PID नेमस्पेससँग सम्बन्धित छ। जब PID 1 सँग प्रक्रिया Namespace मा सुरु हुन्छ, यदि यो अचानक मर्छ भने, त्यसपछि सम्पूर्ण कन्टेनर पनि मर्छ। यदि त्यहाँ दुई प्रक्रियाहरू चलिरहेका छन्: एउटा जीवित छ र अर्को मृत छ, तब कन्टेनर अझै जीवित रहनेछ। तर यो उत्तम अभ्यासहरूको प्रश्न हो, हामी तिनीहरूको बारेमा अन्य सामग्रीहरूमा कुरा गर्नेछौं।

थप विवरणमा पाठ्यक्रमको सुविधाहरू र पूर्ण कार्यक्रम अध्ययन गर्न, कृपया लिङ्क पछ्याउनुहोस्: "डकर भिडियो कोर्स"।

लेखक: मार्सेल इब्राभ, प्रमाणित Kubernetes प्रशासक, साउथब्रिजमा अभ्यास इन्जिनियर, वक्ता र Slurm पाठ्यक्रमहरूको विकासकर्ता।

स्रोत: www.habr.com