हर दिन, AWS Lambda खरबों फंक्शन इनवोकेशन चलाता है। AWS Fargate लाखों कंटेनर शेड्यूल करता है। उनमें से हर एक एक पूर्ण वर्चुअल मशीन है, जिसका अपना कर्नेल है, और एक सेकंड के एक अंश में बूट होती है।
कैसे? लगभग 50,000 लाइनों का Rust कोड जिसे Firecracker कहा जाता है, जो इसलिए अस्तित्व में आया क्योंकि उद्योग ने अंततः स्वीकार कर लिया कि एक Linux कंटेनर जो संसाधन उपयोग को नियंत्रित करता है, उसे कभी भी सुरक्षा सीमा के रूप में डिजित नहीं किया गया था।
आइसोलेशन की समस्या समस्या
आपके लैपटॉप पर हर Docker कंटेनर एक कोट में तीन Linux कर्क Linux कर्नेल सुविधाएँ हैं:
- Namespaces आँखों पर पट्टी हैं। उनके अंदर की प्रक्रिया को सिस्टम का एक निजी दृश्य मिलता है: अपनी खुद की PID सूची, नेटवर्क स्टैक, माउंट टेबल, होस्टनेम, और यूज़र आईडी। कंटेनर के अंदर PID 1 होस्ट पर कुछ रैंडम PID है; कंटेनर अन्य प्रक्रियाओं को देख भी नहीं सकता।
- cgroups बजट हैं। कंट्रोल ग्रुप्स कर्नेल की लेखा और दर-सीमित करने वाली परत हैं। वे सीमित करते हैं कि एक प्रक्रिया ट्री कितना CPU, मेमोरी, डिस्क IO, और नेटवर्क बैंडविड्थ उपभोग कर सकता है।
- seccomp + capabilities अनुमति-सूचियाँ हैं। capabilities रूट की शक्तियों को लगभग 40 अलग-अलग विशेषों (लो पोर्ट बांधना, कर्नेल मॉड्यूल लोड करना, फाइलसिस्टम माउंट करना, आदि) में विभाजित करती हैं ताकि आप केवल वही प्रदान कर सकें जिनकी आवश्यकता है। seccomp एक प्रति-प्रक्रक्रिया फिल्टर है जो तय करता है कि प्रक्रिया को कौन से syscalls (कर्नेल में यूज़रस्पेस का एकमात्र API) करने की अनुमति है।
आप इसे Docker स्थापित किए बिना भी स्वयं साबित कर सकते हैं:
Docker जो कुछ भी करता है (इमेज लेयर्स, रजिस्ट्री, DNS) वह शीर्ष पर ऑर्केट्रेशन है।
वह सारी सारी सुरक्षा एक Linux कर्नेल के माध्यम से होती है, जो लगभग 30 मिलियन लाइनों का कोड है जो 400+ syscalls को उजाग करता है। होस्ट पर हर कंटेनर उसी कर्नेल में कॉल करता है। उन syscalls में से किसी में भी एक बग और उस मशीन पर हर टेनेंट के लिए खेल खत्म।
पूर्ण वर्चुअल मशीनें आइसोलेशन को बलपूर्वक हल करती हैं: प्रत्येक VM का अपना कर्नेल होता है।
आधुनिक CPUs में एक "गेस्ट मोड" होता है जो वास्तविक सिलिकॉन पर गेस्ट निर्देशों को चलाता है। होस्ट तभी शामिल होता है जब गेस्ट कुछ विशेषाधिकार प्राप्त करता है (वास्तविक हार्डवेयर को छूता है, फॉल्ट करता है, बाधित होता है)। एक हाइपरवाइजर पतली परत है जो उन क्षणों का मध्यस्थता करती है।
Linux अपने हाइपरवाइजर को एक कर्नेल मॉड्यूल के रूप में भेजता है जिसे KVM कहा जाता है, जो /dev/kvm पर उजागर होता है। यह हार्डवेयर वर्चुअलाइजेशन एक्सटेंशन (Intel पर vmx, AMD पर svm) पर सवार सवार है:
पू है:
पूर्ण VM की समस्या यह है कि वे धीमे और मोटे हैं। एक क्लासिक QEMU VM एक पूर्ण काल्पनिक PC (BIOS, PCI बस, IDE कंट्रोलर, VGA कार्ड, PS/2 कीबोर्ड) का अनुकरण करता है क्योंकि 1998 का OS इसी के खिलाफ बूट होने की उम्मीद करता था। इमेज सैकड़ों मेगाबाबाइट्स की होती है। बूट में सेकंड लगते हैं। आपका वर्कलोड शुरू होने से पहले ही मेमोरी फुटप्रिंट सैकड़ों MiB का होता है। एक वेब अनुरोध के लिए जो 40ms रहता है, आप मशीन को बूट करने में उससे 40 गुना अधिक खर्च करेंगे।
तो आप इनके बीच फंस गए हैं:
- कंटेनर: 50ms बूट, 5 MiB ओवरहेड, साझा-कर्नेल अटैक सतह।
- VMs: 5+ सेकंड बूट, 300+ MiB ओवरहेड, हार्डवेयर-पृथक।
हर कोई जो अविश्वसनीय मल्टी-टेनेंट कोड चला रहा है (AWS, और मूल रूप से हर मौजूदा AI सैंडबॉक्स विक्रेता) को एक साथ उस व्यापार के दोनों पहलुओं की आवश्यकता है।
माइक्रोVMs में प्रवेश
एक VMM (वर्चुअल मशीन मॉनिटर) यूज़र-स्पेस प्रक्रिया है जो हाइपरवाइजर को चलाती है: यह गेस्ट मेमोरी सेट करता है, वर्चुअल डिवाइस प्लग करता है, और KVM को गेस्ट कोड चलाना शुरू करने के लिए कहता है।
एक माइक्रोVM एक VMM है जिसमें 1998 का PC हटा दिया गया है: कोई BIOS नहीं, कोई PCI बस नहीं, कोई VGA नहीं, कोई USB नहीं, कोई ACPI नहीं (कोई भी लीगेसी हार्डवेयर नहीं जिसके माध्यम से एक वास्तविक डेस्कटॉप बूट होता है, और उनमें से कोई भी 40ms फंक्शन कॉल के लिए प्रासंगिक नहीं है)। जो बचता है: KVM, एक सीरियल कंसोल, और मुट्ठी भर virtio डिवाइस (नेट, ब्लॉक, vsock)।
virtio मानक "मुझे पता है कि मैं एक VM में चल रहा हूँ" डिवाइस इंटरफ़ेस है। गेस्ट वास्तविक Intel e1000 कार्ड या IDE कंट्रोलर चलाने का दिखावा करने के बजाय हल्के वर्चुअल NICs और डिस्क (virtio-net, virtio-block) के माध्यम से हाइपरवाइजर के साथ सहयोग करता है। वह सहयोग, साथ ही ऊपर के सभी लापता लीगेसी हार्डवे का, माइक्रोVMs के तेजी से बूट होने का सबसे बड़ा कारण है।
परिणाम:
- VMM लॉन्च से गेस्ट यूज़रस्पेस में init चलाने तक लगभग 125ms बूट।
- प्रति VM <5 MiB VMM मेमोरी ओवरहेड (होस्ट प्रति VM जो बहीपिंग मेमोरी का भुगतान करता है, इससे पहले कि गेस्ट वर्कलोड अपने लिए कुछ भी आवंटित करे)।
- एक होस्ट पर 150 VMs/सेकंड निर्माण दर।
- बेयर मेटल की तुलना में ~2–8% रनटाइम प्रदर्शन हिट।
एक पूर्ण VM के समान हार्डवेयर-स्तरीय आइसोलेशन, एक कंटेनर के समान परिमाण का घनत्व।
Firecracker VMM है VMM, वह प्रक्रिया जो वास्तव में /dev/kvm से बात करती है और माइक्रोVM को बूट करती है। इस पोस्ट का शेष भाग उस स्टैक को एंड-टू-एंड कवर करता है।
Firecracker
नवंबर 2018 में, AWS ने AWS ने Firecracker को re:Invent में ओपन-सोर्स किया। यह पहले से ही Lambda को प्रोडक्शन में चला रहा था, वह चीज़ जो आपके import pandas कोल्ड-स्टार्ट को मिलीसेकंड द्वारा बिल करने योग्य बनाती है। 2020 में, टीम ने NSDI '20 में आर्किटेक्चर प्रकाशित किया।
आर्किटेक्चर
Google के crosvm से फोर्क किया गया, Rust में फिर से लिखा गया, आधे से अधिक कोड हटा दिया गया। प्रत्येक Firecracker प्रक्रिया एक माइक्रोVM है, जिसमें ठीक तीन थ्रेड प्रकार के प्रकार हैं (docs/design.md में प्रलेखित):
- API थ्रेड ऑर्डर डेस्क है। एक Unix सॉकेट (एक केवल-लोकल सॉकेट जो डिस्क पर एक फाइल के रूप में रहता है, TCP पोर्ट नहीं) से बंधा एक REST सर्वर। बूट से पहले कॉन्फ़िगरेशन और बाद में सीमित कार्रवाइयाँ स्वीकार करता है।
- VMM थ्रेड हार्डवेयर फैक्ट्री फ्लोर है। यह हर उस डिवाइस होने का दिखावा करता है जिसे गेस्ट देख सकता है। जब गेस्ट उस चीज़ को दबाता है जिसे वह NIC रजिस्टर समझता है, CPU गेस्ट को रोकता है, VMM दबाव को संभाल करता है ("गेस्ट ने TX क्यू को किक किया, इसे खाली"), और फिर से शुरू करता है। तंत्र: गेस्ट मैजिक पतों को पढ़ता/लिखता है; CPU उन्हें होस्ट पर ट्रैप करता है।[^mmio]
- vCPU थ्रेड धावक हैं। प्रक्रियाएँ हैं। प्रति गेस्ट CPU एक, प्रत्येकड़े लूप में: KVM से गेस्ट को तब तक चलाने के लिए कहें जब तक कुछ दिलचस्प न हो (डिवाइस दबाव, इंटरप्ट, हॉल्ट), इसे संभालें, लूप करें।
वे Rust चैनलों (प्रक्रिया के अंदर, थ्रेड्स के बीच लॉक-फ्री मैसेज क्यू) के माध्यम से एक दूसरे से बात करते हैं। गेस्ट ठीक चार डिवाइस देखता है।
चार डिवाइस
- virtio-net VM का NIC है, बिना किसी 1998 अनुकरण के। गेस्ट पैकेट को virtqueue (साझा मेमोरी में एक रिंग बफर) में लिखता है; VMM उन्हें होस्ट-साइड TAP डिवाइस (एक वर्चुअल ईथरनेट इंटरफ़ेस जिसे कर्नेल एक फाइल के रूप में उजागर करता है) के माध्यम से बाहर निकाल करता है, जो io_uring या epoll द्वारा संचालित होता है ताकि VMM थ्रेड ब्लॉक न हो।
- virtio-block VM की डिस्क है, होस्ट पर सिर्फ फाइल IO। गेस्ट सेक्टर अनुरोधों को virtqueue में रखता है; VMM होस्ट फाइल के विरुद्ध सादा pread/pwrite जारी करता है। कोई IDE, कोई AHCI, कोई SCSI नहीं।
- virtio-vsock होस्ट के लिए VM का इंटरकॉम है। IP/पोर्ट जोड़ी के बजाय (कॉन्टेक्स्ट-आईडी, पोर्ट) टपल द्वारा संबोधित, ताकि गेस्ट एजेंट बिना किसी गेस्ट IP और वायर पर स्पूफ करने के लिए कुछ भी नहीं के साथ घर फोन कर सकता है (लॉग, हेल्थ पिंग्स, स्नैपशॉट मेटाडेटा)।
- 8250 सीरियल UART बूट कंसोल है। एक निश्चित पते पर अनुकरणित एक छोटी लीगेसी सीरियल चिप। virtio के आने से पहले अर्ली-बूट लॉग और क्रैश डंप के लिए उपयोग किया जाता है। सस्ता, सार्वभौमिक, कभी दूर नहीं जाने वाला।
एक माइक्रोVM को एंड-टू-एंड बूट करना
API संपूर्ण कंट्रोल प्लेन है: कॉन्फ़िगरेशन चैनल, जानबूझकर डेटा प्लेन (vCPU थ्रेड जो वास्तव में गेस्ट कोड चलाते हैं) से अलग रखा गया है। आप बाइनरी को एक Unix सॉकेट की ओर इशारा करते हुए शुरू करते हैं:
फिर आप इसमें कॉन्फ़िगरेशन PUT करते हैं:
चार HTTP कॉल। यही संपूर्ण कंट्रोल प्लेन है।
सुरक्षा प्याज
एक KVM सीमा पहले से ही मजबूत है। Firecracker इसके चारों ओर दो और परतें लपेटता है।
जेलर एक सैंडबॉक्स-निर्माता है। इसका एकमात्र काम VMM को चलने से पहले बॉक्स करना है। यह एक chroot (एक Linux सुविधा जो एक प्रक्रिया को एक एकल निर्देशिका उपवृक्ष में बंद कर देती है जैसे कि वह निर्देशिका फाइलसिस्टम की जड़ हो; प्रक्रिया सचमुच उसके ऊपर कुछ भी नाम नहीं दे सकती) बनाता है, एक नए PID नेमस्पेस में गिरता है ताकि वह होस्ट की अन्य प्रक्रियाओं को नहीं देख सकता, एक अनप्रिविलेज्ड uid/gid पर स्विच करता है, cgroup CPU/मेमोरी सीमाएँ लागू करता है, और उसके बाद ही उस जेल के अंदर Firecracker बाइनरी को निष्पादित करता है:
अब VMM प्रक्रिया के पास एक समर्पित chroot को छोड़कर कोई फाइलसिस्टम नहीं है, होस्ट पर अन्य प्रक्रियाओं का कोई दृश्य नहीं है, और कोई रूट क्षमताएँ नहीं हैं। यदि गेस्ट-से-होस्ट पलायन virtio या KVM के माध्यम से उतरता है, तो हमलावर cgroup सीमाओं के साथ उस chroot में उतरता है।
Seccomp एक प्रति-थ्रेड syscall अनुमति सूची है। सूच सूची में नहीं है उसे मार दिया जाता है (या EPERM वापस करता है) इससे पहले कि वह कर्नेल के syscall हैंडलर तक पहुँचे। Firecracker तीन स्तर भेजता है:
- स्तर 0: बंद। प्रोडक्शन में उपयोग न करें।
- स्तर 1: syscall संख्या द्वारा अनुमति-सूची।
- स्तर 2: तर्क मानों को भी प्रतिबंधित करें (जैसे ioctl ठीक है, लेकिन केवल KVM_RUN कमांड के साथ)। डिफ़ॉल्ट और अनुशंसित।
प्रत्येक थ्रेड को न्यूनतम संभव सतह मिलती है: API थ्रेड को ioctl(KVM_RUN) की आवश्यकता नहीं है; vCPU थ्रेड को socket() की आवश्यकता नहीं है। एक सरलीकृत दृश्य कि एक नियम कैसा दिखता है:
हमलावर को होस्ट तक पहुँचने के लिए प्रत्येक परत को स्वतंत्र रूप से विफल होना होगा।
स्नैपशॉट: Lambda SnapStart के पीछे चीट कोड
एक चल रहे माइक्रोVM का स्नैपशॉट लें। इसे मिलीसेकंड में, एक अलग होस्ट पर, एक बिल्कुल नई VMM प्रक्रिया में पुनर्स्थापित करें। कर्नेल बूट छोड़ें, init छोड़ें, JIT वार्मअप छोड़ें।
आप चल रहे VM को फ्रीज करते हैं और मेमोरी + डिवाइस स्थिति को डिस्क पर डंप करते हैं:
एक स्नैपशॉट पोस्ट-वार्मअप स्थिति को कैप्चर करता है, ताकि पुनर्स्थापित VM अपने जीवन की शुरुआत में नहीं, बल्कि बीच में जागता है।
यह ठीक वैसा ही है जैसा AWS Lambda SnapStart करता है: एक Java Lambda को एक बार इनिशियलाइज़ करें, माइक्रोVM का स्नैपशॉट लें, और उस स्नैपशॉट को प्रत्येक बाद के कोल्ड स्टार्ट पर पुनर्स्थापित करें (घोषणा)। JVM कोल्ड स्टार्ट अचानक 8+ सेकंड से सेकंड से भी कम हो जाते हैं।
वे एक साथ कैसे फिट होते हैं
gVisor एक अलग डिज़ाइन है: Go में एक यूज़र-स्पेस कर्नेल, Linux syscall इंटरफ़ेस का एक पुनः कार्यान्वयन जो एक सामान्य प्रक्रिया के रूप में चलता है। गेस्ट के syscalls होस्ट कर्नेल के बजाय gVisor से टकराते हैं, और gVisor तय करता है कि क्या (यदि कुछ) आगे भेजना है। माइक्रोVM की तुलना में शुरू करने में तेज, हॉट पथ पर 10–30% syscall ओवरहेड, और एक अलग विश्वास सीमा।
Firecracker "मेरा अपना कर्नेल, लेकिन कोई PCI BIOS नहीं" बॉक्स में बैठता है: हार्डवेयर आइसोलेशन, छो छोटा डिवाइस मॉडल, और मिलीसेकंड में बूट में बूट।
अपना उपकरण चुनें:
इसका उपयोग कौन करता है
उन सर्वरलेस प्लेटफार्मों को सूचीबद्ध करना लगभग तेज है जो माइक्रोVMs के शीर्ष पर नहीं बैठते हैं।
प्रोडक्शन में Firecracker:
- AWS Lambda और AWS Fargate: मूल उपयोग मामला। प्रत्येक Lambda इनवोकेशन एक Firecracker माइक्रोVM में उतरता है; Fargate कार्य Firecracker VMs हैं जिनके अंदर एक पतला कंटेनर रनटाइम है।
- Fly.io Machines: प्रत्येक फ्लाई मशीन रन एक Firecracker माइक्रोVM है, जो वैश्विक रूप से वितरित है, जिसमें सेकंड से कम कोल्ड स्टार्ट और स्थायी डिस्क हैं।
- लगभग हर AI एजेंट कोड-एक्जीक्यूशन सैंडबॉक्स जिसका आपने पिछले अट्ठारह महीनों में उपयोग किया है, एक Firecracker माइक्रोVM में रहता है।
इस बिंदु पर एक सैंडबॉक्स API का आकार सभी विक्रेताओं में लगभग समान है:
कोड की लगभग चार पंक्तियों में: एक Firecracker माइक्रोVM बूट होता है, एक कर्नेल इनिशियलाइट करता है, गेस्ट के अंदर एक एजेंट प्रक्रिया vsock पर आपका कमांड प्राप्त करती है, इसे चलाती है, परिणाम वापस स्ट्रीम करती है, और VM मर जाता है।
एजेंट युग: अब यह सब क्यों मायने रखता है
एक साल पहले, "AI सैंडबॉक्स क्या है?" एक विशिष्ट प्रश्न था। यदि कोई LLM कोड उत्पन्न करता था, तो संभवतः वह किसी भी मशीन पर चलाने के लिए 100% सुरक्षित नहीं था, इसलिए आप इसे एक अल्पकालिक सैंडबॉक्स में चलाते थे।
आज हर गंभीर AI उत्पाद एक एजेंट भेजता है। उनके सैंडबॉक्स भी बेहतर हुए, लेकिन एजेंटों का आकार बदल गया, और पुराने रनटाइम उत्तर नए आकार में फिट नहीं होते।
इन-प्रोसेस एजेंट बनाम होस्ट-स्तरीय एजेंट
AI एजेंटों का पहला दौर आपके एप्लिकेशन के अंदर रहता था। आप एक लाइब्रेरी आयात करते थे, एक लूप वायर करते थे, और इसे अपने मौजूदा बैकएंड में चलाते थे:
हर कॉल एक मॉडल के लिए HTTP राउंड-ट्रिप था। हर टूल कॉल आपकी अपनी प्रक्रिया में एक फंक्शन था। "सैंडबॉक्स" आपका अपना सर्वर था। यह Vercel AI SDK, LangChain, OpenAI Agents SDK की दुनिया है। यह बढ़िया काम करता है और आज भी प्रोडक्शन एजेंटों का एक बड़ा हिस्सा भेजता है।
दूसरा दौर अलग है। Claude Code, Codex, और OpenCode होस्ट-स्तरीय एजेंट हैं: बाइनरी जो एक मशीन पर कब्जा कर लेती हैं, लाइब्रेरी नहीं जो आपके अंदर रहती हैं। वे एक वास्तविक शेल, एक पैकेज मैनेजर, और एक लिखने योग्य डिस्क की उम्मीद करते हैं। जब आप Claude Code को एक कार्य देते हैं, तो वह इस तरह की चीज़ चलाता है:
वह एक शेल/bash है। उसे एक वास्तविक फाइलसिस्टम, एक वास्तविक fork/exec, एक पैकेज मैनेजर, डिस्क जिस पर आप लिख सकते हैं, एक नेटवर्क जिस तक आप पहुँच सकते हैं, की आवश्यकता है। उनमें से कोई भी चैट-समापन टूल स्कीमा के रूप में व्यक्त नहीं किया जा सकता है, और उनमें से कोई भी अन्य टेनेंट्स के साथ साझा-कर्नेल कंटेनर में चलाना सुरक्षित नहीं है।
प्रयोगशालाएँ सीधे इन हार्नेस (मॉडल के चारों ओर मचान) पर अपने मॉडल को पोस्ट-ट्रेनिंग दे रही हैं: शेल, फाइल एडिटर, टेस्ट रनर, एजेंट लूप ही। इसका मतलब है कि "मॉडल + हार्नेस जिस पर इसे प्रशिक्षित किया गया था" और "मॉडल + DIY मचान" के बीच का अंतर हर तिमाही बढ़ रहा है।
प्रति एजेंट एक संपूर्ण Linux मशीन, जो अविश्वसनीत कोड चला रही है जो एजेंट ने अभी आविष्कार किया है, ठीक वही वर्कलोड है जिसके लिए Firecracker बनाया गया था। ऊपर दिया गया अभिसरण कोई दुर्घटना नहीं थी।
हम एजेंटों के साथ कंप्यूट और हार्नेस पृथक्करण के आसपास अधिक प्रयोग देखना शुरू कर रहे हैं। Anthropic का Managed Agents इसका एक उदाहरण है, जहाँ एजेंट हार्नेस को सैंडबॉक्स के बगल में चलाया जा रहा है, उसके अंदर नहीं।
कुछ कंपनियाँ पूर्ण होस्टेड फाइल सिस्टम भी बना रही हैं (जैसे Archil और Mesa), एजेंटों को बेहतर खोज और भंडारण देने के लिए।
जैसे-जैसे एजेंट बेहतर होते जाएंगेते हैं, Firecracker पर निर्मित कई और दिलचस्प बुनियादी ढाँचा प्रस्ताव होंग होंगे।
आप वास्तव में एजेंट इंफ्रा प्लेटफार्मों को किसके लिए भुगतान कर रहे हैं
सामान्य "कोई भी कोड चलाएँ" सैंडबॉक्स अब एक वस्तु बन गए हैं। बुनियादी ढाँचा पूरी तरह से ओपन-सोर्स है। माइक्रोVM परत Firecracker या Cloud Hypervisor है, जो Apache 2.0 के तहत उपलब्ध है। कंटेनर-से-रूटफ्स रूपांतरण 200-लाइनों का Go स्क्रिप्ट है। प्रतिभाशाली इंजीनियर एक सप्ताहांत में एक कार्यशील सैंडबॉक्स प्लेटफॉर्म खड़ा स्थापित कर सकते हैं।
आप VM से जुड़ी चीज़ों के लिए भुगतान करते हैं। नंगा माइक्रोVM तो बस प्रवेश शुल्क है।
दिलचस्प उत्पाद सतह:
- ऑब्ज़र्वबिलिटी ही उत्पाद है, डीबग सहायता नहीं। एजेंट जो कुछ भी करता है (stdout, syscalls, फाइल राइट्स, नेटवर्क रिक्वेस्ट) एक सॉकेट के माध्यम से होस्ट-साइड कलेक्टर तक जाता है। एजेंट निर्मियों को पूर्ण सत्र रीप्ले और सबसे अच्छे उत्पाद बनाने के लिए प्रति-कार्रवाई कलाकृतियों की आवश्यकता होती है।
- रहस्य वायर पर ब्रोक किए जाते हैं, गेस्ट को कभी नहीं दिए जाते। गेस्ट कभी प्लेसहोल्डर एनव वेरिएबल्स देखता है; सैंडबॉक्स के अंदर echo $SECRET प्लेसहोल्डर लौटाता है। एक होस्ट-साइड ईग्रेस प्रॉक्सी (हर आउटबाउंड पैकेट को इसे पार करना होता है) एक स्पष्ट अनुमति सूची के विरुद्ध, प्रति-सत्र ऑडिट ट्रेल के साथ, होस्ट-साइड TAP (VM के वर्चुअल NIC का कर्नेल-स्वामित्व वाला सिरा, जिसे गेस्ट नहीं देख या संबोधित नहीं कर सकता) पर वास्तन क्रेडेंशियल को प्रतिस्थापित करता है। एजेंट मनमाना कोड चला सकता है जो उसने पाँच सेकंड पहले उत्पन्न किया था और फिर भी उस क्रेडेंशियल को बाहर नहीं निकाल सकता जो उसके पास कभी था ही नहीं।
- पहचान होस्ट पर हस्ताक्षरित होती है, एजेंट के अंदर नहीं। आउटबाउंड अनुरोध एक क्रिप्टोग्राफिक प्रति-सत्र पहचान (जिसमें Web Bot Auth हस्ताक्षर शामिल हैं, जो HTTP Message Signatures + Ed25519 पर निर्मित हैं) ले जा सकते हैं जो पैकेट के ब्रिज छोड़ने से पहले होस्ट द्वारा बनाई जाती है। हस्ताक्षर कुंजी कभी माइक्रोVM में प्रवेश नहीं करती।
- अन्य कंप्यूट रनटाइम के समान माइक्रोVM में बंडल किया जाता है। Browserbase प्रत्येक एजेंट रनटाइम को उसी होस्ट पर ब्राउज़र के साथ 1:1 जोड़ता है, अक्सर उसी माइक्रोVM में। एजेंट प्रक्रिया और Chromium के बीच भौतिक दूरी प्रभावी रूप से शून्य है: CDP कमांड (Chrome DevTools Protocol, Chrome को प्रोग्रामेटिक रूप से चलाने के लिए उपयोग किया जाने वाला JSON-ओवर-WebSocket वेबसॉकेट वायर फॉर्मेट) एक Unix सॉकेट पर जाते हैं, सेवाओवकों के नेटवर्क पर नहीं, इसलिए कार्रवाई विलंबता एकल अंकों मिलीसेकंड है। स्क्रीनकास्ट फ्रेम को सत्र रीप्ले में उतरने के लिए सार्वजनिक इंटरनेट पार नहीं करना पड़ता।
और आप यह सब Docker के शीर्ष पर सफाई से नहीं जोड़ सकते। सी सीमाएँ नहीं हैं। हमौजूद नहीं हैं। हमारा दावा है कि एजेंट रनटाइम बाजार कच्चे कंप्यूट से नहीं, बल्कि सबसे अच्छी ऑब्ज़र्वबिलिटी, रहस्य, पहचान, साझेदारी, और एक उत्पाद सतह में संक्षिप्त सह-स्थित कंप्यूट से जीता जाएगा।
देखने लायक रनटाइम विकल्प
- Bubblewrap: अनप्रिवार): अनप्रिविलेज्ड यूज़र-नेमस्पेस सैंडबॉक्सिंग। एक गैर-रूट उपयोगकर्ता sudo के बिना एक सैंडबॉक्स शुरू कर सकता है, उन्ही कर्नेल प्रिमिटिव का उपयोग करके जिनका उपयोग Flatpak डेस्कटॉप ऐप्स को सीमित करने के लिए करता है। VM से हल्का, फिर भी होस्ट कर्नेल साझा करता है, इसलिए यह वास्तविक अविश्वसनीय कोड के खिलाफ माइक्रोVMs का विकल्प नहीं है। लेकिन यह माइक्रोVM के अंदर चलाने के लिए एक शानदार नेस्टेड-आइसोलेशन परत है, या आपके अपने होस्ट पर विश्वसनीय कोड के लिए एक अच्छा विकल्प है।
- V8 आइसोलेट्स: Cloudflare Workers का मॉडल। प्रत्येक आइसोलेट एक अलग JS निष्पादन संदर्भ है जिसका अपना हीप है, सभी एक V8 प्रक्रिया को संभावित रूप से हजारों अन्य टेनेंट्स के साटा है। स्टार्टअप ~5ms है, माइक्रोVM की तुलना में दो परिमाण तेज। विश्वास सीमा V8 का अपना सैंडबॉक्स है; ऐतिहासिक रूप से इसने अच्छा प्रदर्शन किया है, लेकिन यह हाइपरवाइजर की तुलना में बहुत पतली रेखा है। दूसरी पकड़: आपको केवल Node-फ्लेवर्ड सिमैंटिक्स मिलते हैं। कोई fork, कोई exec, कोई नेटिव मॉड्यूल, सिम्युलेटेड फाइलसिस्टम नहीं। शुद्ध JS एजेंट कोड के लिए विनाशकारी; यदि pip install numpy की आवश्यकता है तो बेकार।
- gVisor: Google का Go में यूज़र-स्पेस कर्नेल। नेस्टेड वर्चुअलाइजेशन के बिना मजबूत आइसोलेशन (एक VM के अंदर चलने वाला गेस्ट VM, जिसे अधिकांश क्लाउड प्रदाता डिफ़ॉल्ट रूप से अक्षम करते हैं; gVisor को इसकी आवश्यकता नहै, इसलाई, इसलिए यह GKE में बॉक्स से बाहर काम करता है)। syscall-भारी वर्कलोड पर ~10–30% भुगतान करता है। जब हार्डवेयर वर्चुअलाइजेशन उपलब्ध नहीं है तो एक ठोस मध्य मार्ग।
- WASM सैंडबॉक्स (wasmtime, wasmer): नियतात्मक, छोटा, तेज, लेकिन पारिस्थितिकी तंत्र उथला है। WASI (WASM के लिए मानक syscall API) परिपक्व हो रहा है। "इस मनमाने Python/Node बाइनरी को चलाएँ" के लिए ड्रॉप-इन लक्ष्य नहीं है।
यदि आप अविश्वसनीय सामान्य-उद्देश्यीय कोड के लिए निर्माण कर रहे हैं: Firecracker (या Cloud Hypervisor, एक समान VMM/virtio डिज़ाइन)। यदि आप ज्ञात JS वर्कलोड के लिए निर्माण कर रहे हैं: V8 आइसोलेट्स। बाकी सब कुछ एक विशिष्ट प्रश्न का विशिष्ट उत्तर है।
बड़ी तस्वीर
Firecracker ने कंप्यूटिंग के सबसे सबसे पुराने विचारों में से एक, एक वर्चुअल मशीन, लिया और इसे सस्ता बनाने के लिए पर्याप्त हटा दिया। यह दांव लगा रहा है कि हार्डवेयर-लगाया गया आइसोलेशन इसके लायक है यदि आप इसे पर्याप्त तेज बनाया जा सके।
वह दांव हमेशा सर्वरलेस के लिए भुगतान करने वाला था। जो बदल गया है वह यह है कि "अविश्वसनीय मल्टी-टेनेंट कोड" वर्कलोड "एक वेब फंक्शन जिसे मैं सैंडबॉक्स नहीं करना चाहता" से बढ़कर "एक एजेंट जो मनमाने आदेश उत्पन्न करता है जो प्रोडक्शन को छू सकता है" हो गया है। परिधि स्थानांतरित हो गई और साझा-कर्नेल पलायन के लिए सहनशीलता "स्वीकार्य जोखिम" से "अशिप करने योग्य नहीं" हो गई।
और यह हुआ। यह एक Rust बाइनरी है, 50,000 लाइनें लंबी, जो /dev/kvm से बात करती है।
