https://github.com/hasibul442/what-is-docker

https://github.com/hasibul442/what-is-docker

Last synced: 7 months ago
JSON representation

• Host: GitHub
• URL: https://github.com/hasibul442/what-is-docker
• Owner: hasibul442
• Created: 2022-10-27T06:39:37.000Z (almost 3 years ago)
• Default Branch: main
• Last Pushed: 2022-10-30T10:28:00.000Z (almost 3 years ago)
• Last Synced: 2025-01-21T12:11:26.681Z (9 months ago)
• Size: 23.4 KB
• Stars: 0
• Watchers: 2
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

          
# ডকার কি ও কেন ?

মাইক্রোসার্ভিস ডেভেলপার বা ডেভ-অপস যারা আছেন তাদের কাছে ডকার নামটা বেশ পরিচিত।একটু গভীরে গিয়ে ডকারের ব্যাপারে জানতে হলে  Operating System Level Virtualization কি  সেটা বুঝতে হবে। আপাতত নিচের সংজ্ঞাটা দেখে নেওয়া যাক, বিস্তারিত পরে বলছি। 

একটি কার্নেলের ওপর একাধিক isolated ইউজার স্পেইসের অস্তিত্বকে অপারেটিং সিস্টেম লেভেল ভার্চুয়ালাইজেসন বলে [সোর্স: Wikipedia]

একটু খুলে বললে আধুনিক অপারেটিং সিস্টেমগুলোতে আমাদের অ্যাপ্লিকেশনগুলো Virtual Memory নামক একটা মেমোরি এড্রেস স্পেইসে চলে। এই ব্যাপারটা অনেকেরই জানা। এভাবে ভার্চুয়াল মেমোরি ব্যবহার করার পিছনে অনেকগুলো কারনের মধ্যে অন্যতম একটি কারণ হচ্ছে Memory Protection, মানে রান টাইমে একটি প্রসেস যাতে অন্য আরেকটি প্রসেসের মেমোরি স্পেইসে প্রবেশ করতে না পারে সেটা নিশ্চিত করা।

অপারেটিং সিস্টেমে কিছু প্রসেস আছে যাদের সিস্টেম System Resource গুলো  সরাসরি access করার Privilege থেকে থাকে। 

এই প্রসেসগুলো সাধারণত Kernel এবং Device Drivers হয়ে থাকে। এসমস্ত প্রিভিলেজসম্পন্ন প্রসেসসমুহের মেমোরি প্রটেকশনের জন্যে ভার্চুয়াল মেমোরি স্পেইসের একাংশকে dedicate করে দেয়া হয়। এর কারনে ভার্চুয়াল মেমোরি দ্বিখণ্ডিত হয়। একটি খণ্ডে চলে কার্নেল আর ডিভাইস ড্রাইভারদের মত প্রিভিলেজসম্পন্ন প্রসেসসমুহ আর এই খণ্ডটা Kernel Space নামে পরিচিত। আরেকটি খণ্ডে চলে বাকি সব সাধারণ প্রসেস যেমন ব্রাউসার, টেক্সট এডিটর, গেমস, ইত্যাদি আর এই খণ্ডটা User Space নামে পরিচিত।

প্রিভিলেজের এরূপ বৈষম্যের কারনে ইউজার স্পেইসের প্রসেসগুলো বা ইউজার প্রসেস সিস্টেম রিসোর্সগুলোকে সরাসরি এক্সেস করতে পারে না, বরং তারা কার্নেল ও ডিভাইস ড্রাইভারদের মাধ্যমে সিস্টেম রিসোর্সগুলো এক্সেস করে থাকে। আর এটা করতে ইউজার প্রসেস কার্নেলের সাথে System Call এর মাধ্যমে communicate করে।

