Vì sao tôi chuyển từ Docker sang Podman

 (codesmash.dev)
14 điểm bởi GN⁺ 2025-09-06 | 8 bình luận | Chia sẻ qua WhatsApp
  • Docker từ lâu bị chỉ ra các vấn đề về lỗ hổng bảo mật và tiêu tốn tài nguyên do cấu trúc daemon nền (dockerd)
  • Podman áp dụng kiến trúc không daemon, cho phép container chạy trực tiếp dưới quyền người dùng, giảm bề mặt tấn công và tăng cường độ ổn định
  • Nhờ hỗ trợ tích hợp systemd, thiết kế thân thiện với Kubernetes và bộ công cụ tách biệt theo triết lý Unix như Buildah/Skopeo, hiệu quả vận hành được nâng cao
  • Giữ mức tương thích cao với Docker CLI, nên chỉ với alias docker=podman là hầu hết quy trình làm việc hiện có vẫn hoạt động nguyên vẹn
  • Ngay cả trong môi trường vận hành thực tế, bảo mật và quản lý tài nguyên cũng trở nên đơn giản hơn, và với các dự án mới, Podman đang trở thành lựa chọn hợp lý và hướng đến tương lai hơn

Giới hạn và vấn đề bảo mật của Docker

  • Docker có cấu trúc trong đó daemon dockerd luôn chạy với quyền root
    • Nếu phát hiện lỗ hổng trong daemon, toàn bộ máy chủ có thể bị đặt vào tình thế rủi ro
  • Một số ví dụ về sự cố bảo mật lớn
    • 2019: thoát container runC (CVE-2019-5736)
    • 2022: lỗ hổng Linux Dirty Pipe, thoát cgroups v1
    • 2024: runC “Leaky Vessels”, lỗ hổng BuildKit
    • 2024: chiến dịch cryptojacking thông qua việc lộ Docker API
  • Khi những sự cố như vậy lặp lại, rủi ro mang tính nền tảng của kiến trúc dựa trên daemon ngày càng lộ rõ

Kiến trúc không daemon của Podman

  • Podman không sử dụng daemon nền
    • Khi chạy podman run, container hoạt động như tiến trình con trực tiếp của tiến trình gọi lệnh
    • Vì chạy ở chế độ rootless, ngay cả quyền root trong container trên máy chủ cũng chỉ tương đương quyền người dùng thông thường
  • Ưu điểm
    • Tăng cường bảo mật: nếu xảy ra thoát container thì phạm vi thiệt hại được thu hẹp
    • Bảo đảm ổn định: một container chết cũng không ảnh hưởng đến các container khác
    • Hiệu quả tài nguyên: không có daemon không cần thiết thường trú nên giảm mức dùng bộ nhớ

Các tính năng khác biệt của Podman

  • Tích hợp systemd
    • Tự động tạo file unit systemd bằng podman generate systemd
    • Có thể quản lý dịch vụ bằng lệnh systemctl tiêu chuẩn
  • Thân thiện với Kubernetes
    • Khái niệm Pod được tích hợp sẵn, thuận tiện cho việc phát triển ứng dụng đa container
    • Có thể tạo trực tiếp Kubernetes YAML bằng podman generate kube
  • Triết lý Unix
    • Podman tập trung vào chạy container, còn build image dùng Buildah, quản lý registry dùng Skopeo
    • Có thể tận dụng các công cụ được tối ưu theo từng mục đích

Quá trình chuyển đổi và khả năng tương thích

  • Việc chuyển từ Docker sang Podman gần như không gián đoạn
    • CLI tương thích nên có thể dùng nguyên cách gọi cũ, chỉ thay docker bằng podman
    • Dockerfile hiện có cũng vẫn hoạt động như cũ
  • Điểm khác biệt
    • Ở chế độ rootless không thể bind cổng nhỏ hơn 1024 → khuyến nghị dùng reverse proxy
    • Cần quản lý quyền của volume
    • Các công cụ phụ thuộc vào Docker socket có thể dùng chế độ tương thích Docker API của Podman

Ứng dụng thực tế và lợi ích

  • Sau khi dùng Podman trong môi trường vận hành
    • Giảm gánh nặng kiểm tra bảo mật, mặc định đã áp dụng bảo mật rootless
    • Mô hình sử dụng tài nguyên trở nên đơn giản và dễ dự đoán hơn
  • Docker vẫn rất phổ biến, nhưng nếu là dự án mới hoặc có quyền tự do lựa chọn công nghệ thì Podman phù hợp hơn
    • Tích hợp tự nhiên với hệ thống quản trị Linux
    • Kiến trúc định hướng Kubernetes
    • Cung cấp môi trường chạy container an toàn và hợp lý hơn

