Docker hay Podman: rootless không còn là lợi thế của riêng một bên

Docker và Podman đều có thể chạy container không cần quyền root trên host. Nếu dự án đã phụ thuộc Docker Compose và các công cụ kết nối với Docker Engine, giữ Docker thường ít tốn công chuyển đổi hơn; nếu muốn mỗi tài khoản trên máy chủ Linux tự quản lý container mà không cần daemon trung tâm thường trực, Podman đáng cân nhắc. Tài liệu rootless của Docker nêu rõ cả daemon lẫn container chạy trong user namespace dưới tài khoản không có quyền root khi host đáp ứng điều kiện thiết lập.

Vì vậy, rootless không phải ưu thế chỉ Podman có. Tài liệu giới thiệu Podman mô tả công cụ Linux không cần daemon cho cách dùng CLI thông thường, làm việc với container và image theo chuẩn OCI, đồng thời cho phép người dùng không đặc quyền quản lý container. Lựa chọn thực tế phụ thuộc vào kiến trúc quản lý, những tích hợp stack đang dùng và công sức cần bỏ ra để chuyển chúng.

Daemon thay đổi cách vận hành ra sao?

Docker CLI gửi yêu cầu đến Docker daemon, nơi quản lý việc tạo và chạy container. Ở chế độ rootless, daemon vẫn tồn tại nhưng chạy dưới tài khoản không đặc quyền. Điều đó giữ được mô hình client–server quen thuộc: công cụ tự động hóa cần trỏ đúng Docker context hoặc socket của tài khoản ấy, còn dịch vụ theo người dùng phải được cấu hình để hoạt động khi cần.

Với lệnh CLI thông thường, Podman không cần một daemon trung tâm chạy liên tục. Cách này phù hợp khi các tài khoản trên cùng máy Linux tự quản lý workload của mình. Podman vẫn có dịch vụ REST API và socket cho client từ xa hoặc phần mềm cần giao diện API; chọn Podman không tự động loại bỏ mọi thành phần dạng dịch vụ khỏi một hệ thống đã tích hợp với Docker API.

Khác biệt kiến trúc tác động rõ nhất đến việc ai quản lý tiến trình và công cụ phụ trợ kết nối ở đâu. Nó không tự quyết định quyền truy cập tệp, cổng hay tốc độ xử lý của ứng dụng. Các điểm đó cần được xem trong cấu hình rootless và workload cụ thể.

Checklist rootless trước khi chọn

Với Docker, host cần có newuidmap, newgidmap và dải UID/GID phụ cấp cho tài khoản vận hành. Sau khi thiết lập, docker info phải cho thấy CLI đang kết nối với context rootless và máy chủ báo tùy chọn bảo mật rootless. Chạy được lệnh docker mà không nhập sudo chưa đủ để kết luận daemon cũng không có quyền root: CLI vẫn có thể đang nói chuyện với daemon hệ thống.

Với Podman, hãy chạy thử bằng đúng tài khoản sẽ vận hành ứng dụng. Nếu container ghi vào thư mục bind mount, kiểm tra quyền sở hữu tệp cả trong container lẫn trên host; nếu ứng dụng công bố cổng ra ngoài, kiểm tra cổng đó dưới tài khoản không đặc quyền. Một cấu hình chạy được bằng root có thể cần điều chỉnh quyền tệp hoặc cổng khi chuyển sang rootless.

• Xác nhận tài khoản nào sở hữu tiến trình container và dữ liệu được ghi trên host.
• Kiểm tra đường dẫn socket mà Compose, CI hoặc công cụ quản lý khác thực sự sử dụng.
• Khởi động lại dịch vụ và kiểm tra nó còn chạy theo yêu cầu sau khi người dùng đăng xuất hoặc host khởi động lại.
• Thử đọc, ghi và khôi phục dữ liệu qua chính volume mà workload sẽ dùng.

Checklist này giúp phân biệt một engine hỗ trợ rootless với một stack vận hành ổn trong rootless. Hai kết luận không đồng nghĩa: lỗi quyền trên bind mount hoặc một client nối nhầm socket vẫn có thể khiến ứng dụng thất bại dù engine đã được thiết lập đúng.

Lệnh quen thuộc không bảo đảm stack tương thích

Những lệnh kéo image, build và chạy container của Podman đủ quen để người dùng Docker bắt đầu nhanh. Tuy nhiên, chuẩn OCI không bao trùm mọi tùy chọn build, cách lưu image cục bộ hoặc hành vi của công cụ gọi API. Trong nghiên cứu tương thích của Tampere University hoàn thành tháng 10 năm 2024, phần lớn thao tác CLI được chuyển bằng cách thay tên lệnh, nhưng phép thử của tác giả gặp lỗi với COPY --link và bỏ qua HEALTHCHECK khi build image ở định dạng OCI.

Đó là kết quả theo phiên bản và cấu hình trong nghiên cứu, không phải phán quyết cho mọi bản phát hành sau này. Nó chỉ ra hai chỗ nên thử trực tiếp: Dockerfile có tùy chọn build đặc thù và cơ chế xác định dịch vụ đã sẵn sàng. Tương tự, alias docker=podman đổi tên lệnh chứ không khiến script đọc đầu ra CLI, công cụ gọi Docker API hay hai kho image cục bộ trở thành tương đương.

