Docker कंटेनरों के 10 साल

 (cacm.acm.org)
11 पॉइंट द्वारा GN⁺ 2026-03-08 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • 2013 में पहली रिलीज़ के बाद से डेवलपर्स के applications को build, deploy और run करने के तरीकों को मूल रूप से बदलने वाले Docker की तकनीकी विकास यात्रा पर केंद्रित ACM पेपर, जो सरल CLI के पीछे छिपे दशकों के systems research को व्यवस्थित करता है
  • Linux namespace का उपयोग करके virtual machine के बिना भी process isolation हासिल करने का तरीका Docker की मुख्य तकनीकी नींव है, और 2001 से क्रमिक रूप से जोड़े गए 7 प्रकार के namespace को मिलाकर lightweight container लागू किए गए
  • macOS और Windows support के लिए library virtual machine monitor (HyperKit) को desktop app के भीतर एम्बेड करने वाली उलटी सोच की architecture अपनाई गई, जिसमें पारंपरिक hypervisor तरीके के बजाय user process के अंदर Linux चलाया गया
  • अब यह ARM·RISC-V जैसे heterogeneous hardware और AI workloads को support करता है, और cloud·desktop·edge में मानक development infrastructure के रूप में स्थापित हो चुका है
  • AI workloads के उभार के साथ GPU dependency management एक नई चुनौती बनकर उभरा है, और CDI(Container Device Interface) के ज़रिए GPU support तथा TEE(विश्वसनीय execution environment) integration सहित Docker का विकास जारी है

तकनीकी उत्पत्ति

  • 2000 के दशक की शुरुआत में Linux distributions पर असंख्य dependencies को manually install करना और software को सीधे compile·configure करना आम बात थी, और 2010 में cloud computing के उभार के साथ यह प्रक्रिया और भी जटिल हो गई
  • Docker ने इसे सरल बनाते हुए डेवलपर्स को application और उसकी सभी dependencies को filesystem image ("container") के रूप में package करने की सुविधा दी, ताकि Docker installed किसी भी machine पर उसे चलाया जा सके
  • virtual machine के विपरीत, पूरे operating system की installation के बिना सिर्फ कुछ commands से इसे चलाया जा सकता है

सामान्य workflow

  • डेवलपर Dockerfile लिखता है, जो shell syntax आधारित step-by-step build process को परिभाषित करता है
    • Python website उदाहरण: FROM python:3 से शुरू करके dependency installation, code copy, port expose और run command तक सब कुछ एक ही file में लिखा जाता है
  • docker build से container image बनाई जाती है और docker push से Docker Hub पर push की जाती है
  • docker run -v data:/app/data -p 80:80 की तरह data volume mount और network port expose सेट करके इसे चलाया जाता है
  • 2013 के बाद CLI काफ़ी विस्तृत हो गई और backend पूरी तरह redesign हुआ, लेकिन Dockerfile लिखना → docker build → docker run वाला मूल workflow लगातार एक जैसा बना रहा
  • GitHub पर public repositories के root में मौजूद Dockerfile की संख्या 34 लाख से अधिक पाई गई

अंदरूनी कार्यप्रणाली: Linux namespace

  • OS kernel process memory को isolate करता है, लेकिन filesystem, config files, dynamic libraries जैसे कई system resources साझा रहते हैं
    • एक ही machine पर टकराती dynamic library आवश्यकताओं वाले कई apps install करना बहुत कठिन होता है
    • network port conflict जैसी process-से-process अनचाही दखलअंदाज़ी हो सकती है
  • हर app को अलग virtual machine (VM) में चलाने से यह समस्या हल होती है, लेकिन duplicate kernel·filesystem·cache·bridge network आदि के कारण यह बहुत भारी पड़ता है
    • क्योंकि हर guest OS स्वतंत्र रूप से चलता है, इसलिए storage·memory deduplication भी कठिन होती है
  • 1978 के Unix v7 का chroot() अलग root filesystem की अनुमति देता था, लेकिन multiple app filesystems को compose करने का support नहीं था
  • Nix और Guix app-विशिष्ट directory repackaging + dynamic linking से इसका समाधान करते हैं, लेकिन proprietary software पर इन्हें लागू करना कठिन है और network port conflict की समस्या भी हल नहीं होती
  • Docker ने Linux namespace को चुना: हर process shared resources जैसे files·directories तक पहुँचने के तरीके को अलग-अलग नियंत्रित कर सकती है
    • उदाहरण: अलग namespace में मौजूद दो processes /etc/passwd को क्रमशः /alice/etc/passwd और /bob/etc/passwd के रूप में अलग तरह से interpret कर सकती हैं
    • namespace सिर्फ resource को खोलते समय लागू होता है, उसके बाद file descriptor बिना अतिरिक्त overhead के सामान्य kernel resource की तरह काम करता है
  • namespace introduction timeline
    • 2001 Linux 2.5.2: mount namespace
    • 2006 Linux 2.6.19: IPC namespace
    • 2007 Linux 2.6.24: network stack namespace
    • कुल 7 प्रकार के namespace supported
  • Plan 9 के विपरीत, namespace शुरुआत से design नहीं किए गए थे बल्कि क्रमिक रूप से जोड़े गए, इसलिए वे low-level थे और उपयोग में कठिन थे
  • FreeBSD और Solaris की समान क्षमताएँ भी व्यापक उपयोग तक नहीं पहुँच सकीं
  • 2013 में Docker का मुख्य योगदान: VM की भारी isolation और OS के मूल building blocks की usability के बीच एक व्यावहारिक संतुलन ढूँढना

