Docker का शाप
डेवलपर्स और ऑपरेटर Docker के लाभों—deployments को सरल बनाने—और server software के लिए इसे एक blunt packaging tool के रूप में बढ़ते उपयोग—के बीच संतुलन पर विचार करते हैं। कई लोग reproducible setups, आसान experimentation, और “works on my machine” समस्याओं को घटाने के लिए containers की सराहना करते हैं, लेकिन image provenance, opaque configuration, root-by-default security, और कई अलग base systems को patch करने के बोझ की आलोचना करते हैं। traditional distro packages, Nix, VMs, और अधिक अनुशासित container practices जैसे alternatives को dependencies और long‑term maintenance पर नियंत्रण वापस पाने के तरीकों के रूप में उठाया जाता है.
आलोचना का दायरा: वितरण बनाम परिनियोजन के रूप में Docker
- कई टिप्पणीकार कहते हैं कि लेख वास्तव में इस बारे में है कि Docker का दुरुपयोग वितरण तंत्र के रूप में किया जा रहा है (एक पैकेज फ़ॉर्मेट की तरह), न कि परिनियोजन के लिए कंटेनरों के बारे में।
- शिकायत: केवल Docker image (या docker‑compose stack) भेजना निर्भरताओं को छिपा देता है, और मौजूदा infra (databases, backups, monitoring, auth, TLS) के साथ एकीकरण को कठिन बना देता है।
- बचाव: जटिल apps के लिए (जैसे DB, cache, queues जैसी कई services),
docker compose upसॉफ़्टवेयर को आज़माने और चलाने की बाधा को नाटकीय रूप से कम कर देता है, खासकर hobbyists और छोटी teams के लिए।
विश्वास, provenance, और “इंटरनेट से random images”
- चिंता: लोग अक्सर third‑party images को बिना ज़्यादा सोचे-समझे चला देते हैं—maintenance, support, update guarantees, architecture support, या long‑term availability पर कम ध्यान देते हुए।
- कुछ लोग तर्क देते हैं कि “official” org images (जैसे Bitnami, linuxserver.io) भी, अगर आपके पास business relationship या स्पष्ट guarantees नहीं हैं, तो व्यावहारिक रूप से अभी भी इंटरनेट के random binaries ही हैं।
- दूसरे जवाब देते हैं कि सभी software stacks में trust शामिल होता है (distro, hardware, cloud), और containers बस trust की एक और layer हैं।
सुरक्षा, root, और updates
- व्यापक रूप से नोट की गई समस्या: containers को root के रूप में चलाना सामान्य मान लिया गया है, और non‑root/read‑only images बनाना दर्दनाक है, इसलिए असुरक्षित defaults जीत जाते हैं।
- यह सवाल उठाया गया कि organizations वास्तव में अनेक containers में base image और library security updates कैसे manage करती हैं; कुछ कहते हैं CI rebuilds + scanners और tools (जैसे Watchtower‑style) इसे एक “solved” समस्या बनाते हैं, जबकि अन्य कहते हैं कि व्यवहार में अधिकांश लोग इसे अच्छी तरह नहीं करते।
कॉन्फ़िगरेशन, filesystems, और networking
- बार-बार आने वाले pain points:
- File/volume mounts और UID mapping झंझट वाले हैं; containers के अंदर/बाहर files copy करना अक्सर permissions पर टूट जाता है।
- Docker networking और Docker Compose जटिल hosts पर fragile हो जाते हैं; कुछ लोगों ने podman networking को भी समस्याग्रस्त बताया।
- Config generators/entrypoint scripts और multi‑layered config (Helm → env vars → image → app) debugging को बहुत opaque बना सकते हैं।
विकल्प और व्यापक packaging बहस
- Nix/NixOS को reproducibility, dependency isolation, और supply‑chain control के लिए बार-बार बेहतर उत्तर के रूप में उद्धृत किया गया; दूसरे नोट करते हैं कि इसमें भी binary blobs और complexity बनी रहती है।
- कुछ लोग पारंपरिक OS packaging, static binaries (Go, musl), या simple “single EXE/zip” मॉडल (जैसा Windows पर है) को Docker से अधिक साफ़-सुथरा मानते हैं।
- Meta-theme: Docker को pre‑container chaos की तुलना में एक बहुत बड़ा व्यावहारिक सुधार भी माना जाता है और साथ ही एक ऐसा tool भी, जो laziness, complexity, और opaque stacks को मज़बूत करता है।