ডকার স্কাউটের প্রাথমিক অ্যাক্সেস রিলিজের সাথে, ডকার হাব অবশেষে চিত্রের অভ্যন্তরীণগুলি কল্পনা করতে শুরু করেছে। এটা অসাধারণ! কেন ডকার হাব বছর আগে এটি করেনি? কারণ এর ব্যবসায়িক মডেল।
আমরা আরও এগিয়ে যাওয়ার আগে, ডকার ছবিগুলি কী দিয়ে তৈরি তা সংক্ষেপে পর্যালোচনা করা যাক।
যখন আপনি কমান্ড লাইনে docker pull
চালিয়ে একটি ডকার ইমেজ ডাউনলোড করেন, তখন ডকার সিএলআই প্রতিটি স্তরের ডাউনলোডের অগ্রগতি প্রদর্শন করে যখন এটি ছবিটি টানবে। আপনি যদি কখনও একটি ডকার ইমেজ ডাউনলোড করে থাকেন, আপনি সম্ভবত এটি দেখেছেন:
আপনি যদি আগে ডকারের সাথে কাজ করে থাকেন তবে আপনি সম্ভবত আপনার নিজের চিত্রগুলির জন্য এই স্তরগুলির কিছু সংজ্ঞায়িত করেছেন। বিকাশকারীরা যখন তারা ডকারফাইলস লেখে তখন এই স্তরগুলিকে স্পষ্টভাবে সংজ্ঞায়িত করে। উদাহরণস্বরূপ, এই ডকারফাইলের প্রতিটি লাইন একটি স্তর তৈরি করে:
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"]
স্তরগুলি হল আর্কাইভ করা লিনাক্স ডিরেক্টরি-এগুলি ফাইল সিস্টেম টারবল। ডকার আপনার সমস্ত ইমেজ লেয়ার ডাউনলোড করে এবং তাদের প্রত্যেকটিকে একটি আলাদা ডিরেক্টরিতে আনপ্যাক করে। আপনি যখন docker run
কমান্ড ব্যবহার করে একটি ডকার ইমেজ থেকে একটি ধারক চালু করেন, তখন ডকার ডেমন চিত্র স্তরগুলিকে একত্রিত করে একটি ধারক তৈরি করে।
পণ্য হিসাবে ডকারের অনেক মূল্য সংযোজন হল যে এটি এই বিবরণগুলিকে বিমূর্ত করে দেয়, ব্যবহারকারীরা কীভাবে কাজ করে সে সম্পর্কে চিন্তা না করেই স্তরযুক্ত পাত্রের সুবিধাগুলি কাটাতে দেয়। কিন্তু সমস্ত বিমূর্ততা ফুটো হয়ে যায়, এবং ডকারও এর ব্যতিক্রম নয়—কখনও কখনও, আপনাকে পর্দা টানতে হবে।
ডকার ইমেজ লেয়ারে কন্টেইনারের ফাইল সিস্টেমে উপস্থিত প্রতিটি বাইনারির মূল গল্প থাকে। ডকার ইমেজের প্রথম লাইনটি হল "ফ্রম লাইন"। এটি ডকার ইমেজ (এবং এইভাবে, ইমেজ স্তরগুলি) সংজ্ঞায়িত করে যা ডকারফাইল উপরে তৈরি করে।
বর্তমান ডকারফাইল থেকে স্তরগুলি এবং এর মূল চিত্র শৃঙ্খল থেকে স্তরগুলি পরিদর্শন করে, বিকাশকারীরা নির্ধারণ করতে পারে যে একটি কন্টেইনারের রুট ফাইল সিস্টেমের প্রতিটি ফাইল কোথা থেকে এসেছে। এটি খুবই মূল্যবান তথ্য। এটি বিকাশকারীদের সাহায্য করে:
ডকার ইমেজ সংস্করণ জুড়ে ফাইল পরিবর্তনগুলি ট্রেস করতে একটি ভিজ্যুয়ালাইজেশনের স্তরগুলির মাধ্যমে ক্লিক করার কল্পনা করুন। যখন একটি স্বয়ংক্রিয় নিরাপত্তা স্ক্যান আপনার চিত্রগুলির একটিতে একটি দুর্বলতা সনাক্ত করে, তখন কীভাবে দুর্বলতা প্রবর্তিত হয়েছিল তা সনাক্ত করতে একটি স্তর পরিদর্শন সরঞ্জাম ব্যবহার করে কল্পনা করুন৷
অত্যধিক ইমেজ আকার কোম্পানি অনেক টাকা খরচ করতে পারে. অনেক CI/CD পাইপলাইন প্রতিটি পুল অনুরোধের জন্য ডকার ইমেজ টেনে নেয়, তাই দীর্ঘ ডকার ইমেজ ডাউনলোড পাইপলাইনকে ধীর করে দিতে পারে, যা ডেভেলপারদের কম দক্ষ করে তোলে এবং CPU সময় নষ্ট করে। যেহেতু সংস্থাগুলি সাধারণত প্রতি ঘন্টার ভিত্তিতে অবকাঠামোগত খরচ দেয়, প্রতি ঘন্টা নষ্ট করা একটি অপ্রয়োজনীয় খরচ।
নষ্ট গণনা সংস্থানগুলির বাইরে, ফোলা ডকার চিত্রগুলি অত্যধিক নেটওয়ার্ক স্থানান্তর খরচ হতে পারে। যদি কোনও সংস্থা AWS অঞ্চল জুড়ে ডকার ইমেজ ডাউনলোড করে, বা AWS থেকে খোলা ইন্টারনেটে, ডকার ইমেজ ব্লোট সরাসরি অর্থহীন পরিকাঠামো ব্যয়ে অনুবাদ করে। এই দ্রুত আপ যোগ.
ঘটনাক্রমে আপনার ডকার ইমেজ স্তরগুলিতে ব্লোট প্রবর্তন করা সহজ। পূর্বে চিত্রিত ডকারফাইলে একটি ক্লাসিক উদাহরণ রয়েছে — লাইন 4 থেকে স্তরটি ডিস্কে 40MB ফাইল সংরক্ষণ করে, যা 11 লাইন থেকে পরবর্তী স্তর দ্বারা মুছে ফেলা হয়। ডকার চিত্রগুলি কীভাবে কাজ করে, সেই ডেটা এখনও চিত্রের অংশ, যোগ করে 40MB অপ্রয়োজনীয় ছবির আকার।
এটি একটি সাধারণ উদাহরণ—আসলে, এটি সরাসরি ডকারের ডকুমেন্টেশনের বাইরে। আরও জটিল ডকারফাইলগুলিতে, এই ভুলটি চিহ্নিত করা আরও কঠিন হতে পারে।
ডকার ইমেজ স্তরগুলি কমান্ড লাইন ব্যবহার করে ইন্টারঅ্যাক্ট করা কঠিন হতে পারে, কিন্তু ডকার স্কাউট সম্প্রতি প্রকাশিত হওয়ার আগে, কমান্ড লাইনটি ছিল যেখানে আপনি অত্যাধুনিক জিনিসগুলি খুঁজে পেতে পারেন। এখানে দুটি মৌলিক পন্থা আছে.
এটি নো-ফ্রিলস, ইউনিক্স পদ্ধতি। আপনার যা দরকার তা হল একটি হোস্ট যা ডকার ডেমন চালাচ্ছে। এটি একটি সহজ পদ্ধতি:
docker create
চালান।docker inspect
ব্যবহার করুন।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"
এই তদন্তের জন্য আমরা যে স্তরগুলি দেখতে চাই তা হল "LowerDir" ডিরেক্টরিগুলির তালিকা৷ অন্যান্য ডিরেক্টরিগুলি নিজেই ডকার চিত্রের অংশ নয় - আমরা তাদের উপেক্ষা করতে পারি।
সুতরাং, আমরা কমান্ড লাইনে "LowerDir" ডিরেক্টরিগুলির তালিকা বিশ্লেষণ করি:
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
এগুলি হল চিত্রের স্তরগুলির তালিকা, ক্রমানুসারে, সর্বনিম্ন স্তরটি প্রথমে। এখন আমাদের ম্যানুয়ালি এই লেয়ার ডিরেক্টরিগুলিকে ডকারফাইল লাইনগুলির সাথে সম্পর্কযুক্ত করতে হবে যা তাদের তৈরি করেছে।
দুর্ভাগ্যবশত, ডকার আমাদের একটি ডকার ইমেজ থেকে সরাসরি এই লাইনগুলি বের করার উপায় দেয় না - এটি 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
এই আউটপুটটি ব্যবহার করে, আমরা সনাক্ত করতে পারি কোন স্তরগুলিতে ডিরেক্টরি রয়েছে এবং কোন ডকারফাইল কমান্ডটি স্তর তৈরি করেছে (ক্রিয়েটেড বাই কলামে দেখানো হয়েছে)।
docker history
কমান্ড আপনার কন্টেইনারের স্তরগুলিকে একই ক্রমে আউটপুট করে যেমন docker inspect
স্তর ডিরেক্টরিগুলির তালিকা করে। এটি জেনে, আমরা ম্যানুয়ালি দুটি আউটপুট একসাথে মার্জ করতে পারি কোন স্তরগুলি অন্যদের চেয়ে বড়, কোন ডকারফাইল কমান্ড তাদের তৈরি করেছে এবং কোন ডিরেক্টরিতে প্রতিটি স্তর রয়েছে।
এখানে লেয়ার A এর বিষয়বস্তু রয়েছে, যা একটি 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
লেয়ার B এর বিষয়বস্তুর তুলনায়, যা লেয়ার A থেকে অবশিষ্ট ফাইলগুলিকে মুছে দেয়:
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
ডিরেক্টরি উভয় স্তরেই বিদ্যমান, কিন্তু লেয়ার B-এ, ডিরেক্টরিটি প্রায় কোনো স্থান ব্যবহার করে না।
কারণ লেয়ার B এর ডিরেক্টরিতে "হোয়াইটআউট ফাইল" রয়েছে যা ডকার ফাইলগুলিকে চূড়ান্ত কন্টেইনার ফাইল সিস্টেম থেকে বাদ দেওয়ার জন্য চিহ্নিত করতে ব্যবহার করে।
এই কারণে, লেয়ার B-তে ফাইলগুলি "মুছে ফেলা" হওয়া সত্ত্বেও, সেগুলি এখনও লেয়ার A-তে বিদ্যমান, এবং এইভাবে আপনার চিত্রের সামগ্রিক আকারে অবদান রাখে—অপ্রয়োজনীয় ব্লোটের 38.2 MB।
এখন, এটা কি সহজ ছিল না? 😉
ম্যানুয়াল পদ্ধতিটি এতই জটিল এবং অবাধ্য যে ওপেন সোর্স সম্প্রদায় এই কাজের জন্য বিশেষভাবে একটি টুল তৈরি করেছে—এটিকে dive
বলা হয়। ডাইভ হল একটি CLI টুল যা একটি ছবিকে ইনপুট হিসেবে নেয়, এর ফাইল সিস্টেম পার্স করে এবং আপনার টার্মিনালে একটি টেক্সট-ভিত্তিক ইন্টারেক্টিভ UI উপস্থাপন করে। এটি আপনার জন্য চিত্র স্তরগুলির সাথে সম্পর্কযুক্ত করে, আপনাকে আরও সহজে স্তর ডিরেক্টরিগুলি পরিদর্শন করতে দেয়৷
উপরের ডকারফাইল থেকে ডকার ইমেজের বিরুদ্ধে চালানো হলে, এটি এইরকম দেখায়:
┃ ● 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
চেয়ে সুন্দর।
এছাড়াও, বড় ছবিগুলি ডাইভের ক্ষমতাকে ছাপিয়ে যেতে পারে। বড় ইমেজ পরিদর্শন করার সময়, ডাইভ অনেক মেমরি খরচ করে-কখনও কখনও কার্নেল ডাইভ প্রক্রিয়াটিকে কোনো ডেটা আউটপুট করার আগে মেরে ফেলবে।
একটি বিকাশকারীর দৃষ্টিকোণ থেকে, ডকার হাবে ডকার ইমেজ লেয়ার ভিজ্যুয়ালাইজেশন বিদ্যমান থাকার আশা করা সবসময়ই বোধগম্য হয়েছে। সর্বোপরি, আমাদের ডকার ইমেজ ডেটা ইতিমধ্যেই ডকার হাবের ব্যাকএন্ডে থাকে।
আমি প্রায়ই আমার ব্রাউজারে ডকার ইমেজ অভ্যন্তরীণ পরিদর্শন করার কল্পনা করেছি, একটি UI ব্যবহার করে যা দেখতে এরকম কিছু ছিল:
ডকার স্কাউটের সাথে, দেখা যাচ্ছে যে ডকার একটি কোম্পানি হিসাবে সেই দিকে অগ্রসর হচ্ছে। আজ, যদি আমি ডকার হাবের সর্বশেষ পোস্টগ্রেস চিত্রটিতে নেভিগেট করি, আমাকে এটির সাথে স্বাগত জানানো হবে:
একজন বিকাশকারী হিসাবে, এটি উত্তেজনাপূর্ণ। এই নতুন UI আমাকে চিত্র স্তরের বিশদটি দৃশ্যতভাবে ব্রাউজ করতে দেয়, দুর্বলতা এবং চিত্রের আকারের সমস্যাগুলি হাইলাইট করে ঠিক যেমনটি আমি চাই।
যখন ডকার হাব প্রথম চালু করা হয়েছিল, তখন এর দুই ধরনের ব্যবহারকারী ছিল:
এবং ডকারকে এই দুই ধরণের ব্যবহারকারীদের কাছে ভিন্নভাবে যোগাযোগ করতে হয়েছিল।
ডকার 2013 সালে আত্মপ্রকাশ করার পরে, বিকাশকারীরা অবিলম্বে তাদের পণ্য ব্যবহার করতে চেয়েছিলেন। ডকার কন্টেইনার প্রত্যেকের সফ্টওয়্যার প্যাকেজিং এবং স্থাপনার মানসম্মত করে। সফ্টওয়্যার বিকাশকারী সম্প্রদায়ে কন্টেইনারগুলি দ্রুত জনপ্রিয় হয়ে ওঠে।
সফটওয়্যার প্রকাশকরা অবশ্য আরও দ্বিধায় ছিলেন। কেন তারা তাদের সফ্টওয়্যারকে এমন একটি প্ল্যাটফর্মে আপলোড করবে যার মূল উপযোগিতা সফ্টওয়্যার পণ্যগুলির মধ্যে পার্থক্য দূর করছে?
ডকার হাব সফল করার জন্য ডকারকে তাদের জয় করতে হয়েছিল। তাই ডেভেলপারদের আকৃষ্ট করার উপর ফোকাস করার পরিবর্তে, ডকার হাবের ডিজাইন এবং ফিচার সেটটি সফ্টওয়্যার প্রকাশকদের জন্য তৈরি করেছে।
প্রকাশকদের জন্য, ডকার হাব একটি বিপণন সাইট ছিল। এটি তাদের পণ্যের বিজ্ঞাপনের জন্য একটি জায়গা দিয়েছে। এটি ডেভেলপারদের ডকার ইমেজের অভ্যন্তরীণ বিবরণ দেখতে দেয়নি, গাড়ি ডিলারশিপ আপনাকে তাদের ইঞ্জিন ব্লকগুলিকে আলাদা করতে দেয়। অভ্যন্তরীণ প্রকৌশল বিশদগুলি প্রদর্শনে রাখা হয়নি, সেগুলিকে লুকিয়ে রাখা হয়েছিল, তাই ক্রেতারা কীভাবে তৈরি করা হয়েছিল তা নয়, নিজেরাই পণ্যগুলির দিকে মনোনিবেশ করতেন।
ডকার হাবের ইমেজ সাইজ অপ্টিমাইজেশান এবং সাপ্লাই চেইন ইন্ট্রোস্পেকশনের জন্য ডেভেলপার-মুখী বৈশিষ্ট্যের অভাব ছিল কারণ ডকার ইতিমধ্যেই সেই বৈশিষ্ট্যগুলি ছাড়াই বিকাশকারীদের উপর জয়লাভ করেছে। প্রকৃতপক্ষে, এই বৈশিষ্ট্যগুলিতে সফ্টওয়্যার প্রকাশকদের খারাপ দেখানোর প্রবণতা রয়েছে - এবং তারা ডকার হাবের ব্যবহারকারীদের সফল হওয়ার জন্য এখনও জয়ের প্রয়োজন ছিল।
সফ্টওয়্যার প্রকাশক এবং বিকাশকারী উভয়কে পরিবেশন করার এই গতিশীলতা ডকার হাবকে একটি দ্বিমুখী প্ল্যাটফর্ম করে তুলেছে।
দ্বি-পার্শ্বযুক্ত প্ল্যাটফর্ম হল এমন ব্যবসা যেগুলির দুটি ভিন্ন শ্রেণীর ব্যবহারকারী রয়েছে এবং জিনিসগুলি কাজ করার জন্য প্ল্যাটফর্মে অংশগ্রহণ করার জন্য তাদের উভয়েরই প্রয়োজন। সাধারণত, এটি প্ল্যাটফর্ম ব্যবহার করার অনুপ্রেরণা যা ব্যবহারকারীদের বিভিন্ন গ্রুপে বিভক্ত করে।
যদিও ব্যবহারকারীদের দুটি গ্রুপ একে অপরের সাথে সরাসরি লেনদেন নাও করতে পারে, দ্বি-পার্শ্বযুক্ত প্ল্যাটফর্মগুলি বাজারের মতো - তারা মূল্য তৈরি করে না যদি না বিক্রেতারা বিক্রি করতে এবং ক্রেতারা কিনতে না দেখায়।
প্রযুক্তি শিল্পে, দ্বি-পার্শ্বযুক্ত প্ল্যাটফর্মগুলি সর্বব্যাপী। সফল হলে, এই ব্যবসায়িক মডেলগুলি নেটওয়ার্ক প্রভাব তৈরি করে যা ব্যবসাগুলিকে টেকসই বৃদ্ধি এবং লাভের দিকে চালিত করে। একটি নির্দিষ্ট বিন্দুর পরে, প্ল্যাটফর্মের আকার এবং একটি স্থানের প্রতিষ্ঠিত অবস্থান প্ল্যাটফর্মে নতুন ব্যবহারকারীদের আকর্ষণ করে।
একবার আপনি কী খুঁজছেন তা জানলে, দ্বি-পার্শ্বযুক্ত প্ল্যাটফর্মগুলি সহজেই খুঁজে পাওয়া যায়। এখানে তিনটি উদাহরণ আছে।
LinkedIn-এ, দুই ধরনের ব্যবহারকারী আছে—কর্মচারী এবং নিয়োগকারী পরিচালক। উভয় গ্রুপই বিভিন্ন কারণে অংশগ্রহণ করে—কর্মচারীরা চাকরি চায়, এবং নিয়োগকারী ম্যানেজাররা লোক নিয়োগ করতে চায়।
অন্য গ্রুপ অংশগ্রহণ করা শুরু না করা পর্যন্ত কোনো গ্রুপই সাইট থেকে যা চেয়েছিল তা পেতে পারেনি। প্রতিটি গোষ্ঠীর পর্যাপ্ত সংখ্যক সাইন আপ হয়ে গেলে, এটি উভয় গ্রুপের নতুন সদস্যদের জন্য ডিফল্ট জায়গা হয়ে ওঠে এবং মাইক্রোসফ্ট 26 বিলিয়ন ডলারে কেনার জন্য সাইটের বৃদ্ধি নিজেই স্থায়ী হয়।
ইউটিউবে কন্টেন্ট ক্রিয়েটর আছে এবং দর্শক আছে। দর্শকরা ভিডিও দেখতে সাইটে আসে—সামগ্রী নির্মাতারা ভাল ভাইব, খ্যাতি এবং ভাগ্যের জন্য সাইটে প্রকাশ করে।
YouTube কন্টেন্ট স্রষ্টারা সফল হতে পারে এমন একটি জায়গা হিসেবে খ্যাতি প্রতিষ্ঠা করার পর, আরও বেশি সংখ্যক কন্টেন্ট স্রষ্টারা উপস্থিত হয়েছেন—এবং তারা আরও বেশি কন্টেন্ট তৈরি করার সাথে সাথে আরও বেশি দর্শক দেখতে এসেছে। একবার প্ল্যাটফর্মটি একটি নির্দিষ্ট আকারের বাইরে বেড়ে গেলে, বিষয়বস্তু নির্মাতা এবং দর্শকদের এটি ব্যবহার চালিয়ে যাওয়া ছাড়া আর কোনও বিকল্প ছিল না—প্রতিটি গোষ্ঠীর অপরটির প্রয়োজন ছিল এবং তারা শুধুমাত্র YouTube এর মাধ্যমে একে অপরকে খুঁজে পেতে পারে।
ডকার হাব প্রাসঙ্গিক হওয়ার জন্য, ছবি আপলোড করার জন্য সফ্টওয়্যার প্রকাশকদের এবং সেগুলি ডাউনলোড করার জন্য বিকাশকারীদের প্রয়োজন৷ একবার পর্যাপ্ত প্রকাশকরা ছবিগুলিকে ডকার হাবে ঠেলে দিলে, এটি ডেভেলপারদের কাছে টানার ডিফল্ট জায়গা হয়ে উঠবে। প্ল্যাটফর্মটি বাড়তে থাকলে, ডকার হাব তাদের সকলকে শাসন করার জন্য একটি রেজিস্ট্রি হিসাবে তার আধিপত্যকে সিমেন্ট করবে।
অন্তত, এটাই ছিল পরিকল্পনা। বাস্তবে, ডকার (কোম্পানি) প্রত্যাখ্যান করেছিল এবং ডকার হাব কখনই "একটি" হয়ে ওঠেনি। একটি দ্বি-পার্শ্বযুক্ত প্ল্যাটফর্ম তৈরি করার সময়, স্টার্টআপগুলির একটি পণ্য থাকে, তবে তাদের দুবার পণ্য-বাজার উপযুক্ত খুঁজে পেতে হয়। ডকারের জন্য, এই বোঝাটি বহন করার জন্য খুব বেশি ছিল - শেষ পর্যন্ত, এটি ডকারকে অর্ধেক ভাগ করে দেয় ।
এখন, তার এন্টারপ্রাইজ ব্যবসা বিক্রি করার পরে, ডকার নিজেকে নতুন করে উদ্ভাবন করেছে, তার সাবস্ক্রিপশন পরিষেবাকে একচেটিয়াভাবে ডেভেলপার এবং তাদের নিয়োগকারীদের উপর ফোকাস করে। ডকার হাব এখন আর দ্বিমুখী প্ল্যাটফর্ম নয়, এটি সহজ SaaS—গ্রাহকরা তাদের ছবিগুলিকে ঠেলে ও টানানোর বিনিময়ে একটি মাসিক ফি প্রদান করে।
এটি ক্যালকুলাস পরিবর্তন করে। ডকারকে খুশি করার জন্য এখন আর "প্রকাশক" ব্যবহারকারী ব্যক্তিত্ব নেই—তারা সবই ডেভেলপারদের মধ্যে রয়েছে৷ ডকার হাবের জন্য, এটি ডকার স্কাউটের চিত্র স্তর পরিদর্শন কার্যকারিতার জন্য পথ তৈরি করে। আমরা যারা দূর থেকে দেখছি, এটি একটি স্টার্টআপের ব্যবসায়িক মডেল এবং এর পণ্য অফারগুলির মধ্যে সূক্ষ্ম, ভিত্তিগত সংযোগ প্রদর্শন করে।
এছাড়াও এখানে প্রকাশিত.