Tóm tắt hướng dẫn chuyển FastAPI

  • Có thể dùng nguyên Dockerfile hiện có
  • Chỉ cần thay bằng podman build, podman run
  • Dùng podman generate systemd để đăng ký dịch vụ systemd
  • Hỗ trợ môi trường đa dịch vụ như DB bằng cách tận dụng Pod
  • Quy trình Docker Compose có thể xử lý bằng podman-compose hoặc chuyển đổi qua kompose

Bài viết liên quan

8 bình luận

 
shortstories 2025-09-09

Ở đây có viết rằng có thể chuyển đổi không gián đoạn, nhưng trong môi trường vận hành thực tế lại có khá nhiều thứ kỳ lạ. Ví dụ, trên môi trường mac, do dùng nén zstd theo thiết lập mặc định nên image đã build che phủ registry khá nhiều, v.v..
 
codemasterkimc 2025-09-08

Cả Docker lẫn podman đều....

securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL

securityContext:
runAsNonRoot: true
runAsUser: UID
 
koxel 2025-09-08

Thực tế là khả năng tương thích với Docker không tốt nên tính tiện dụng cũng không cao lắm...
Tôi từng chuyển sang Podman vì nghĩ đến chế độ rootless, rồi lại quay về Docker.
Như người khác đã nói, nếu dùng với Kubernetes thì cứ dùng containerd là xong.
 
click 2025-09-08

Tôi hơi có thắc mắc là nếu Docker compose không hoạt động tốt, còn ưu điểm là tương thích với Kubernetes, thì chẳng phải dùng luôn Kubernetes ngay từ đầu sẽ hợp lý hơn sao?
Tôi cũng định thử dùng, nhưng vì nó không chạy được ngay một lần là xong và cũng không thể tự map các cổng dưới 1024, nên cuối cùng tôi dùng kết hợp k3s với nerdctl để build image.
 
ndrgrd 2025-09-07

Tôi vẫn luôn muốn chuyển đổi vào một lúc nào đó, nhưng khi đã thử trước đây thì trái với những gì các lập trình viên nói, có quá nhiều dự án docker compose không hoạt động đúng cách...
 
afewgoodman 2025-09-07

Docker còn chẳng hỗ trợ network mà.
 
devsepnine 2025-09-07

Theo mình biết thì nó cũng hỗ trợ tính năng mạng tương tự Docker.
Hiện vẫn còn phần nào chưa hoạt động ổn đúng không?
 
