डॉकर का नया बिजनेस मॉडल और इमेज विज़ुअलाइज़ेशन का युग

डॉकर स्काउट की शुरुआती एक्सेस रिलीज़ के साथ, डॉकर हब अंततः छवि आंतरिक की कल्पना करना शुरू कर रहा है। यह भी खूब रही! डॉकर हब ने वर्षों पहले ऐसा क्यों नहीं किया? अपने बिजनेस मॉडल की वजह से.

इससे पहले कि हम आगे बढ़ें, आइए संक्षेप में समीक्षा करें कि डॉकर छवियां किस चीज़ से बनी हैं।

सामग्री अवलोकन

• डॉकर छवियां परतों से बनी होती हैं
• डेवलपर्स डॉकर छवि आंतरिक को क्यों देखते हैं?
• डेवलपर्स डॉकर छवि आंतरिक को कैसे देखते थे
• डॉकर स्काउट: छवि आंतरिक निरीक्षण करने का एक बेहतर तरीका
• उन्हें इतनी देर देर क्यों लगी?
• दो तरफा मंच
• जो पिछला है वो प्रस्तावना है

डॉकर छवियां परतों से बनी होती हैं

जब आप कमांड लाइन पर docker pull चलाकर डॉकर छवि डाउनलोड करते हैं, तो डॉकर सीएलआई छवि खींचते ही प्रत्येक परत की डाउनलोड प्रगति प्रदर्शित करता है। यदि आपने कभी डॉकर छवि डाउनलोड की है, तो आपने संभवतः इसे देखा होगा:

यदि आपने पहले डॉकर के साथ काम किया है, तो संभवतः आपने अपनी छवियों के लिए इनमें से कुछ परतों को परिभाषित किया होगा। जब डेवलपर्स Dockerfiles लिखते हैं तो वे इन परतों को स्पष्ट रूप से परिभाषित करते हैं। उदाहरण के लिए, इस Dockerfile की प्रत्येक पंक्ति एक परत बनाती है:

 FROM ubuntu:22.04 # install apt dependencies RUN apt-get update RUN apt-get install -y iputils-ping python3 python3-pip # install python dependencies RUN pip3 install numpy # cleanup apt lists RUN rm -rf /var/lib/apt/lists/* CMD ["/bin/bash"]

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

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

डेवलपर्स डॉकर छवि आंतरिक को क्यों देखते हैं?

आपूर्ति श्रृंखला निरीक्षण

डॉकर छवि परतों में कंटेनर के फ़ाइल सिस्टम में मौजूद प्रत्येक बाइनरी की मूल कहानी होती है। डॉकर छवि में पहली पंक्ति "FROM लाइन" है। यह डॉकर छवि (और इस प्रकार, छवि परतें) को परिभाषित करता है जिसके ऊपर डॉकरफ़ाइल बनाता है।

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

• सॉफ़्टवेयर लाइसेंसिंग अनुबंधों का पालन करें
• अनुपालन ऑडिट को अधिक सुचारू रूप से पास करें
• सुरक्षा कमजोरियों का पता लगाएं और उनसे बचें

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

छवि आकार अनुकूलन

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

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

आपकी डॉकर छवि परतों में गलती से ब्लोट डालना आसान है। पहले दर्शाए गए डॉकरफ़ाइल में एक क्लासिक उदाहरण शामिल है - पंक्ति 4 की परत डिस्क पर 40 एमबी फ़ाइलों को सहेजती है, जो बाद में पंक्ति 11 की परत द्वारा हटा दी जाती हैं। डॉकर छवियां कैसे काम करती हैं, इसके कारण वह डेटा अभी भी छवि का हिस्सा है, जोड़ना 40एमबी अनावश्यक छवि आकार।

यह एक सरल उदाहरण है - वास्तव में, यह सीधे डॉकर के दस्तावेज़ से निकला है। अधिक जटिल डॉकरफ़ाइल्स में, इस गलती को पहचानना अधिक कठिन हो सकता है।

