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

 (antiz.fr)
4 điểm bởi GN⁺ 5 ngày trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Docker image Arch Linux với khả năng tái tạo bit-for-bit nay đã được cung cấp, mở rộng cột mốc tương tự từng đạt được với image WSL vài tháng trước sang Docker
  • Image được phát hành bằng thẻ repro chuyên dụng, và để đảm bảo tính tái tạo thì khóa pacman đã bị loại bỏ nên ở trạng thái mặc định không thể dùng pacman ngay
  • Để cài đặt hoặc cập nhật gói trong container, cần tạo lại keyring bằng pacman-key --init && pacman-key --populate archlinux
  • Tính tái tạo được xác minh bằng sự trùng khớp digest giữa các bản build và so sánh với diffoci, đồng thời áp dụng thêm các điều chỉnh như build rootFS theo cách quyết định, chuẩn hóa timestamp và loại bỏ bộ nhớ đệm phụ của ldconfig
  • Có thể xem quy trình tái tạo trong REPRO.md, và trong tương lai có thể tiến tới máy chủ rebuilder để tự động build lại và xác minh, cũng như công khai log build và kết quả

Nội dung chính

  • Docker image của Arch Linux nay được cung cấp ở dạng có thể tái tạo bit-for-bit, mở rộng cột mốc tương tự từng đạt được với image WSL vài tháng trước sang phía Docker
  • Image này được phát hành bằng thẻ repro chuyên dụng, và để đảm bảo tính tái tạo thì khóa pacman phải bị loại bỏ khỏi image nên không thể dùng pacman ngay
    • Cho đến khi có giải pháp phù hợp hơn, do hạn chế này nên hiện trước mắt được cung cấp dưới dạng một thẻ riêng
  • Để 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ạo lại keyring
    • Ở lần chạy đầu tiên có thể thực hiện theo chế độ tương tác, 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 kiểm tra bằng sự trùng khớp digest giữa các lần build, và xác minh bằng podman inspect --format '{{.Digest}}' <image> cùng so sánh với diffoci
  • Có thể xem cách tái tạo Docker image 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 Docker image theo cách quyết định, và đã tái sử dụng cùng quy trình với image WSL vốn dùng chung hệ thống build rootFS
    • Có thể xem commit WSL liên quan tại đây
  • Một trong các điều chỉnh dành riêng cho Docker là thiết lập SOURCE_DATE_EPOCH, đồng thời để LABEL org.opencontainers.image.created trong Dockerfile cũng tuân theo giá trị này
  • Trong image đã build, tệp bộ nhớ đệm phụ var/cache/ldconfig/aux-cache của ldconfig, vốn gây ra tính không quyết định, đã được xóa ở bước Dockerfile
  • Khi dùng docker build hoặc podman build, áp dụng chuẩn hóa timestamp bằng các tùy chọn --source-date-epoch=$SOURCE_DATE_EPOCH và --rewrite-timestamp
    • Ví dụ được nêu 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 hơn toàn bộ thay đổi liên quan trong merge request diff của kho archlinux-docker
  • Ở bước tiếp theo, nhóm đang cân nhắc xây dựng rebuilder trên máy chủ cho Docker image, image WSL, và các image có thể tái tạo trong tương lai, để tự động build lại định kỳ, xác minh tính tái tạo, và công khai log build cùng kết quả

Bài viết liên quan

1 bình luận

 
GN⁺ 5 ngày trước
Ý 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