FreeBSD jails বনাম Docker containers: মূল পার্থক্য কী?

FreeBSD jails এবং Docker containers একই সমস্যার সমাধান দেয়, তবে তাদের গঠন ভিন্ন। উভয়ই একটি শেয়ার্ড কার্নেলের ওপর আলাদা ইউজারল্যান্ড চালায়, তাই এদের কোনোটিই ভার্চুয়াল মেশিন নয়। মূল পার্থক্য হলো এদের ভেতরের বিষয়বস্তুতে। একটি Docker container সাধারণত একটি registry থেকে ডাউনলোড করা লেয়ারড ইমেজ থেকে একটি মাত্র প্রসেস চালায়। অন্যদিকে, একটি jail সম্পূর্ণ FreeBSD ইউজারল্যান্ড চালায়: এর নিজস্ব /etc, নিজস্ব rc স্টার্টআপ স্ক্রিপ্ট, নিজস্ব pkg ডাটাবেস এবং আপনার প্রয়োজন অনুযায়ী যেকোনো সংখ্যক প্রসেস। এই পৃষ্ঠার অন্যান্য প্রায় সব পার্থক্যই এই মূল বিষয়টি থেকে উদ্ভূত।

SSD Nodes-এ কোনো FreeBSD ইমেজ নেই। আপনি এই প্ল্যাটফর্মে কোনো FreeBSD সার্ভার ভাড়া নিতে পারবেন না এবং নিচের কোনো অংশই এখানে কেনা যায় এমন কোনো মেশিনের জন্য ইন্সটলেশন গাইড নয়। এটি দুটি আইসোলেশন মডেলের তুলনা, যা লেখা হয়েছে যাতে আপনি বুঝতে পারেন আপনার কাজের জন্য কোনটি প্রয়োজন এবং যাতে আপনি কোনো অনুমান ছাড়াই FreeBSD টিমের সেটআপ পড়তে পারেন।

Jail আসলে কী

FreeBSD 4.0-এ 2000 সালের মার্চ মাসে Jails-এর আবির্ভাব ঘটে, যা cgroups-এর চেয়ে পুরনো এবং Docker-এর চেয়ে প্রায় এক দশক আগের প্রযুক্তি। এই মেকানিজমটি একটি মাত্র kernel call-এর ওপর ভিত্তি করে কাজ করে। jail(8) একটি directory tree গ্রহণ করে এবং সেটির ভেতরে একটি jail ID যুক্ত করে প্রসেস চালু করে; এরপর kernel সেই ID বহনকারী যেকোনো প্রসেসের জন্য নির্দিষ্ট কিছু অপারেশন নিষিদ্ধ করে দেয়। একটি jailed প্রসেস তার jail-এর বাইরের প্রসেস দেখতে পায় না, filesystem mount বা unmount করতে পারে না, kernel module লোড করতে পারে না এবং jail-কে দেওয়া হয়নি এমন কোনো network address-এ bind করতে পারে না। এখানে শেখার মতো আলাদা কোনো namespace type নেই এবং প্রতিটি ফিচারের জন্য আলাদা করে opt-in করার প্রয়োজন হয় না: jail-এর কনফিগারেশনে থাকা প্যারামিটার অনুযায়ী এই সীমাবদ্ধতাগুলো একটি একক ইউনিট হিসেবে কার্যকর হয়।

Host-এ, jls চলমান jail-গুলোর তালিকা দেখায় এবং jexec web sh আপনাকে web নামে নির্দিষ্ট jail-এর ভেতরে একটি shell-এ নিয়ে যায়।

একটি directory-তে FreeBSD userland রেখে আপনি একটি jail তৈরি করতে পারেন। base system আপনার জন্য এই কাজটি করে দেয়:

sudo bsdinstall jail /usr/local/jails/containers/web

এটি আপনার release-এর জন্য base distribution set ডাউনলোড করে এবং সাধারণ post-install ধাপগুলো সম্পন্ন করে, যাতে আপনি নতুন সার্ভারের মতোই root password সেট করতে পারেন এবং timezone নির্বাচন করতে পারেন। এর ফলাফল হলো একটি ফোল্ডারের ভেতর থাকা সম্পূর্ণ FreeBSD ইনস্টলেশন। এরপর আপনি /etc/jail.conf-এ সেটির বর্ণনা দেন:

web {
  host.hostname = "web.example.internal";
  path = "/usr/local/jails/containers/web";
  ip4.addr = "10.0.0.10";
  exec.start = "/bin/sh /etc/rc";
  exec.stop = "/bin/sh /etc/rc.shutdown";
  mount.devfs;
}

এটি চালু করুন, তারপর পরীক্ষা করুন:

sudo service jail start web
jls

jls এখন JID, hostname এবং IP address সহ web-এর তালিকা দেখাবে। যদি jail-টি দেখা না যায়, তবে সরাসরি sudo jail -c web চালান। এটি একই কনফিগারেশন foreground-এ প্রয়োগ করে এবং যে প্যারামিটারটি গ্রহণ করা সম্ভব হয়নি তা প্রিন্ট করে, ফলে service output-এ ব্যর্থতার কারণ খুঁজতে হয় না।

যে লাইনটি দুবার পড়া প্রয়োজন তা হলো exec.start = "/bin/sh /etc/rc"। একটি jail চালু করলে তার ভেতরে FreeBSD-এর স্বাভাবিক boot script চলে, তাই jail-টি তার নিজস্ব /etc/rc.conf-এ enabled থাকা প্রতিটি service চালু করে। Docker container-এ এর সমতুল্য কোনো ধাপ নেই, কারণ এটি কেবল image-এর entrypoint প্রসেস চালায় এবং সেই প্রসেসটি বন্ধ হয়ে গেলে container-টিও বন্ধ হয়ে যায়।

সফটওয়্যার যেভাবে ইনস্টল করবেন: ইমেজ ও রেজিস্ট্রি বনাম ব্যবহারকারীর তৈরি ইউজারল্যান্ড

প্রথম দিনেই আপনি এই পার্থক্যের মুখোমুখি হবেন।

Docker-এর ক্ষেত্রে আপনি সফটওয়্যারের নাম উল্লেখ করেন এবং তা পেয়ে যান। docker pull nginx অন্য কারো তৈরি ও পরীক্ষিত একটি লেয়ারড, কন্টেন্ট-অ্যাড্রেসড ইমেজ নিয়ে আসে এবং docker compose up -d সেটিকে তার ভলিউম ও নেটওয়ার্কসহ চালু করে। রেজিস্ট্রিই হলো এখানে মূল পণ্য। Docker ওয়ার্কফ্লোর বেশিরভাগ সুবিধাই আসে এই বিষয়টি থেকে যে, হাজার হাজার প্রজেক্ট তাদের কার্যকরী ইমেজ প্রকাশ করে। আর এই কারণেই VPS-এ Docker চালানো একটি দীর্ঘ প্রজেক্ট না হয়ে খুব দ্রুত সম্পন্ন করা সম্ভব হয়।

FreeBSD-তে জেল (jail) ইমেজের কোনো ডিফল্ট পাবলিক রেজিস্ট্রি নেই। আপনাকে একটি খালি ইউজারল্যান্ড তৈরি করে তাতে ইনস্টল করতে হয়, ঠিক যেভাবে আপনি একটি বেয়ার সার্ভার সেটআপ করতেন। এতে টাইপিং কিছুটা বেশি হয়। তবে এটি অনেক বেশি স্বচ্ছ, কারণ জেলে যা চলে তা pkg দ্বারা সেখানে রাখা হয়েছে, যা হোস্টের ব্যবহৃত প্যাকেজ সেট থেকেই আসে।

টুলিংয়ের মাধ্যমে এই কাজ সংক্ষিপ্ত করা যায়। BastilleBSD হলো সাধারণ জেল ম্যানেজার এবং এটি একটি প্যাকেজ:

sudo pkg install bastille
sudo sysrc bastille_enable=YES
sudo bastille setup
sudo bastille bootstrap 15.1-RELEASE

bastille setup আপনার জন্য নেটওয়ার্কিং, স্টোরেজ এবং ফায়ারওয়াল কনফিগার করে। bastille bootstrap একবার একটি রিলিজ ডাউনলোড করে এবং পরবর্তীতে আপনি যত জেল তৈরি করবেন, তা এটি পুনরায় ব্যবহার করে। FreeBSD 15.1 হলো বর্তমান প্রোডাকশন রিলিজ, যা 2026 সালের জুন মাসে প্রকাশিত হয়েছে; আপনি যে রিলিজটি চালাচ্ছেন সেটি ব্যবহার করুন।

একটি জেল তৈরি করা এখন একটি কমান্ডের কাজ এবং তাতে সফটওয়্যার ভরা আরও একটি কমান্ডের কাজ:

sudo bastille create web 15.1-RELEASE 10.17.89.10/24
sudo bastille pkg web install nginx
sudo bastille service web nginx start
sudo bastille console web

bastille console web আপনাকে জেলের ভেতরে একটি লগইন শেল দেয় এবং bastille list হোস্টের বর্তমান অবস্থা দেখায়। একটি বিল্ড পুনরায় তৈরি করতে, Bastille টেমপ্লেটগুলো একটি ফাইলে ধাপগুলো সংরক্ষণ করে এবং সেগুলো জেলে প্রয়োগ করে, যা এই জগতে Dockerfile-এর সবচেয়ে কাছাকাছি। প্রতিটি জেলে একটি টেমপ্লেট পুনরায় চালানো যায়। এখানে আগে থেকে তৈরি করা কিছু আসে না।

তাই সৎ সারসংক্ষেপটি ছোট। Docker আপনাকে অন্যের তৈরি বিল্ড দেয়। জেল আপনাকে আপনার নিজের ইনস্টল করা সফটওয়্যার দেয়। যদি আপনার পছন্দের সফটওয়্যারটি শুধুমাত্র কন্টেইনার ইমেজ হিসেবেই পাওয়া যায়, তবে অন্য কোনো বিষয় বিবেচনার আগেই এই সিদ্ধান্ত চূড়ান্ত হয়ে যায়।

অবস্থা এবং আপগ্রেড: ZFS যে পরিবর্তনগুলো আনে

Docker জেনেশুনেই ডেটার অবস্থাকে আলাদা করে রাখে। কন্টেইনারের ফাইলসিস্টেমটি অস্থায়ী, আপনার ডেটা একটি named volume বা bind mount-এ থাকে এবং একটি আপগ্রেড মানে হলো docker compose pull এর পর docker compose up -d। কন্টেইনারটি প্রতিস্থাপিত হয় এবং আপনি যা কোনো volume-এ রাখেননি তা মুছে যায়। আপনি যদি নিয়ম মেনে চলেন তবে এটি একটি সুবিধা, আর ভুলে গেলে এটি ডেটা হারানোর কারণ। এজন্যই Compose stack-এ bind mounts এবং named volumes-এর মধ্যে নির্বাচন অত্যন্ত গুরুত্বপূর্ণ।

একটি jail ডেটার অবস্থাকে আলাদা করে না এবং ZFS-এর কারণেই এটি কার্যকর হয়। পুরো jail-টি একটি মাত্র dataset:

sudo zfs snapshot zroot/jails/containers/web@pre-upgrade
sudo pkg -j web upgrade
sudo zfs rollback zroot/jails/containers/web@pre-upgrade

এটি চালানোর আগে zfs list দিয়ে প্রকৃত dataset-এর নাম যাচাই করে নিন; উপরের পাথটি হ্যান্ডবুকে ব্যবহৃত লেআউট। স্ন্যাপশট নিতে প্রায় এক সেকেন্ড সময় লাগে এবং jail-এর বিষয়বস্তু পরিবর্তিত না হওয়া পর্যন্ত এটি প্রায় কোনো জায়গা দখল করে না। যদি আপগ্রেডের ফলে সার্ভিসটি ভেঙে যায়, তবে রোলব্যাক পুরো userland-কে তার আগের অবস্থায় ফিরিয়ে আনে, যার মধ্যে package database এবং রাত 2টায় আপনার হাতে এডিট করা কনফিগারেশন ফাইলগুলোও অন্তর্ভুক্ত থাকে। Docker-এ এর কোনো বিল্ট-ইন বিকল্প নেই, কারণ এর মডেলে ধরে নেওয়া হয় যে আপনার এমন কিছুর প্রয়োজন নেই।

zfs clone হলো অন্য অর্ধেক। একটি স্ন্যাপশটের ক্লোন হলো একটি নতুন রাইটেবল jail, যা তার প্যারেন্টের সাথে অপরিবর্তিত ব্লকগুলো শেয়ার করে। তাই একটি 3 জিবি jail-এর স্টেজিং কপি তৈরি করতে ডিস্কে প্রায় কোনো জায়গাই লাগে না, যতক্ষণ না আপনি তাতে পরিবর্তন আনা শুরু করেন। একজন FreeBSD অ্যাডমিন এভাবেই আপগ্রেড রিহার্স করার জন্য "প্রোডাকশনের মতো হুবহু" একটি jail তৈরি করেন।

বেস সিস্টেম আপগ্রেড প্যাকেজ থেকে আলাদা। যে jail-এ তার নিজস্ব userland-এর কপি থাকে তার জন্য:

sudo freebsd-update -b /usr/local/jails/containers/web fetch install

Thin jail এই কাজ বারবার করা থেকে বিরত রাখে। এগুলো nullfs-এর মাধ্যমে একটি শেয়ারড read-only বেস মাউন্ট করে এবং প্রতিটি jail-কে নিজস্ব একটি ছোট রাইটেবল লেয়ার দেয়। ফলে আপনি বেসটি একবার প্যাচ করলেই প্রতিটি jail তার ফলাফল দেখতে পায়। Bastille ডিফল্টভাবে thin jail তৈরি করে।

নেটওয়ার্কিং: প্রকাশিত পোর্ট বনাম অ্যাড্রেসিং সিদ্ধান্ত

Docker আপনার জন্য নেটওয়ার্কিং নির্ধারণ করে এবং ব্যতিক্রমগুলো প্রকাশ করতে বলে। কন্টেইনারগুলো একটি bridge-এ অবস্থান করে, তারা user-defined নেটওয়ার্কে service name ব্যবহার করে একে অপরের সাথে যোগাযোগ করে, এবং -p 8080:80 সেগুলোর একটিকে host-এর কাছে উন্মুক্ত করে। এটি কার্যকর করার জন্য Docker নিজস্ব packet filter রুল লেখে, যার মাধ্যমেই একটি প্রকাশিত কন্টেইনার পোর্ট সরাসরি ufw-কে পাশ কাটিয়ে চলে যায়।

একটি jail আপনাকে শুরুতেই মডেল বেছে নিতে বাধ্য করে, এবং এখানে দুটি মডেল রয়েছে।

Shared IP. ip4.addr = "10.0.0.10" একটি বিদ্যমান host interface-এ সেই ঠিকানা যোগ করে এবং jail-কে তার মধ্যে সীমাবদ্ধ রাখে। jail-এর নিজস্ব কোনো network stack নেই, তাই এটি নিজস্ব firewall চালাতে পারে না। এটি সব ঠিকানায় bind করতে পারে না: একটি jailed socket যখন 0.0.0.0-এর জন্য অনুরোধ করে, তখন kernel সেটিকে jail-এর নিজস্ব ঠিকানায় rewrite করে দেয়। দুটি jail একই ঠিকানার port 80-তে listen করতে পারে না, তাই আপনাকে প্রতিটিকে আলাদা ঠিকানা দিতে হবে, অথবা সামনে একটি reverse proxy বসাতে হবে।

VNET. jail-এ vnet; যোগ করলে এটি একটি পূর্ণাঙ্গ network stack পায়: নিজস্ব interface, নিজস্ব routing table এবং নিজস্ব firewall রুল। আপনি এটিকে একটি epair দিয়ে host-এর সাথে যুক্ত করেন, যা একটি virtual cable যার দুই প্রান্ত দুই দিকে থাকে, এবং host-এর প্রান্তটি একটি bridge-এ বসানো হয়। Docker আপনাকে যা দেয়, এটি তার সবচেয়ে কাছাকাছি এবং Bastille-এর -V ও -B jail টাইপের পেছনে এই মোডটিই কাজ করে।

একটি host port-কে jail-এর ভেতরে forward করা একটি pf redirect রুল। Bastille এটিকে এভাবে গুছিয়ে দেয়:

sudo bastille rdr web tcp 80 80

এখানে কোনো EXPOSE নেই এবং কোনো স্বয়ংক্রিয় প্রকাশনাও নেই। jail-এর নিজস্ব ঠিকানা বা redirect রুল অনুমতি না দিলে কোনো কিছুই সেখানে পৌঁছাতে পারে না। এটি শুরুতে কিছুটা ধীরগতির মনে হলেও firewall-এর দিক থেকে অনেক বেশি নিরাপদ।

রিসোর্স লিমিট: cgroups বনাম rctl