একটা সময় ছিল যখন একটা সার্ভার আর একটা সার্ভিস-অ্যাপ্লিকেশন হাজারটা কাজ করত। মানে মনে করেন আপনার একটা ইনভেন্টরি ম্যানেজমেন্ট ওয়েব অ্যাপ্লিকেশন আছে। আর সেই ওয়েব অ্যাপ্লিকেশনের জন্য একটা ফ্রন্টএন্ড, একটা ব্যাকএন্ড আর একটা ডেটাবেস আছে। এই ধরনের অ্যাপ্লিকেশন আর্কিটেকচারকে বলা হয় Three-Tier-Architecture। আর আপনার সেই একটা ব্যাকএন্ডেই সব business logic handle করে। মানে অথেনটিকেশন থেকে শুরু করে ইনভেন্টরির যত কাজ কর্ম, যেমন স্টক ম্যানেজমেন্ট, সেলস ম্যানেজমেন্ট, কন্টাক্ট ইনফরমেশন ম্যানেজমেন্ট, ডেটাবেস এক্সেস, লগিং, টেস্টিং সব! এই ধরনের ব্যাকএন্ড আর্কিটেকচারকে বলা হয় Monolithic-Architecture।

## মাইক্রোসার্ভিস-আর্কিটেকচার

মনোলিথিক আর্কিটেকচারের সমস্যা কোথায় সেই কথা বলতে অনেক সময় লাগবে। যাই হোক,  একটা ব্যাকএন্ড সার্ভিস দ্বারা সব কাজ করার বিপরীতে কাজগুলোকে ছোট ছোট সার্ভিসে ভেঙ্গে দেয়াটাই অনেক সময়ে শ্রেয়। মানে ইনভেন্টরির স্টক ম্যানেজমেন্টের জন্য একটা সার্ভিস, সেলস ম্যানেজমেন্টের জন্য একটা সার্ভিস, কন্টাক্ট ইনফরমেশন ম্যানেজমেন্টের জন্য একটা সার্ভিস, অথেনটিকেশনের জন্য একটা সার্ভিস, লগিং-এর জন্য একটা সার্ভিস, ইত্যাদি। এই ধরনের অ্যাপ্লিকেশন আর্কিটেকচারকে বলা হয় Microservice-Architecture।

ইউজার স্পেইস কি জিনিস সেটা আমরা জানলাম। আর মাইক্রোসার্ভিস কি  সেটাও একটু আকটু বুঝলাম। এখানে লক্ষণীয় ব্যাপার এই যে আমাদের মাইক্রোসার্ভিসগুলো কিন্তু সাধারণত ইউসার অ্যাপ্লিকেশন হয়ে থাকে। মানে তারা ইউজার স্পেইসে চলে। আর তারা যেই সার্ভারে থাকে সেই সার্ভারের সিস্টেম রিসোর্সগুলো এক্সেস করতে তাদের সেই সার্ভারের কার্নেলের সাহায্য নিতে হয়।

আর তাই আমাদের ইনভেন্টরি ম্যানেজমেন্টের আলাদা আলাদা সার্ভিসগুলো বা মাইক্রোসার্ভিসগুলো, যেমন স্টক ম্যানেজমেন্ট সার্ভিস, সেলস ম্যানেজমেন্ট সার্ভিস, কন্টাক্ট ইনফরমেশন ম্যানেজমেন্ট সার্ভিস, ইত্যাদি সবগুলো যদি একটা সার্ভারে থাকে তাহলে সবগুলো সার্ভিসই একই ইউজার স্পেইস শেয়ার করবে আর একই কার্নেলের সাথে কথা বলবে।

But life is not that simple. আমাদের প্রত্যেকটা সার্ভিস যে একই Runtime Environment বা একই ইউজার সেটিংসের ওপর নির্ভরশীল হবে সেটার কি গ্যারান্টি? বরং অধিকাংশ ক্ষেত্রেই সার্ভিসগুলো ভিন্ন ভিন্ন রানটাইম এনভায়রনমেন্ট আর ভিন্ন ভিন্ন ইউজার সেটিংসের ওপর চলে। সেটাই বেশি কমন।

মানে মনে করেন আমাদের স্টক ম্যানেজমেন্ট সার্ভিসটি চলে পাইথনের জ্যাংগো ফ্রেইমওয়ারকে, আমাদের সেলস ম্যানেজমেন্ট সার্ভিসটি চলে জাভার স্প্রিং ফ্রেইমওয়ারকে, ইত্যাদি। শুধু তাই না: আবার এমনও হতে পারে যে আমাদের দুই বা তার অধিক সার্ভিস একই পোর্টে চলে। বা একই Environment Variable ব্যবহার করে, কিন্তু তার ভ্যালু ভিন্ন।