Docker की Linux container execution संरचना

  • Docker की संरचना client-server प्रकार की है, जिसमें host पर चलने वाला server daemon (dockerd) और RESTful API के माध्यम से request भेजने वाला CLI client शामिल है
  • 2015 के आसपास monolithic daemon को तोड़कर specialized components में reorganize किया गया
    • BuildKit: filesystem image assemble करना
    • containerd: image को running container के रूप में instantiate करना और network·storage resources को manage करना

container image

  • docker build call होने पर Dockerfile के executable files और data को दर्शाने वाली layered filesystem image बनती है
    • सबसे निचली layer: Debian या Alpine Linux जैसी OS distribution (या tar archive से manually assembled)
    • उसके बाद की layers: Dockerfile के अलग-अलग commands के execution से बने filesystem differences
  • इसे content-addressed storage system में store किया जाता है: filesystem image के hash को key के रूप में manage किया जाता है
    • efficient deduplication, immutability की गारंटी, और hash के ज़रिए tampering verification
  • 2016 में Open Container Initiative(OCI) ने image format को standardize किया, और इसके कई independent implementations मौजूद हैं
  • Linux filesystems overlayfs, btrfs, ZFS का उपयोग करके copy-on-write layers को कुशलतापूर्वक snapshot·clone किया जाता है
  • stargz storage snapshotter के माध्यम से image lazy-pulling support भी उपलब्ध है

container instance

  • docker run call होने पर OCI image से namespace द्वारा isolated process ("container") बनाने के लिए system resources allocate किए जाते हैं
  • containerd हर container के लिए आवश्यक namespace को dynamically configure करते हुए ये काम करता है:
    • resource isolation और I/O speed limiting के लिए process cgroups (control groups) परिभाषित करना
    • container के भीतर local network port को host interface के externally exposed port पर remap करना
    • persistent app state के लिए host filesystem के mutable storage volume को attach करना
    • PID namespace से container की process tree को isolate करना
    • user namespace से container के local UID को host के दूसरे UID पर map करना (उदाहरण: container के भीतर UID 1000 → host पर UID 12345 या 23456)
  • namespace configuration में थोड़ा overhead होता है, लेकिन यह पूरी Linux VM spawn करने से बहुत कम है, और अधिकतर मामलों में 1 सेकंड से कम रहता है
  • Linux kernel बंद किए गए containers को सामान्य processes की तरह garbage collect करता है

Linux से आगे: macOS और Windows support

  • client-server architecture की वजह से CLI secure network connection के माध्यम से remote Docker instance को command भेज सकती है
  • 2015 में Docker Linux development में व्यापक रूप से अपनाया जा चुका था, लेकिन macOS/Windows डेवलपर्स के लिए Linux containers चलाने में usability barrier सामने आया
    • अधिकांश डेवलपर्स macOS/Windows को primary development environment के रूप में इस्तेमाल करते हैं, लेकिन Docker filesystem images सिर्फ Linux kernel पर ही चल सकती हैं
    • public cloud के उभार के साथ deployment environment के लिए Linux को प्राथमिकता मिली