Docker একটি কন্টেইনারের রিসোর্স লিমিট নির্ধারণ করে cgroups-এর মাধ্যমে, এবং এই লিমিটগুলো সেখানেই থাকে যেখানে কন্টেইনারটি সংজ্ঞায়িত করা হয়: কমান্ড লাইনে --memory=1g --cpus=1.5 হিসেবে, অথবা Compose ফাইলে সংশ্লিষ্ট কী (key) হিসেবে। আপনি যদি আপনার স্ট্যাক একটি VPS-এ Docker Compose ফাইলে সংরক্ষণ করে থাকেন, তবে লিমিটটি সেই সার্ভিসের পাশেই থাকে এবং git-এর মাধ্যমে তার সাথে পরিভ্রমণ করে।

FreeBSD ব্যবহার করে rctl, এবং এটি এমন একটি সাবসিস্টেম যা আপনাকে চালু করতে হবে। রিসোর্স অ্যাকাউন্টিং ডিফল্টভাবে বন্ধ থাকে কারণ প্রতিটি অ্যালোকেশনের ক্ষেত্রে এটি সামান্য খরচ তৈরি করে। /boot/loader.conf-এ টিউনেবল (tunable) যোগ করুন এবং রিবুট করুন:

kern.racct.enable=1

এরপর একটি রুল সেট করুন এবং তা পর্যবেক্ষণ করুন:

sudo rctl -a jail:web:vmemoryuse:deny=1g
rctl -hu jail:web

rctl -hu jail:web জেল (jail)-এর বর্তমান ব্যবহার মানুষের পাঠযোগ্য ইউনিটে প্রদর্শন করে, যাতে কোনো কিছু ভেঙে পড়ার আগেই আপনি দেখতে পারেন লিমিটের কতটা কাছাকাছি সেটি রয়েছে। deny অ্যাকশনটি জেলের ভেতরে ওভার-লিমিট অ্যালোকেশনকে ব্যর্থ করে দেয়, ফলে হোস্ট মেশিনে কোনো কিল মেসেজ দেখার পরিবর্তে আপনি অ্যাপ্লিকেশনটির নিজস্ব অ্যালোকেশন এরর দেখতে পান।

rctl -a দিয়ে যোগ করা রুলগুলো পরবর্তী রিবুটের সময় মুছে যায়। FreeBSD-এর rctl সার্ভিস এগুলোকে /etc/rctl.conf থেকে রিলোড করে, তাই রুলটি সেই ফাইলে লিখুন এবং সার্ভিসটি এনাবল করুন:

sudo sysrc rctl_enable=YES

এটি সেই ক্ষেত্র যেখানে Docker স্পষ্টতই বেশি সুবিধাজনক। একটি Compose ফাইলের লিমিট সেই সার্ভিসের সাথেই রিভিউ করা যায় যা সে নিয়ন্ত্রণ করে। অন্যদিকে, একটি rctl রুল হলো একটি আলাদা ফাইলের লাইন, যা অন্য কোথাও সংজ্ঞায়িত একটি জেলকে নির্দেশ করে।

যখন সমাধানটি একটি ভার্চুয়াল মেশিন: bhyve

একটি jail হোস্টের কার্নেল শেয়ার করে, তাই কিছু বিষয় এখানে কখনোই সম্ভব নয়। এটি ভিন্ন কোনো কার্নেল ভার্সন চালাতে পারে না, কার্নেল মডিউল লোড করতে পারে না এবং Linux কন্টেইনারের মতো Linux বাইনারি চালাতে পারে না। FreeBSD-তে Linux কম্প্যাটিবিলিটি লেয়ার বা linuxulator রয়েছে, কিন্তু এটি Linux সিস্টেম কলের একটি সীমিত অংশ বাস্তবায়ন করে এবং যেকোনো Linux ইমেজের জন্য এটি সর্বজনীন সমাধান নয়।

bhyve হলো FreeBSD-এর হাইপারভাইজার। যখন আপনার একটি প্রকৃত মেশিন বাউন্ডারি প্রয়োজন হয়, তখন এটিই সঠিক টুল। যেমন: ভিন্ন কোনো অপারেটিং সিস্টেম, ভিন্ন কার্নেল, অথবা এমন কোনো টেন্যান্ট যার সাথে আপনি কার্নেল শেয়ার করতে চান না। এর বিনিময়ে আপনাকে মেমোরি রিজার্ভ রাখতে হয় (যা শেয়ার করা যায় না) এবং দ্বিতীয় একটি কার্নেল প্যাচ করার বাড়তি দায়িত্ব নিতে হয়। Linux-এ কন্টেইনার এবং পূর্ণাঙ্গ ভার্চুয়াল মেশিনের মধ্যে যে সিদ্ধান্ত নিতে হয়, এটিও ঠিক তাই। আর এই সিদ্ধান্তের ওপরই নির্ভর করে আপনার নিচে nested virtualization সাপোর্ট করে এমন একটি VPS প্রয়োজন কি না।

