ตอนนี้ Arch Linux มีอิมเมจ Docker ที่ทำซ้ำได้แบบ bit-for-bit แล้ว

 (antiz.fr)
4 คะแนน โดย GN⁺ 5 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • อิมเมจ Docker ของ Arch Linux ที่มี ความสามารถในการทำซ้ำได้แบบ bit-for-bit พร้อมใช้งานแล้ว โดยขยายหมุดหมายเดียวกันที่ทำได้กับอิมเมจ WSL เมื่อไม่กี่เดือนก่อนมาสู่ Docker
  • อิมเมจถูกเผยแพร่ด้วย แท็ก repro โดยเฉพาะ และเพื่อรับประกันความสามารถในการทำซ้ำได้จึงมีการลบคีย์ pacman ออก ทำให้ในสถานะเริ่มต้นไม่สามารถใช้ pacman ได้ทันที
  • หากต้องการติดตั้งหรืออัปเดตแพ็กเกจภายในคอนเทนเนอร์ จำเป็นต้อง สร้าง keyring ใหม่ และสามารถเริ่มต้นได้ด้วย pacman-key --init && pacman-key --populate archlinux
  • ความสามารถในการทำซ้ำได้ตรวจสอบด้วย digest ที่ตรงกัน ระหว่างการบิลด์และการเปรียบเทียบด้วย diffoci พร้อมมีการปรับแต่งอย่างการบิลด์ rootFS แบบกำหนดได้แน่นอน การทำให้ timestamp เป็นมาตรฐาน และการลบแคชเสริมของ ldconfig
  • ขั้นตอนการทำซ้ำสามารถดูได้ใน REPRO.md และในอนาคตอาจต่อยอดไปสู่การรีบิลด์และตรวจสอบอัตโนมัติผ่าน เซิร์ฟเวอร์ rebuilder รวมถึงการเปิดเผยบันทึกการบิลด์และผลลัพธ์

เนื้อหาสำคัญ

  • ตอนนี้ อิมเมจ Docker ของ Arch Linux ถูกแจกจ่ายในรูปแบบที่ ทำซ้ำได้แบบ bit-for-bit แล้ว โดยเป็นการขยายหมุดหมายเดียวกันที่ทำได้กับอิมเมจ WSL เมื่อไม่กี่เดือนก่อนมายังฝั่ง Docker
  • อิมเมจนี้เผยแพร่ผ่าน repro tag โดยเฉพาะ และเพื่อรับประกันความสามารถในการทำซ้ำได้จำเป็นต้องลบ คีย์ pacman ออกจากอิมเมจ จึงไม่สามารถใช้ pacman ได้ทันที
    • ข้อจำกัดนี้ทำให้ในช่วงนี้ยังต้องเผยแพร่เป็นแท็กแยกไปก่อน จนกว่าจะมีวิธีแก้ที่เหมาะสม
  • หากต้องการติดตั้งหรืออัปเดตแพ็กเกจภายในคอนเทนเนอร์ ต้องรัน pacman-key --init && pacman-key --populate archlinux ก่อนเพื่อ สร้าง keyring ใหม่
    • ในการรันครั้งแรกอาจทำแบบโต้ตอบได้ หรือจะรันในคำสั่ง RUN ของ Dockerfile ที่ใช้อิมเมจนี้เป็นเบสก็ได้
    • ใน Distrobox สามารถจัดการผ่าน pre-init hook ได้ เช่น distrobox create -n arch-repro -i docker.io/archlinux/archlinux:repro --pre-init-hooks "pacman-key --init && pacman-key --populate archlinux"
  • ความสามารถในการทำซ้ำแบบ bit-for-bit ของอิมเมจนี้ยืนยันได้จาก digest ที่ตรงกัน ระหว่างการบิลด์ และตรวจสอบด้วย podman inspect --format '{{.Digest}}' <image> ร่วมกับการเปรียบเทียบด้วย diffoci
  • วิธีทำซ้ำอิมเมจ Docker นี้ดูได้จาก REPRO.md

