পাঠ ২২ · ৫৭-এর মধ্যে · মডিউল ৬
Home / Courses / Cloud Computing & DevOps / কন্টেইনার vs VM

কন্টেইনার বনাম ভার্চুয়াল মেশিন

Containers vs virtual machines
৮ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • হাইপারভাইজার-ভিত্তিক ভার্চুয়ালাইজেশন ও OS-লেভেল ভার্চুয়ালাইজেশনের মধ্যে মৌলিক পার্থক্য
  • কেন কন্টেইনার VM-এর চেয়ে হালকা ও দ্রুত, কিন্তু তুলনামূলক কম আইসোলেটেড
  • namespaces ও cgroups — কন্টেইনার আইসোলেশনের পেছনের OS-লেভেল মেকানিজম, সংক্ষেপে
  • Python দিয়ে VM বনাম কন্টেইনারের একটি তুলনামূলক ডেটা টেবিল তৈরি ও পাঠ করা

১ · ভার্চুয়াল মেশিন — সম্পূর্ণ মেশিন ভার্চুয়ালাইজেশন

ভার্চুয়াল মেশিনVirtual Machine (VM)একটি হাইপারভাইজার-এর মাধ্যমে সম্পূর্ণ একটি কম্পিউটার এমুলেট করা — নিজস্ব সম্পূর্ণ OS কার্নেলসহ, শেয়ার্ড ফিজিক্যাল হার্ডওয়্যারের উপর চলে। একটি হাইপারভাইজারHypervisorএকটি সফটওয়্যার লেয়ার যা ফিজিক্যাল হার্ডওয়্যারের উপর বসে একাধিক VM-কে চালানো ও তাদের মধ্যে হার্ডওয়্যার রিসোর্স ভাগ করে দেয়।-এর মাধ্যমে একটি ফিজিক্যাল সার্ভারের উপর একাধিক VM চলে — প্রতিটি VM-এর নিজস্ব সম্পূর্ণ অপারেটিং সিস্টেম কার্নেল, নিজস্ব বুট প্রসেস, নিজস্ব ডিভাইস ড্রাইভার — যেন এটি একটি সম্পূর্ণ স্বতন্ত্র কম্পিউটার।

ফলাফল — প্রতিটি VM ভারী (গিগাবাইট আকারের ডিস্ক ইমেজ, শত শত মেগাবাইট RAM শুধু OS চালাতেই লাগে), এবং বুট হতে সময় লাগে (একটি সম্পূর্ণ OS বুট করতে হয় — সাধারণত সেকেন্ড থেকে মিনিট)। বিনিময়ে, আইসোলেশন সবচেয়ে শক্তিশালী — একটি VM-এর ক্র্যাশ বা কম্প্রোমাইজ অন্য VM-কে সরাসরি প্রভাবিত করতে পারে না, কারণ প্রতিটির নিজস্ব সম্পূর্ণ কার্নেল রয়েছে।

২ · কন্টেইনার — OS-লেভেল ভার্চুয়ালাইজেশন

কন্টেইনারContainerOS-লেভেলে ভার্চুয়ালাইজ করা একটি প্রসেস — হোস্টের কার্নেল শেয়ার করে, কিন্তু ফাইলসিস্টেম/প্রসেস/নেটওয়ার্ক আলাদা (isolated) থাকে namespaces ও cgroups-এর মাধ্যমে। একই হোস্টে চলা সব কন্টেইনার হোস্টের একই কার্নেল শেয়ার করে — কিন্তু Linux-এর দুটি কার্নেল ফিচারের মাধ্যমে একে অপর থেকে আলাদা থাকে —

Namespaces
প্রতিটি কন্টেইনারকে তার নিজস্ব প্রসেস আইডি, ফাইলসিস্টেম ভিউ ও নেটওয়ার্ক ইন্টারফেসের "দৃষ্টিভ্রম" দেয় — যদিও আসলে সবাই একই কার্নেলে চলছে।
Cgroups (Control Groups)
প্রতিটি কন্টেইনার কতটুকু CPU, মেমরি, ডিস্ক I/O ব্যবহার করতে পারবে তার সীমা বেঁধে দেয় — একটি কন্টেইনার পুরো হোস্টের রিসোর্স খেয়ে ফেলতে পারে না।