এখানে একটু বলে নেয়া ভালো যে, আমরা যারা ছোটোখাটো ডেভেলপার তাঁদের হয়তো মনে হতে পারে যে আমার একটা প্রোজেক্টকে এরকম ছোটো ছোটো সার্ভিসে ভাগ কেন করবো? আবার সেই সব সার্ভিস একেকটা আলাদা আলাদা ল্যাঙ্গুয়েজ, ফ্রেমওয়ার্কে কেন চলবে? মূলত ছোটোখাটো এপ্লিকেশনের জন্য চিন্তা করলে এটা অদ্ভূত মনে হতেই পারে। কিন্তু আপনি যখন অনেক বড় মাপের কোনো এপ্লিকেশন নিয়ে কাজ করবেন যার লাখ লাখ ইউজার তখন আপনার সার্ভিসকে আরো রিলায়েবল, এফিসিয়েন্ট করার জন্য অনেক ক্ষেত্রেই মাইক্রোসার্ভিসই ভালো আর্কিটেকচার বলে মনে হতে পারে। মাইক্রোসার্ভিস কেন, কখন, কোথায় দরকার সেটা যেহেতু এই আর্টিকেলের আলোচ্য বিষয় না, তাই আপাতত ওদিকে যাচ্ছি না।

যাই হোক মূল কথায় ফিরে আসি। এধরনের অনেক কারনে সার্ভিসগুলো একই ইউজার স্পেইসে চালানো মোটেই ভাল আইডিয়া না। তাহলে কি করবো? একেকটা সার্ভিসের জন্য একেকটা physical server চালাবো?

কিন্তু বাস্তবতা হল ডেভলপাররা অলস, আর কোম্পানিরা গরিব! তাই চাইলেও অধিকাংশ সময়ে প্রতিটা সার্ভিসের জন্য আলাদা আলাদা ফিজিক্যাল সার্ভার রাখাটা feasible না।

তাহলে উপায়? আমরা দেখেছি যে একটা সার্ভারে একটা কার্নেল থাকে আর একটা ইউজার স্পেইস থাকে। আর আমাদের সমস্যাটাতো ইউজার স্পেইস নিয়ে। কার্নেল নিয়ে তো আমাদের কোনও ইস্যু নেই। আমরা যদি কোন কায়দায় একটা সার্ভারের একটা কার্নেলের ওপরেই অনেকগুলো ইউজার স্পেইস চালাতে পারতাম? প্রত্যেকটা ইউজার স্পেইসে একটা করে সার্ভিস চলবে। তাহলে ব্যাপারটা কেমন হয়?

## অপারেটিং সিস্টেম লেভেল ভার্চুয়ালাইজেসনের সংজ্ঞাটা মনে আছে তো?

একটি কার্নেলের ওপর একাধিক isolated ইউসার স্পেইসের অস্তিত্বকে অপারেটিং সিস্টেম লেভেল ভার্চুয়ালাইজেসন বলে [সোর্স: wikipedia]

ওকে, তো যেভাবে ভাবছিলাম সেটার সাথে অপারেটিং সিস্টেম লেভেল ভার্চুয়ালাইজেসনের সংজ্ঞাটার মিল পাওয়া যাচ্ছে। লক্ষ্য করুন সংজ্ঞাটাতে isolated শব্দটা ব্যবহার করা হয়েছে। Isolated বলতে এখানে বোঝানো হচ্ছে প্রতিটা ইউজার স্পেইসের রানটাইম এনভায়রনমেন্ট, ইউজার সেটিংস, ইত্যাদি ভিন্ন ভিন্ন। আর একটা ইউজার স্পেইসের প্রসেস আরেকটা ইউজার স্পেইসে প্রবেশ করতে পারে না। মানে মেমোরি প্রটেকশন, যেটার ব্যাপারে আগে বলেছি।

