FreeBSD jails विरुद्ध Docker containers: फरक काय?

FreeBSD jails विरुद्ध Docker containers, एका परिच्छेदात

FreeBSD jails आणि Docker containers एकाच समस्येचे दोन वेगवेगळ्या पद्धतींनी निराकरण करतात. दोन्ही एकाच shared kernel वर isolated userlands चालवतात. त्यामुळे यापैकी कोणतेही virtual machine नाही. फरक आतमध्ये काय चालते यात आहे. Docker container registry मधून pull केलेल्या layered image मधील एक process चालवतो. jail मध्ये संपूर्ण FreeBSD userland चालते: त्याचा स्वतःचा /etc, स्वतःचे rc startup scripts, स्वतःचा pkg database आणि आवश्यक तितके processes. या पृष्ठावरील जवळजवळ प्रत्येक इतर फरक याच मूलभूत फरकातून निर्माण होतो.

SSD Nodes FreeBSD images देत नाही. या platform वर तुम्ही FreeBSD server भाड्याने घेऊ शकत नाही आणि खालील मजकूर येथे खरेदी करता येणाऱ्या machine साठी install guide नाही. हा दोन isolation models चा तुलनात्मक आढावा आहे. यामुळे एखाद्या workload ला प्रत्यक्षात कोणते model आवश्यक आहे हे तुम्ही ठरवू शकता आणि अंदाज न लावता FreeBSD team ची setup समजून घेऊ शकता.

प्रत्यक्षात jail म्हणजे काय

Jails मार्च 2000 मध्ये FreeBSD 4.0 मध्ये आले. त्यामुळे ते cgroups पेक्षा जुने आणि Docker पेक्षा साधारण एक दशक जुने आहेत. ही यंत्रणा एका kernel call वर आधारित आहे. jail(8) एक directory tree घेते आणि त्यातील processes ला jail ID जोडून सुरू करते. त्यानंतर kernel त्या ID असलेल्या कोणत्याही process साठी ठरावीक operations नाकारतो. jailed process ला त्याच्या jail बाहेरील processes दिसत नाहीत. तो filesystems mount किंवा unmount करू शकत नाही. तो kernel modules load करू शकत नाही. तसेच jail ला न दिलेल्या network addresses वर bind करू शकत नाही. शिकण्यासाठी वेगळ्या namespace प्रकाराची गरज नाही. प्रत्येक feature स्वतंत्रपणे opt-in करण्याचीही गरज नाही. ही सर्व बंधने एकत्र लागू होतात. jail च्या config मधील parameters नुसार त्यात बदल करता येतात.

Host वर jls चालू jails ची यादी दाखवते. jexec web sh मध्ये web नावाच्या jail मधील shell उघडते.

Directory मध्ये FreeBSD userland ठेवून तुम्ही jail तयार करता. Base system हे काम तुमच्यासाठी करते:

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

हा command तुमच्या release साठी base distribution set आणतो आणि नेहमीच्या post-install steps चालवतो. त्यामुळे नवीन server वर जसे root password सेट करता आणि timezone निवडता, तसेच येथेही करता. याचा परिणाम म्हणजे एका folder मध्ये असलेली FreeBSD installation. त्यानंतर तिचे वर्णन /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 थेट चालवा. हा command foreground मध्ये तीच configuration लागू करतो आणि स्वीकारता न आलेला parameter दाखवतो. त्यामुळे failure service output मध्ये लपून राहत नाही.

दोनदा वाचण्यासारखी ओळ म्हणजे exec.start = "/bin/sh /etc/rc". jail सुरू केल्यावर त्यामध्ये FreeBSD ची नेहमीची boot script चालते. त्यामुळे jail स्वतःच्या /etc/rc.conf मध्ये enabled असलेली प्रत्येक service सुरू करते. Docker container मध्ये यासारखा टप्पा नसतो. तो image मधील entrypoint process चालवतो आणि तो process थांबल्यावर container थांबतो.

सॉफ्टवेअर मिळवण्याची पद्धत: images आणि registries विरुद्ध तुम्ही स्वतः भरत असलेले userland

पहिल्याच दिवशी जाणवणारा हा फरक आहे.

