Docker hay Podman rootless: build có thể chậm gần 6 lần

Với máy chủ hoặc CI cần giảm đặc quyền, Docker rootless là lựa chọn phù hợp nếu pipeline phụ thuộc vào Docker API và daemon; Podman phù hợp khi muốn chạy lệnh bằng tài khoản thông thường mà không cần daemon thường trực. Đừng chọn theo giả định rằng một bên luôn build nhanh hơn. Image nền, cache và cách Open Build Service (OBS) chuẩn bị môi trường có thể làm thay đổi kết quả trước cả khi xét đến storage driver.

Trong bảng đo của luận văn tại Đại học Tampere, với gói nhiều phụ thuộc và cache đầy, quy trình Podman truyền thống mất tổng cộng 101,80 giây so với 17,06 giây của Docker truyền thống, tức gần 6 lần; thời gian build do OBS ghi nhận lần lượt là 96 và 13 giây, nhưng khi dùng preinstall image rồi chạy lại, hai mức này còn 6 và 7 giây. Chênh lệch ban đầu thuộc về những quy trình OBS cụ thể: bảng đo không tách riêng phần chi phí do rootless gây ra, cũng không xác lập một mức phạt tốc độ chung cho Podman.

Rootless thay đổi quyền của tiến trình nào?

Docker rootless đặt daemon và container trong user namespace, còn Podman chạy container không cần daemon thường trực.

Docker thông thường nhận lệnh qua một daemon có quyền cao trên host. Ở chế độ rootless, tài liệu Docker xác định cả daemon lẫn container chạy trong user namespace dưới tài khoản không có quyền root; host cần công cụ ánh xạ UID/GID và dải subordinate UID, GID tối thiểu 65.536 mục cho người dùng. Đây là điểm khác với cấu hình userns-remap: container được ánh xạ người dùng, nhưng daemon vẫn chạy với quyền root.

Tài liệu lệnh Podman mô tả một công cụ không cần daemon thường trực, có giao diện dòng lệnh tương đồng với Docker và cho phép chạy phần lớn lệnh bằng tài khoản thông thường. Vì Docker cũng hỗ trợ rootless, việc Podman không có daemon thường trực không tự nó chứng minh Podman an toàn hơn trong mọi triển khai. Phạm vi quyền của tài khoản chạy job, những thư mục host được gắn vào container và quyền truy cập socket vẫn cần được tính vào mô hình an toàn của cả hai lựa chọn.

Vì sao quy trình OBS chênh lệch mạnh?

Trong phép đo trên, OBS dựng một gói thử nghiệm có nhiều phụ thuộc phát triển. Đường xử lý Podman truyền thống không dùng được preinstall image trong môi trường không đặc quyền: OBS phải cài riêng các phụ thuộc khi chuẩn bị build. Vì thế, dù cache gói đã đầy, bước thiết lập môi trường vẫn chiếm thời gian. Con số tổng thời gian bao gồm cả chuẩn bị, giải quyết phụ thuộc, thực thi build và các bước bao quanh lệnh build; nó không đồng nghĩa với thời gian biên dịch của riêng mã nguồn.

Cách triển khai mới dùng preinstall image làm image nền cho container, để các phụ thuộc đã nằm sẵn trong môi trường thực thi. Nghiên cứu còn thay đổi đường xử lý vốn loại preinstall image đối với Podman không đặc quyền và bỏ thao tác chroot bên trong container ở chế độ này; nếu giữ chroot, tiến trình build sẽ không nhìn thấy các gói trong image nền. Khi image đã được nhập và tái sử dụng, Podman không còn phải cài lại từng phụ thuộc theo đường xử lý cũ.

Lượt đầu dùng image nền vẫn phải trả chi phí nhập image, còn lượt sau hưởng lợi từ image đã lưu. Đây là lý do thứ tự nhanh chậm đảo chiều trong cùng bộ phép đo. Môi trường thử nghiệm chạy OBS công khai từ WSL trên một máy tính cá nhân, nên thời gian tuyệt đối không thể chuyển thẳng thành dự báo cho runner Linux của doanh nghiệp. Một CI tạo runner mới cho mỗi job cũng có điều kiện cache khác với máy giữ image qua nhiều lượt chạy.