গ্রেট, তাহলে তাই করি! মানে একটা সার্ভারে একটা কার্নেলের ওপর অনেকগুলো isolated ইউউজার স্পেইস, আর একেকেটা ইউজার স্পেইসে একেকটা সার্ভিস চলবে।

মানে পাইথনের জ্যাংগো ফ্রেইমওয়ারকের ওপর স্টক ম্যানেজমেন্ট সার্ভিসটি একটা ইউজার স্পেইসে চলবে, জাভার স্প্রিং ফ্রেইমওয়ারকের ওপর সেলস ম্যানেজমেন্ট সার্ভিসটি আরেকটা ইউজার স্পেইসে চলবে, ইত্যাদি।

## অপারেটিং সিস্টেম লেভেল ভার্চুয়ালাইজেসন for the win!

কিন্তু চিন্তা শেষ হয়েও হয়না শেষ! এই isolation মেইন্টেইন করার দায়িত্ব কে নেবে?! আরও লক্ষ্য করুন, একটা কার্নেলের ওপর অনেকগুলো ইউজার স্পেইস। মানে একই সিস্টেম রিসোর্স বিভিন্ন ইউজার স্পেইসের প্রসেস একই সময়ে এক্সেস করতে চাইতে পারে। আবার একটা ইউজার স্পেইসের প্রসেস আরেকটা ইউজার স্পেইসের প্রসেসের সাথে কথা বলতে চাইতে পারে। এক কথায় অনেকগুলো জটিলতা দেখা দিবে আর এসব ম্যানেজ করার জন্য কিছু একটা লাগবে। মানে ইউজার স্পেইসগুলোর সার্বিক ব্যবস্থাপনা, তাদের কার্নেলের সাথে যোগাযোগ এবং একে ওপরের সাথে যোগাযোগের জন্যে ম্যানেজারের মত কিছু একটা দরকার।

আশা করি এতক্ষণে অপারেটিং সিস্টেম লেভেল ভার্চুয়ালাইজেসন কি আর কেন লাগতে পারে সেটার একটা ধারণা পেয়েছি। কিন্তু এটাতো একটা কনসেপ্ট মাত্র। এই কনসেপ্টের অনেকগুলো ইমপ্লিমেন্টেশন আছে। অপারেটিং সিস্টেম লেভেল ভার্চুয়ালাইজেসন কনসেপ্টটার অনেকগুলো ইমপ্লিমেন্টেশনের মধ্যে অন্যতম একটা ইমপ্লিমেন্টেশন হচ্ছে ডকার (Docker) !

আর একটা কার্নেলের ওপর আলাদা আলাদা isolated ইউজার স্পেইসগুলোকে Container বলা হয়। বাস্তবে সবগুলো কন্টেইনারই একই ইউজার স্পেইসের ভেতরে থাকে, কিন্তু ভার্চুয়ালি আলাদা আলাদা ইউজার স্পেইস মনে হয়

একটা সময় ছিল যখন একটা সার্ভারেই কোড ডেভেলপ করা হতো, সেই সার্ভারেই টেস্ট হতো, আর সেই সার্ভারেই ডিপ্লয় হতো। কিন্তু এখন অধিকাংশ সময়েই একটা প্রজেক্টের পিছে অনেকজন পারসোনেল থাকেন আর একটা অ্যাপ্লিকেশন অনেকগুলো সার্ভারে ডিপ্লয় করা হয়। মানে মনে করেন আমাদের ইনভেন্টরি ম্যানেজমেন্ট প্রজেক্টের কোডটা হয়তো লেখা হয় কয়েকজন ডেভেলপারের ল্যাপটপে, সেটা টেস্ট করা হয় একটা লোকাল সার্ভারে আর সেটা ডিপ্লয় করা হয় AWS-এর EC2-তে।