Docker for Mac application बनाना

  • मुख्य बाधा: Linux वर्ज़न Docker के आदी डेवलपर्स के लिए यह बिना अतिरिक्त सेटअप के काम करना चाहिए, और वही Docker image चला पाना चाहिए
  • मौजूदा तरीके (Linux को desktop OS के बगल में अलग से चलाना) को उलटते हुए, hypervisor को macOS/Windows user-space app के अंदर एम्बेड किया गया और उसके भीतर Linux चलाया गया
    • unikernel शोध से प्रेरणा: इसने साबित किया कि OS components को किसी बड़े application के भीतर लचीले ढंग से एम्बेड किया जा सकता है
  • HyperKit: Intel CPU के hardware virtualization extensions का उपयोग करके सामान्य user process में Linux kernel चलाने वाला library VMM
    • एम्बेड किया गया Linux kernel Docker daemon चलाता है, जो containers को मैनेज करता है और सामान्य Docker server endpoint की तरह काम करता है
    • Linux management की सभी बारीकियां desktop app के भीतर छिपी रहती हैं → desktop का docker build और docker run एम्बेडेड Linux instance तक पहुँचाए जाते हैं और "बस काम करते हैं"
  • यह तरीका Podman जैसे दूसरे container systems ने भी अपनाया, और macOS/Windows पर containers चलाने का मानक तरीका बन गया

LinuxKit: एम्बेडेड कस्टम Linux distribution

  • एक कस्टम Linux distribution जिसे standalone नहीं, बल्कि दूसरे apps के component के रूप में एम्बेड होने के लिए डिज़ाइन किया गया
  • app startup time को न्यूनतम रखने के लिए Docker container चलाने के लिए ज़रूरी न्यूनतम components के साथ custom user space बनाया गया
  • हर single component को container के भीतर चलाया जाता है, इसलिए boot के समय इस्तेमाल होने वाले root namespace में कुछ भी नहीं चलता
  • Docker containers द्वारा उपयोग किए जाने वाले वही copy-on-write filesystem और network namespaces इस्तेमाल किए गए
  • LinuxKit + HyperKit संयोजन से native macOS process के लगभग बराबर गति पर Linux process boot किए जा सकते थे
  • 2016 में Docker for Mac और Windows app के रूप में जारी किया गया

Networking समस्याएं और SLIRP समाधान

  • एम्बेडेड Linux container से macOS/Windows तक networking connection उम्मीद से कहीं अधिक मुश्किल समस्या साबित हुआ
  • पुराना Ethernet bridging तरीका जटिल network management मांगता था, और enterprise desktops के firewall और virus checker इसे संभावित दुर्भावनापूर्ण traffic मान लेते थे, जिससे beta users से हज़ारों bug reports आए
  • SLIRP समाधान: 1990 के दशक के मध्य में Palm Pilot PDA को इंटरनेट से जोड़ने के लिए पहली बार इस्तेमाल किया गया टूल
    • container के TCP handshake के समय Ethernet frames shared memory के ज़रिए virtio protocol से host तक भेजे जाते हैं
    • MirageOS की unikernel libraries का उपयोग करके Linux networking requests को macOS/Windows native socket calls में बदला जाता है
    • OCaml में लिखा user-space TCP/IP stack vpnkit host OS पर इन्हें प्राप्त करके macOS connect() syscall कॉल करता है
    • VPN policy के नज़रिए से बाहर जाने वाला traffic किसी अलग machine से नहीं, बल्कि Docker app से उत्पन्न हुआ माना जाता है
  • 2016 beta test में vpnkit तैनात करने के बाद enterprise users की bug reports 99% से अधिक घट गईं
  • बाद में SLIRP तरीका serverless cloud क्षेत्र में भी अपनाया गया, यानी पुरानी dial-up networking तकनीक का इस्तेमाल नई container management समस्याओं को हल करने में हुआ

Inbound network traffic का प्रबंधन

  • जब Linux container किसी port पर listen करता है, तो CLI में स्पष्ट रूप से request न किया जाए तो वह अपने-आप इंटरनेट पर expose नहीं होता (उदाहरण: docker run -p 80:80 nginx)
  • आदर्श user experience: container port सीधे desktop IP पर दिखाई दे, ताकि browser से http://localhost:8080 पर पहुँचा जा सके
    • VMware Fusion जैसे पुराने desktop virtualization tools localhost की जगह अस्थायी intermediate IP expose करते थे
  • LinuxKit kernel में custom eBPF program इंस्टॉल किया गया → desktop host के अनुरूप listening socket बनने का trigger → port forwarder सक्रिय
  • नतीजा: Mac पर Linux container चलाते ही तुरंत localhost से access संभव, बिल्कुल native Linux machine जैसा developer experience