Với CI, một job đại diện có giá trị hơn danh sách lệnh giống nhau. Job đó nên bao gồm build image, khởi chạy dịch vụ phụ trợ, chờ ứng dụng sẵn sàng, lấy log, xuất artifact và dọn tài nguyên. Nếu một bước dùng socket Docker, cần thử chính bước tích hợp đó thay vì chỉ xác nhận container khởi động được.

Chuyển thử một Compose stack

Giả sử stack thử nghiệm gồm ứng dụng web và cơ sở dữ liệu. Trước khi đổi engine, ghi lại hành vi của stack trên Docker: ứng dụng kết nối cơ sở dữ liệu bằng tên dịch vụ nào, dữ liệu có còn sau khi tạo lại container, health check chuyển trạng thái ra sao và cổng nào được công bố trên host. Dùng dữ liệu thử nghiệm để hai lần chạy có thể so sánh mà không tác động đến hệ thống đang phục vụ người dùng.

Khi chạy cùng tệp cấu hình với Podman, cần ghi rõ chương trình Compose thực sự được gọi. Tài liệu podman compose cho biết lệnh này gọi một nhà cung cấp Compose bên ngoài, chẳng hạn docker-compose hoặc podman-compose, rồi thiết lập kết nối tới socket Podman. Vì thế, kết quả phụ thuộc cả vào nhà cung cấp Compose được cài và cấu hình của nó, không chỉ vào Podman.

1. Chạy các thao tác khởi động, dừng và tạo lại stack; xác nhận ứng dụng thực sự phục vụ yêu cầu sau khi dịch vụ phụ trợ sẵn sàng.
2. Đọc và ghi dữ liệu qua volume bằng đúng tài khoản rootless dự kiến; kiểm tra chủ sở hữu tệp trên host sau khi tạo lại container.
3. Thử phân giải tên giữa các dịch vụ, cổng công bố, health check và các bước CI dùng socket hoặc Docker API. Ghi riêng lỗi do engine và lỗi do nhà cung cấp Compose.

Nếu stack chạy đúng nhưng script vận hành cần sửa, chi phí chuyển đổi nằm ở tích hợp và bảo trì quy trình. Nếu một job phụ thuộc sâu vào hành vi riêng của Docker, giữ job đó trên Docker cũng là lựa chọn hợp lý trong khi đánh giá Podman cho workload khác.

Benchmark nói gì về tốc độ?

Không có cơ sở để hứa ứng dụng sẽ nhanh hơn rõ rệt chỉ vì đổi engine. Trong luận văn đo hiệu năng của University of Oulu tháng 10 năm 2024, bài thử CPU Y-Cruncher trên laptop HP EliteBook 840 G2 cho thời gian trung bình 134 giây ở máy gốc, Docker và Podman; phép đo khởi động rồi dừng container sau khi khởi động lại host lại ghi nhận trung bình 1,08 giây với Docker và 0,39 giây với Podman.

Hai kết quả đo hai việc khác nhau: thời gian chạy tác vụ CPU và độ trễ của một vòng đời container ngắn. Tác giả cho rằng daemon Docker có thể góp phần vào chênh lệch khởi động trong cấu hình ấy, nhưng đó không phải phép đo tác động riêng của daemon. Các container dùng cấu hình mặc định và workload benchmark, nên những con số này không chứng minh một stack Compose production hoặc hai cấu hình rootless sẽ có cùng mức chênh lệch.

Nếu tốc độ là tiêu chí quyết định, phép so sánh hữu ích phải giữ cùng image, dữ liệu và giới hạn tài nguyên, rồi đo đúng việc đang gây chậm: build, khởi động hay xử lý yêu cầu khi ứng dụng đã chạy. Kết quả CPU gần nhau không xóa được khác biệt ở tác vụ tạo container liên tục; ngược lại, vài phần giây ở khởi động không cho biết thông lượng của dịch vụ chạy lâu.

Chọn theo môi trường sử dụng

• Máy phát triển cá nhân: Docker là lựa chọn ít xáo trộn khi dự án đã dùng Docker Compose, script và công cụ phát triển quanh Docker Engine. Podman phù hợp để cân nhắc trên Linux nếu muốn quy trình theo tài khoản người dùng và những tính năng cần dùng đã vượt qua phép thử stack.
• Máy chủ Linux nhiều người dùng: Podman có lợi thế kiến trúc khi mỗi tài khoản tự quản lý container mà không cần daemon trung tâm thường trực. Docker rootless vẫn đáp ứng mục tiêu chạy daemon và container không có quyền root; hãy so chi phí duy trì các context, socket và tích hợp hiện có trước khi đổi.
• CI: giữ Docker khi pipeline phụ thuộc chặt vào Docker socket hoặc hành vi Compose hiện tại. Thử Podman trên một job có build, dịch vụ phụ trợ và bước dọn dẹp khi mục tiêu là thay đổi mô hình vận hành; chỉ mở rộng sau khi job cho ra artifact và trạng thái dịch vụ như mong đợi.

Đọc thêm:

• F5 chặn lệnh của AI agent trước khi chạy: tháng 10 mới có
• AWS và Azure nối mạng riêng trực tiếp: bản thử nghiệm chỉ mở ở bốn vùng
• Surfshark mua Optery: dữ liệu khách hàng vẫn ở hạ tầng riêng