Arch Linux giờ cung cấp image Docker có thể tái tạo bit-for-bit

• Tính tái tạo bit-for-bit nghĩa là khi build từ cùng một nguồn thì bất kể build vào lúc nào, ở đâu hay do ai thực hiện, kết quả tạo ra vẫn hoàn toàn giống nhau đến từng byte
  • Để đạt được điều này, cần loại bỏ toàn bộ các yếu tố phi tất định như timestamp, cache, metadata... vốn có thể thay đổi nhỏ tùy theo môi trường build
• Nếu trực tiếp build image Docker rồi so sánh xem digest (hash) có trùng với image phát hành chính thức hay không, bất kỳ ai cũng có thể tự mình xác minh độc lập rằng image được phát hành không bị chỉnh sửa: điều này rất quan trọng về mặt bảo mật chuỗi cung ứng
• Image Docker của Arch Linux nay đã được cung cấp dưới dạng có thể tái tạo bit-for-bit, mở rộng cùng cột mốc đã đạt được trước đó vài tháng với image WSL sang phía Docker
• Image này được phát hành với repro tag riêng, và để đảm bảo tính tái tạo thì pacman key phải bị xóa khỏi image nên không thể dùng pacman ngay lập tức
  • Cho đến khi có giải pháp phù hợp, do hạn chế này nên trước mắt nó được cung cấp dưới dạng tag riêng
• Nếu muốn cài đặt hoặc cập nhật gói trong container, trước tiên cần chạy pacman-key --init && pacman-key --populate archlinux để tái tạo keyring
  • Có thể thực hiện theo cách tương tác ở lần chạy đầu tiên, hoặc chạy trong câu lệnh RUN của Dockerfile dùng image này làm base
  • Với Distrobox, có thể xử lý bằng pre-init hook như distrobox create -n arch-repro -i docker.io/archlinux/archlinux:repro --pre-init-hooks "pacman-key --init && pacman-key --populate archlinux"
• Tính tái tạo bit-for-bit của image được xác nhận bằng việc digest trùng khớp giữa các lần build, và được kiểm chứng bằng podman inspect --format '{{.Digest}}' <image> cùng so sánh với diffoci
• Có thể xem cách tái tạo image Docker này trong REPRO.md

Triển khai và các điều chỉnh

• Thách thức lớn nhất là build rootFS base cho image Docker theo cách tất định, và quy trình giống hệt image WSL dùng chung hệ thống build rootFS đã được tái sử dụng
  • Có thể xem commit WSL liên quan tại đây
• Một trong các điều chỉnh riêng cho Docker là thiết lập SOURCE_DATE_EPOCH, đồng thời căn chỉnh LABEL org.opencontainers.image.created trong Dockerfile để cũng tuân theo giá trị này
• Trong image đã build, file cache phụ ldconfig là var/cache/ldconfig/aux-cache, thứ gây ra tính phi tất định, đã bị xóa ở bước Dockerfile
• Khi dùng docker build hoặc podman build, các tùy chọn --source-date-epoch=$SOURCE_DATE_EPOCH và --rewrite-timestamp được dùng để áp dụng chuẩn hóa timestamp
  • Ví dụ được nêu ra là thời gian của etc/, etc/ld.so.cache, etc/os-release, sys/, var/cache/, var/cache/ldconfig/, proc/, dev/ từng bị ghi khác nhau
• Có thể xem chi tiết đầy đủ các thay đổi liên quan trong merge request diff của kho archlinux-docker
• Bước tiếp theo được cân nhắc là dựng rebuilder trên server cho image Docker, image WSL, và các image có thể tái tạo trong tương lai để tự động rebuild định kỳ, xác minh tính tái tạo, đồng thời công khai log build và kết quả

[GN⁺]

Ý kiến trên Hacker News

• Thật đáng mừng khi thấy kiểu tự tin này
  Tôi đã chạy Arch Linux trên WSL 2 gần 1 năm và thấy rất tuyệt, sau đó dùng Arch native khoảng 5 tháng nữa và cũng rất hài lòng
  Đến giờ tôi vẫn tiếp tục dùng Arch native, và dotfiles được tôi kiểm thử bằng Arch Docker image trên một filesystem sạch
  Khi cần kiểm thử end-to-end bao gồm cả việc thiết lập toàn bộ môi trường desktop, tôi chạy Arch trong VM
  Tôi cũng có rất nhiều vấn đề, nhưng ít nhất thì bản thân Arch không phải là một trong số đó

  • Không biết với các thay đổi của dotfiles thì có staged rollout hay rollback không
    Tôi đang tìm một bộ dotfiles cấp enterprise còn hỗ trợ cả metric Prometheus và health probe nữa, nên nghe đúng là mang vibe như vậy
  • Cảm ơn vì còn hỗ trợ cả distro khác, và cũng cảm ơn vì đã chia sẻ
    Trước giờ tôi chưa từng nghĩ mình cần nó, nhưng vừa nhìn thấy là lại thấy cần ngay
  • Không biết bạn đã thử NixOS hay flakes chưa
    Nếu có thì cũng muốn nghe cảm nhận của bạn