ইকোসিস্টেম, যা বেশিরভাগ টিমের Docker ব্যবহারের প্রকৃত কারণ

উপরের সবকিছুই মডেলটি নিয়ে। বেশিরভাগ টিমের পছন্দের মূল কারণ হলো প্রতিটি প্রযুক্তির চারপাশের বিশাল জগত।

Docker-এর সাথে আছে Docker Hub এবং GHCR, docker compose, একটি সার্ভারে কুলাতে না পারলে Kubernetes ব্যবহারের সুবিধা, আগে থেকেই সংযুক্ত কন্টেইনার সাপোর্টসহ CI রানার, এবং প্রায় প্রতিটি প্রজেক্টের README-তে একটি কমান্ডেই কুইকস্টার্টের ব্যবস্থা। Jails-এর ক্ষেত্রে আছে FreeBSD ports tree, যা বিশাল এবং অত্যন্ত যত্নসহকারে রক্ষণাবেক্ষণ করা হয়, তবে এতে সরাসরি চালানোর উপযোগী অ্যাপ্লিকেশনের সংখ্যা অনেক কম। যখন কোনো প্রজেক্ট শুধুমাত্র একটি কন্টেইনার ইমেজ প্রকাশ করে, তখন FreeBSD-এর ক্ষেত্রে আপনাকে এর ডকুমেন্টেশন পড়ে নিজে সবকিছু গুছিয়ে নিতে হবে।

Jails এই বিনিময়ের অন্য প্রান্তে তার জায়গা করে নেয়। আপনি Jails ব্যবহার করবেন যখন আপনি ইতিমধ্যে ZFS ব্যবহার করছেন এবং পুরো সার্ভিসের স্ন্যাপশট ও রোলব্যাককে গুরুত্ব দেন, যখন আপনার সার্ভিসগুলো FreeBSD নেটিভ, যখন আপনি একটি সিঙ্গেল প্রসেসের পরিবর্তে প্রতি টেন্যান্টের জন্য পূর্ণাঙ্গ ইউজারল্যান্ড চান, অথবা যখন আপনি কার্নেল, প্যাকেট ফিল্টার, ফাইলসিস্টেম এবং ডকুমেন্টেশনকে একটি সিস্টেম হিসেবে একত্রে রক্ষণাবেক্ষণ করতে চান। শেষোক্ত বিষয়টিকেই মানুষ FreeBSD-এর 'কোহারেন্ট' বা সুসংগত বৈশিষ্ট্য বলে থাকে, এবং সার্ভার প্ল্যাটফর্ম হিসেবে Linux ও FreeBSD-এর তুলনামূলক আলোচনায় এবং FreeBSD 15 সার্ভার ব্যবহারের ক্ষেত্রে কী পরিবর্তন এনেছে সে বিষয়ে বিস্তারিত আলোচনা করা হয়েছে।

পরিশেষে একটি সিদ্ধান্ত। যদি আপনার টিম ইতিমধ্যে Docker-এ দক্ষ হয়, তবে অন্য প্ল্যাটফর্মে যাওয়ার খরচ অনেক এবং এর সুফল সুনির্দিষ্ট হতে হবে। শুধুমাত্র আইসোলেশনের মানের জন্য প্ল্যাটফর্ম পরিবর্তন করবেন না; দুটি মডেলই যথেষ্ট কাছাকাছি, তাই আপনার কনফিগারেশনই এখানে বেশি গুরুত্বপূর্ণ। প্ল্যাটফর্ম পরিবর্তন করুন যদি আপনি ZFS-ভিত্তিক পুরো সার্ভিসের রোলব্যাক চান, অথবা যদি আপনি ইতিমধ্যে FreeBSD ব্যবহারকারী হন।

FAQ

আমি কি FreeBSD-তে Docker image চালাতে পারি?