Docker मध्ये तुम्ही सॉफ्टवेअरचे नाव देता आणि ते मिळवता. docker pull nginx दुसऱ्या व्यक्तीने तयार करून तपासलेली layered, content-addressed image fetch करते आणि docker compose up -d तिचे volumes व network जोडून ती सुरू करते. Registry हेच उत्पादन असते. Docker workflow मधील बहुतांश मूल्य हे आहे की हजारो प्रकल्प कार्यरत image प्रकाशित करतात. त्यामुळे VPS वर Docker चालवणे हे मोठ्या प्रकल्पाऐवजी अल्प वेळात पूर्ण होणारे काम ठरते.

FreeBSD मध्ये jail images साठी default public registry उपलब्ध नसते. तुम्ही रिकामे userland तयार करून त्यात सॉफ्टवेअर install करता. ही पद्धत bare server सेट अप करण्यासारखीच आहे. त्यामुळे अधिक typing करावे लागते. पण प्रक्रिया अधिक पारदर्शक असते, कारण jail मध्ये चालणारे सर्व काही pkg ने तेथे ठेवलेले असते आणि त्यासाठी host वापरत असलेल्या त्याच package set मधून packages घेतले जातात.

Tooling मुळे ही प्रक्रिया लहान होते. BastilleBSD हा सर्वसाधारणपणे वापरला जाणारा jail manager आहे आणि तो एक package आहे:

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

bastille setup तुमच्यासाठी networking, storage आणि firewall configure करते. bastille bootstrap एखादा release एकदाच download करते आणि त्यानंतर तयार केलेले प्रत्येक jail तोच release पुन्हा वापरते. FreeBSD 15.1 हा सध्याचा production release आहे आणि तो June 2026 मध्ये उपलब्ध झाला; तुम्ही चालवत असलेला release त्याऐवजी वापरा.

त्यानंतर jail तयार करण्यासाठी एक command आणि त्यात सॉफ्टवेअर install करण्यासाठी आणखी एक command पुरतो:

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 jail च्या आत login shell देते आणि bastille list host वर काय उपलब्ध आहे ते दाखवते. Build पुन्हा करायचा असल्यास Bastille templates मध्ये steps एका file मध्ये ठेवून ते jail वर लागू करता येतात. या वातावरणात हे Dockerfile शी सर्वाधिक जवळचे साधन आहे. प्रत्येक jail वर template पुन्हा लागू केला जातो. काहीही prebuilt स्वरूपात येत नाही.

म्हणून थोडक्यात सांगायचे तर, Docker इतरांनी तयार केलेले builds तुम्हाला देते. Jails मध्ये तुम्ही स्वतः installs करता. तुमच्या निवडलेल्या सॉफ्टवेअरपैकी एखादे container image म्हणूनच उपलब्ध असेल आणि इतर कोणत्याही स्वरूपात नसेल, तर इतर कोणत्याही निकषाचा विचार करण्यापूर्वीच हा प्रश्न सुटतो.

State आणि upgrades: ZFS मुळे बदलणारा भाग

Docker जाणीवपूर्वक state वेगळा ठेवतो. Container filesystem disposable असतो, तुमचा डेटा named volume किंवा bind mount मध्ये राहतो आणि upgrade म्हणजे docker compose pull नंतर docker compose up -d. Container बदलला जातो आणि volume मध्ये न ठेवलेला कोणताही डेटा नष्ट होतो. हा नियम पाळल्यास ही उपयुक्त रचना आहे; तो विसरल्यास data-loss incident होतो. म्हणूनच Compose stack मध्ये bind mounts आणि named volumes मधील निवड अत्यंत महत्त्वाची ठरते.

Jail state वेगळा ठेवत नाही आणि हे शक्य होण्यामागे 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

ही command चालवण्यापूर्वी zfs list वापरून प्रत्यक्ष dataset name तपासा; वरील path handbook मध्ये वापरलेली रचना आहे. Snapshot घेण्यासाठी सुमारे एक सेकंद लागतो. Jail मधील contents बदलत नाहीत तोपर्यंत त्यासाठी जवळजवळ अतिरिक्त space लागत नाही. Upgrade मुळे service मध्ये बिघाड झाल्यास rollback संपूर्ण userland पूर्वीच्या स्थितीत आणतो. यात package database आणि तुम्ही रात्री 2 वाजता हाताने संपादित केलेल्या config files चाही समावेश होतो. Docker मध्ये यासाठी built-in equivalent नाही, कारण त्याचे model तुम्हाला अशी सुविधा कधीच नको आहे असे गृहीत धरते.