การติดตั้งใช้งานและการปรับแต่ง

  • งานที่ท้าทายที่สุดคือการบิลด์ rootFS พื้นฐานสำหรับอิมเมจ Docker แบบกำหนดได้แน่นอน และได้นำ กระบวนการเดียวกัน ที่ใช้กับอิมเมจ WSL ซึ่งแชร์ระบบบิลด์ rootFS ร่วมกันมาใช้ซ้ำ
    • สามารถดูคอมมิตของ WSL ที่เกี่ยวข้องได้ที่ นี่
  • หนึ่งในการปรับแต่งเฉพาะสำหรับ Docker คือการตั้งค่า SOURCE_DATE_EPOCH และทำให้ LABEL org.opencontainers.image.created ใน Dockerfile สอดคล้องกับค่านี้ด้วย
  • มีการลบไฟล์แคชเสริม ldconfig ที่ก่อให้เกิด ความไม่เป็นกำหนดแน่นอน ในอิมเมจที่บิลด์แล้ว คือ var/cache/ldconfig/aux-cache ออกจากขั้นตอน Dockerfile
  • ระหว่าง docker build หรือ podman build มีการใช้ตัวเลือก --source-date-epoch=$SOURCE_DATE_EPOCH และ --rewrite-timestamp เพื่อ ทำให้ timestamp เป็นมาตรฐาน
    • มีการยกตัวอย่างปัญหาที่เวลาใน etc/, etc/ld.so.cache, etc/os-release, sys/, var/cache/, var/cache/ldconfig/, proc/, dev/ ถูกประทับไม่ตรงกัน
  • ดูรายละเอียดการเปลี่ยนแปลงทั้งหมดเพิ่มเติมได้จาก merge request diff ของรีโพซิทอรี archlinux-docker
  • ขั้นถัดไปที่กำลังพิจารณาคือการตั้ง rebuilder บนเซิร์ฟเวอร์สำหรับอิมเมจ Docker, อิมเมจ WSL และอิมเมจที่ทำซ้ำได้อื่น ๆ ในอนาคต เพื่อรีบิลด์อัตโนมัติเป็นระยะ ตรวจสอบความสามารถในการทำซ้ำได้ และเปิดเผยบันทึกการบิลด์พร้อมผลลัพธ์

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 5 일 전
ความคิดเห็นจาก Hacker News

  • ชอบที่มี ความมั่นใจ แบบนี้
    ผมรัน Arch Linux บน WSL 2 อยู่เกือบ 1 ปีแล้วและมันดีมาก จากนั้นก็ใช้ Arch แบบเนทีฟต่ออีกราว 5 เดือนและก็ยังประทับใจเหมือนเดิม
    ตอนนี้ก็ยังใช้ Arch แบบเนทีฟอยู่ และทดสอบ dotfiles บน Arch Docker image ด้วยไฟล์ซิสเต็มที่สะอาด
    ถ้าต้องการทดสอบแบบ end-to-end ที่รวมถึงการตั้งค่าสภาพแวดล้อมเดสก์ท็อปเต็มรูปแบบ ก็จะรัน Arch ใน VM
    ผมเองก็มีปัญหาเยอะนะ แต่อย่างน้อย Arch เองไม่ใช่หนึ่งในนั้น

    • สงสัยว่าเวลาเปลี่ยน dotfiles มี staged rollout หรือ rollback ด้วยไหม
      ผมกำลังมองหาการตั้งค่า dotfiles ระดับองค์กรที่รองรับทั้ง Prometheus metrics และ health probe อยู่พอดี ฟังดูได้อารมณ์นั้นเลย
    • ขอบคุณที่รองรับ distro อื่นด้วย และขอบคุณที่แชร์
      ก่อนหน้านี้ไม่เคยคิดเลยว่าตัวเองต้องการสิ่งนี้ แต่พอเห็นแล้วก็รู้สึกว่าจำเป็นขึ้นมาทันที
    • อยากรู้ว่าเคยลอง NixOS หรือ flakes ไหม
      ถ้าเคย อยากฟังเหมือนกันว่ารู้สึกยังไง

  • ผมว่าคอนเทนเนอร์ Docker ทุกตัวเดิมทีก็ควรเป็น แบบนี้
    การรัน apt-get update ในขั้นตอน docker build นี่แทบจะเป็น anti-pattern เลย

    • แต่ถ้าใช้ https://github.com/reproducible-containers/repro-sources-lis... ก็ถือเป็นข้อยกเว้นได้
      ผมเคยใช้เองแล้ว มันทำงานได้ค่อนข้างดี
    • ไม่ว่าทางไหนก็ไม่ได้สะดวกสมบูรณ์แบบอยู่ดี
      ถ้าไม่อัปเดต ก็จะสะสม ปัญหาความปลอดภัย ที่รู้กันอยู่ในคอนเทนเนอร์ แต่ถ้าอัปเดต ความสามารถในการทำซ้ำได้ ก็พัง
      ความสามารถในการทำซ้ำได้นั้นเท่มากและมีข้อดีด้านความปลอดภัยด้วยจริง แต่พอคอนเทนเนอร์อายุเกินเดือน มันก็อาจเริ่มดูไม่ใช่เป้าหมายแล้ว และอายุสูงสุดที่เหมาะสมอาจอยู่ระดับเป็นวันมากกว่า
    • รู้ว่าเป็น anti-pattern แต่ก็ไม่รู้ว่าทางเลือกคืออะไรถ้าต้องติดตั้งซอฟต์แวร์
      หมายถึงให้ไปดึงซอร์สโค้ดที่ติดแท็กไว้แล้วคอมไพล์ทุกอย่างเองด้วย gcc หรือเปล่า
    • ผมไม่เห็นด้วยที่จะมองมันเป็นกฎตายตัว
      คอนเทนเนอร์ที่ทำซ้ำได้ เป็นเรื่องดี แต่ไม่ได้จำเป็นเสมอไป และก็มีหลายกรณีที่รัน apt-get ในคอนเทนเนอร์แล้วไม่ต้องสนใจเรื่องความสามารถในการทำซ้ำได้ก็ได้
    • มันยิ่งยากขึ้นอีกเพราะหลาย distro พอลงเวอร์ชันใหม่ก็ลบ เวอร์ชันเก่า ออกจาก repo ทันที
      แน่นอนว่าก็ยังพอมีวิธีดึงจาก archive ได้อยู่

  • ปกติแล้ว อิมเมจที่ทำซ้ำได้ มักให้ความพึงพอใจทางใจมากกว่าจะเป็นฟีเจอร์ที่จำเป็น แต่จะมีวันที่มันจำเป็นจริง ๆ
    ฝั่งเราก็เคยมีอิมเมจสองตัวที่ควรจะเหมือนกันทุกอย่าง แต่กลับมี 3 ไบต์ ต่างกันใน timestamp บนคนละเครื่อง แล้วนั่นทำให้เราเสียเวลาทั้งบ่ายไปกับการ bisect ในทิศทางที่ผิด
    มันไม่ใช่ชัยชนะที่หวือหวา แต่มีคุณค่าจริง ๆ

    • อยากรู้เหมือนกันว่าความต่างของ timestamp ตั้งแต่แรกมันลามไปเป็นเหตุขัดข้องได้ยังไง

  • น่าจะหาทางแทรกอะไรบางอย่างเพื่อบอกทุกคนได้ว่าใช้ Arch ใน CI/CD pipeline
    ก็คงเหมือนกับบอกคนอื่นว่าตัวเองเล่น Crossfit นั่นแหละ

    • ทำให้นึกถึง koan ข้อนี้เลย
      ถ้าคุณเจอคนที่เป็นทั้งวีแกน เล่นครอสฟิต และเป็นผู้ใช้ Arch คนคนนั้นจะบอกคุณเรื่องอะไรก่อน
    • ผมไม่เคยเข้าใจเลยว่าทำไมบางคนถึงภูมิใจที่ตัวเอง ไม่ได้ใช้ Slackware

  • ดูข้อมูลเกี่ยวกับ Reproducible Builds ได้ที่นี่
    https://reproducible-builds.org/
    ส่วนชุมชน Bootstrappable Builds ที่เกี่ยวข้องกันอย่างใกล้ชิดอยู่ที่นี่
    https://bootstrappable.org/

  • ผมสงสัยว่าในระยะยาว ระบบปฏิบัติการแบบ mutable ที่ออกแบบมาดีอย่าง Arch หรือ Alpine อาจชนะระบบแบบ NixOS ได้ไหม
    เพราะสคริปต์ติดตั้งมีพลังในการแสดงออกมากกว่าภาษาคอนฟิกแบบประกาศ และโดยทั่วไปก็ไม่ได้ยืดยาวกว่าเสียด้วย

    • ถ้าอย่างนั้นก็น่าจะใช้ Guix ไปเลย
      จะได้ทั้งภาษาคอนฟิกแบบประกาศ และในขณะเดียวกันก็ได้ภาษาโปรแกรมที่ Turing-complete และเขียนง่ายด้วย
    • อยากรู้ว่า strictly more powerful หมายถึงอะไรอย่างแม่นยำ

  • ผมอ่านบทความแล้วและมันดูเจ๋งมาก แต่รู้สึกว่าเขาพูดปนกันระหว่าง Dockerfile กับ docker image
    ถ้าสร้างไฟล์ tar ของอิมเมจโดยตรงด้วยอะไรอย่าง nix แทน Dockerfile น่าจะง่ายกว่า และถึงจะค่อนข้างเฉพาะทางแต่ก็น่าจะดูสะอาดกว่าด้วย

  • ขอทักนิดหนึ่งว่าใช้คำว่า OCI Image น่าจะถูกต้องกว่า
    มันรันบน podman ได้ไม่มีปัญหาเลย

    • ในคอมเมนต์ชุดนี้ผมอาจยังใหม่เกินกว่าจะตามบริบททั้งหมดได้ แต่ประเด็นนี้ทำให้ ตาสว่าง มาก

  • ขอคารวะอย่างมากต่อคนที่ทำให้สิ่งนี้เกิดขึ้นได้จริง
    เวลาและความพยายามที่ต้องใช้เพื่อสร้างพาดหัวข่าวแบบนี้ขึ้นมาสักอัน น่าจะมากกว่าที่คนส่วนใหญ่จินตนาการ

  • เป็นอีกเรื่องหนึ่งไปเลย แต่ในหน้านั้นมี แอนิเมชัน อยู่ตัวหนึ่ง ทำให้องค์ประกอบเกือบทั้งหมดของหน้าขยับลงไปราว 20 พิกเซลเป็นเวลา 1 วินาที
    พอเห็นเลย์เอาต์สั่นอยู่ตรงหน้า ก็คิดว่า CLS คงพังเละเทะแน่ ๆ แต่ค่า CLS จริงกลับเป็น 0
    เลยทำให้สงสัยว่า CLS เป็น metric ที่ชวนให้เข้าใจผิดหรือเปล่า

    • นั่นเกิดจากแอนิเมชันที่ตั้งใจทำไว้
      CLS วัดการเปลี่ยนแปลงในช่วง initial rendering ดังนั้นถึงจะดูเหมือนเลย์เอาต์ขยับ แต่ก็ไม่ใช่ประเภทที่ถูกนับเป็น CLS
    • นั่นไม่ใช่ layout shift
      มันเป็นการเคลื่อนไหวจาก CSS transition ซึ่งเป็นการเปลี่ยนแปลงที่คาดเดาได้ จึงไม่ถูกนับเป็น layout shift