Apptainer - Container ứng dụng cho Linux

• Nền tảng container mã nguồn mở được thiết kế tập trung vào sự đơn giản / tốc độ / bảo mật
  • Tối ưu cho môi trường HPC (điện toán hiệu năng cao) và hệ thống dùng chung
• Cung cấp định dạng image container tệp đơn bất biến (immutable), hỗ trợ mã hóa và ký số
• Tập trung vào khả năng sử dụng tích hợp hơn là cô lập, nên trong môi trường cụm máy chủ/server có thể tận dụng ngay GPU, mạng tốc độ cao và hệ thống tệp song song
• Có thể lấy mọi container từ registry OCI (Open Containers Initiative), đồng thời tối đa hóa khả năng tương thích với Docker
  • Hỗ trợ pull, run và build hầu hết container trên Docker Hub mà không cần thay đổi
• Được đổi tên từ Singularity và chuyển thành dự án của Linux Foundation
• Với container tệp đơn dựa trên SIF (Singularity Image Format), có thể dễ dàng di chuyển, triển khai và chia sẻ
• Quyền người dùng bên trong và bên ngoài container là như nhau, áp dụng mô hình bảo mật an toàn mà theo mặc định không thể leo thang thêm đặc quyền trên host
• Giấy phép BSD

[galadbran]

Bài viết về unregistry được nhắc đến trong ý kiến trên Hacker News:
Unregistry – truyền trực tiếp docker push tới máy chủ mà không cần registry | GeekNews

[GN⁺]

Ý kiến trên Hacker News

• Nhóm chúng tôi đã thử Apptainer trên cụm máy tính dùng cho thiết kế/xác minh silicon, nhưng cuối cùng lại quay về các mô-đun TCL(chuyển sang Lua) truyền thống

  • Đã gặp nhiều vấn đề.
    • Thứ nhất, các container không thể dùng lẫn nhau. Ví dụ nếu các công cụ như Make, GCC, Git nằm ở các Apptainer khác nhau, thì khi vào Make sẽ không nhìn thấy GCC
    • Thứ hai, nếu đầu ra phụ thuộc vào bên trong container thì sẽ không hoạt động đúng. Khi build chương trình bằng Apptainer GCC, binary được tạo ra sẽ liên kết với các thư viện bên trong Apptainer nên không chạy được, đồng thời cũng phát sinh vấn đề với header C
    • Thứ ba, giá trị PATH liên tục bị rối, lặp đi lặp lại lỗi không nhìn thấy các đường dẫn hoặc công cụ cần thiết bên ngoài Apptainer
    • Nhìn chung ý tưởng thì tốt nhưng về tính khả dụng thực tế lại quá phiền toái, nên cuối cùng dùng trực tiếp OS cũ(RHEL8) còn dễ hơn nhiều
  • Tôi xem Apptainer/Singularity khá giống Docker(chỉ là không có đầy đủ thiết lập mạng). Những vấn đề này cũng xảy ra tương tự với container Docker truyền thống.
    • Trong workflow HPC của tôi, tôi dùng Apptainer như một bản thay thế Docker kiểu drop-in, và cho mục đích đó thì nó khá phù hợp
    • Ưu điểm lớn nhất của Apptainer là container không cần quyền root. Vì vậy không làm được networking phức tạp, nhưng trong môi trường đa thuê như HPC thì an toàn hơn nhiều về mặt bảo mật
  • Nếu điều bạn khó chịu nhất khi dùng ứng dụng container là nó hoạt động đúng kiểu container, thì đó chính là bản chất của container
  • Không nên trộn lẫn các mảnh container với nhau. Cũng giống như việc không trộn binary từ các bản phân phối Linux khác nhau
    • Lý tưởng nhất là dùng container để phát triển trong một môi trường thống nhất. Vì container là môi trường cô lập, nên bất cứ thứ gì được biên dịch thì kết quả cũng phải nằm trong chính container đó
    • Tuy nhiên, cũng có thể tạo nhiều container từ cùng một base image để đảm bảo tính tương thích tệp(điều này chỉ đúng khi bạn đưa vào mọi phụ thuộc cần thiết)

• Rất vui khi thấy Apptainer được chú ý. Trong một số trường hợp nó tốt hơn Docker, Podman v.v.

  • Khi cần chạy nhiều tác vụ trong một container(điều này không được khuyến khích ở các công nghệ container khác)
  • HPC (và một số môi trường đại học)
  • Hỗ trợ mô hình phân phối một tệp duy nhất(tất nhiên không hỗ trợ delta)
  • Có thể ký mã hóa tệp SIF mà không cần máy chủ bên ngoài riêng biệt
  • Hỗ trợ GPU mạnh mẽ

• docker cũng có thể phân phối một tệp duy nhất bằng các lệnh docker save và docker load.

  • Tuy không hỗ trợ delta, nhưng gần đây một giải pháp tên là "unregistry" đã được liên kết trên HN; nó cho phép chức năng "docker push" và áp dụng delta mà không cần Docker Registry

