Arch Linux अब bit-for-bit पुनरुत्पादित किए जा सकने वाले Docker इमेज उपलब्ध कराता है

• bit-for-bit पुनरुत्पादन क्षमता वाले Arch Linux Docker इमेज अब उपलब्ध हैं, और कुछ महीने पहले WSL इमेज में हासिल किया गया यही माइलस्टोन अब Docker तक बढ़ा दिया गया है
• इमेज एक समर्पित repro टैग के साथ वितरित किए जाते हैं, और पुनरुत्पादन क्षमता सुनिश्चित करने के लिए pacman keys हटा दी गई हैं, इसलिए डिफ़ॉल्ट स्थिति में pacman को तुरंत उपयोग नहीं किया जा सकता
• कंटेनर के अंदर पैकेज इंस्टॉल या अपडेट करने के लिए keyring को फिर से बनाना ज़रूरी है, और इसे pacman-key --init && pacman-key --populate archlinux से इनिशियलाइज़ किया जा सकता है
• पुनरुत्पादन क्षमता को build के बीच digest मैच और diffoci तुलना से सत्यापित किया जाता है, और इसके साथ rootFS deterministic build, timestamp normalization, और ldconfig auxiliary cache हटाने जैसे समायोजन भी लागू किए गए हैं
• पुनरुत्पादन की प्रक्रिया REPRO.md में देखी जा सकती है, और आगे चलकर rebuilder server के ज़रिए automatic rebuild और verification, build logs तथा results को सार्वजनिक करने तक यह आगे बढ़ सकता है

---

मुख्य बातें

• Arch Linux के Docker इमेज अब bit-for-bit पुनरुत्पादित किए जा सकने वाले रूप में उपलब्ध हैं, और कुछ महीने पहले WSL इमेज में हासिल किया गया यही माइलस्टोन अब Docker पक्ष तक बढ़ाया गया है
• यह इमेज समर्पित repro टैग के साथ वितरित किया जाता है, और पुनरुत्पादन क्षमता सुनिश्चित करने के लिए pacman keys को इमेज से हटाना पड़ता है, इसलिए pacman को सीधे इस्तेमाल नहीं किया जा सकता
  • उचित समाधान तैयार होने तक, इस सीमा के कारण इसे फिलहाल एक अलग टैग के रूप में उपलब्ध कराया गया है
• कंटेनर के अंदर पैकेज इंस्टॉल या अपडेट करने के लिए पहले pacman-key --init && pacman-key --populate archlinux चलाकर keyring को फिर से बनाना ज़रूरी है
  • पहली बार चलाने पर यह इंटरैक्टिव तरीके से आगे बढ़ सकता है, या इस इमेज को base के रूप में इस्तेमाल करने वाले Dockerfile के RUN स्टेटमेंट में इसे चलाया जा सकता है
  • Distrobox में इसे distrobox create -n arch-repro -i docker.io/archlinux/archlinux:repro --pre-init-hooks "pacman-key --init && pacman-key --populate archlinux" जैसे pre-init hook के रूप में संभाला जा सकता है
• इमेज की bit-for-bit पुनरुत्पादन क्षमता build के बीच digest match से जांची जाती है, और podman inspect --format '{{.Digest}}' <image> तथा diffoci तुलना से सत्यापित की जाती है
• इस Docker इमेज को पुनरुत्पादित करने का तरीका REPRO.md में देखा जा सकता है

इम्प्लीमेंटेशन और समायोजन

• Docker इमेज के लिए base rootFS को deterministic तरीके से build करना सबसे बड़ी चुनौती थी, और rootFS build system साझा करने वाले WSL इमेज के साथ उसी प्रक्रिया को दोबारा इस्तेमाल किया गया
  • संबंधित WSL commit को यहाँ देखा जा सकता है
• Docker-विशिष्ट समायोजनों में से एक के रूप में SOURCE_DATE_EPOCH सेट किया गया, और Dockerfile के org.opencontainers.image.created LABEL को भी उसी के अनुरूप बनाया गया
• built इमेज में non-determinism पैदा करने वाली ldconfig auxiliary cache फ़ाइल var/cache/ldconfig/aux-cache को Dockerfile चरण में हटा दिया गया
• docker build या podman build के समय --source-date-epoch=$SOURCE_DATE_EPOCH और --rewrite-timestamp विकल्पों का उपयोग कर timestamp normalization लागू किया गया
  • उदाहरण के तौर on etc/, etc/ld.so.cache, etc/os-release, sys/, var/cache/, var/cache/ldconfig/, proc/, dev/ के समय अलग-अलग दर्ज होने की समस्या बताई गई