Storage driver và mạng ảnh hưởng ở bước nào?

Các lớp image trong build Podman rootless đi qua native overlayfs, fuse-overlayfs hoặc VFS với chi phí xử lý khác nhau.

Với Podman, hướng dẫn hiệu năng xếp native overlayfs nhanh hơn fuse-overlayfs, rồi đến VFS, đồng thời lưu ý mạng rootless thường đi qua trình điều khiển ở không gian người dùng và chịu chi phí hiệu năng. Tài liệu nêu một ngoại lệ đáng chú ý: khi Podman rootless dùng ánh xạ UID/GID đã sửa đổi, native overlayfs có thể tạo container lần đầu chậm hơn fuse-overlayfs cho cùng image và ánh xạ. Chi phí ấy nằm ở khâu tạo container, không phải tốc độ chạy của container sau khi đã tạo.

Do đó, ghi mỗi chữ “rootless” trong kết quả benchmark vẫn thiếu thông tin quyết định. Một job tải nhiều gói từ mạng sẽ nhạy với đường truyền và cache tải xuống; một job có sẵn mọi gói có thể bộc lộ rõ hơn chi phí chuẩn bị lớp image và tạo container. Storage driver, hệ thống tệp của host, image nền và trạng thái cache phải được ghi cùng kết quả thời gian. Dùng mạng host để giảm chi phí truyền tải cũng thay đổi mức cô lập mạng và quyền tiếp cận dịch vụ cục bộ trên host.

Khả năng tương thích có thể tốn hơn thời gian build

Podman có các lệnh quen thuộc với người dùng Docker, nhưng sự tương đồng của CLI không bảo đảm toàn bộ pipeline chạy nguyên trạng. Một job có thể phụ thuộc vào Docker API, địa chỉ socket, quyền trên volume hoặc cách công cụ phụ trợ khởi tạo container. Khi đổi runtime, những điểm nối đó có thể đòi hỏi chỉnh pipeline ngay cả lúc lệnh build đơn lẻ chạy thành công. Chi phí chuyển đổi vì vậy là phần của quyết định vận hành, bên cạnh số giây đo được.

Docker rootless cũng đặt điều kiện lên host. Danh sách giới hạn của Docker nêu các storage driver được hỗ trợ, yêu cầu cgroup v2 cùng systemd để dùng cgroup, và cấu hình riêng khi cần mở cổng TCP/UDP đặc quyền. Nếu CI cần áp giới hạn tài nguyên chặt chẽ hoặc dịch vụ phải nhận kết nối qua cổng thấp, các điều kiện này ảnh hưởng trực tiếp đến khả năng thay thế daemon Docker đang chạy với quyền root.

Chọn theo workload và điều kiện đo

Nếu chuỗi build đã tích hợp sâu với Docker API, thử Docker rootless trước sẽ giữ được nhiều điểm kết nối hiện có trong khi giảm quyền của daemon. Nếu job có thể gọi container trực tiếp bằng tài khoản riêng và không cần daemon thường trực, Podman là phương án đáng cân nhắc. Ở cả hai trường hợp, quyền được cấp trên host và khả năng tái sử dụng image quan trọng hơn nhãn “rootless” khi đánh giá đồng thời an toàn và thời gian chờ.

Để quyết định bằng số đo của chính CI, hãy giữ cùng kernel, phần cứng, gói cần dựng và image nền; ghi rõ storage driver, mạng, cache gói và cache image. Đo riêng lượt đầu với image chưa nhập, lượt chạy lại, tổng thời gian job và phần thời gian build bên trong. Nếu quy trình hiện không tận dụng được image chứa sẵn phụ thuộc, sửa cách chuẩn bị môi trường có thể đem lại nhiều giá trị hơn việc đổi tên runtime. Phép đo OBS cho thấy chính thay đổi đó đã đảo thứ tự kết quả giữa hai công cụ.

Đọc thêm: