Apptainer - Linux के लिए application container

• सरलता/गति/सुरक्षा पर केंद्रित होकर डिज़ाइन किया गया open source container platform
  • HPC(उच्च-प्रदर्शन कंप्यूटिंग) और shared system environment के लिए अनुकूलित
• immutable single-file container image format प्रदान करता है, और encryption तथा signing का समर्थन करता है
• isolation की बजाय integrated usability पर ध्यान देता है, इसलिए cluster/server environment में GPU, high-speed network, parallel file system का सीधे उपयोग किया जा सकता है
• OCI(Open Containers Initiative) registry से सभी container लाए जा सकते हैं, और Docker compatibility को अधिकतम करता है
  • Docker Hub में मौजूद अधिकांश container को बिना बदलाव pull, run, build करने का समर्थन
• मौजूदा Singularity का नाम बदलकर Linux Foundation project में स्थानांतरित किया गया
• SIF(Singularity Image Format) आधारित single-file container के रूप में आसानी से move, deploy और share किया जा सकता है
• container के अंदर और बाहर user permissions समान रहती हैं, और default रूप से host पर अतिरिक्त privilege escalation असंभव होने वाला सुरक्षित security model लागू है
• BSD license

[galadbran]

Hacker News की टिप्पणियों में उल्लेखित unregistry लेख:
Unregistry – “docker push” को registry के बिना सीधे सर्वर पर भेजना | GeekNews

[GN⁺]

Hacker News की राय

• हमारी टीम ने सिलिकॉन डिज़ाइन/वेरिफिकेशन के compute cluster में Apptainer आज़माया, लेकिन आखिरकार पारंपरिक TCL(Lua में migrated) modules पर वापस लौट आई

  • कई समस्याएँ आईं।
    • पहली, containers एक-दूसरे को इस्तेमाल नहीं कर सकते। उदाहरण के लिए, अगर Make, GCC, Git जैसे tools अलग-अलग Apptainer में हों, तो Make के अंदर जाने पर GCC दिखाई नहीं देता
    • दूसरी, अगर outputs container के अंदर की dependencies पर निर्भर हों तो वे ठीक से काम नहीं करते। GCC Apptainer से program build करने पर built binary, Apptainer के अंदर की libraries से link हो जाती है और चल नहीं पाती, C header issues भी आए
    • तीसरी, PATH value बार-बार गड़बड़ा जाती थी, जिससे Apptainer के बाहर के ज़रूरी paths या tools दिखाई नहीं देते थे
    • कुल मिलाकर idea अच्छा था, लेकिन व्यावहारिक usability में इतनी झंझट थी कि आखिर में सीधे पुराना OS(RHEL8) इस्तेमाल करना कहीं आसान लगा
  • मैं Apptainer/Singularity को Docker जैसा मानता हूँ (बस, networking setup पूरी तरह उपलब्ध नहीं है)। ऐसी समस्याएँ पारंपरिक Docker containers में भी वैसी ही आती हैं।
    • मेरे HPC workflow में मैं Apptainer को Docker के drop-in replacement की तरह इस्तेमाल करता हूँ, और इस काम के लिए यह ठीक बैठता है
    • Apptainer का सबसे बड़ा फायदा non-root container होना है। इसकी वजह से complex networking नहीं हो पाती, लेकिन HPC जैसे multi-tenant environment में यह कहीं ज़्यादा secure है
  • अगर container app इस्तेमाल करते हुए सबसे बड़ी शिकायत यह है कि वह container की तरह behave करता है, तो यही container की मूल प्रकृति है
  • container के टुकड़ों को मिलाकर इस्तेमाल नहीं करना चाहिए। यह वैसा ही है जैसे अलग-अलग Linux distributions के binaries को मिलाकर नहीं चलाते
    • आदर्श रूप से container का उपयोग एक integrated environment में development के लिए होना चाहिए। container एक isolated environment है, इसलिए आप जो भी compile करें उसका result उसी container में होना चाहिए
    • हाँ, एक ही base image से कई images बनाकर file compatibility सुनिश्चित की जा सकती है (लेकिन तभी जब आप सभी ज़रूरी dependencies शामिल करें)

• अच्छा लग रहा है कि Apptainer पर ध्यान दिया जा रहा है। कुछ स्थितियों में यह Docker, Podman आदि से बेहतर है

  • जब एक container में कई jobs चलानी हों (जो दूसरी container technologies में recommended नहीं है)
  • HPC (और कुछ university environments)
  • single-file distribution model का support (हालाँकि delta support नहीं है)
  • अलग external server के बिना SIF file को encrypt और sign किया जा सकता है
  • मज़बूत GPU support

• Docker में भी docker save और docker load commands से single-file distribution संभव है।

  • delta support तो नहीं है, लेकिन हाल में "unregistry" नाम का एक solution HN पर link हुआ था, जो Docker Registry के बिना भी "docker push" जैसी functionality और delta application दे सकता है