डेवलपर्स डॉकर छवि आंतरिक को कैसे देखते थे

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

एक कंटेनर शुरू करें और उसे देखें

यह बिना किसी तामझाम के स्वयं करें यूनिक्स पद्धति है। आपको बस एक डॉकर डेमॉन चलाने वाले होस्ट की आवश्यकता है। यह एक सरल तरीका है:

1. छवि से एक कंटेनर प्रारंभ करने के लिए docker create चलाएँ।
2. नए कंटेनर की परत निर्देशिकाओं को खोजने के लिए docker inspect उपयोग करें।
3. उन परत निर्देशिकाओं को डॉकर छवि की रेखाओं के साथ सहसंबंधित करें।
4. कमांड लाइन पर उन निर्देशिकाओं में cd और अपने दिमाग में परतों के बारे में तर्क करें।

यह एक झंझट है. मान लीजिए कि हम डॉकर छवि में कुछ छवि ब्लोट को ट्रैक करने का प्रयास कर रहे हैं जिसे हम कुछ महीनों से उपयोग कर रहे हैं लेकिन हाल ही में आकार में काफी वृद्धि हुई है।

सबसे पहले, हम छवि से एक कंटेनर बनाते हैं:

 where-the@roadmap-ends ~ $ docker create --name example where-the-roadmap-ends 339b8905b681a1d4f7c56f564f6b1f5e63bb6602b62ba5a15d368ed785f44f55