• Cả Apptainer lẫn singularity ce đều thường được dùng trong HPC. Cả hai đều tách ra từ dự án Singularity cũ, nhưng không hoàn toàn giống nhau

  • Chúng tôi dùng singularity trên nhiều siêu máy tính(HPC), và một số nhà nghiên cứu cài Apptainer ở máy cục bộ để sử dụng
  • Gần đây chúng tôi phát hiện lỗi múi giờ trong mã Python(matplotlib, xarray v.v.); trên singularity ce thì có vấn đề nhưng trên Apptainer lại hoạt động bình thường
  • Apptainer mới có codebase tương tự, nhưng các bản sửa lỗi đang được phản ánh nhanh hơn. Ví dụ, singularity đã ghi đè múi giờ của người dùng lên hệ thống nên gây ra vấn đề
  • Liên kết tham khảo: singularity issue #3686
  • Apptainer không phải là fork của dự án Singularity cũ. Apptainer là dự án chính gốc, chỉ được đổi tên sau một cuộc bỏ phiếu của cộng đồng. Dự án cũng được chuyển sang Linux Foundation
    • Trường hợp Sylabs tuyển tác giả ban đầu rồi fork dự án chính là singularity ce
    • Tham khảo: community announcement
  • Dù vậy, tính tương thích container giữa chúng vẫn được giữ nguyên, nên build bằng Apptainer vẫn có thể chạy trên Singularity(và ngược lại cũng vậy)

• Apptainer về cơ bản chính là Singularity. Bài báo liên quan ở đây

  • Khi dùng hệ thống dùng chung ở các cụm đại học hoặc chính phủ, Apptainer lúc nào cũng có sẵn còn Podman/Docker thì hầu như không có
  • Trong môi trường như vậy, thay vì dùng container, có lẽ sẽ có lợi hơn nếu làm quen với quản trị viên hệ thống và hiểu cách cụm đó được vận hành
  • Tôi thắc mắc vì sao Docker/Podman lại ít được dùng hơn, và vì sao nên tránh dùng container. Có phải do vấn đề hiệu năng không

• Flatpak đang muốn chuyển từ OSTree sang nền tảng container. Họ nói lợi thế lớn là có bộ công cụ container được bảo trì tốt. Nhưng tôi thắc mắc điều này khác Apptainer ở điểm nào

  • Có lẽ điểm nổi bật của Flatpak là kiểm soát sandbox cho từng ứng dụng như phân chia quyền hạn chi tiết thông qua xdg-dbus, để có thể dùng gần như ứng dụng native
    • Tôi không chắc Apptainer có tách biệt/cô lập hoàn toàn đến mức đó hay không
    • Nếu dùng các công cụ như containertoolbx thì khác biệt giữa các cách làm container cũng không còn quá quan trọng
    • Thành thật mà nói, chức năng giữa các công cụ bị chồng lấn khá nhiều, nhưng bản thân điều đó tôi cũng thấy ổn

• Trong môi trường tôi đang dùng, mục đích lớn nhất của việc dùng Apptainer không liên quan đến phân phối, cô lập hay khả năng sẵn có của phần mềm.

  • Cụm HPC của chúng tôi có giới hạn quota inode cho từng người dùng, nên rất khó cài các phần mềm có quá nhiều tệp(ví dụ: Anaconda)
  • Nhưng image Apptainer là một tệp duy nhất dựa trên squashfs, nên có thể lưu nhiều cái mà không phải lo quota inode
  • Cài phần mềm theo cách thông thường quả thực dễ hơn, nhưng quota sẽ cạn rất nhanh

• Tôi đồng ý với ý kiến của Havoc. Thông điệp khá mơ hồ: Apptainer là bản thay thế Flatpak cho desktop, hay là công cụ dành cho máy chủ

  • Dành cho máy chủ. Tuy nhiên bản thân câu hỏi cũng khá mơ hồ
    • Apptainer dùng để chạy ứng dụng CLI trong container immutable, rootless
    • Công cụ gần nhất với nó là Fedora Toolbx
    • Mục đích chính của Apptainer là phân phối và tái sử dụng các công cụ tính toán khoa học. Nó dùng được mà không cần quyền root, không thể sửa rootfs theo từng container, tự động mount thư mục làm việc, và cũng hỗ trợ GPU tốt(dù điểm này tôi chưa tự kiểm tra)
    • Tham khảo: Fedora Toolbx

• Cái tên "Apptainer" nghe khó phát âm và có cảm giác hơi sai sai

• Nếu là lập trình viên, có thể bạn đang tìm một công cụ container để cô lập

  • Tôi đã thử tạo một công cụ dựa trên Podman để cô lập các dự án phát triển khác nhau. Nếu cần cho việc dùng thử hoặc kiểm tra bảo mật, có thể xem mã nguồn hoặc bài blog
  • Tôi tò mò vì sao toolbox lại không đủ dùng
    • Với tôi, toolbox khá ổn vì khi cài môi trường phát triển theo từng dự án thì không phải quản lý nhiều filesystem ẩn

• Trên cụm SLURM và các máy chủ không có quyền root thì nó rất hữu ích

  • Tôi cũng có kinh nghiệm dùng nó trên cụm SLURM
    • Tài liệu chính thức rất đầy đủ nên đủ tốt cho người mới bắt đầu
    • Tuy nhiên nếu không có fakeroot hay sudo thì sẽ khá phiền vì phải build Apptainer ở máy cục bộ rồi chuyển trực tiếp lên máy chủ mới dùng được