zfs clone हा दुसरा महत्त्वाचा भाग आहे. Snapshot चा clone हा नवीन writable jail असतो. तो parent सोबत न बदललेले blocks share करतो. त्यामुळे 3 GB jail ची staging copy disk वर जवळजवळ काहीही अतिरिक्त space घेत नाही, जोपर्यंत तुम्ही त्यात बदल सुरू करत नाही. अशा प्रकारे FreeBSD admin upgrade ची पूर्वतयारी करण्यासाठी production सारखाच jail तयार करतो.

Base system upgrade packages पासून वेगळा असतो. स्वतःची userland copy असलेल्या jail साठी:

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

Thin jails मध्ये हे काम पुन्हा पुन्हा करावे लागत नाही. ते nullfs द्वारे एक shared read-only base mount करतात आणि प्रत्येक jail ला स्वतःचा लहान writable layer देतात. त्यामुळे base एकदाच patch केला तरी प्रत्येक jail ला त्याचा परिणाम दिसतो. Bastille thin jails default ने तयार करते.

नेटवर्किंग: प्रकाशित पोर्ट विरुद्ध address निवड

Docker तुमच्यासाठी networking ठरवतो आणि अपवाद म्हणून आवश्यक असलेले पोर्ट publish करण्यास सांगतो. Containers bridge वर येतात, user-defined network वर service name द्वारे एकमेकांपर्यंत पोहोचतात आणि -p 8080:80 त्यापैकी एखादा container host साठी उघडतो. हे साध्य करण्यासाठी Docker स्वतःचे packet filter rules लिहितो. त्यामुळेच published container port थेट ufw च्या नियमांपलीकडे पोहोचतो.

Jail वापरताना सुरुवातीलाच networking model निवडावा लागतो. त्याचे दोन प्रकार आहेत.

Shared IP. ip4.addr = "10.0.0.10" हा address विद्यमान host interface ला जोडतो आणि jail ला तोच address वापरण्यापुरते मर्यादित करतो. Jail कडे स्वतःचा network stack नसतो. त्यामुळे तो स्वतःचे firewall चालवू शकत नाही. तसेच तो प्रत्यक्षात प्रत्येक address वर bind करू शकत नाही: 0.0.0.0 साठी विनंती करणारा jailed socket kernel jail च्या स्वतःच्या address मध्ये बदलतो. एकाच address वरील port 80 वर दोन jails एकाच वेळी listen करू शकत नाहीत. त्यामुळे प्रत्येक jail ला स्वतंत्र address द्यावा किंवा समोर reverse proxy ठेवावा.

VNET. Jail मध्ये vnet; जोडा. त्याला पूर्ण network stack मिळतो: स्वतःचे interfaces, स्वतःची routing table आणि स्वतःचे firewall rules. Host शी जोडण्यासाठी epair वापरा. हे एक virtual cable आहे; त्याचे एक टोक प्रत्येक बाजूला असते. Host चे टोक bridge वर जोडा. Docker देत असलेल्या networking शी हा सर्वात जवळचा पर्याय आहे. Bastille मधील -V आणि -B jail types याच mode वर आधारित आहेत.

Host port jail मध्ये forward करणे म्हणजे pf redirect rule. Bastille त्यासाठी wrapper देते:

sudo bastille rdr web tcp 80 80

EXPOSE नसतो आणि automatic publishing देखील नसते. Address किंवा redirect rule परवानगी देत नसेल, तर कोणतेही network traffic jail पर्यंत पोहोचत नाही. सुरुवातीचा setup अधिक वेळ घेतो; मात्र firewall अधिक शांत राहतो.

संसाधन मर्यादा: cgroups विरुद्ध rctl

Docker cgroups वापरून कंटेनरवर मर्यादा लागू करते. ही मर्यादा कंटेनर जिथे परिभाषित केला आहे तिथेच ठेवली जाते: कमांड लाइनवरील --memory=1g --cpus=1.5 किंवा Compose फाइलमधील संबंधित keys. तुमचा stack VPS वरील Docker Compose फाइलमध्ये ठेवत असल्यास, मर्यादा ज्या service ला लागू होते तिच्याजवळच राहते आणि git मध्ये तिच्यासोबत पुढे जाते.

FreeBSD rctl वापरते. हे subsystem स्वतंत्रपणे सुरू करावे लागते. प्रत्येक allocation वर थोडा overhead येत असल्याने resource accounting default ने बंद असते. /boot/loader.conf मध्ये tunable जोडा आणि reboot करा:

kern.racct.enable=1

त्यानंतर rule सेट करून त्याचे निरीक्षण करा:

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