Storage

  • डेवलपर्स को code लोकल पर edit करते हुए container के भीतर वही code और tests चलाने होते हैं
  • Linux पर docker run -v /host:/container के जरिए bind mount से live file access मिलता है
  • macOS और Windows में अलग kernel होने की वजह से bind mount काम नहीं करता
    • Docker, KVM hypervisor से निकले virtio-fs shared memory protocol का उपयोग करके filesystem operations को host तक भेजता है (FUSE request format में)
    • host इन requests को प्राप्त करके संबंधित open, read, write syscalls चलाता है
  • डेवलपर का code और data host filesystem पर ही बना रहता है, इसलिए Apple Time Capsule या Spotlight जैसे backup और search tools उससे access कर सकते हैं

Windows Services for Linux (WSL)

  • 2017 में Microsoft ने WSL जारी किया: Windows पर सीधे Linux apps चलाने का तरीका
    • पहला वर्ज़न virtualization के बजाय Linux binaries के system calls को Windows system calls में dynamic translation करने वाले library OS तरीके पर आधारित था
    • यह कई apps के लिए सफल रहा, लेकिन Docker containers चलाने के लिए ज़रूरी system calls का पर्याप्त समर्थन नहीं था
  • 2018 में WSL2 जारी हुआ: Docker for Mac की तरह background में पूरा Linux VM चलाने के रूप में इसे फिर से डिज़ाइन किया गया
    • WSL2 Docker, LinuxKit WSL distribution के भीतर daemon और user containers चलाता है
    • Docker API और network port forwarding का प्रबंधन Windows खुद और दूसरी Linux distributions के लिए करता है
  • Docker containers के cross-platform विकास को संभव बनाने वाली प्रमुख architecture: पारंपरिक रूप से "kernel-only code" को user-space libraries के रूप में दोबारा उपयोग करके दूसरे apps में एम्बेड करने वाला library OS approach
  • इस architecture की सफलता का प्रमाण यही है कि यह अदृश्य होते हुए भी सर्वव्यापी है: लाखों डेवलपर्स रोज़ Docker का उपयोग करते हैं बिना इस चिंता के कि वह किस OS पर चल रहा है

नया developer workflow: multiple CPU architectures

  • Docker के शुरुआती दौर में ज़्यादातर cloud workloads Intel architecture पर आधारित थे
  • 2018 में Amazon Graviton ARM processor और 2020 में Apple M1 ARM CPU आने से स्थिति बदली
    • ARM पर workloads चलाने से कम लागत और बेहतर performance मिल सकती है
  • एक ही Docker image में Intel, ARM, POWER और RISC-V जैसी multiple CPU architectures का समर्थन ज़रूरी हो गया
  • server side पर OCI image format को multiarch manifests तक विस्तारित किया गया
  • एक single host पर कई CPU architectures के लिए images build करने हेतु Linux की binfmt_misc सुविधा का उपयोग किया गया
    • QEMU के जरिए ARM और Intel binaries के बीच पारदर्शी translation
    • overhead मुख्य रूप से build चरण में ही आता है, जबकि तैयार multiarch images किसी भी host पर native execution देती हैं
  • Apple ने Rosetta के माध्यम से CPU instruction set translation के लिए hardware और software support दिया → इसे Docker architecture में आसानी से जोड़ा गया
  • आज Intel और ARM containers को साथ-साथ चलाना एक सामान्य developer workflow है

