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

• bit-for-bit पुनरुत्पादकता का मतलब है कि एक ही source से build करने पर, कब, कहाँ, या किसने build किया हो, परिणाम byte स्तर तक पूरी तरह एक जैसा हो
  • इसे हासिल करने के लिए timestamps, cache, metadata जैसी सभी non-deterministic चीज़ों को हटाना पड़ता है, जो build environment के अनुसार थोड़ा बदल सकती हैं
• अगर Docker image को सीधे build करके official distribution image के digest (hash) से उसकी समानता की तुलना की जाए, तो कोई भी व्यक्ति स्वतंत्र रूप से सत्यापित कर सकता है कि वितरित image के साथ छेड़छाड़ नहीं हुई है: यह supply chain security के लिहाज़ से महत्वपूर्ण है
• Arch Linux की Docker image अब bit-for-bit पुनरुत्पादक रूप में उपलब्ध है, और कुछ महीने पहले WSL image में हासिल किए गए इसी milestone को अब Docker तक बढ़ाया गया है
• यह image समर्पित repro tag के साथ वितरित की जाती है, और पुनरुत्पादकता सुनिश्चित करने के लिए image से pacman keys हटानी पड़ती हैं, इसलिए pacman को तुरंत इस्तेमाल नहीं किया जा सकता
  • उपयुक्त समाधान मिलने तक, इस सीमा के कारण इसे फिलहाल अलग tag के रूप में उपलब्ध कराया गया है
• container के अंदर package install या update करने के लिए पहले pacman-key --init && pacman-key --populate archlinux चलाकर keyring को दोबारा बनाना ज़रूरी है
  • पहली बार चलाने पर इसे interactive तरीके से किया जा सकता है, या इस image को base बनाकर Dockerfile के RUN statement में चलाया जा सकता है
  • 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 से संभाला जा सकता है
• image की bit-for-bit पुनरुत्पादकता को builds के बीच digest match से जांचा जाता है, और इसे podman inspect --format '{{.Digest}}' <image> तथा diffoci की तुलना से सत्यापित किया जाता है
• इस Docker image को पुनरुत्पादित करने का तरीका REPRO.md में देखा जा सकता है

कार्यान्वयन और समायोजन

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

[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 के रूप में नहीं गिना जाता