• संबंधित सभी बदलावों को archlinux-docker repository के merge request diff में और विस्तार से देखा जा सकता है
• अगले चरण के रूप में Docker इमेज, WSL इमेज, और भविष्य के पुनरुत्पादित किए जा सकने वाले इमेजों के लिए server पर rebuilder स्थापित कर नियमित automatic rebuild, पुनरुत्पादन क्षमता verification, और build logs व results को सार्वजनिक करने तक पर विचार किया जा रहा है

[GN⁺]

Hacker News की राय

• ऐसा आत्मविश्वास देखना अच्छा लगता है
  मैंने लगभग 1 साल तक WSL 2 पर Arch Linux चलाया और अनुभव बहुत अच्छा रहा, फिर करीब 5 महीने तक native Arch इस्तेमाल किया और उससे भी संतुष्ट रहा
  अभी भी native Arch ही इस्तेमाल कर रहा हूँ, और अपने dotfiles को एक साफ़ filesystem पर Arch Docker image के साथ test करता हूँ
  जब end-to-end test की ज़रूरत होती है, जिसमें पूरा desktop environment सेट करना हो, तब VM में Arch चलाता हूँ
  मेरी ज़िंदगी में समस्याएँ बहुत हैं, लेकिन कम से कम Arch उनमें से एक नहीं है

  • सोच रहा हूँ कि dotfiles में बदलाव के लिए staged rollout या rollback भी है क्या
    मैं तो Prometheus metrics और health probe तक सपोर्ट करने वाला enterprise-grade dotfiles setup ढूँढ रहा था, और यह बिल्कुल वैसा ही लग रहा है
  • दूसरे distro भी support करने के लिए धन्यवाद, और इसे साझा करने के लिए भी शुक्रिया
    मुझे अब तक लगा ही नहीं था कि इसकी ज़रूरत है, लेकिन देखते ही लगा कि यह चाहिए
  • क्या आपने NixOS या flakes भी इस्तेमाल किए हैं?
    अगर किए हैं, तो उस पर आपकी प्रतिक्रिया भी सुनना चाहूँगा

• मेरा मानना है कि सारे Docker container मूल रूप से ऐसे ही होने चाहिए थे
  docker build स्टेज में apt-get update चलाना लगभग anti-pattern है

  • हाँ, लेकिन https://github.com/reproducible-containers/repro-sources-lis... इस्तेमाल करें तो यह अपवाद बन जाता है
    मैंने खुद इस्तेमाल किया है, और यह काफ़ी अच्छा चला
  • किसी भी तरफ़ जाएँ, यह पूरी तरह आरामदायक नहीं है
    अगर update नहीं करते, तो container में ज्ञात security issues जमा होते जाते हैं, और अगर update करते हैं, तो reproducibility टूट जाती है
    reproducibility निश्चित ही शानदार है और इसके security फायदे भी हैं, लेकिन container एक महीना पुराना होते ही शायद लक्ष्य से बाहर जैसा लगने लगे, और इसकी अधिकतम उम्र शायद दिन के हिसाब से सोचना ज़्यादा सही हो
  • मुझे पता है कि यह anti-pattern है, लेकिन जब software install करना हो तो विकल्प क्या है, समझ नहीं आता
    क्या मतलब यह है कि tagged source code लाओ और gcc से सब कुछ खुद compile करो?
  • इसे किसी पूर्ण नियम की तरह देखना मुझे सही नहीं लगता
    reproducible container अच्छी चीज़ है, लेकिन हर बार ज़रूरी नहीं, और बहुत से मामलों में container के अंदर apt-get चलाना ठीक है, भले reproducibility की परवाह न की जाए
  • मुश्किल इसलिए भी बढ़ जाती है क्योंकि कई distro नई version आते ही repo से पुराने version हटा देते हैं
    हालाँकि archive से लाने का तरीका तो होता ही है