rctl -hu jail:web jail चा सध्याचा वापर human-readable units मध्ये दाखवते. त्यामुळे काही बिघडण्यापूर्वी वापर मर्यादेच्या किती जवळ आहे ते पाहता येते. deny action मुळे मर्यादेपेक्षा जास्त allocation jail मध्ये fail होते. त्यामुळे host वर kill message दिसण्याऐवजी application ची स्वतःची allocation error दिसते.

rctl -a ने जोडलेले rules पुढील reboot वेळी नष्ट होतात. FreeBSD ची rctl service ते /etc/rctl.conf मधून पुन्हा load करते. त्यामुळे rule त्या फाइलमध्ये लिहा आणि service enable करा:

sudo sysrc rctl_enable=YES

या बाबतीत Docker स्पष्टपणे अधिक सोयीचे आहे. Compose फाइलमधील मर्यादेचे review ती ज्या service वर लागू होते तिच्यासोबत करता येते. rctl rule ही वेगळ्या फाइलमधील एक line असते आणि त्यात कुठेतरी परिभाषित केलेल्या jail चे नाव दिलेले असते.

जेव्हा उत्तर virtual machine असते: bhyve

Jail host kernel सामायिक करते. त्यामुळे काही गोष्टी कायमच्या उपलब्ध राहत नाहीत. ती वेगळी kernel version चालवू शकत नाही, kernel module लोड करू शकत नाही आणि Linux container प्रमाणे Linux binaries चालवू शकत नाही. FreeBSD मध्ये linuxulator नावाचा Linux compatibility layer आहे. मात्र तो Linux system calls च्या एका उपसंचाची अंमलबजावणी करतो. त्यामुळे कोणत्याही Linux images साठी तो सर्वसाधारण उपाय नाही.

bhyve हा FreeBSD चा hypervisor आहे. तुम्हाला खऱ्या machine boundary ची आवश्यकता असेल तेव्हा हे योग्य साधन आहे: वेगळी operating system, वेगळी kernel किंवा kernel सामायिक न केलेला tenant. यासाठी shared memory ऐवजी reserved memory वापरावी लागते आणि patch करण्यासाठी दुसरी kernel ठेवावी लागते. Linux वर containers आणि full virtual machines यांपैकी निवड करताना हाच निर्णय घ्यावा लागतो. तसेच यावरूनच खाली nested virtualization समर्थित करणारा VPS आवश्यक आहे का हे ठरते.

परिसंस्था: बहुतेक टीम Docker का वापरतात याचे खरे कारण

वरील सर्व चर्चा मॉडेलविषयी आहे. बहुतेक टीम कोणता पर्याय निवडतात हे प्रत्येक पर्यायाभोवती असलेल्या परिसंस्थेच्या व्याप्तीवर ठरते.

Docker सोबत Docker Hub आणि GHCR, docker compose, एकाच मशीनची क्षमता अपुरी ठरल्यावर Kubernetes, आधीपासून container support जोडलेले CI runners आणि जवळजवळ प्रत्येक प्रकल्पाच्या README मध्ये one-command quickstart उपलब्ध असतो. Jails साठी FreeBSD ports tree मोठा आणि काळजीपूर्वक देखभाल केलेला आहे. मात्र तयार स्वरूपात थेट चालवता येणाऱ्या application bundles चा संच तुलनेने लहान आहे. एखादा प्रकल्प container image प्रकाशित करतो आणि इतर काहीही देत नाही, तेव्हा FreeBSD वरील मार्ग म्हणजे त्याचे documentation वाचून सर्व घटक स्वतः एकत्र करणे.

या तडजोडीच्या दुसऱ्या बाजूला Jails उपयुक्त ठरतात. तुम्ही आधीपासून ZFS चालवत असाल आणि संपूर्ण सेवेचे snapshot आणि rollback महत्त्वाचे वाटत असतील, तुमच्या सेवा FreeBSD native असतील, प्रत्येक tenant साठी एका प्रक्रियेऐवजी पूर्ण userland हवे असेल, किंवा kernel, packet filter, filesystem आणि documentation हे सर्व एकाच प्रणालीचा भाग म्हणून एकत्रितपणे देखभाल केलेले हवे असेल, तर Jails निवडा. FreeBSD ला coherent म्हणताना लोकांचा अर्थ हाच असतो. याची अधिक सविस्तर चर्चा server platforms म्हणून Linux आणि FreeBSD यांची व्यापक तुलना आणि server वापरासाठी FreeBSD 15 मध्ये झालेले बदल येथे आहे.