• Tôi nghĩ mọi Docker container vốn dĩ nên như thế này
  Chạy apt-get update ở bước docker build gần như là một anti-pattern

  • Tuy vậy, nếu dùng https://github.com/reproducible-containers/repro-sources-lis... thì lại là ngoại lệ
    Tôi đã dùng thử và nó hoạt động khá tốt
  • Dù theo cách nào thì cũng không hoàn toàn tiện
    Không cập nhật thì container sẽ tích tụ các vấn đề bảo mật đã biết, còn cập nhật thì lại làm hỏng tính tái lập
    Tính tái lập rõ ràng rất hay và cũng có lợi ích về bảo mật, nhưng khi container đã quá một tháng thì nó có thể bắt đầu giống như lệch khỏi mục tiêu, và có lẽ tuổi thọ tối đa phù hợp hơn nên tính theo ngày
  • Tôi biết đó là anti-pattern, nhưng không rõ lựa chọn thay thế là gì khi cần cài phần mềm
    Ý là phải tải source code đã được gắn tag rồi tự biên dịch mọi thứ bằng gcc sao?
  • Tôi không đồng ý khi coi đó là quy tắc tuyệt đối
    Container tái lập được đúng là tốt, nhưng không phải lúc nào cũng cần, và cũng có rất nhiều trường hợp bạn cứ chạy apt-get trong container mà không cần bận tâm đến tính tái lập
  • Điều đó còn khó hơn vì nhiều distro xóa phiên bản cũ khỏi repo ngay khi bản mới xuất hiện
    Dĩ nhiên vẫn có cách lấy từ archive

• Image tái lập được thường dễ bị xem là một tính năng chỉ mang lại cảm giác thỏa mãn về mặt tinh thần trong ngày thường, nhưng rồi sẽ có lúc nó trở nên thực sự cần thiết
  Chúng tôi từng có hai image lẽ ra phải giống hệt nhau nhưng lại tạo ra chênh lệch 3 byte ở timestamp trên hai máy khác nhau, và vì thế mà mất nguyên một buổi chiều để bisect theo sai hướng
  Không hào nhoáng, nhưng rõ ràng là một chiến thắng rất đáng giá

  • Tôi tò mò không biết ngay từ đầu việc chênh lệch timestamp đã dẫn đến sự cố như thế nào

• Có lẽ tôi sẽ cài gì đó để mọi người đều biết rằng tôi dùng Arch trong CI/CD pipeline
  Tiện thể cũng cho họ biết luôn là tôi tập Crossfit nữa

  • Làm tôi nhớ đến một koan thế này
    Nếu bạn gặp một người vừa ăn chay, vừa tập CrossFit, lại còn là người dùng Arch, thì họ sẽ nói cho bạn biết điều gì trước tiên?
  • Tôi chưa bao giờ hiểu vì sao ai đó lại thấy tự hào vì chuyện không dùng Slackware

• Có thể xem thông tin về Reproducible Builds tại đây
  https://reproducible-builds.org/
  Cộng đồng Bootstrappable Builds có liên quan chặt chẽ nằm ở đây
  https://bootstrappable.org/

• Tôi tự hỏi liệu về lâu dài những hệ điều hành mutable được thiết kế tốt như Arch hay Alpine có thể đánh bại những hệ thống như NixOS hay không
  Vì script cài đặt có tính biểu đạt cao hơn ngôn ngữ cấu hình khai báo, mà nhìn chung lại cũng không dài dòng hơn

  • Nếu vậy thì có lẽ cứ dùng Guix thôi
    Bạn sẽ có cả ngôn ngữ cấu hình khai báo, đồng thời có luôn một ngôn ngữ lập trình Turing-complete dễ viết
  • Tôi tò mò chính xác strictly more powerful ở đây có nghĩa là gì

• Tôi đã đọc bài và thấy khá ấn tượng, nhưng có cảm giác họ đang dùng lẫn lộn giữa Dockerfile và docker image
  Có lẽ sẽ dễ hơn nếu họ dùng thứ như nix để build trực tiếp file tar của image thay vì Dockerfile, dù đúng là sẽ hơi mang tính cực khách nhưng có lẽ vẫn gọn gàng hơn

• Chỉ là một góp ý nhỏ thôi nhưng tôi nghĩ dùng thuật ngữ OCI Image sẽ chính xác hơn
  Nó cũng chạy hoàn toàn ổn với podman

  • Trong phần bình luận này tôi hơi gà nên không theo hết ngữ cảnh, nhưng câu này đúng là một điểm khai sáng khá mạnh với tôi

• Tôi thật sự rất kính nể những người đã biến điều này thành hiện thực
  Thời gian và công sức cần bỏ ra để tạo nên một dòng tiêu đề như thế này lớn hơn rất nhiều so với tưởng tượng

• Chuyện hoàn toàn khác, nhưng trên trang đó có một animation khiến gần như mọi phần tử trên trang dịch xuống khoảng 20 pixel trong vòng 1 giây
  Nhìn layout rung lắc ngay trước mắt nên tôi tưởng nó sẽ phá nát CLS, nhưng CLS thực tế lại là 0
  Vậy nên tôi bắt đầu tự hỏi có phải CLS là một chỉ số dễ gây hiểu nhầm không

  • Đó là do animation có chủ đích gây ra
    CLS xử lý các thay đổi ở lần render ban đầu, nên dù trông giống layout shift thì đó không phải loại sẽ bị tính vào CLS
  • Đó không phải là layout shift
    Đó là chuyển động do CSS transition tạo ra, là thay đổi có thể dự đoán được, nên không bị tính là layout shift