• Apptainer और singularity ce दोनों HPC में आम तौर पर इस्तेमाल होते हैं। दोनों products पुराने Singularity project से निकले हैं, लेकिन पूरी तरह एक जैसे नहीं हैं

  • हम कई supercomputers(HPC) पर singularity इस्तेमाल करते हैं, और कुछ researchers local में Apptainer install करके चलाते हैं
  • हाल में Python code(matplotlib, xarray आदि) में timezone bug मिला, जिसमें singularity ce में समस्या थी लेकिन Apptainer में सब सही चला
  • नया Apptainer code base काफ़ी मिलता-जुलता है, लेकिन bug fixes ज़्यादा तेज़ी से reflect हो रही हैं। उदाहरण के लिए, singularity में user timezone को system पर overwrite कर देने से समस्या हुई
  • संदर्भ लिंक: singularity issue #3686
  • Apptainer पुराने Singularity project का fork नहीं है। Apptainer ही मूल main project है, और community vote के बाद सिर्फ नाम बदला गया। बाद में यह Linux Foundation के अंतर्गत चला गया
    • singularity ce वह मामला है जहाँ Sylabs ने मूल developer को साथ लेकर project को fork किया
    • संदर्भ: community announcement
  • फिर भी आपसी container compatibility बनी हुई है, इसलिए Apptainer में build किया हुआ Singularity में चल सकता है (और उल्टा भी)

• Apptainer लगभग Singularity ही है। संबंधित paper यहाँ है

  • अगर आप university या government cluster के shared system का उपयोग करते हैं, तो Apptainer लगभग हमेशा मिलेगा, जबकि Podman/Docker शायद ही मिलें
  • ऐसे environments में container इस्तेमाल करने के बजाय system administrator से अच्छे संबंध बनाकर उस cluster के संचालन तरीक़े को समझना ज़्यादा फायदेमंद हो सकता है
  • जिज्ञासा है कि Docker/Podman कम क्यों इस्तेमाल होते हैं, और containers से बचना बेहतर क्यों माना जाता है। क्या इसकी वजह performance है

• Flatpak OSTree से container-based approach की ओर जाना चाहता है। उसका कहना है कि maintained container tooling एक बड़ा फायदा है। लेकिन यह Apptainer से कैसे अलग है, यह जानने की उत्सुकता है

  • शायद Flatpak की खासियत यह है कि वह xdg-dbus के ज़रिए permissions को granular तरीके से control करता है और individual app sandbox control देकर उसे native जैसा इस्तेमाल करने देता है
    • Apptainer इस स्तर तक पूरी तरह अलग/isolated करता है या नहीं, इस पर यक़ीन नहीं है
    • containertoolbx जैसे tools इस्तेमाल करें तो container approaches का फ़र्क़ ज़्यादा मायने नहीं रखता
    • सच कहूँ तो tools के बीच functionality overlap बहुत है, लेकिन मुझे यह अपने-आप में ठीक लगता है

• मेरे environment में Apptainer इस्तेमाल करने का सबसे बड़ा उद्देश्य deployment, isolation, या software availability से जुड़ा नहीं है।

  • हमारे HPC cluster में हर user के लिए inode quota limit है, इसलिए बहुत सारी files वाला software (जैसे Anaconda) install करना मुश्किल होता है
  • लेकिन Apptainer image squashfs-based single file होती है, इसलिए inode quota की चिंता किए बिना कई images रखी जा सकती हैं
  • वैसे उसी software को सामान्य तरीके से install करना ज़्यादा आसान है, लेकिन quota बहुत जल्दी ख़त्म हो जाता है

• मैं Havoc की राय से सहमत हूँ। संदेश थोड़ा अस्पष्ट है: Apptainer Desktop के लिए Flatpak का विकल्प है, या server-oriented tool, यह साफ़ नहीं लगता

  • server-oriented है। लेकिन सवाल खुद भी थोड़ा अस्पष्ट है
    • Apptainer immutable, rootless containers में CLI apps चलाने के लिए है
    • इसका सबसे मिलता-जुलता tool Fedora Toolbx है
    • Apptainer का मुख्य उपयोग scientific computing tools के distribution और reuse में है। इसे root permissions के बिना इस्तेमाल किया जा सकता है, rootfs को हर container में बदला नहीं जा सकता, working directory अपने-आप mount हो जाती है, और GPU support भी अच्छा है (हालाँकि मैंने खुद test नहीं किया)
    • संदर्भ: Fedora Toolbx

• Apptainer नाम का उच्चारण थोड़ा अटपटा लगता है, जैसे कुछ ठीक नहीं बैठ रहा हो

• अगर आप developer हैं, तो संभव है कि आप isolation के लिए container tool ढूँढ रहे हों

  • मैंने Podman के आधार पर अलग-अलग development projects को isolate करने वाला एक tool बनाया था। अगर security testing या उपयोग के लिए चाहिए, तो code या blog post देख सकते हैं
  • जिज्ञासा है कि toolbox काफ़ी क्यों नहीं था
    • मेरे लिए toolbox ठीक था क्योंकि project-wise development environment install करते समय कई hidden filesystems manage नहीं करने पड़ते थे

• SLURM cluster और बिना root permissions वाले servers पर यह बहुत उपयोगी है

  • मैंने भी SLURM cluster में इसका इस्तेमाल किया है
    • इसकी official documentation अच्छी है, इसलिए शुरुआती लोगों के लिए काफ़ी है
    • लेकिन अगर fakeroot या sudo न हो, तो local में Apptainer build करके server पर सीधे transfer करना पड़ता था, जो काफ़ी झंझट वाला था