Linux image চালানো সম্ভব নয় এবং এটি সমর্থিত কোনো পদ্ধতিও নয়। FreeBSD-তে OCI container-এর সমর্থন রয়েছে: sudo pkg install -y podman-suite কমান্ডটি Podman ইনস্টল করে, যা ocijail-এর মাধ্যমে কন্টেইনার চালায়। এটি মূলত নিচে প্রকৃত jail তৈরি করে। কন্টেইনার মনিটরের জন্য fdescfs-কে /dev/fd-এ মাউন্ট করা প্রয়োজন এবং কন্টেইনার NAT (network address translation)-এর জন্য pf প্রয়োজন। FreeBSD-নেটিভ OCI image সবচেয়ে ভালো কাজ করে। Linux image চালানোর জন্য অতিরিক্তভাবে Linux compatibility layer প্রয়োজন এবং 2026 সালের আগস্ট পর্যন্ত FreeBSD Podman পোর্টটিকে পরীক্ষামূলক হিসেবে গণ্য করা হয়। যদি আপনার ডিপ্লয়মেন্টটি Linux image-এর একটি স্ট্যাক হয়, তবে সেটি Linux-এই চালানো উচিত।

FreeBSD jail কি Docker কন্টেইনারের চেয়ে বেশি নিরাপদ?

উভয়ই একটি হোস্ট কার্নেল শেয়ার করে, তাই কার্নেলের কোনো ত্রুটি উভয়ের জন্যই ঝুঁকিপূর্ণ। প্রকৃত অনিরাপদ কোডের জন্য কোনোটিই আদর্শ সীমানা নয়। মূল পার্থক্য হলো শুরুর অবস্থানে। একটি jail শুরু হয় অনেকগুলো অপারেশন বন্ধ রেখে, যা আপনাকে একটি একটি করে প্যারামিটার দিয়ে চালু করতে হয়। একটি Docker কন্টেইনার শুরু হয় root হিসেবে, যেখানে কিছু capability বাদ দেওয়া থাকে এবং অতিরিক্ত নিরাপত্তা ব্যবস্থা আপনাকে নিজে থেকে যোগ করতে হয়। বাস্তবে, মডেলের চেয়ে কনফিগারেশনই বেশি গুরুত্বপূর্ণ: allow.mount এবং allow.raw_sockets চালু থাকা একটি jail, সতর্কতার সাথে কনফিগার করা কন্টেইনারের চেয়ে বেশি নিরাপদ নয়।

আমি কীভাবে একটি jail ব্যাকআপ নেব?

ডেটাসেটের স্ন্যাপশট নিন এবং তা পাঠিয়ে দিন। sudo zfs snapshot zroot/jails/containers/web@backup ব্যবহার করুন, তারপর সেই স্ন্যাপশটটিকে zfs send করে অন্য কোনো পুলে বা এমন কোনো ফাইলে রাখুন যা আপনি সার্ভার থেকে সরিয়ে নিতে পারবেন। যেহেতু একটি jail তার পুরো ইউজারল্যান্ডকে একটি ডেটাসেটে রাখে, তাই স্ন্যাপশটটি ইনস্টল করা প্যাকেজ এবং ডেটাকে একটি নির্দিষ্ট সময়ে সামঞ্জস্যপূর্ণ অবস্থায় ধরে রাখে, সেই সাথে আপনার হাতে এডিট করা প্রতিটি কনফিগারেশন ফাইলও সংরক্ষিত থাকে। এটি Docker-এর অভ্যাসের বিপরীত, যেখানে আপনি named volume এবং Compose ফাইল ব্যাকআপ রাখেন এবং বাকি অংশ image থেকে পুনরায় তৈরি করেন।

আমার কি BastilleBSD প্রয়োজন, নাকি বেস সিস্টেমই যথেষ্ট?

বেস সিস্টেমই যথেষ্ট এবং শুরু করার জন্য এটিই সেরা জায়গা। jail.conf, jls, jexec এবং service jail start পুরো মডেলটিকে কভার করে। একবার আপনি এগুলো শিখে নিলে, কোনো নির্দিষ্ট হোস্টের টুলিং না জেনেই আপনি যেকোনো FreeBSD হোস্ট বুঝতে পারবেন। Bastille হলো এর ওপর একটি সুবিধাজনক স্তর: এটি রিলিজ বুটস্ট্র্যাপ করে, thin jail তৈরি করে, টেমপ্লেট প্রয়োগ করে এবং আপনার জন্য pf রিডাইরেক্ট রুল লিখে দেয়। প্রথমে বেস কমান্ডগুলো শিখুন, তারপর যখন jail-এর সংখ্যা বেড়ে যাওয়ায় টাইপ করা ক্লান্তিকর মনে হবে, তখন Bastille যোগ করুন।