Trusted Execution Environment (TEE) के जरिए secrets management

  • कंटेनर environment में password या API key जैसी secrets management हमेशा एक चुनौती रही है
    • इन्हें filesystem image में bake किए बिना dynamically inject करना चाहिए
  • Docker socket forwarding को support करता है, जिससे local domain socket को container में mount किया जा सकता है
    • Docker for Mac/Windows के मामले में Linux VM तक socket forwarding होता है
    • ssh-agent जैसे key management system को key सीधे expose किए बिना container के भीतर इस्तेमाल किया जा सकता है
  • socket forwarding बुनियादी सुरक्षा स्तर देता है, लेकिन बढ़ती software supply chain में malware के खिलाफ और अधिक defense layers की ज़रूरत है
  • hypervisor protection को सीधे container runtime में लागू करके cross-container protection का स्तर बेहतर किया गया
  • Trusted Execution Environment (TEE): modern CPU की hardware capability के जरिए ऐसे confidential VMs बनाए जा सकते हैं जो host OS से भी secret data की रक्षा कर सकें
    • app, kernel, और hypervisor boundaries के पार data access restrictions लागू किए जा सकते हैं
    • लेकिन TEE को configure और use करना, OS virtualization की तरह, management complexity रखता है
  • Confidential Containers working group ऐसे app विकसित कर रहा है जो TEE के भीतर चलते हैं और Docker से managed होते हैं
    • Docker CLI desktop के local TEE से host के रास्ते remote cloud TEE environment तक encrypted message forwarding करता है
    • developer बिना साइट पर जाए भी sensitive cloud environment में authenticate कर सकते हैं, और credentials desktop enclave में सुरक्षित रूप से store रहते हैं

AI workloads के लिए GPGPU support

  • AI workloads के उभार के साथ एक बिल्कुल नई चुनौती सामने आई: ज़्यादातर machine learning workloads GPU पर चलते हैं
  • मुख्य समस्या: GPU workloads को exactly matching kernel GPU driver और user-space libraries चाहिए, जबकि कई container एक ही shared kernel पर चलते हैं
    • अगर दो apps एक ही kernel GPU driver के अलग-अलग versions मांगें, तो वही मूल conflict पैदा होता है जिसे Docker शुरू में हल करना चाहता था
  • मार्च 2023 से Docker CDI(Container Device Interface) को support कर रहा है
    • container startup के समय filesystem image को customize किया जाता है
    • GPU device files और GPU-specific dynamic libraries को bind mount किया जाता है और ld.so cache फिर से generate किया जाता है
  • CDI किसी खास GPU class या vendor के भीतर image portability सुनिश्चित करता है, लेकिन अलग-अलग OS और hardware brands के बीच यह पूरी तरह seamless नहीं है
    • CDI जिन dynamic libraries को जोड़ता है वे अलग-अलग API define करती हैं, इसलिए container के पारंपरिक interface, यानी stable Linux system call ABI, जैसा कोई समकक्ष यहां नहीं है
    • Nvidia GPU के लिए बना app Apple M-series CPU पर आसानी से क्यों नहीं चलता: GPU virtualization support अभी अलग-अलग hardware के बीच vector instructions को translate करने जितना mature नहीं हुआ है
  • container community और GPU manufacturers के साथ मिलकर GPU-related dependencies को manage करने के ज़्यादा flexible और सुरक्षित तरीके विकसित किए जा रहे हैं
  • उम्मीद है कि portable interface initiative किसी सहमति तक पहुँचेगा

निष्कर्ष

  • Docker की शुरुआत 2013 में इस लक्ष्य के साथ हुई थी कि developers के लिए app को build, share और run करना आसान बनाया जाए
  • आज यह standard cloud और desktop development workflows में गहराई से integrated है, और दुनिया भर में लाखों developers रोज़ इसका इस्तेमाल करते हैं, साथ ही हर महीने अरबों requests संभाली जाती हैं
  • interoperability के लिए standards बनाने वाली सक्रिय और विविध open source community को बनाए रखना एक लगातार लक्ष्य रहा है
    • CNCF(Cloud Native Computing Foundation) कई core components का steward है
    • Open Container Initiative(Linux Foundation का हिस्सा) image format का steward है
  • आज इन तत्वों के कई implementations सक्रिय हैं, और cloud, desktop, तथा automotive, mobile, और spacecraft जैसे edge environments में इनकी deployment बढ़ रही है
  • 2025 तक सामान्य developer workflow में continuous testing और deployment, IDE language servers, और agentic coding के जरिए AI support शामिल हैं
  • Docker के नज़रिए से core "build and run" workflow 10 साल पहले जैसा ही है, लेकिन विभिन्न environments में friction कम करने के लिए system support काफ़ी मज़बूत हुआ है
  • लक्ष्य Docker को ऐसा अदृश्य साथी बनाना है जो developers को तेज़ी से code deploy करने में मदद करे, और जिसे modern AI coding workflows के अनुसार scale करने योग्य बनाया गया हो

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.