Nix, Docker के इमेज बिल्डर से बेहतर Docker इमेज बिल्डर

 (xeiaso.net)
4 पॉइंट द्वारा GN⁺ 2024-03-17 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Nix, Docker के इमेज बिल्डर से बेहतर है

  • Nix के तीन पहलू हैं: package manager, language, और operating system.
  • Nix का उपयोग करके Docker images बनाना, Docker के अपने image builder की तुलना में कुछ मामलों में बेहतर है.
  • Nix build process में ज़रूरी सभी dependencies पहले से ज्ञात कराता है, और इंटरनेट कनेक्शन के बिना भी build संभव बनाता है.

Nix के फायदे

  • Nix का उपयोग करने पर Docker images अधिक कुशलता से बनाई जा सकती हैं.
  • Nix dependencies को न्यूनतम Docker layers में बाँटता है, जिससे update के समय केवल न्यूनतम बदलाव ही लागू होते हैं.
  • अगर कई services एक ही repository में हों, तो वे Docker layers को आपस में share कर सकती हैं, जिससे दक्षता बढ़ती है.

Douglas Adams उद्धरण सेवा का उदाहरण

  • इसमें Go program को Nix से package करके Docker image में बदलने की प्रक्रिया समझाई गई है.
  • dockerTools.buildLayeredImage function का उपयोग करके layered image बनाई जा सकती है.
  • नतीजतन, एक सामान्य container image मिलती है, जिसे कहीं भी deploy किया जा सकता है.

GN⁺ की राय

  • Nix का उपयोग software development process में dependency management और build reproducibility को काफ़ी बेहतर बना सकता है.
  • Docker की तुलना में, Nix अपनी deterministic build प्रकृति के कारण लंबे समय में समय और संसाधनों की बचत कर सकता है.
  • हालांकि, Nix के नए concepts और usage beginners के लिए कुछ कठिन हो सकते हैं, और मौजूदा CI/CD pipeline में इसे integrate करने में दिक्कत आ सकती है.
  • इस तकनीक को अपनाते समय टीम के भीतर training और adaptation period की ज़रूरत होती है, साथ ही मौजूदा infrastructure के साथ compatibility पर भी विचार करना चाहिए.
  • Nix जैसी क्षमताएँ देने वाले अन्य tools में Guix शामिल है, जो deterministic package management और builds भी प्रदान करता है.

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

1 टिप्पणियां

 
GN⁺ 2024-03-17
Hacker News की राय

  • मैंने कई बार Nix को पसंद करने की कोशिश की, लेकिन अब लगता है कि हार मानने का समय आ गया है।

    • मेरे पास Nix इस्तेमाल करने वाले दो सिस्टम हैं, लेकिन उन्हें छूने से भी डर लगता है।
    • सिद्धांत रूप से Nix idempotent और deterministic है, लेकिन अगर आप dependency के हर हिस्से को ठीक से नहीं समझते, तो अजीब नतीजों और बेकार error का सामना करना पड़ सकता है।
    • documentation बहुत खराब है, और tutorial भी सिर्फ़ थोड़ा ही मदद करते हैं।
    • Docker की ताकत उसी अव्यवस्था में है; shell और package manager की बुनियादी समझ भर से आप लगभग कुछ भी आसानी से बना सकते हैं।

  • Nix और NixOS अभी उसी अवस्था में हैं, जैसे GitHub से पहले git था।

    • इसका मूल विचार मौजूदा SVN या Docker की तुलना में कहीं अधिक गंभीर computer science पर आधारित है।
    • flox के रिलीज़ होने के बाद स्थिति बदली हो सकती है, और flox इस्तेमाल में आसान है।
    • flakes और nix-command के बिना Nix का कोई खास मतलब नहीं बनता, और ये experimental हैं तथा डिफ़ॉल्ट रूप से disabled रहते हैं।
    • Nix/NixOS या ऐसा ही कुछ Docker को भी उसी अवस्था में पहुँचा देगा, लेकिन GitHub जैसा क्षण आने से पहले नहीं।

  • मैंने Darwin पर Docker image बनाने में 2-3 दिन लगाए, और यह लेख जैसे मेरा मज़ाक उड़ा रहा हो।

    • Nix मनचाही चीज़ हासिल करने के लिए बेहतरीन टूल है, लेकिन इसमें कभी-कभी ऐसे अंधेरे कोने होते हैं जो आत्मा तक सुखा देते हैं।

  • shared Docker layer क्यों उपयोगी होती हैं, इसकी व्याख्या ब्लॉग पोस्ट में नहीं है।

    • caching की वजह से वे उपयोगी हैं। जितनी ज़्यादा images एक ही layer साझा करेंगी, caching उतनी बेहतर होगी।
    • Nix पहले से ही hash के ज़रिए dependency को स्टोर करता है, इसलिए layer हमेशा एक ही version और configuration के साथ समान रहती हैं।

  • Java application के लिए Docker image को Nix से build करने का अनुभव बहुत सुखद नहीं था।

    • gradle2nix के बंद हो जाने के बाद, Gradle-आधारित Java application के लिए Docker image build करने का कोई साफ़ विकल्प नहीं है।

  • अगर आपने पहले से Nix अपनाया हुआ है, तो यह उपयोगी है, और उम्मीद है कि Nix या Guix जैसे अधिक declarative package management solution लोकप्रिय हों।

    • अगर आप Docker इस्तेमाल करते हुए धीरे-धीरे Nix अपनाना चाहते हैं, तो Dockerfile बनाए रखते हुए Nix configuration build करने का एक वैकल्पिक तरीका है।

  • एक platform engineer के रूप में मैं Nix को पसंद करना चाहता हूँ, लेकिन यह हर किसी के लिए आसान नहीं है।

    • उदाहरण के लिए, मैं devbox add python@3.11 की तरह package जोड़ना पसंद करता हूँ।

  • Nix ज़्यादातर library के लिए upstream के साथ इतना असंगत है कि इसके लिए काफ़ी packaging effort लगती है।

    • जटिल C या C++ library के मामले में, Nix के लिए सब कुछ wrap करना काम का बड़ा हिस्सा बन जाता है।

  • मैंने हाल ही में CI base image को Nix से build करने की कोशिश की, लेकिन image बहुत बड़ी निकली और linking समस्या की वजह से कुछ काम ठीक से नहीं चले।

    • multi-architecture image बनाने के लिए वास्तव में दूसरी architecture पर चलाने की कोशिश करनी पड़ती है, और यह सिर्फ़ qemu का इस्तेमाल करने वाली hardware virtualization को support करता है।

  • मैं Dagger इस्तेमाल कर रहा हूँ, और यह Docker के संस्थापकों की दूसरी कोशिश के रूप में ज़्यादातर समस्याओं को हल करता है।

    • आप pipeline उसी भाषा में लिख सकते हैं जो आप पहले से इस्तेमाल कर रहे हैं, और layer graph तथा advanced caching जैसी BuildKit की उन्नत सुविधाओं का लाभ उठा सकते हैं।