FreeBSD Jails आणि Docker Containers मधील मुख्य फरक

FreeBSD jails आणि Docker containers एकाच समस्येवर दोन वेगवेगळ्या प्रकारे उपाय करतात. दोन्ही एकाच सामायिक कर्नलवर (shared kernel) आयसोलेटेड युजरलँड चालवतात, त्यामुळे यापैकी एकही व्हर्च्युअल मशीन नाही. फरक फक्त आत काय असते यात आहे. Docker container हे रजिस्ट्रीवरून घेतलेल्या लेअर्ड इमेजमधील एकच प्रोसेस चालवते. याउलट, jail मध्ये संपूर्ण FreeBSD युजरलँड असतो: स्वतःची /etc, स्वतःची rc स्टार्टअप स्क्रिप्ट्स, स्वतःची pkg डेटाबेस आणि तुम्हाला हव्या तितक्या प्रोसेसेस. या पानावर दिलेले इतर जवळजवळ सर्व फरक याच एका मूलभूत फरकामुळे निर्माण होतात.

SSD Nodes वर FreeBSD इमेजेस उपलब्ध नाहीत. तुम्ही या प्लॅटफॉर्मवर FreeBSD सर्व्हर भाड्याने घेऊ शकत नाही आणि खाली दिलेली माहिती येथे खरेदी करता येणाऱ्या मशीनसाठी इन्स्टॉल गाइड नाही. हे दोन आयसोलेशन मॉडेल्सची तुलना आहे, जी तुम्हाला तुमच्या वर्कलोडसाठी काय आवश्यक आहे हे ओळखण्यास आणि FreeBSD टीमचे सेटअप समजून घेण्यास मदत करेल.

Jail म्हणजे नेमके काय

FreeBSD 4.0 मध्ये मार्च 2000 मध्ये Jails ची सुरुवात झाली. हे cgroups पेक्षा जुने आणि Docker पेक्षा साधारणपणे एक दशकाने जुने तंत्रज्ञान आहे. ही यंत्रणा एका कर्नल कॉलवर आधारित आहे. jail(8) एका डिरेक्टरी ट्रीला घेते आणि त्यामध्ये Jail ID जोडलेल्या प्रक्रिया सुरू करते. त्यानंतर, तो ID असलेल्या कोणत्याही प्रक्रियेसाठी कर्नल काही ठराविक ऑपरेशन्स करण्यास नकार देते. Jail मधील प्रक्रिया तिच्या बाहेरील प्रक्रिया पाहू शकत नाही, फाइलसिस्टम माउंट किंवा अनमाउंट करू शकत नाही, कर्नल मॉड्यूल्स लोड करू शकत नाही आणि Jail ला न दिलेल्या नेटवर्क ॲड्रेसवर बाइंड होऊ शकत नाही. यामध्ये शिकण्यासारखे कोणतेही वेगळे नेमस्पेस प्रकार नाहीत किंवा प्रति-वैशिष्ट्य (per-feature) निवडीची गरज नाही: हे निर्बंध एकाच युनिटच्या स्वरूपात येतात आणि Jail च्या कॉन्फिगरेशनमधील पॅरामीटर्सद्वारे नियंत्रित केले जातात.

होस्टवर, jls चालू असलेल्या Jails ची यादी दाखवते आणि jexec web sh तुम्हाला web नावाच्या Jail च्या आत शेलमध्ये घेऊन जाते.

तुम्ही एका डिरेक्टरीमध्ये FreeBSD userland ठेवून Jail तयार करता. बेस सिस्टम तुमच्यासाठी हे काम करते:

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

हे तुमच्या रिलीजसाठी बेस डिस्ट्रिब्युशन सेट मिळवते आणि सामान्य पोस्ट-इन्स्टॉल पायऱ्या राबवते. त्यामुळे तुम्ही नवीन सर्व्हरवर करता तसाच root पासवर्ड सेट करू शकता आणि टाइमझोन निवडू शकता. याचा परिणाम असा होतो की एका फोल्डरमध्ये 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 ॲड्रेससह web ची यादी दाखवली पाहिजे. जर Jail दिसत नसेल, तर sudo jail -c web थेट चालवा. हे त्याच कॉन्फिगरेशनला फोरग्राउंडमध्ये लागू करते आणि जे पॅरामीटर स्वीकारले गेले नाही ते प्रिंट करते, ज्यामुळे सर्व्हिस आउटपुटमध्ये त्रुटी शोधण्याऐवजी थेट कारण समजते.

exec.start = "/bin/sh /etc/rc" ही ओळ दोनदा वाचण्यासारखी आहे. Jail सुरू केल्यावर त्यामध्ये FreeBSD ची सामान्य बूट स्क्रिप्ट चालते, त्यामुळे Jail त्याच्या स्वतःच्या /etc/rc.conf मध्ये इनेबल केलेली प्रत्येक सर्व्हिस सुरू करते. Docker कंटेनरमध्ये यासारखी कोणतीही पायरी नसते, कारण ते इमेजची एंट्रीपॉइंट प्रक्रिया चालवते आणि ती प्रक्रिया थांबली की कंटेनरही थांबतो.

सॉफ्टवेअर कसे मिळवायचे: इमेजेस आणि रजिस्ट्री विरुद्ध तुम्ही स्वतः तयार केलेले युजरलँड

पहिल्याच दिवशी तुम्हाला यातील फरक जाणवतो.

Docker मध्ये तुम्ही सॉफ्टवेअरचे नाव घेता आणि ते तुम्हाला मिळते. docker pull nginx एखाद्याने तयार केलेली आणि तपासलेली, लेअर्ड, कंटेंट-अॅड्रेस्ड इमेज मिळवते आणि docker compose up -d तिला व्हॉल्यूम्स आणि नेटवर्कसह सुरू करते. रजिस्ट्री हेच मुख्य उत्पादन आहे. Docker वर्कफ्लोचे बहुतेक मूल्य यात आहे की हजारो प्रकल्प कार्यरत इमेजेस प्रकाशित करतात, ज्यामुळे VPS वर Docker चालवणे हा एक मोठा प्रकल्प न राहता एक छोटे काम बनते.

FreeBSD मध्ये जेल इमेजेसची कोणतीही डीफॉल्ट सार्वजनिक रजिस्ट्री नसते. तुम्ही एक रिकामे युजरलँड तयार करता आणि त्यात सॉफ्टवेअर इन्स्टॉल करता, जसे तुम्ही बेअर सर्व्हर सेटअप करताना करता. यात जास्त टाईपिंग करावे लागते. पण हे अधिक पारदर्शक आहे, कारण जेलमध्ये जे चालते ते 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 च्या सर्वात जवळचे आहे. प्रत्येक जेलवर एक टेम्पलेट पुन्हा चालवले जाते. काहीही आधीच तयार केलेले (prebuilt) येत नाही.

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

स्थिती आणि अपग्रेड्स: ZFS मधील बदल

Docker मुद्दामहून स्थिती (state) विभागते. कंटेनरची फाइलसिस्टम तात्पुरती असते, तुमचा डेटा named volume किंवा bind mount मध्ये असतो आणि अपग्रेड म्हणजे docker compose pull नंतर docker compose up -d करणे होय. कंटेनर बदलला जातो आणि तुम्ही व्हॉल्यूममध्ये न ठेवलेली कोणतीही गोष्ट नष्ट होते. जर तुम्ही नियमांचे पालन केले तर हे एक वैशिष्ट्य आहे, परंतु विसरल्यास डेटा गमावण्याची घटना घडते. म्हणूनच bind mounts आणि named volumes मधील निवड Compose स्टॅकमध्ये अत्यंत महत्त्वाची ठरते.

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 चे नाव तपासा; वरील path ही हँडबुकमध्ये वापरलेली मांडणी आहे. स्नॅपशॉट घेण्यासाठी साधारण एक सेकंद लागतो आणि jail मधील मजकूर बदलेपर्यंत तो जवळजवळ कोणतीही जागा व्यापत नाही. जर अपग्रेडमुळे सेवा बंद पडली, तर rollback संपूर्ण userland ला त्याच्या आधीच्या स्थितीत परत आणते, ज्यामध्ये पॅकेज डेटाबेस आणि तुम्ही रात्री 2 वाजता हाताने बदललेल्या कॉन्फिगरेशन फाइल्सचाही समावेश असतो. Docker मध्ये याला कोणताही अंगभूत पर्याय नाही, कारण त्याच्या मॉडेलमध्ये अशी गरज कधीच भासणार नाही असे गृहीत धरले जाते.

zfs clone हा दुसरा महत्त्वाचा भाग आहे. स्नॅपशॉटची clone म्हणजे एक नवीन writable jail असते, जी मूळ jail सोबत न बदललेले ब्लॉक्स शेअर करते. त्यामुळे 3 GB च्या jail ची staging प्रत तयार करण्यासाठी, जोपर्यंत तुम्ही त्यात बदल करत नाही, तोपर्यंत डिस्कवर कोणतीही जागा लागत नाही. FreeBSD ॲडमिनिस्ट्रेटर अपग्रेडचा सराव करण्यासाठी "production सारखीच" jail याच पद्धतीने तयार करतात.

बेस सिस्टमचे अपग्रेड हे पॅकेजेसपासून वेगळे असते. स्वतःची userland प्रत असलेल्या jail साठी:

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

Thin jails हे काम पुन्हा पुन्हा करणे टाळतात. त्या nullfs द्वारे एक सामायिक read-only बेस माउंट करतात आणि प्रत्येक jail ला स्वतःचा एक छोटा writable स्तर देतात. त्यामुळे तुम्ही एकदा बेस पॅच केला की सर्व jails ना त्याचे परिणाम दिसतात. Bastille डीफॉल्टनुसार thin jails तयार करते.

नेटवर्किंग: पब्लिश केलेले पोर्ट्स विरुद्ध ॲड्रेसिंगचा निर्णय

Docker तुमच्यासाठी नेटवर्किंगचा निर्णय घेते आणि तुम्हाला अपवाद पब्लिश करण्यास सांगते. कंटेनर्स एका ब्रिजवर येतात, ते युजर-डिफाइन्ड नेटवर्कवर सर्व्हिस नेमद्वारे एकमेकांशी संपर्क साधतात आणि -p 8080:80 त्यापैकी एकाला होस्टसाठी उघड करते (expose करते). हे घडवून आणण्यासाठी Docker स्वतःचे पॅकेट फिल्टर नियम लिहिते, आणि याच कारणामुळे पब्लिश केलेला कंटेनर पोर्ट थेट ufw ला ओलांडून जातो.

जेल (jail) वापरताना तुम्हाला सुरुवातीलाच मॉडेल निवडावे लागते, आणि त्याचे दोन प्रकार आहेत.

Shared IP. ip4.addr = "10.0.0.10" हे ॲड्रेस विद्यमान होस्ट इंटरफेसमध्ये जोडते आणि जेलला त्यापुरते मर्यादित करते. जेलकडे स्वतःचा नेटवर्क स्टॅक नसतो, त्यामुळे ते स्वतःचा फायरवॉल चालवू शकत नाही. तसेच ते सर्व ॲड्रेसवर बाइंड (bind) होऊ शकत नाही: जेलमधील सॉकेट जेव्हा 0.0.0.0 ची मागणी करते, तेव्हा कर्नल ते जेलच्या स्वतःच्या ॲड्रेसवर रिराईट करते. दोन जेल एकाच ॲड्रेसच्या पोर्ट 80 वर लिसन करू शकत नाहीत, म्हणून तुम्हाला प्रत्येकाला एक वेगळा ॲड्रेस द्यावा लागतो, किंवा समोर एक रिव्हर्स प्रॉक्सी ठेवावी लागते.

VNET. जेलमध्ये vnet; जोडल्यास त्याला पूर्ण नेटवर्क स्टॅक मिळतो: स्वतःचे इंटरफेस, स्वतःचे राउटिंग टेबल आणि स्वतःचे फायरवॉल नियम. तुम्ही त्याला epair द्वारे होस्टशी जोडता, जो दोन्ही बाजूंना टोक असलेला एक व्हर्च्युअल केबल असतो, आणि होस्टचे टोक एका ब्रिजवर ठेवता. Docker तुम्हाला जे देते, त्याच्याशी हे सर्वात मिळतेजुळते आहे आणि Bastille च्या -V व -B जेल प्रकारांमागे हेच मॉडेल असते.