फिर, docker inspect हमें बताता है कि डाउनलोड की गई छवि की परत निर्देशिकाएं हमारे फ़ाइल सिस्टम पर कहां समाप्त हुईं:

 where-the@roadmap-ends ~ $ docker inspect example | grep GraphDriver -A7 "GraphDriver": { "Data": { "LowerDir": "/var/lib/docker/overlay2/1c18bd289d9c3f9f0850e301bf86955395c312de3a64a70e0d0e6a5bed337d47-init/diff:/var/lib/docker/overlay2/wbugwbg23oefsf678r7anbn4f/diff:/var/lib/docker/overlay2/j0dekt7y8xgix11n0lturmf8t/diff:/var/lib/docker/overlay2/zd57mz6l4zrsjk9snc2crphfq/diff:/var/lib/docker/overlay2/83za1pmv9xri44tddzyju0usm/diff:/var/lib/docker/overlay2/8c639b22627e0ad91944a70822b442e5bff848968263a37715a293a15483c170/diff", "MergedDir": "/var/lib/docker/overlay2/1c18bd289d9c3f9f0850e301bf86955395c312de3a64a70e0d0e6a5bed337d47/merged", "UpperDir": "/var/lib/docker/overlay2/1c18bd289d9c3f9f0850e301bf86955395c312de3a64a70e0d0e6a5bed337d47/diff", "WorkDir": "/var/lib/docker/overlay2/1c18bd289d9c3f9f0850e301bf86955395c312de3a64a70e0d0e6a5bed337d47/work" }, "Name": "overlay2"

इस जांच के लिए हम जिन परतों को देखना चाहते हैं वे "लोअरडिर" निर्देशिकाओं की सूची हैं। अन्य निर्देशिकाएँ स्वयं डॉकर छवि का हिस्सा नहीं हैं—हम उन्हें अनदेखा कर सकते हैं।

इसलिए, हम कमांड लाइन पर "लोअरडिर" निर्देशिकाओं की सूची को पार्स करते हैं:

 where-the@roadmap-ends ~ $ docker inspect example | grep GraphDriver -A7 | grep LowerDir | awk '{print $2}' | sed 's|"||g' | sed 's|,||g' | sed 's|:|\n|g' /var/lib/docker/overlay2/1c18bd289d9c3f9f0850e301bf86955395c312de3a64a70e0d0e6a5bed337d47-init/diff /var/lib/docker/overlay2/wbugwbg23oefsf678r7anbn4f/diff /var/lib/docker/overlay2/j0dekt7y8xgix11n0lturmf8t/diff /var/lib/docker/overlay2/zd57mz6l4zrsjk9snc2crphfq/diff /var/lib/docker/overlay2/83za1pmv9xri44tddzyju0usm/diff /var/lib/docker/overlay2/8c639b22627e0ad91944a70822b442e5bff848968263a37715a293a15483c170/diff

ये छवि में परतों की सूची हैं, क्रम में, सबसे पहले सबसे निचली परत। अब हमें इन परत निर्देशिकाओं को उन Dockerfile लाइनों के साथ मैन्युअल रूप से सहसंबंधित करने की आवश्यकता है जो उन्हें उत्पन्न करती हैं।

दुर्भाग्य से, डॉकर हमें डॉकर छवि से इन पंक्तियों को सीधे निकालने का कोई तरीका नहीं देता है - यह सबसे अच्छा है जिसे हम docker history उपयोग करके प्राप्त कर सकते हैं:

 where-the@roadmap-ends ~ $ docker history where-the-roadmap-ends IMAGE CREATED CREATED BY SIZE COMMENT 6bbac081b2a7 2 hours ago CMD ["/bin/bash"] 0B buildkit.dockerfile.v0 <missing> 2 hours ago RUN /bin/sh -c rm -rf /var/lib/apt/lists/* #… 0B buildkit.dockerfile.v0 <missing> 2 hours ago RUN /bin/sh -c pip3 install numpy # buildkit 70MB buildkit.dockerfile.v0 <missing> 2 hours ago RUN /bin/sh -c apt-get install -y iputils-pi… 343MB buildkit.dockerfile.v0 <missing> 2 hours ago RUN /bin/sh -c apt-get update # buildkit 40.1MB buildkit.dockerfile.v0 <missing> 8 months ago /bin/sh -c #(nop) CMD ["bash"] 0B <missing> 8 months ago /bin/sh -c #(nop) ADD file:550e7da19f5f7cef5… 69.2MB

इस आउटपुट का उपयोग करके, हम यह पहचान सकते हैं कि किन परतों में निर्देशिकाएं हैं और किस डॉकरफाइल कमांड ने परत बनाई है (CREATED BY कॉलम में दिखाया गया है)।

docker history कमांड आपके कंटेनर में परतों को उसी क्रम में आउटपुट करता है जिस क्रम में docker inspect परत निर्देशिकाओं को सूचीबद्ध करता है। यह जानते हुए, हम मैन्युअल रूप से दो आउटपुट को एक साथ मर्ज कर सकते हैं यह देखने के लिए कि कौन सी परतें दूसरों की तुलना में बड़ी हैं, किस डॉकरफाइल कमांड ने उन्हें बनाया है, और किस निर्देशिका में प्रत्येक परत शामिल है।

यहां लेयर ए की सामग्री है, जो apt-get update करती है:

 where-the@roadmap-ends ~ $ du -hs /var/lib/docker/overlay2/83za1pmv9xri44tddzyju0usm/diff/var/lib/apt/lists 38.2M /var/lib/docker/overlay2/83za1pmv9xri44tddzyju0usm/diff/var/lib/apt/lists

परत बी की सामग्री की तुलना में, यह परत ए से बची हुई फ़ाइलों को हटा देता है:

 where-the@roadmap-ends ~ $ du -hs /var/lib/docker/overlay2/wbugwbg23oefsf678r7anbn4f/diff/var/lib/apt/lists 4.0K /var/lib/docker/overlay2/wbugwbg23oefsf678r7anbn4f/diff/var/lib/apt/lists

/var/lib/apt/lists निर्देशिका दोनों परतों में मौजूद है, लेकिन परत बी में, निर्देशिका लगभग कोई स्थान का उपयोग नहीं करती है।

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

इस वजह से, लेयर बी में फ़ाइलें "हटाए जाने" के बावजूद, वे अभी भी लेयर ए में मौजूद हैं, और इस प्रकार आपकी छवि के समग्र आकार में योगदान करते हैं - 38.2 एमबी अनावश्यक ब्लोट।

अब, क्या यह आसान नहीं था? 😉

गोता का प्रयोग करें

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

जब उपरोक्त Dockerfile से Docker छवि के विरुद्ध चलाया जाता है, तो यह इस तरह दिखता है:

 ┃ ● Layers ┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ │ Aggregated Layer Contents ├─────────────────────────────────────────────────────────────────────────────── Cmp Size Command └── var 69 MB FROM acee8cf20a197c9 └── lib 40 MB RUN /bin/sh -c apt-get update # buildkit └── apt 343 MB RUN /bin/sh -c apt-get install -y iputils-ping python3 python3-pip # buildkit └── lists 70 MB RUN /bin/sh -c pip3 install numpy # buildkit ├── auxfiles 0 B RUN /bin/sh -c rm -rf /var/lib/apt/lists/* # buildkit ├── lock ├── partial │ Layer Details ├─────────────────────────────────────────────────────────────────────────────────────────── ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-backports_InRelease ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-backports_main_binary-arm64_Packages.lz4 Tags: (unavailable) ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-backports_universe_binary-arm64_Packages.lz4 Id: 2bc27a99fd5750414948211814da00079804292360f8e2d7843589b9e7eb5eee ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-security_InRelease Digest: sha256:6e6fb36e04f3abf90c7c87d52629fe154db4ea9aceab539a794d29bbc0919100 ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-security_main_binary-arm64_Packages.lz4 Command: ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-security_multiverse_binary-arm64_Packages.lz4 RUN /bin/sh -c apt-get update # buildkit ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-security_restricted_binary-arm64_Packages.lz4 ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-security_universe_binary-arm64_Packages.lz4 │ Image Details ├─────────────────────────────────────────────────────────────────────────────────────────── ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-updates_InRelease ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-updates_main_binary-arm64_Packages.lz4 Image name: where-the-roadmap-ends ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-updates_multiverse_binary-arm64_Packages.lz4 Total Image size: 522 MB ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-updates_restricted_binary-arm64_Packages.lz4 Potential wasted space: 62 MB ├── ports.ubuntu.com_ubuntu-ports_dists_jammy-updates_universe_binary-arm64_Packages.lz4 Image efficiency score: 90 % ├── ports.ubuntu.com_ubuntu-ports_dists_jammy_InRelease ├── ports.ubuntu.com_ubuntu-ports_dists_jammy_main_binary-arm64_Packages.lz4 Count Total Space Path ├── ports.ubuntu.com_ubuntu-ports_dists_jammy_multiverse_binary-arm64_Packages.lz4 2 28 MB /var/lib/apt/lists/ports.ubuntu.com_ubuntu-ports_dists_jammy_universe_binary-arm64_Pack ├── ports.ubuntu.com_ubuntu-ports_dists_jammy_restricted_binary-arm64_Packages.lz4 2 7.3 MB /usr/bin/perl └── ports.ubuntu.com_ubuntu-ports_dists_jammy_universe_binary-arm64_Packages.lz4 2 4.4 MB /usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.30 2 2.9 MB /var/lib/apt/lists/ports.ubuntu.com_ubuntu-ports_dists_jammy_main_binary-arm64_Packages 2 2.0 MB /var/lib/apt/lists/ports.ubuntu.com_ubuntu-ports_dists_jammy-updates_main_binary-arm64_ 2 1.7 MB /var/lib/apt/lists/ports.ubuntu.com_ubuntu-ports_dists_jammy-updates_universe_binary-ar

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

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

डॉकर स्काउट: छवि आंतरिक निरीक्षण करने का एक बेहतर तरीका

एक डेवलपर के दृष्टिकोण से, डॉकर हब में डॉकर छवि परत विज़ुअलाइज़ेशन मौजूद होने की अपेक्षा करना हमेशा उचित होता है। आख़िरकार, हमारा डॉकर छवि डेटा पहले से ही डॉकर हब के बैकएंड में रहता है।

मैंने अक्सर एक यूआई का उपयोग करके अपने ब्राउज़र में डॉकर छवि आंतरिक का निरीक्षण करने की कल्पना की है जो कुछ इस तरह दिखता है:

डॉकर स्काउट के साथ, ऐसा प्रतीत होता है कि डॉकर एक कंपनी के रूप में उस दिशा में आगे बढ़ रहा है। आज, अगर मैं डॉकर हब में नवीनतम पोस्टग्रेज छवि पर नेविगेट करता हूं, तो मुझे इसके साथ स्वागत किया जाता है:

एक डेवलपर के रूप में, यह रोमांचक है। यह नया यूआई मुझे छवि परत विवरण को दृश्य रूप से ब्राउज़ करने देता है, भेद्यता और छवि आकार के मुद्दों को उजागर करता है जैसे मैं चाहता हूं।

उन्हें इतनी देर देर क्यों लगी?

जब डॉकर हब पहली बार लॉन्च किया गया था, तो इसके दो प्रकार के उपयोगकर्ता थे:

• डेवलपर्स , जो डॉकर छवियां डाउनलोड करते हैं
• सॉफ़्टवेयर प्रकाशक , जो डॉकर छवियां अपलोड करते हैं

और डॉकर को इन दोनों प्रकार के उपयोगकर्ताओं से अलग-अलग तरीके से संपर्क करना था।

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

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

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

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

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

सॉफ्टवेयर प्रकाशकों और डेवलपर्स दोनों की सेवा की इस गतिशीलता ने डॉकर हब को दो-तरफा मंच बना दिया।

दो तरफा मंच

दो-तरफा प्लेटफ़ॉर्म ऐसे व्यवसाय हैं जिनमें उपयोगकर्ताओं की दो अलग-अलग श्रेणियां होती हैं और काम करने के लिए प्लेटफ़ॉर्म में भाग लेने के लिए दोनों की आवश्यकता होती है। आमतौर पर, यह प्लेटफ़ॉर्म का उपयोग करने की प्रेरणा है जो उपयोगकर्ताओं को विभिन्न समूहों में विभाजित करती है।

हालाँकि उपयोगकर्ताओं के दो समूह एक दूसरे के साथ सीधे लेनदेन नहीं कर सकते हैं, दो-तरफा प्लेटफ़ॉर्म बाज़ार की तरह हैं - वे तब तक मूल्य नहीं बनाते हैं जब तक विक्रेता बेचने के लिए नहीं आते हैं और खरीदार खरीदने के लिए नहीं आते हैं।

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

एक बार जब आप जान जाते हैं कि आप क्या खोज रहे हैं, तो दो-तरफा प्लेटफ़ॉर्म को पहचानना आसान हो जाता है। यहां तीन उदाहरण हैं.

Linkedin

लिंक्डइन पर, दो प्रकार के उपयोगकर्ता हैं-कर्मचारी और नियुक्ति प्रबंधक। दोनों समूह अलग-अलग कारणों से भाग लेते हैं - कर्मचारी नौकरी चाहते हैं, और नियुक्ति प्रबंधक लोगों को नौकरी पर रखना चाहते हैं।

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

यूट्यूब

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

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

डॉकर हब

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

जो पिछला है वो प्रस्तावना है

कम से कम वह योजना थी। वास्तव में, डॉकर (कंपनी) ने मना कर दिया, और डॉकर हब कभी भी "एक" नहीं बन सका। दो-तरफा प्लेटफ़ॉर्म बनाते समय, स्टार्टअप के पास एक उत्पाद होता है, लेकिन उन्हें दो बार उत्पाद-बाज़ार के लिए उपयुक्त खोजना पड़ता है। डॉकर के लिए, यह बोझ सहन करना बहुत अधिक था - अंत में, इसने डॉकर को आधे में विभाजित कर दिया ।

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

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