• reproducible image अक्सर रोज़मर्रा में बस भावनात्मक संतोष देने वाली सुविधा लग सकती है, लेकिन एक दिन इसकी सच में ज़रूरत पड़ती है
  हमारे यहाँ भी दो image, जो एक जैसे होने चाहिए थे, अलग-अलग machine पर timestamp में 3 byte का अंतर दे रहे थे, और उसी वजह से हम गलत दिशा में bisect करते हुए पूरा एक दोपहर बर्बाद कर बैठे
  यह कोई चमकदार जीत नहीं थी, लेकिन इसकी कीमत ज़रूर थी

  • मुझे जिज्ञासा है कि आख़िर timestamp का अंतर शुरू में failure तक कैसे पहुँचा

• शायद कोई ऐसी चीज़ जोड़ना संभव होगा जो सबको बता दे कि आप CI/CD pipeline में Arch इस्तेमाल करते हैं
  जैसे Crossfit करने की बात भी सबको बता देते हैं

  • इससे यह koan याद आता है
    अगर आप किसी vegan crossfitter और Arch user से मिलें, तो वह सबसे पहले आपको क्या बताएगा?
  • मैंने कभी नहीं समझा कि कोई इस बात पर गर्व क्यों करेगा कि वह Slackware इस्तेमाल नहीं करता

• Reproducible Builds के बारे में जानकारी यहाँ है
  https://reproducible-builds.org/
  इससे क़रीब से जुड़ा Bootstrappable Builds समुदाय यहाँ है
  https://bootstrappable.org/

• सोचता हूँ कि क्या Arch या Alpine जैसे अच्छी तरह डिज़ाइन किए गए mutable operating system लंबी अवधि में NixOS जैसे सिस्टम से आगे निकल सकते हैं
  क्योंकि install scripts, declarative configuration language की तुलना में अधिक expressive होती हैं, और आम तौर पर ज़्यादा लंबी-चौड़ी भी नहीं होतीं

  • उस स्थिति में शायद Guix इस्तेमाल करना चाहिए
    वहाँ आपको declarative configuration language भी मिलती है, और साथ ही एक Turing-complete, उपयोगी programming language भी
  • strictly more powerful से ठीक-ठीक मतलब क्या है, यह जानने की उत्सुकता है

• मैंने लेख पढ़ा, और यह काफ़ी अच्छा लगा, लेकिन ऐसा लगा कि इसमें Dockerfile और docker image को थोड़ा मिलाकर बताया गया है
  Dockerfile की जगह अगर nix जैसी किसी चीज़ से सीधे image tar file बनाई जाती, तो शायद यह आसान होता; हाँ, थोड़ा niche होता, लेकिन फिर भी ज़्यादा साफ़-सुथरा लगता

• छोटी-सी बात है, लेकिन मुझे लगता है OCI Image शब्द ज़्यादा सही है
  यह podman में भी बिना किसी समस्या के चलता है

  • इस comment section में मैं थोड़ा नौसिखिया हूँ, इसलिए पूरा संदर्भ नहीं पकड़ पा रहा, लेकिन यह बात काफ़ी आँखें खोल देने वाली लगी

• जिन्होंने इसे वास्तव में संभव बनाया, उनके लिए बहुत सम्मान
  सिर्फ़ ऐसा headline बना पाने के लिए जितना समय और मेहनत लगती होगी, वह कल्पना से परे है

• पूरी तरह अलग बात, लेकिन उस page में एक animation है, जिसकी वजह से 1 सेकंड के लिए page के लगभग सभी elements लगभग 20 pixel नीचे खिसकते हैं
  सामने layout हिलता हुआ दिख रहा था, इसलिए लगा कि यह CLS को बुरी तरह बिगाड़ देगा, लेकिन असल CLS 0 था
  इससे सोचने लगा कि कहीं CLS कोई भ्रामक metric तो नहीं

  • यह जानबूझकर किए गए animation की वजह से होता है
    CLS initial rendering के समय होने वाले बदलावों को देखता है, इसलिए भले यह layout movement जैसा दिखे, यह उस तरह की चीज़ नहीं है जो CLS में गिनी जाए
  • वह layout shift नहीं है
    वह CSS transition से होने वाली movement है, यानी अपेक्षित बदलाव, इसलिए उसे layout shift के रूप में नहीं गिना जाता