GN⁺ 2025-09-06
Ý kiến Hacker News
  • Vào khoảng 2001/2002, tôi cần xây dựng một hộp WiFi hotspot. Khi đó tôi là fan của OpenBSD và muốn tối giản hết mức một bản phân phối viết bằng Python. Tôi muốn tránh việc sao chép file không cần thiết và các vấn đề phụ thuộc, nên đã chọn khái niệm chroot và jail. Mã triển khai của tôi chạy phần mềm bên ngoài môi trường jail, rồi dùng ptrace để theo dõi các file mà tiến trình mở. Từ đầu ra này tôi trích xuất danh sách phụ thuộc để đóng gói. Kết quả là bản phân phối nhỏ, giữ được tính bất biến và còn tăng cường bảo mật. Khi Docker xuất hiện, nó làm tôi nhớ lại cách cũ đó, và tôi tự hỏi liệu có công cụ tương tự nào theo dõi mức sử dụng file của container Docker để cắt gọn bản phân phối hay không
    • Pipeline CI/CD tốt nhất tôi từng dùng là triển khai Django freelance. Dùng git post-receive hook để tự động build static file và khởi động lại httpd mỗi khi git push. Chỉ cần git push live master là triển khai xong. Tôi đã dùng Docker rất nhiều, nhưng đây vẫn là cách deploy dễ nhất. Tôi hiểu lợi ích của Docker, nhưng thiết lập HTTP trên Ubuntu hay OpenBSD thực ra không khó đến vậy. Tôi vẫn nghi ngờ liệu tính tái lập riêng của Docker có thật sự đáng để chấp nhận mức overhead quản trị đó không
    • Kết quả đầu tiên trên Google là slimtoolkit/slim với 22k sao
    • Trong môi trường OpenWrt có một công cụ tên là ujail, truyền cho nó một file thực thi ELF thì nó sẽ phân tích các phụ thuộc thư viện cần thiết và chỉ mount những file bắt buộc ở chế độ chỉ đọc lên tmpfs
      Liên kết mã liên quan
  • Với tôi, Podman thực sự là một trải nghiệm tuyệt vời. Tôi thấy dùng Docker khó và đầy bẫy, còn Podman thì hoàn toàn không hề kém cạnh. Quan trọng nhất là công ty tôi không phải lo về giấy phép. Đúng là đôi bên cùng có lợi
    • Tôi tò mò không biết trong công ty giấy phép có thật sự là mối lo không. Chính sách giấy phép trả phí của Docker Desktop là hợp lý. Miễn phí nếu dưới 250 nhân viên hoặc doanh thu dưới 10 triệu USD. Ngay cả khi phí giấy phép là 90 USD/năm thì so với lương lập trình viên ở Mỹ còn chưa bằng tiền bữa trưa. Hơn nữa còn có thể dùng công cụ được hỗ trợ chính thức trên mọi OS
    • Thực ra công ty cũng không cần quá lo về giấy phép. Docker Engine là mã nguồn mở hoàn toàn nên miễn phí. Chỉ Docker Desktop mới cần giấy phép riêng khi dùng trong doanh nghiệp. Nhưng phần lớn tính năng đều dùng được trên Docker Engine
    • Podman tốt hơn Docker rất nhiều. Không cần lo chuyện xử lý quyền user/group hay các vấn đề bảo mật của tiến trình root. Cũng không cần gửi dữ liệu vào một daemon
    • Trên một số PC, trình gỡ cài đặt Windows của Podman không xóa sạch mọi thành phần nên khi chạy lại sẽ báo lỗi. Kể cả xóa service thủ công thì vấn đề vẫn còn. Đây là một nguồn gây khó chịu khá thường xuyên
  • Tôi rất thích Podman, nhưng không phải lúc nào nó cũng hoạt động tốt với mọi container. Ví dụ, các container lớn như gitlab thường phụ thuộc vào lịch sử phức tạp và những điểm kỳ quặc của Docker nên hay phát sinh lỗi trên podman. Các image tự làm thì phần lớn chạy tốt trên podman. Với các container có vấn đề, tôi lách bằng cách khởi động một VM incus rồi chạy chúng trong đó. Cả Podman lẫn Docker đều không nhất quán trong cách truy cập GPU nên khá bất tiện. Dù vậy, tôi vẫn nghĩ podman nhỉnh hơn một chút. Đặc biệt là rootless là một lợi thế lớn
    • Tôi đoán phần lớn vấn đề đến từ các image khởi động PID 1 dưới quyền root. Podman mặc định là rootless nên mới phát sinh chuyện này. Nếu muốn dùng cả image dựa trên root mà không cần Docker, bạn có thể tách Podman thành chế độ rootful và rootless rồi chỉ định môi trường mong muốn bằng cờ --connection. Khi cần, Podman còn có thể tự tạo VM (dùng lima). Podman Desktop cũng có lớp tương thích Docker để giảm vấn đề tương thích
    • Chính việc có container không chạy được trên podman có lẽ đã là động lực cho bài blog đó. Khi lượng người dùng đủ lớn, việc kiểm tra cả môi trường podman trước khi publish có lẽ sẽ trở thành thông lệ
    • Chúng tôi đang chạy cả GitLab server và runner bằng podman. Cá nhân tôi muốn chuyển runner sang k8s, nhưng hiện tại dùng Traefik vẫn hoạt động tốt
    • Tôi dùng rất nhiều tính năng liên quan đến buildx, bề ngoài thì podman có vẻ hỗ trợ nhưng thực tế lại không ổn
  • Trên Ubuntu, hỗ trợ podman là vấn đề lớn nhất. Phiên bản podman mặc định của Ubuntu quá cũ nên không thể dùng ngay được. Tôi dùng podman v5, GitHub Actions là v3, còn đồng nghiệp của tôi dùng docker. Kết quả là script của tôi phải chạy được trên podman cũ, podman mới và cả docker, làm phát sinh độ phức tạp
    • Không có kho phát hành bản build .deb nào thật sự đáng tin cậy. Không có .deb chính thức, còn những nơi tôi tìm thấy thì hoặc đã cũ hoặc nói rằng sẽ không cập nhật nữa. Vậy thì câu hỏi là tại sao Podman không làm cho việc cài đặt dễ hơn. Tôi nghĩ là vì RedHat không muốn đổ nguồn lực phát triển vào việc hỗ trợ sản phẩm của đối thủ. Điều này cũng dễ hiểu thôi, nhưng bên ngoài hệ sinh thái RedHat thì có cảm giác như bị xem là công dân hạng hai
    • Tôi nghĩ đây là vấn đề lớn nhất. Độ nhận diện thấp so với Docker cũng là một chuyện, nhưng chính vấn đề lệch phiên bản mới là nguyên nhân lớn hơn khiến Podman trở thành lựa chọn ngách. Các distro như Ubuntu thường cung cấp phần mềm cũ, việc này lẽ ra phía maintainer phải tự xử lý, nhưng phía Podman không làm quá tích cực. Vì thế tôi cũng đã đổi home server sang hệ Red Hat để dùng Podman mới nhất
    • Việc không có .deb upstream chính thức được cung cấp ổn định khiến chúng tôi không thể dùng Podman nội bộ. Nhìn kho .deb chính thức của Docker được quản lý bài bản mà thấy ghen tị
    • Đây cũng là một trong những lý do tôi không dùng Ubuntu/Debian: cập nhật quá chậm. Có thể dùng qua flatpak, nhưng tôi vẫn muốn loại phần mềm này được cung cấp mặc định
    • Vì Podman là mã nguồn mở nên những nơi như Ubuntu hoàn toàn có thể tự đóng gói và cập nhật. Việc RedHat không mặn mà trực tiếp hỗ trợ đóng gói phần mềm cho đối thủ cũng là điều có thể hiểu được
  • Gần đây vì công việc ở công ty mà tôi phải trải nghiệm thiết lập Podman, và đó là một trong những trải nghiệm tệ nhất. Tổ hợp rootless Podman + SELinux + user thường bên trong container đúng là địa ngục
    • Thật ra nếu muốn vật lộn thì với cái gì cũng có thể vật lộn, nhưng thực tế thì phần lớn đều chạy ổn. Tôi đang chạy nhiều service (Forgejo, runner, uptime-kuma, v.v.) bằng container rootless sau reverse proxy nginx trên các máy RHEL10 có bật SELinux
    • Tôi chưa từng thấy được lợi ích của rootless. Nếu máy chỉ là một security domain đơn lẻ thì cứ chạy bằng root cũng không sao, còn nếu không thì nên dùng môi trường cô lập thực sự như VM (Firecracker/Kata, v.v.). Rootless chỉ khiến mọi thứ cực khổ hơn mà lợi ích thì đáng ngờ
    • Tôi cũng gặp đúng tình huống này ở công ty, nhưng nếu giải quyết theo cách riêng của podman (xem docs) thì vẫn dùng được. Điều quan trọng là phải xem tài liệu của phiên bản gần đây
    • Tôi đã chỉ dùng podman trên Fedora hơn 7 năm nay
    • Tổ chức của chúng tôi đã di trú toàn bộ từ Docker sang Podman, giữa chừng có chút lục đục nhưng năng lực của đội SysDev đã xử lý ổn thỏa
  • Có người nói rằng nếu workflow Docker Compose trở nên quá phức tạp thì nên chuyển thẳng sang Kubernetes YAML, nhưng theo trải nghiệm của tôi thì YAML của K8s còn phức tạp hơn docker compose rất nhiều. Và không phải ai cũng dùng Kubernetes
    • Tôi thì nghĩ ngược lại. YAML K8s có độ phức tạp tương đương docker compose, thậm chí đôi khi còn đơn giản hơn. Chỉ là nó cực kỳ dài dòng thôi. Một compose 100 dòng có thể bị tách thành 20 file YAML, mỗi file 50 dòng. Tôi ước gì kubectl có tính năng sugar để chuyển đổi qua lại giữa YAML đơn giản/phức tạp
    • Khi chuyển docker compose sang k8s yaml, dùng LLM làm một lớp chuyển đổi hoạt động cực kỳ tốt. Nhân tiện, podman cũng có tính năng tạo k8s yaml nên có thể chuyển dần khá tự nhiên
    • Tôi không biết tạo file compose, nhưng lại biết viết k8s yaml. Vì vậy compose đối với tôi lại "phức tạp" hơn
  • Lệnh podman generate systemd được nhắc trong bài giờ đã bị deprecated. Giải pháp thay thế là Podman Quadlets, hoạt động giống như một docker-compose.yaml được định nghĩa bên trong file unit của systemd
    • Việc giao compose/orchestration cho systemd là hợp lý. Nó không có cấu trúc client-server như docker mà là tiến trình người dùng thực sự, nên đây rõ ràng là lựa chọn phù hợp
    • Vấn đề là gần như không có tài liệu
  • Việc ánh xạ container nhiều UID sang một user duy nhất trên host là rất khó. Mặc định, root trong container sẽ được ánh xạ sang user đang chạy trên host, nhưng gần đây nhiều ứng dụng bắt đầu dùng user không phải root trong container (ví dụ www-data, user 1000, v.v.). Những user này sẽ được ánh xạ sang secondary ID trên host, và khi đó lúc map volume thì quyền sở hữu file trở thành mồ côi, rất khó hiểu. Rất thiếu một tùy chọn đơn giản để ánh xạ mọi UID về một user duy nhất, còn các tùy chọn hiện có (crun uidmap, userns) thì không hoạt động tốt. Tôi nghi ngờ tính hiệu quả thực sự của việc ánh xạ secondary ID
    • Nếu tôi hiểu đúng thì đây là giới hạn của Linux namespace. Để các công cụ như Docker hay Podman hỗ trợ kiểu ánh xạ này thì bản thân Linux phải hỗ trợ trước. Lý do việc ánh xạ UID 1:1 là cần thiết là vì nếu user 1000 và 0 trong container cùng ánh xạ về một user trên host thì thông tin chủ sở hữu file sẽ bị rối
    • Có lẽ nên xem xét idmapped mount. Nó chỉ hỗ trợ remap ở cấp file system, không giải quyết được các lời gọi kernel
    • Sẽ rất hay nếu có cách để trong container nó cứ hoạt động như chính nó, và trong log cũng hiện nguyên chủ sở hữu như vậy
    • Dùng tùy chọn ignore_chown_errors thì khi ánh xạ root về user ID có thể áp dụng khá đơn giản mà không cần thêm ánh xạ nào khác
  • Tôi đã thử di trú sang Podman nhiều lần nhưng thất bại ở nhiều điểm. Thứ nhất, hiệu năng của podman trên VPS nhỏ của tôi tệ hơn docker rất nhiều (bỏ qua chi tiết). Thứ hai, hệ sinh thái phát triển vẫn chưa theo kịp hoàn toàn. Rất nhiều công cụ phụ thuộc vào socket Docker, còn podman thì không hoạt động tốt vì vấn đề quyền hoặc khác biệt tương thích API. Podman không phải là một bản thay thế drop-in hoàn hảo
    • Nếu dùng rootless podman thì mạng chậm có thể là do slirp4netns. pasta là cách nhanh hơn. Docker mặc định thiết lập mạng bằng daemon có đặc quyền, nên nếu bạn dùng podman dưới quyền root thì về lý thuyết không nên có khác biệt hiệu năng
    • Lỗi quyền SELinux của podman và quadlet vẫn luôn là nỗi đau đầu. Nói chung, thường sẽ dễ hơn nếu tạo một pod có toàn quyền trên host, mount các /dev cần thiết và chỉ phơi ra những chương trình cực kỳ hạn chế trên mạng cô lập
    • Thú vị là trên hệ thống thiếu tài nguyên của tôi, podman lại vượt docker khá xa về hiệu năng và mức dùng tài nguyên. Có vẻ là do khác biệt giữa crun và runc. Thêm nữa, podman không có daemon nên nhẹ hơn
  • Tôi bỏ cả Docker lẫn Podman và chuyển sang FreeBSD Jails
    • Có thể xem thêm thông tin chi tiết và các công cụ quản lý tại đây,
      tại đây,
      tại đây,
      tại đây
    • Có thể chạy ngay MS SQL Server hay hàng nghìn container docker bên trong FreeBSD jail không? Lựa chọn FreeBSD đòi hỏi cái giá khá lớn như giới hạn tương thích chẳng hạn. Đó là lý do jails không thể trở nên phổ biến hơn
    • Thiết lập có vẻ rất nhiều, tôi tò mò không biết FreeBSD có thứ gì như containerd không
    • FreeBSD jails là một đặc tính đặc thù của distro đó
    • Tôi tò mò không biết FreeBSD jail khác gì so với việc chạy VM trên host Linux