होस्ट पोर्ट जेलमध्ये फॉरवर्ड करणे म्हणजे एक pf रिडायरेक्ट नियम असतो. Bastille हे खालीलप्रमाणे रॅप करते:

sudo bastille rdr web tcp 80 80

येथे कोणताही EXPOSE नसतो आणि ऑटोमॅटिक पब्लिशिंग नसते. जोपर्यंत जेलचा ॲड्रेस किंवा रिडायरेक्ट नियम परवानगी देत नाही, तोपर्यंत काहीही जेलपर्यंत पोहोचू शकत नाही. ही सुरुवात थोडी संथ असली तरी फायरवॉल अधिक सुरक्षित आणि शांत राहतो.

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

Docker कंटेनरवर cgroups द्वारे मर्यादा लादते आणि या मर्यादा कंटेनर जिथे परिभाषित केला आहे तिथेच असतात: कमांड लाईनवर --memory=1g --cpus=1.5 वापरून किंवा Compose फाईलमध्ये संबंधित कीज वापरून. जर तुम्ही तुमचा स्टॅक आधीच 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 जेलचा सध्याचा वापर मानवी-वाचनीय स्वरूपात प्रिंट करते, त्यामुळे काहीही बिघडण्यापूर्वी ते मर्यादेच्या किती जवळ आहे हे तुम्ही पाहू शकता. deny ॲक्शनमुळे मर्यादेबाहेरील ॲलोकेशन जेलच्या आत अयशस्वी होते, परिणामी तुम्हाला होस्टवर 'kill' मेसेज दिसण्याऐवजी ॲप्लिकेशनची स्वतःची ॲलोकेशन एरर दिसते.

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 runners, आणि जवळजवळ प्रत्येक प्रोजेक्टच्या README मध्ये एक-कमांड क्विकस्टार्ट सुविधा मिळते. Jails सोबत FreeBSD ports tree येते, जे मोठे आणि काळजीपूर्वक निगा राखलेले आहे, तसेच वापरण्यास तयार असलेल्या ॲप्लिकेशन बंडल्सचा एक छोटा संच मिळतो. जेव्हा एखादा प्रोजेक्ट फक्त कंटेनर इमेज प्रकाशित करतो, तेव्हा FreeBSD चा मार्ग म्हणजे त्याचे डॉक्युमेंटेशन वाचणे आणि स्वतः सर्व भाग एकत्र करणे.

Jails या व्यवहाराच्या दुसऱ्या बाजूला स्वतःचे स्थान निर्माण करतात. जेव्हा तुम्ही आधीच ZFS वापरत असता आणि संपूर्ण सर्व्हिसचे स्नॅपशॉट आणि रोलबॅक महत्त्वाचे मानता, जेव्हा तुमच्या सर्व्हिसेस FreeBSD नेटिव्ह असतात, जेव्हा तुम्हाला एका प्रोसेसऐवजी प्रत्येक टेनंटसाठी पूर्ण userland हवा असतो, किंवा जेव्हा तुम्हाला कर्नल, पॅकेट फिल्टर, फाइलसिस्टम आणि डॉक्युमेंटेशन एकाच सिस्टिमप्रमाणे मेंटेन केलेले हवे असते, तेव्हा तुम्ही Jails निवडता. शेवटच्या मुद्द्याचा अर्थ असा आहे की लोक FreeBSD ला 'सुसंगत' (coherent) का म्हणतात, आणि यावर Linux आणि FreeBSD ची सर्व्हर प्लॅटफॉर्म म्हणून तुलना आणि FreeBSD 15 ने सर्व्हर वापरासाठी काय बदलले यामध्ये अधिक सविस्तर चर्चा केली आहे.

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

FAQ

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