शेवटचा निष्कर्ष असा आहे. तुमच्या टीमला Docker आधीपासून माहीत असेल, तर स्थलांतराचा खर्च वास्तविक आहे आणि त्यातून मिळणारा लाभ विशिष्ट असला पाहिजे. isolation quality साठी बदल करू नका; दोन्ही मॉडेलमधील फरक इतका कमी आहे की तुमची configuration अधिक महत्त्वाची ठरते. संपूर्ण सेवेचा ZFS-backed rollback हवा असेल किंवा तुम्ही आधीपासून FreeBSD वापरत असाल, तरच बदल करा.

FAQ

मी FreeBSD वर Docker images चालवू शकतो का?

Linux images नाही, आणि समर्थित पद्धतीने तर अजिबात नाही. FreeBSD मध्ये OCI container support आहे: sudo pkg install -y podman-suite Podman install करते. Podman ocijail द्वारे containers चालवते. हा runtime प्रत्यक्ष jails तयार करतो. Container monitor साठी fdescfs हे /dev/fd वर mounted असणे आवश्यक आहे. Container NAT (network address translation) साठी pf आवश्यक आहे. FreeBSD-native OCI images सर्वाधिक चांगल्या प्रकारे काम करतात. Linux images साठी Linux compatibility layer देखील आवश्यक आहे. August 2026 पर्यंत FreeBSD Podman port अजूनही experimental म्हणून वर्णन केले जाते. तुमचा deployment Linux images च्या stack वर आधारित असेल, तर तो Linux वर चालवा. RHEL family मध्ये यासाठी Rocky Linux किंवा AlmaLinux वर Docker install करणे आवश्यक आहे. तेथे काहीही install करण्यापूर्वी Podman पुन्हा एकदा अशा package म्हणून दिसते, जे docker command चे ownership आधीपासून राखते.

FreeBSD jails Docker containers पेक्षा अधिक सुरक्षित आहेत का?

दोन्ही एकाच host kernel चा वापर करतात. त्यामुळे kernel bug दोन्हीसाठी धोका असतो. खरोखर untrusted code साठी यांपैकी कोणतेही isolation boundary म्हणून निवडू नये. फरक त्यांच्या सुरुवातीच्या स्थितीत आहे. Jail मध्ये operations चा व्यापक संच सुरुवातीला नाकारलेला असतो. तुम्ही ते एकावेळी एका parameter द्वारे पुन्हा enable करता. Docker container मध्ये namespaces च्या संचामध्ये root म्हणून सुरुवात होते. त्यातील काही capabilities काढलेल्या असतात. पुढील hardening opt-in असते. प्रत्यक्षात model पेक्षा configuration अधिक महत्त्वाची ठरते: allow.mount आणि allow.raw_sockets enable केलेला jail काळजीपूर्वक configure केलेल्या container पेक्षा अधिक सुरक्षित नसतो.

मी jail चा backup कसा घ्यावा?

Dataset चा snapshot घ्या आणि तो पाठवा. sudo zfs snapshot zroot/jails/containers/web@backup, त्यानंतर तो snapshot दुसऱ्या pool वर किंवा box बाहेर copy करता येईल अशा file मध्ये zfs send करा. Jail चा संपूर्ण userland एका dataset मध्ये असल्यामुळे snapshot मध्ये installed packages आणि data एका सुसंगत बिंदूवरील स्थितीसह captured होतात. तुम्ही हाताने edit केलेल्या प्रत्येक config file चाही त्यात समावेश होतो. हे Docker पद्धतीच्या अगदी विरुद्ध आहे. Docker मध्ये named volumes आणि Compose file चा backup घेतला जातो आणि उर्वरित भाग image मधून पुन्हा तयार केला जातो.

मला BastilleBSD आवश्यक आहे का, की base system पुरेसे आहे?

Base system पुरेसे आहे आणि सुरुवात करण्यासाठी तेच अधिक योग्य आहे. jail.conf, jls, jexec आणि service jail start हे संपूर्ण model समाविष्ट करतात. ही commands समजल्यानंतर त्या host ची tooling आधी शिकण्याची गरज न पडता कोणताही FreeBSD host वाचता येतो. Bastille हा त्यावरील convenience layer आहे. तो releases bootstrap करतो, thin jails तयार करतो, templates लागू करतो आणि तुमच्यासाठी pf redirect rules लिहितो. आधी base commands शिका. त्यानंतर jails ची संख्या वाढल्यावर वारंवार typing करणे त्रासदायक वाटू लागल्यास Bastille जोडा.