google/gvisorयूज़रस्पेस एप्लिकेशन कर्नेल के माध्यम से कंटेनरों को सैंडबॉक्स करता है जो सिस्टम कॉल को इंटरसेप्ट करता है, होस्ट कर्नेल एक्सेस को सीमित करता है, और OCI रनटाइम के माध्यम से Docker/Kubernetes के साथ एकीकृत होता है।
gVisor चल रहे अनुप्रयोगों और होस्ट ऑपरेटिंग सिस्टम के बीच अलगाव की एक मजबूत परत प्रदान करता है। यह एक अनुप्रयोग कर्नेल है जो [Linux-जैसा इंटरफ़ेस][linux] लागू करता है। Linux के विपरीत, यह एक मेमोरी-सुरक्षित भाषा (Go) में लिखा गया है और उपयोगकर्ता स्थान (userspace) में चलता है।
gVisor में runsc नामक एक [Open Container Initiative (OCI)][oci] रनटाइम शामिल है जो मौजूदा कंटेनर टूलिंग के साथ काम करना आसान बनाता है। runsc रनटाइम Docker और Kubernetes के साथ एकीकृत होता है, जिससे सैंडबॉक्स्ड कंटेनर चलाना सरल हो जाता है।
seccomp-bpf), और न ही Linux अलगाव प्राथमिकताओं के ऊपर एक रैपर है (जैसे firejail, AppArmor, आदि)।gVisor एक अलग तीसरा दृष्टिकोण अपनाता है, जो VM के कई सुरक्षा लाभ प्रदान करता है, साथ ही सामान्य उपयोगकर्ता स्थान अनुप्रयोगों के कम संसाधन उपयोग, तेज़ स्टार्टअप और लचीलेपन को बनाए रखता है।
कंटेनर एक [सैंडबॉक्स][sandbox] नहीं हैं। हालाँकि कंटेनरों ने हमारे अनुप्रयोगों को विकसित करने, पैकेज करने और तैनात करने के तरीके में क्रांति ला दी है, फिर भी अविश्वसनीय या संभावित रूप से दुर्भावनापूर्ण कोड को अतिरिक्त अलगाव के बिना चलाने के लिए उनका उपयोग करना अच्छा विचार नहीं है। जबकि एकल, साझा कर्नेल का उपयोग दक्षता और प्रदर्शन लाभ की अनुमति देता है, इसका यह भी अर्थ है कि एक ही भेद्यता से कंटेनर एस्केप संभव है।
gVisor कंटेनरों के लिए एक अनुप्रयोग कर्नेल है। यह अनुप्रयोग के लिए सुलभ होस्ट कर्नेल सतह को सीमित करता है, जबकि फिर भी अनुप्रयोग को उन सभी सुविधाओं तक पहुँच प्रदान करता है जिनकी वह अपेक्षा करता है। अधिकांश कर्नेल के विपरीत, gVisor भौतिक संसाधनों के एक निश्चित समूह को न तो मानता है और न ही आवश्यक करता है; इसके बजाय, यह मौजूदा होस्ट कर्नेल कार्यक्षमता का लाभ उठाता है और एक सामान्य प्रक्रिया के रूप में चलता है। दूसरे शब्दों में, gVisor Linux के माध्यम से Linux को लागू करता है।
gVisor को बाहरी खतरों के विरुद्ध कंटेनरों को सुदृढ़ करने, अतिरिक्त अखंडता जाँच प्रदान करने, या किसी सेवा के लिए पहुँच के दायरे को सीमित करने वाली तकनीकों और उपकरणों के साथ भ्रमित नहीं किया जाना चाहिए। किसी कंटेनर के लिए कौन-सा डेटा उपलब्ध कराया जाता है, इस बारे में हमेशा सावधान रहना चाहिए।
उपयोगकर्ता दस्तावेज़ीकरण और तकनीकी आर्किटेक्चर, जिसमें त्वरित शुरुआत मार्गदर्शिकाएँ शामिल हैं, [gvisor.dev][gvisor-dev] पर पाई जा सकती हैं।
gVisor x86_64 और ARM64 पर बनता है। अन्य आर्किटेक्चर भविष्य में उपलब्ध हो सकते हैं।
इन निर्देशों के प्रयोजनों के लिए, [bazel][bazel] और अन्य बिल्ड निर्भरताएँ एक बिल्ड कंटेनर में लिपटी हुई हैं। [bazel][bazel] को सीधे उपयोग करना संभव है, या मानक लक्ष्यों के लिए make help टाइप करें।
सुनिश्चित करें कि निम्नलिखित निर्भरताएँ इंस्टॉल हैं:
runsc, containerd-shim-runsc-v1 containerd शिम, और कुछ साइडकार बाइनरीज़ वाला एक रिलीज़ टारबॉल बनाएँ जिन्हें runsc अपने बगल में एक gvisor-bin/ निर्देशिका में पाने की अपेक्षा करता है, फिर इसे /usr/local/bin में निकालें:
make release-tarball DESTINATION=bin/
sudo tar -C /usr/local/bin -xf bin/gvisor.tar.bz2
विशिष्ट लाइब्रेरी या बाइनरी बनाने के लिए, आप लक्ष्य निर्दिष्ट कर सकते हैं:
make build TARGETS="//pkg/tcpip:tcpip"
अतिरिक्त ओवरहेड के कारण सीधे Bazel का उपयोग करने की अनुशंसा नहीं की जाती है, लेकिन शुरू करने के लिए:
निर्भरताएँ सेट करने के बाद, Bazel का उपयोग करना Makefile के समान है:
bazel build -c opt //debian:gvisor-release-tar-bz2
मानक टेस्ट सूट चलाने के लिए, आप इसका उपयोग कर सकते हैं:
make unit-tests
make tests
विशिष्ट परीक्षण चलाने के लिए, आप लक्ष्य निर्दिष्ट कर सकते हैं:
# Makefile
make test TARGETS="//runsc:version_test"
# Bazel
bazel test //runsc:version_test
कुछ पैकेज macOS पर सीधे टेस्ट चलाने का समर्थन करते हैं। रिपॉज़िटरी द्वारा पिन किए गए संस्करण का चयन करने के लिए Homebrew के साथ Bazelisk इंस्टॉल करें:
brew install bazelisk
# You can then run the tests, e.g.:
bazelisk test --macos_sdk_version=$(xcrun --show-sdk-version) -- //tools/nogo/... //tools/check{aligned,const,escape,linkname,locks,unsafe}/...
go get का उपयोग करनायह प्रोजेक्ट निर्भरताओं को बनाने और प्रबंधित करने के लिए [bazel][bazel] का उपयोग करता है। सुविधा के लिए एक सिंथेटिक
go ब्रांच को बनाए रखा जाता है जो मानक go टूलिंग के साथ संगत है। यह उन बाहरी पैकेजों और लाइब्रेरीज़ के लिए उपयोगी है जो gVisor Go
कोड को अपने Go प्रोजेक्ट्स में आयात करने के लिए gVisor सबपैकेजों (जैसे Netstack के माध्यम से userspace नेटवर्किंग) पर निर्भर करते हैं।
इस ब्रांच को go ब्रांच क्वेरी के साथ स्पष्ट रूप से चुनें। @latest master को रिज़ॉल्व करता है, जिसके लिए Bazel आवश्यक है और यह मानक Go टूलिंग के साथ संगत नहीं है:
go get gvisor.dev/gvisor/pkg/tcpip/transport/tcp@go
नोट: इस ब्रांच से बनाए गए runsc बिल्ड समर्थित नहीं हैं। gVisor और
runsc को कार्य करने के लिए कई बाइनरीज़ की आवश्यकता होती है (जिनमें से कुछ तो Go में भी नहीं लिखी गई हैं)। go ब्रांच को best effort क्षमता में समर्थित किया जाता है, और इस ब्रांच पर सीधा विकास समर्थित नहीं है। विकास master ब्रांच पर होना चाहिए, जिसे फिर go ब्रांच में प्रतिबिंबित किया जाता है।
प्रोजेक्ट शासन संबंधी जानकारी के लिए GOVERNANCE.md देखें।
ज्ञात प्रोडक्शन उपयोगकर्ताओं और अपनाने वालों की सूची के लिए ADOPTERS.md देखें।
[CNCF Slack][cncf-slack] वर्कस्पेस पर हमसे जुड़ें: प्रश्नों और चर्चा के लिए [#gvisor][slack-gvisor] का उपयोग करें, और विकास एवं योगदान के लिए [#gvisor-dev][slack-gvisor-dev] का उपयोग करें। चैनलों में शामिल होने से पहले, आपको CNCF Slack वर्कस्पेस का सदस्य होना आवश्यक है:
[gvisor-users मेलिंग सूची][gvisor-users-list] और [gvisor-dev मेलिंग सूची][gvisor-dev-list] भी प्रश्नों और चर्चा के लिए अच्छे प्रारंभिक बिंदु हैं।
SECURITY.md देखें।
Releases देखें।
Contributing.md देखें।