Linux images चालवता येत नाहीत आणि हा समर्थित मार्ग नाही. FreeBSD मध्ये OCI container साठी समर्थन आहे: sudo pkg install -y podman-suite हे Podman इन्स्टॉल करते, जे ocijail द्वारे कंटेनर चालवते. हे एक रनटाइम आहे जे अंतर्गत प्रत्यक्ष jails तयार करते. यासाठी कंटेनर मॉनिटरकरिता fdescfs हे /dev/fd वर माउंट केलेले असणे आवश्यक आहे आणि कंटेनर NAT (network address translation) साठी pf आवश्यक आहे. FreeBSD-native OCI images सर्वोत्तम काम करतात. Linux images साठी अतिरिक्त 'Linux compatibility layer' ची आवश्यकता असते आणि ऑगस्ट 2026 पर्यंत FreeBSD Podman पोर्ट अजूनही प्रायोगिक (experimental) मानले जाते. जर तुमचे डिप्लॉयमेंट Linux images चा स्टॅक असेल, तर ते Linux वरच चालवा.

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

दोन्ही एकाच होस्ट कर्नलचा वापर करतात, त्यामुळे कर्नल बग दोन्हीसाठी धोकादायक आहे. खरोखर अविश्वसनीय (untrusted) कोडसाठी यापैकी कोणताही पर्याय सुरक्षित सीमा मानला जात नाही. फरक त्यांच्या सुरुवातीच्या स्थितीमध्ये आहे. एक jail अनेक ऑपरेशन्स नाकारून सुरू होते आणि तुम्ही एका वेळी एक पॅरामीटर सक्षम करता. Docker container हे 'root' म्हणून 'namespaces' च्या संचामध्ये सुरू होते, ज्यामध्ये काही क्षमता (capabilities) काढून टाकलेल्या असतात आणि अधिक सुरक्षा (hardening) ही ऐच्छिक असते. प्रत्यक्षात, मॉडेलपेक्षा कॉन्फिगरेशन अधिक महत्त्वाचे असते: जर jail मध्ये allow.mount आणि allow.raw_sockets सक्षम असतील, तर ते काळजीपूर्वक कॉन्फिगर केलेल्या कंटेनरपेक्षा अधिक सुरक्षित नसते.

मी jail चा बॅकअप कसा घेऊ?

डेटासेटचा स्नॅपशॉट घ्या आणि तो पाठवा. sudo zfs snapshot zroot/jails/containers/web@backup वापरा आणि त्यानंतर तो स्नॅपशॉट दुसऱ्या पूलमध्ये किंवा सर्व्हरवरून कॉपी करायच्या फाईलमध्ये zfs send करा. jail आपली संपूर्ण userland एकाच डेटासेटमध्ये ठेवते, त्यामुळे स्नॅपशॉटमध्ये इन्स्टॉल केलेली पॅकेजेस, डेटा आणि तुम्ही हाताने बदललेल्या सर्व कॉन्फिगरेशन फाईल्स एका सुसंगत स्थितीत जतन होतात. हे Docker च्या पद्धतीपेक्षा पूर्णपणे वेगळे आहे, जिथे तुम्ही 'named volumes' आणि 'Compose file' चा बॅकअप घेता आणि बाकी सर्व इमेजवरून पुन्हा तयार करता.

मला BastilleBSD ची गरज आहे की बेस सिस्टम पुरेशी आहे?

बेस सिस्टम पुरेशी आहे आणि सुरुवात करण्यासाठी तीच उत्तम जागा आहे. jail.conf, jls, jexec आणि service jail start हे संपूर्ण मॉडेल कव्हर करतात. एकदा का तुम्हाला हे समजले की, तुम्ही कोणत्याही FreeBSD होस्टवर काम करू शकता, कारण तुम्हाला त्या होस्टच्या विशिष्ट टूल्सवर अवलंबून राहावे लागत नाही. Bastille हा त्यावरील एक सोयीस्कर स्तर (convenience layer) आहे: तो रीलिजेस बूटस्ट्रॅप करतो, thin jails तयार करतो, टेम्पलेट्स लागू करतो आणि तुमच्यासाठी pf रीडायरेक्ट नियम लिहितो. आधी बेस कमांड्स शिका आणि जेव्हा jails ची संख्या वाढल्यामुळे टाईपिंग कंटाळवाणे वाटू लागेल, तेव्हा Bastille चा वापर करा.