যেহেতু কন্টেইনারকে আলাদা কার্নেল বুট করতে হয় না — শুধু হোস্টের কার্নেলের উপর একটি আইসোলেটেড প্রসেস শুরু হয় — একটি কন্টেইনার সাধারণত সেকেন্ড, প্রায়ই মিলিসেকেন্ডে চালু হয়ে যায়, এবং শুধু অ্যাপ্লিকেশন ও তার ডিপেন্ডেন্সির জন্য যতটুকু জায়গা লাগে ততটুকুই নেয় (সাধারণত মেগাবাইটে, VM-এর গিগাবাইটের তুলনায়)।

ভার্চুয়াল মেশিন স্ট্যাক App A Guest OS (কার্নেল #১) App B Guest OS (কার্নেল #২) হাইপারভাইজার ফিজিক্যাল হার্ডওয়্যার কন্টেইনার স্ট্যাক App A App B কন্টেইনার ইঞ্জিন হোস্ট OS (একটিই শেয়ার্ড কার্নেল)
বাম দিকে প্রতিটি অ্যাপের নিজস্ব গেস্ট OS আছে (ভারী); ডান দিকে সব অ্যাপ একই হোস্ট কার্নেল শেয়ার করে, শুধু কন্টেইনার ইঞ্জিন namespaces/cgroups দিয়ে আলাদা রাখে (হালকা)।
ট্রেড-অফ — গতি বনাম আইসোলেশন

কন্টেইনারের শেয়ার্ড কার্নেল মানে একটি কার্নেল-লেভেল দুর্বলতা তাত্ত্বিকভাবে একাধিক কন্টেইনারকে প্রভাবিত করতে পারে — VM-এর তুলনায় ছোট কিন্তু বাস্তব একটি অ্যাটাক সারফেস (Cybersecurity কোর্সের কন্টেইনার-সিকিউরিটি পাঠে বিস্তারিত)। তাই অনেক প্রোডাকশন সিস্টেম দুটোই একসাথে ব্যবহার করে — একটি VM-এর ভেতরে কন্টেইনার চালানো, দুই স্তরের আইসোলেশন পাওয়ার জন্য।

৩ · "বিল্ড ওয়ান্স, রান এনিহোয়ার"

একটি কন্টেইনার ইমেজ অ্যাপ্লিকেশন কোড, তার সব লাইব্রেরি ডিপেন্ডেন্সি, এমনকি নির্দিষ্ট সংস্করণের রানটাইম — সব একসাথে একটি একক প্যাকেজে বান্ডল করে। ফলাফল — যে মেশিনেই এই ইমেজ চালানো হোক না কেন (ডেভেলপারের ল্যাপটপ, টেস্টিং সার্ভার, প্রোডাকশন ক্লাউড ইনস্ট্যান্স) — ঠিক একই এনভায়রনমেন্ট পাওয়া যায়, তাই কুখ্যাত "আমার মেশিনে তো কাজ করছিল" সমস্যা দূর হয়। এটিই কন্টেইনার প্রযুক্তির সবচেয়ে বড় ব্যবহারিক সুবিধা এবং L23-এ আমরা দেখব কীভাবে একটি Dockerfile থেকে এই ইমেজ তৈরি হয়।

Python
# VM বনাম কন্টেইনার — একটি তুলনামূলক সিমুলেশন (illustrative সংখ্যা, বাস্তব বেঞ্চমার্ক নয়)
comparison = {
    "ভার্চুয়াল মেশিন (VM)": {
        "startup_time_sec": 60,
        "isolation_level": "শক্তিশালী (নিজস্ব কার্নেল)",
        "resource_overhead_mb": 2048,
        "portability": "মাঝারি (হাইপারভাইজার-নির্ভর)",
    },
    "কন্টেইনার (Container)": {
        "startup_time_sec": 0.5,
        "isolation_level": "মাঝারি (শেয়ার্ড কার্নেল)",
        "resource_overhead_mb": 50,
        "portability": "উচ্চ (ইমেজ পোর্টেবল)",
    },
}

print(f"{'বৈশিষ্ট্য':22}{'VM':30}{'Container'}")
for field in comparison["ভার্চুয়াল মেশিন (VM)"]:
    vm_val = comparison["ভার্চুয়াল মেশিন (VM)"][field]
    c_val = comparison["কন্টেইনার (Container)"][field]
    print(f"{field:22}{str(vm_val):30}{c_val}")

    
লক্ষ্য করুন startup_time-এর পার্থক্য প্রায় ১২০x এবং resource_overhead-এর পার্থক্য প্রায় ৪০x — এই কারণেই মাইক্রোসার্ভিস আর্কিটেকচারে (যেখানে একই হোস্টে অনেকগুলো ছোট সার্ভিস দ্রুত স্কেল আপ/ডাউন করতে হয়) কন্টেইনার প্রায় সবসময় VM-এর চেয়ে বাস্তবসম্মত পছন্দ।
মূল কথা · Key takeaway

VM সম্পূর্ণ মেশিন ভার্চুয়ালাইজ করে (ভারী, শক্তিশালী আইসোলেশন), কন্টেইনার OS-লেভেলে ভার্চুয়ালাইজ করে (হালকা, দ্রুত, তুলনামূলক দুর্বল আইসোলেশন)। কোনোটাই সবসময়ের জন্য "সেরা" নয় — এই কোর্সের M6-M7 কন্টেইনার- কেন্দ্রিক টুলচেইন (Docker, Kubernetes) শেখায়, কারণ আধুনিক ক্লাউড-নেটিভ ওয়ার্কলোডের জন্য এটিই এখনকার সাধারণ পছন্দ।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ একটি ব্যাংকিং সিস্টেম যেখানে একাধিক গ্রাহকের ওয়ার্কলোড একই হার্ডওয়্যারে চলে, সেখানে কেন VM-ভিত্তিক আইসোলেশন কন্টেইনারের চেয়ে বেশি প্রাধান্য পেতে পারে?

উচ্চ-নিরাপত্তা, মাল্টি-টেন্যান্ট পরিবেশে (যেখানে একাধিক ভিন্ন গ্রাহকের সংবেদনশীল ডেটা একই ফিজিক্যাল হার্ডওয়্যারে থাকে) কার্নেল-লেভেল আইসোলেশনের শক্তিটাই গুরুত্বপূর্ণ হয়ে ওঠে — একটি কন্টেইনার-এস্কেপ দুর্বলতা তাত্ত্বিকভাবে একই হোস্টের অন্য কন্টেইনারকে প্রভাবিত করতে পারে, কিন্তু একটি VM-এস্কেপ দুর্বলতা অনেক বেশি বিরল ও কঠিন। তাই নিয়ন্ত্রক প্রয়োজনীয়তা (compliance) বেশি হলে VM-ভিত্তিক আইসোলেশন প্রায়ই প্রাধান্য পায়, প্রয়োজনে VM-এর ভেতরে কন্টেইনার চালিয়ে দুই স্তরের নিরাপত্তা নিশ্চিত করা হয়।

প্র ০২ "বিল্ড ওয়ান্স, রান এনিহোয়ার" — এই সুবিধাটি একটি টিমের CI/CD পাইপলাইনকে (M8) ঠিক কীভাবে সহজ করে?

যেহেতু একই কন্টেইনার ইমেজ ডেভেলপার, টেস্টিং ও প্রোডাকশন — তিন জায়গাতেই অভিন্নভাবে চলে, তাই "টেস্টে পাস করা বিল্ড প্রোডাকশনেও ঠিক একই আচরণ করবে" এই নিশ্চয়তা পাওয়া যায় — এনভায়রনমেন্ট-ভিত্তিক পার্থক্যের কারণে হঠাৎ ব্যর্থতার ঝুঁকি কমে যায়। এটিই একটি পাইপলাইনকে নির্ভরযোগ্যভাবে স্বয়ংক্রিয় করা সম্ভব করে, কারণ প্রতিটি ধাপ একই আর্টিফ্যাক্ট নিয়ে কাজ করে।

প্র ০৩ কন্টেইনার স্টার্টআপ টাইম এত কম (মিলিসেকেন্ড) হওয়ার সরাসরি কারিগরি কারণ কী — namespaces/cgroups-এর সাথে এর সম্পর্ক ব্যাখ্যা করুন।

একটি কন্টেইনার চালু করতে নতুন করে কোনো কার্নেল বুট করতে হয় না — হোস্টের কার্নেল ইতিমধ্যেই চলমান থাকে, শুধু namespaces ব্যবহার করে একটি নতুন আইসোলেটেড "ভিউ" তৈরি করা হয় (নিজস্ব প্রসেস আইডি স্পেস, ফাইলসিস্টেম মাউন্ট, নেটওয়ার্ক ইন্টারফেস) এবং cgroups দিয়ে রিসোর্স সীমা বসিয়ে দেওয়া হয় — এই পুরো প্রক্রিয়া কার্নেলের মধ্যেই ঘটে, একটি সাধারণ প্রসেস শুরু করার মতোই দ্রুত। VM-এ এর বদলে BIOS/bootloader থেকে শুরু করে একটি সম্পূর্ণ OS বুট সিকোয়েন্স চালাতে হয়, যা স্বাভাবিকভাবেই অনেক বেশি সময় নেয়।

অনুশীলন

  1. চিন্তা করুন: একটি বৈজ্ঞানিক গণনা-নির্ভর ব্যাচ জব (কয়েক ঘণ্টা ধরে চলে, সপ্তাহে একবার চালানো হয়) VM-এ চালানো ভালো, নাকি কন্টেইনারে? কেন?

    যেহেতু জবটি দীর্ঘ সময় ধরে চলে এবং কম ঘনঘন শুরু হয়, স্টার্টআপ টাইমের পার্থক্য (মিলিসেকেন্ড বনাম সেকেন্ড) এখানে প্রায় গুরুত্বহীন — বরং যদি এই জবের জন্য নির্দিষ্ট, ভারী নির্ভরতা (বিশেষ ড্রাইভার, কাস্টম কার্নেল মডিউল) দরকার হয়, তাহলে একটি VM-এর পূর্ণ নিয়ন্ত্রণ বেশি সুবিধাজনক হতে পারে। তবে বাস্তবে অনেক ব্যাচ-প্রসেসিং সিস্টেম কন্টেইনারেও চলে যদি ডিপেন্ডেন্সিগুলো কন্টেইনারাইজযোগ্য হয় — সিদ্ধান্তটি নির্দিষ্ট প্রযুক্তিগত প্রয়োজনীয়তার উপর নির্ভরশীল, কোনো একক সঠিক উত্তর নেই।

  2. পরীক্ষা করুন: উপরের কোড সেলে একটি তৃতীয় এন্ট্রি "সার্ভারলেস ফাংশন" যোগ করুন (startup_time_sec=0.05, isolation_level="সবচেয়ে বেশি বিমূর্ত (কোনো ম্যানেজমেন্ট নেই)", resource_overhead_mb=10, portability="উচ্চ") এবং তিনটির তুলনা দেখুন।

    এটি দেখাবে সার্ভারলেস (L07-এ বিস্তারিত) স্টার্টআপ টাইম ও ওভারহেডে কন্টেইনারের চেয়েও এগিয়ে — কারণ এটি এমনকি কন্টেইনার ম্যানেজ করারও দরকার হয় না, প্রোভাইডার সবকিছু হ্যান্ডেল করে। এই তিনটির (VM, কন্টেইনার, সার্ভারলেস) তুলনা L08-এর কম্পিউট-সিলেকশন ফ্রেমওয়ার্কের ভিত্তি তৈরি করে।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
IaC বেস্ট প্র্যাকটিস ও টেস্টিং