dockerc - Docker इमेज को standalone portable binary में compile करने का टूल

 (github.com/NilsIrl)
27 पॉइंट द्वारा GN⁺ 2024-03-08 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Docker इमेज को स्वतंत्र रूप से चलने वाली, portable binary में compile करने का टूल
  • उपयोगकर्ताओं को docker run, pip install, npm i जैसे कमांड के बिना चलने योग्य binary दी जा सकती है

विशेषताएँ

  • Docker इमेज को portable binary में compile करता है.
  • root permission की आवश्यकता नहीं वाले container.
  • MacOS और Windows support (QEMU का उपयोग) : नियोजित
  • x86_64 support (arm64 support नियोजित)
  • arguments support
  • -e का उपयोग करके environment variable सेट करने का support.
  • -v का उपयोग करके volume सेट करने का support.

उपयोग का तरीका

  • नवीनतम release से dockerc install करें.
  • Docker Hub की इमेज या local Docker daemon storage की इमेज का उपयोग करके output binary बनाएं.
  • बनी हुई binary को सामान्य binary की तरह call किया जा सकता है.
  • -e और -v options को docker run की तरह ही specify किया जा सकता है.
  • container के भीतर चल रही network services तक सीधे पहुंचा जा सकता है, -p specify करने की आवश्यकता नहीं है.
  • इमेज loading के लिए Skopeo का उपयोग होता है, अन्य locations के लिए संबंधित documentation देखें.

GN⁺ की राय

  • dockerc ऐसा टूल है जो Docker की usability को काफी बेहतर बना सकता है, क्योंकि यह उपयोगकर्ताओं को जटिल installation प्रक्रिया के बिना application चलाने देता है. यह खासकर non-technical users के लिए बहुत उपयोगी हो सकता है.
  • Docker इमेज को binary में compile करने की क्षमता distribution और deployment को सरल बनाती है, जिससे developers और system administrators को समय की बचत और अधिक efficiency मिलती है.
  • हालांकि, इस तकनीक को व्यापक रूप से अपनाने के लिए security, performance और compatibility से जुड़ी समस्याओं का पर्याप्त समाधान होना चाहिए. उदाहरण के लिए, यह सत्यापित करना जरूरी है कि compiled binary मूल Docker इमेज जितनी सुरक्षित है या नहीं, और क्या वह सभी systems पर सुचारु रूप से काम करती है.
  • Docker जैसी functionality देने वाले अन्य projects में Podman भी शामिल है, जो root permission के बिना container चलाने की सुविधा देता है.
  • dockerc अपनाते समय मौजूदा Docker workflow के साथ integration, इमेज को update और manage करने के तरीके, और compiled binary के size तथा performance पर विचार करना चाहिए. इस तकनीक का लाभ deployment को सरल बनाना और उपयोग को आसान करना है, लेकिन दूसरी ओर compile process के दौरान होने वाले overhead और संभावित compatibility issues पर सावधानी से विचार करना चाहिए.

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

2 टिप्पणियां

 
cosine20 2024-03-11

ओह, यह काफ़ी दिलचस्प है।
 
GN⁺ 2024-03-08

Hacker News की राय

  • यह सच में बहुत शानदार है।

    • एक यूज़र अपने Docker को और ज़्यादा deployable बनाने की कोशिश कर रहा है। अभी वह QEMU container के अंदर Docker container के अंदर Python environment में एक साधारण Python script से click को automate कर रहा है और netcat का इस्तेमाल कर रहा है। फ़ाइल का आकार 20GB है, जो आज के मानकों से काफ़ी हल्का है।

  • पहले मैं nix-bundle¹ या उसके आधिकारिक समकक्ष nix bundle² का इस्तेमाल करता था और उसकी सिफारिश भी करता था।

    • ये टूल Docker image को सीधे manage करने वाले चरण को छोड़ने देते हैं। खासकर तब उपयोगी होते हैं जब Docker image बनाना मुश्किल हो, या वह प्रक्रिया किसी भूली-बिसरी कला जैसी लगती हो।
    • nix bundle सिर्फ भारी-भरकम executable ही नहीं, बल्कि Docker image, AppImages, और कुछ अन्य image/executable formats भी बना सकता है।

  • बिल्ट-इन OS के साथ portable executable पर वापस लौटना वास्तव में अच्छा है।

    • "मेरे कंप्यूटर पर तो चलता है" वाली बात को यह troubleshooting के एक नए स्तर के नरक तक पहुँचा देता है। फिर भी, प्रोजेक्ट शानदार है।

  • एक यूज़र इंतज़ार कर रहा है कि लोग उन Docker containers को बनाने वाले Dockerfiles भेजना शुरू करें जिनमें ये चीज़ें चलाई जाएँगी।

  • इसमें कोई महान ब्रह्मांडीय विडंबना है।

    • executable फ़ाइल ही माँगने वाले, बिना build या install किए चलाने वाले सेक्शन के तुरंत बाद इस प्रोजेक्ट को build करने के लिए zig का मंत्र आता है।

  • यह शानदार प्रगति है, Nils! AGI House में बात करने के बाद से इस प्रोजेक्ट की प्रगति देख कर खुशी हुई।

    • dockerc, Zig + crun + squashfs/overlayfs का उपयोग करता है। Nils (लेखक) ने इस thread में और जानकारी साझा की है।

  • अभी भी अलग-अलग architecture के लिए अलग चीज़ों की ज़रूरत है।

    • इस बिंदु पर मेरा मानना है कि static compile करके virtual file system शामिल करना बेहतर होगा। यह मूल रूप से वैसा ही है जैसा Sun ने 90 के दशक में बनाया था।

  • अच्छा विचार! यह वास्तव में कैसे काम करता है?

    • एक यूज़र का अनुमान है कि यह custom loader + Docker + image को executable binary में wrap करने जैसा है।

  • rant cartoon का इस्तेमाल अच्छा लगा।

    • अगला rant cartoon शायद यह होगा: "जब executable चलाओ, तो उस application वाली window खुलनी चाहिए।"

  • इसका मतलब क्या है? क्या इससे यूज़र Ruby install किए बिना portable Ruby executable distribute कर सकते हैं?