এর কারনে প্রায় সময়েই দেখা যায় দুজন ভিন্ন ডেভেলপারের ল্যাপটপের রানটাইম এনভায়রনমেন্ট ভিন্ন হওয়ায় অ্যাপ্লিকেশনটাও ভিন্ন ভাবে behave করে। আবার এমনটাও হয় যে ল্যাপটপে সব ঠিকঠাক কিন্তু লোকাল সার্ভারে টেস্ট করার সময়ে অ্যাপ্লিকেশনটা ঠিক মত চলছে না কারন সার্ভারের এনভায়রনমেন্ট ল্যাপটপের এনভায়রনমেন্ট থেকে ভিন্ন। আর এইসব এনভায়রনমেন্ট ঠিকঠাক করতেই সবার দিন রাত শেষ!

আমরা যদি কোন কায়দায় প্রতিটা ডেভেলপমেন্ট ল্যাপটপে আর লোকাল সার্ভারে আর EC2-তেও, মানে সবগুলো জায়গায়, একই ডকার কন্টেইনারে আমাদের অ্যাপ্লিকেশনটা চালাতে পারতাম? সবগুলো জায়গায় একই রানটাইম এনভায়রনমেন্ট আর সেটিংস নিশ্চিত হতো। তাহলে ব্যাপারটা কেমন হয়?

ঠিক এই কাজটা করাই ডকার কন্টেইনার ইমেইজের কাজ। আরো একটা সংজ্ঞা দেখে নেই।

আমাদের অ্যাপ্লিকেশন কোড, আর সেই কোড রান করার জন্য যাবতীয় রানটাইম এনভায়রনমেন্ট আর সেটিংস সব কিছু মিলেই একটা ডকার কন্টেইনার হয়। সেটা আমরা দেখলাম। আর এই কন্টেইনারটার executable package কেই বলে কন্টেইনার ইমেইজ।

মূলত কন্টেইনার ইমেইজ হচ্ছে একটা ডকার কন্টেইনার বানানোর description বা বিবরণ। Executable package বলতে এখানে এটা বোঝানো হচ্ছে যে একটা কন্টেইনার ইমেইজের মাধ্যমে যেকোনো মেশিনেই একই ডকার কন্টেইনার রান করা যায়। অবশ্যই মেশিনগুলোতে ডকার ইন্সটল করা থাকতে হবে

কন্টেইনার ইমেইজের দ্বারা একটা কন্টেইনার বিভিন্ন মেশিনে শেয়ার করা যায়। আরো সহজে বললে কন্টেইনার ইমেইজ হচ্ছে একটা কন্টেইনারের shareable স্ন্যাপশট।

## ডকার ও ভার্চুয়াল মেশিন

ডকারের প্রথম রিলিজ হয় ২০১৩ সালে। এর আগ পর্যন্ত এনভায়রনমেন্ট ভার্চুয়ালাইজেসনের কাজটা মূলত ভার্চুয়াল বক্স আর ভি. এম. ওয়্যারের মত বিভিন্ন Virtual Machine দিয়ে করা হতো। আমরা অনেকেই ভার্চুয়াল মেশিন কম-বেশি ব্যবহার করেছি। কন্টেইনার আর ভার্চুয়াল মেশিনের মধ্যে মৌলিক পার্থক্যটা এই যে কন্টটেইনারদের নিজস্ব কার্নেল থাকে না, তারা সার্ভারের হোস্ট অপারেটিং সিস্টেমের কার্নেলটাই শেয়ার করে। আর ভার্চুয়াল মেশিনেরা সবাই নিজস্ব আলাদা আলাদা অপারেটিং সিস্টেম আর কার্নেল ব্যবহার করে।

প্রত্যেকটা ভার্চুয়াল মেশিনের নিজ নিজ অপারেটিং সিস্টেম আর কার্নেল থাকায় স্বাভাবিক ভাবেই ভার্চুয়াল মেশিনের ইমেইজগুলো বা iso ফাইলগুলো ডকারের কন্টেইনার ইমেইজগুলোর থেকে অনেক বড় হয়। আর একই কারনে ভার্চুয়াল মেশিন চালু হতেও অনেক বেশি সময় নেয়। এসব কারণ ছাড়াও আরও বেশ কিছু কারণে অনেক ক্ষেত্রেই ভার্চুয়াল মেশিনের চেয়ে ডকারের ব্যবহারটাই আজকাল বেশি জনপ্রিয়তা পাচ্ছে।