Khám phá Podman, giải pháp thay thế Docker được tăng cường bảo mật

 (betterstack.com)
6 điểm bởi GN⁺ 2024-01-14 | 1 bình luận | Chia sẻ qua WhatsApp
  • Podman cung cấp trải nghiệm chạy container tương tự Docker, nhưng khác biệt ở chỗ hoạt động không cần daemon, giúp tốt hơn về bảo mật và truy vết kiểm toán
  • Docker dùng kiến trúc client-server xoay quanh Docker daemon, còn Podman tạo container trực tiếp trong phiên người dùng, nên việc truy vết người dùng thực thi rõ ràng hơn
  • Vì tuân theo chuẩn OCI, Podman có thể chạy các image như hello-world, caddy, wordpress, mysql:5.7 trên Docker Hub; trong nhiều trường hợp có thể thay lệnh docker bằng podman
  • Tên image rút gọn không tự động mặc định là Docker Hub như Docker, nên cần một trong các cách: tên image đầy đủ, alias, hoặc cấu hình unqualified-search-registries
  • Cấu hình nhiều container có thể được xử lý bằng Podman Compose, pods, hoặc Kubernetes manifest, nhưng Podman không có orchestration tích hợp cho production như Docker Swarm, nên cần dùng hệ thống bên ngoài như Kubernetes

Điểm khác biệt giữa Podman và Docker

  • Podman là một container engine mã nguồn mở hướng tới mục tiêu trở thành lựa chọn thay thế an toàn và nhẹ hơn Docker
  • Podman chạy container mà không cần daemon thường trực, với cấu trúc trong đó người dùng trực tiếp quản lý container
  • Định hướng bảo mật mặc định tập trung vào rootless container, user namespace và việc sử dụng capability của kernel một cách thận trọng hơn
  • Khả năng tương thích cao với Docker image và hệ lệnh của Docker khiến Podman trở thành lựa chọn thực tế cho nhà phát triển và quản trị viên hệ thống đang tìm giải pháp thay thế Docker

Kiến trúc và truy vết kiểm toán

  • Docker sử dụng mô hình client-server, trong đó yêu cầu chạy container được chuyển từ Docker client đến Docker daemon
    • Tiến trình container trở thành tiến trình con của Docker daemon, không phải của phiên người dùng
    • Khi hệ thống Linux Audit là auditd phát hiện sự kiện từ tiến trình container, audit user ID có thể hiển thị là unset thay vì ID người dùng thực tế
    • Với cấu trúc này, rất khó liên kết hoạt động độc hại với một người dùng cụ thể
  • Podman sử dụng kiến trúc không daemon
    • Mỗi container được tạo trực tiếp thông qua phiên đăng nhập của người dùng
    • Dữ liệu tiến trình container giữ lại thông tin người dùng
    • auditd có thể phát hiện và ghi lại chính xác ID người dùng đã khởi chạy một tiến trình container cụ thể
  • Tùy theo image, tốc độ khởi động container của Podman có thể nhanh hơn Docker tới 50%

Quản lý vòng đời container

  • Vì Podman không có daemon, cách quản lý vòng đời container cũng khác Docker
  • Trên Linux, Podman phụ thuộc nhiều vào Systemd
    • Podman dùng một dịch vụ systemd tên là podman-restart để áp dụng chính sách khởi động lại cho các container được chỉ định bằng cờ --restart always
    • Dịch vụ này tự động khởi động lại các container được chỉ định sau khi hệ thống reboot
  • Podman cũng cung cấp lệnh để tạo file dịch vụ Systemd từ container đang chạy
    • Khi đặt container dưới sự quản lý của systemd, việc khởi động, dừng và kiểm tra trở nên dễ dàng hơn
  • Docker xử lý các tác vụ này bên trong daemon

Các lựa chọn orchestration

  • Trong phát triển cục bộ, người dùng Docker thường định nghĩa và quản lý ứng dụng nhiều container bằng Docker Compose
  • Podman không hỗ trợ file Compose theo mặc định, nhưng cung cấp Podman Compose như một lựa chọn thay thế tương thích
    • Nhìn chung, công cụ này hoạt động với các file docker-compose.yml hiện có
    • Người dùng đã quen Docker Compose có thể tiếp tục dùng các file Compose hiện tại
  • Theo cách native của Podman, có thể dùng pods
    • Đây là khái niệm lấy từ Kubernetes
    • Có thể quản lý nhiều container như một đơn vị duy nhất
  • Trong triển khai production, Podman không có công cụ orchestration tích hợp như Docker Swarm
    • Trong trường hợp này, hệ thống orchestration bên ngoài như Kubernetes là lựa chọn thay thế
    • Kubernetes có thể tích hợp với Podman, nhưng có thể cần cấu hình và thiết lập bổ sung để hoạt động đúng

Giá trị bảo mật mặc định

  • Một rủi ro lớn trong bảo mật container là tình huống container escape khiến hệ thống host bị xâm phạm
  • Podman được thiết kế để cung cấp thiết lập bảo mật mặc định mạnh hơn Docker
    • rootless container
    • user namespace َ- seccomp profile
  • Docker cũng có thể dùng rootless container, user namespace và seccomp profile, nhưng chúng không được bật mặc định và thường cần cấu hình bổ sung
  • Cấu hình mặc định của Podman chạy rootless container trong user namespace được cô lập, giúp hạn chế tác động của các khả năng escape tiềm tàng
  • Thiết lập mặc định của Docker chạy tiến trình container dưới quyền root, dẫn tới rủi ro cao hơn nếu xảy ra escape
  • Giá trị mặc định về capability cũng khác nhau
    • Podman mặc định khởi động container với 11 capability
    • Docker dùng 14 capability với thiết lập mặc định thoáng hơn
  • Cả hai công cụ đều có thể được cấu hình theo hướng bảo mật mạnh, nhưng Podman thường cần ít công sức hơn để đạt trạng thái đó

Những khác biệt nổi bật khi so sánh tính năng

  • Podman hỗ trợ kiến trúc không daemon và tích hợp Systemd
  • Có thể gom container thành pods và xử lý Kubernetes YAML
  • Docker hỗ trợ Docker Swarm, còn Podman thì không
  • Hầu hết các tính năng còn lại có thể xem là nhìn chung tương đương giữa hai bên

Cài đặt và môi trường chạy

  • Podman có thể chạy trên các hệ điều hành chính giống Docker
    • macOS
    • Windows
    • Các bản phân phối Linux phổ biến
  • Khác biệt quan trọng là trên Linux, Podman chạy native, còn trên Windows và macOS thì cần máy ảo
  • Ví dụ giả định dùng các bản phân phối Linux dựa trên Debian như Ubuntu, Mint, Debian
  • Để cài Podman mới nhất, cần bản phân phối tương đối gần đây
    • Tại thời điểm bài viết, phiên bản Podman chính mới nhất là 4.x
    • Ubuntu 22.04 LTS bị giới hạn ở Podman 3.x
    • Ví dụ dựa trên Ubuntu 23.10
  • Sau khi cài đặt, output ví dụ là podman version 4.3.1, xác nhận có thể chạy lệnh podman cục bộ

Chạy Docker image và khả năng tương thích OCI

  • Podman có thể chạy image hello-world được xây dựng bằng công cụ trong hệ sinh thái Docker
  • Khả năng tương thích này có được vì cả Docker và Podman đều tuân theo chuẩn OCI(Open Container Initiative)
    • OCI định nghĩa đặc tả định dạng image và đặc tả runtime
    • Cho phép các container runtime khác nhau tương tác với nhau
  • Phần lớn Docker image và container trên Docker Hub có thể được dùng trong Podman
  • Có thể chuyển workload hiện có sang Podman mà không cần chỉnh sửa, hoặc tận dụng thư viện image trên Docker Hub
  • Ngay cả khi output của hello-world hiển thị “Hello from Docker!”, thực thể thực sự chạy vẫn là Podman
    • Docker client hay Docker daemon không tham gia vào quá trình chạy

Cách xử lý tên image rút gọn

  • Nếu không chỉ định tên image đầy đủ, Docker dùng Docker Hub là docker.io làm registry mặc định
  • Podman không khuyến nghị dùng tên rút gọn và không tự động giả định registry mặc định
  • hello-world có alias trong shortnames.conf nên được diễn giải thành docker.io/library/hello-world
  • Nếu chạy một image không có alias như caddy bằng tên rút gọn, lỗi sau sẽ xảy ra
    • Error: short-name "caddy" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf"
  • Có ba cách xử lý
    • Dùng tên image đầy đủ, chỉ định rõ như docker.io/library/caddy
    • Thêm section [aliases] vào registries.conf để định nghĩa alias "caddy"="docker.io/caddy"
    • Thiết lập unqualified-search-registries=["docker.io"] để tìm tên rút gọn trên Docker Hub
  • Cấu hình theo từng người dùng có thể đặt tại $HOME/.config/containers/registries.conf
    • File này được ưu tiên hơn /etc/containers/registries.conf
    • Có thể cấu hình mà không cần quyền root, phù hợp hơn với cách tiếp cận rootless
  • Nếu dùng Podman như một giải pháp thay thế Docker, về lâu dài cấu hình unqualified-search-registries sẽ tiện hơn alias

Sử dụng private registry

  • Podman có thể dùng private registry giống Docker
  • Ví dụ dùng tài khoản Docker Hub theo luồng sau
    • Tạo access token trên Docker Hub
    • Đặt mô tả là Podman tutorial, quyền là Read & Write
    • Tạo private repository
    • Đăng nhập bằng podman login docker.io
  • Nếu docker.io là mục unqualified-search-registries đầu tiên trong registries.conf thì có thể bỏ qua, nhưng việc chỉ định registry là thực hành tốt
  • Nếu không cung cấp registry, podman login sẽ thất bại với lỗi sau
    • Error: no registries found in registries.conf, a registry must be provided
  • Sau khi đăng nhập, có thể push image hello-world lên private repository, xóa image public cục bộ, rồi chạy container từ image trong private repository
  • Nếu không có thông tin đăng nhập hợp lệ, khi pull private image sẽ xảy ra lỗi từ chối truy cập và yêu cầu xác thực
  • Điểm khác biệt đáng chú ý khi dùng private registry là dùng tiền tố podman thay vì docker; Podman có thể dùng cùng các private registry phổ biến

Chạy nhiều container bằng Podman Compose

  • Khi cần chạy nhiều container như một đơn vị, Podman cung cấp nhiều lựa chọn
    • Podman Compose
    • pods
    • Kubernetes manifests
  • Ví dụ dùng Podman Compose để chạy WordPress và MySQL
  • Podman Compose là công cụ do cộng đồng dẫn dắt, triển khai Compose specification và tích hợp với Podman
  • Công cụ này phụ thuộc vào Python 3; trong ví dụ được cài bằng pipx
    • Output cài đặt ví dụ là podman-compose 1.0.6
    • Phiên bản Podman được dùng là 4.3.1
  • Nếu pipx được cài vào $HOME/.local/bin, đường dẫn đó có thể chưa nằm trong $PATH
    • Có thể thêm đường dẫn bằng pipx ensurepath
    • Cần mở terminal mới hoặc đọc lại file cấu hình shell

Ví dụ WordPress và MySQL

  • Ví dụ định nghĩa người dùng, mật khẩu và tên database trong file .env, rồi cấu hình các service WordPress và MySQL bằng docker-compose.yml
  • Khi chạy podman-compose up -d, Podman Compose phân tích docker-compose.yml
  • Quá trình xử lý service wordpress
    • Tìm external volume cần thiết và tạo nếu chưa có
    • Tìm network phù hợp và tạo nếu chưa có
    • Chạy container wordpress
    • Nếu không có image cục bộ, kéo wordpress:latest từ registry docker.io đã cấu hình
  • Quá trình xử lý service db
    • Tạo volume podman-tutorial_db
    • Kiểm tra network hiện có
    • Chạy container mysql:5.7
    • Nếu không có image cục bộ, kéo từ Docker Hub
  • Sau khi chạy, có thể thấy trang cài đặt WordPress tại localhost:8080
  • Output của podman ps hiển thị container wordpress và db đang chạy
    • wordpress được map cổng dưới dạng 0.0.0.0:8080->80/tcp
    • db chạy bằng image mysql:5.7
  • Danh sách image hiển thị docker.io/library/wordpress:latest và docker.io/library/mysql:5.7
  • Danh sách network hiển thị network podman mặc định và network podman-tutorial_default do Podman Compose tạo
    • podman-tutorial_default được tạo để tách các container được định nghĩa trong docker-compose.yml khỏi những container khác trên cùng hệ thống
  • Danh sách volume hiển thị podman-tutorial_db và podman-tutorial_wordpress
  • podman-compose down dừng và xóa container nhưng giữ lại network và volume
    • Dùng podman volume rm để xóa volume
    • Dùng podman network rm để xóa network
  • Các lệnh gần như giống Docker và Docker Compose; khác biệt là gõ podman và podman-compose thay cho docker và docker-compose

Tiêu chí lựa chọn

  • Podman là một lựa chọn thay thế thực tế cho Docker để chạy container workload
  • Podman có thể thực hiện hầu hết những việc Docker làm được, với lợi thế không cần daemon chạy nền
  • Podman cũng cung cấp các tính năng mà Docker không có
    • Làm việc với file Kubernetes manifest
    • Tổ chức từng container thành pods
  • Nếu cần giải pháp quản lý container nhẹ hơn và an toàn hơn, Podman có thể là lựa chọn tốt hơn
  • Nếu ưu tiên hệ sinh thái mạnh và hỗ trợ cộng đồng rộng, Docker có thể phù hợp hơn
  • Có thể tham khảo thêm trang web chính thức của Podman, tài liệu, cộng đồng

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-01-14
Ý kiến trên Hacker News

  • Tôi từng thích thời Podman hỗ trợ tệp unit systemd. Vì không chỉ container mà cả toàn bộ pod cũng có thể tự khởi động và tự cập nhật bằng systemd
    Nhưng rồi họ bỏ tính năng đó và bắt đầu đẩy Quadlet. Container đơn lẻ thì có thể làm bằng tệp unit, nhưng pod thì phải dùng định nghĩa cụm Kubernetes
    Hơn nữa, khác với Docker, container tuân theo định nghĩa SELinux, nên tôi đã nhiều lần khổ sở vì không truy cập được các thư mục đã ánh xạ
    Rốt cuộc tôi không hiểu Podman muốn mình làm gì. Dùng Kubernetes à? Đừng ánh xạ các đường dẫn logic mà tạo toàn bộ thư mục chuyên dụng riêng à?

    • Hạ tầng của tôi vốn đã được định nghĩa bằng docker-compose.yml, rồi tôi phát hiện podman-compose có một tính năng được tài liệu hóa sơ sài để tạo unit systemd
      Tính năng này không dùng tính năng Podman đã bị loại bỏ nữa mà tự viết trực tiếp tệp unit, và cá nhân tôi thấy mượt hơn nhiều so với cách Podman cũ
      Bật tính năng bằng $ podman-compose systemd -a create-unit, còn đăng ký unit systemd bằng $ podman-compose systemd -a register, $ systemctl --user enable --now "podman-compose@$PROJECT_NAME"
      Việc cập nhật được xử lý bằng $ podman-compose pull rồi $ systemctl --user restart "podman-compose@$PROJECT_NAME". $PROJECT_NAME thường là tên thư mục
      Nếu muốn kiểm tra, mã nguồn của tính năng ở đây: https://github.com/containers/podman-compose/blob/f6dbce3618...
      Tôi vẫn đang dùng podman 4.3.1, nhưng không thấy có lý do gì để cách này ngừng hoạt động ở các phiên bản sau
    • Việc “khác với Docker, container tuân theo định nghĩa SELinux” thực ra lại là lỗi của Docker. Nếu hệ thống không được cấu hình cho SELinux thì nên tắt nó đi
      Và các tệp systemd mà podman-generate-systemd từng tạo ra rốt cuộc cũng chỉ chạy kiểu "podman start containername", nên tự viết cũng dễ. Chỉ có điều, khác với những thứ như docker-compose, container gần như là hộp đen
      Ưu điểm của Quadlet là định nghĩa container được khai báo trong tệp .container. Trước đây người ta phải tự ghi dòng lệnh podman run vào unit systemd, nên ở khía cạnh đó Quadlet là một cải tiến lớn và cũng có thể là lựa chọn thay thế cho docker-compose. Tất nhiên vẫn có ưu nhược điểm
    • Tôi là fan lâu năm, nhưng phần này thì đồng ý
      Mỗi lần định chạy podman generate systemd [...], tôi lại nhớ ra đã có sự chuyển đổi này
      Lý do tôi không gặp thường xuyên là vì tôi đã tự tạo một role Ansible xử lý việc này theo cách khá ổn
      Dù vậy, cảm giác Podman đã lạc hướng khá rõ. Họ đã chấp nhận hướng bảo trì tệp unit và thiết kế quan hệ rồi, nên cứ để tôi dùng trình sinh là được. Tôi không quan tâm Quadlet hay chuyện nó tốt hơn
    • Nếu không muốn xử lý SELinux, chỉ cần thêm dòng sau vào containers.conf: [containers] label=false
      Nếu không thích mức bảo mật mặc định của Podman, thường sẽ có cách để tắt nó
    • Gần đây tôi chuyển sang NixOS, và NixOS xem systemd là chuẩn cho mọi thứ, kể cả container
      Mô hình này rất trực quan, nhưng để áp dụng cho Docker Compose thì cần chuyển đổi thủ công khá nhiều
      Vì vậy tôi đã tạo một công cụ chuyển tệp Compose thành cấu hình NixOS để có thể diễn giải và quản lý theo kiểu native: https://github.com/aksiksi/compose2nix

  • Có một ưu điểm gần như không được nhắc tới như lý do quyết định để chọn Podman thay vì Docker: Docker làm hỏng cấu hình mạng
    Cố chạy đồng thời Docker và máy ảo KVM cùng với bridge là một cơn ác mộng, còn Podman thì hòa hợp hơn nhiều ngay cả với cấu hình mặc định
    VPN cũng nhiều lần bị Docker làm hỏng, hoặc ngược lại làm hỏng Docker. Tôi không rõ networking của Podman bên trong hoạt động thế nào, nhưng ít nhất nó có vẻ được thiết kế tốt để không cản trở các công việc khác. Với Docker thì tôi tuyệt đối không thể nói như vậy

    • Với tôi, Buildah mới là tính năng cốt lõi thật sự. Nó có thể hoạt động tốt với Docker, nhưng gần với cùng họ công cụ như Podman hơn
      Tôi xem Dockerfile là rác rưởi thuần túy. Ngôn ngữ có sẵn đã đủ rồi, tôi thật sự ghét việc “lập trình viên rảnh rỗi” lại tạo thêm DSL hay ngôn ngữ lập trình mới. Đặc biệt nếu là YAML thì càng vậy, dù trường hợp này không phải YAML, nhưng Dockerfile là một ví dụ tuyệt vời cho thấy vì sao nên dừng làm những chuyện như thế
      Nhìn Buildah không có bud là thấy lý do. Chỉ cần use case hơi lệch khỏi đường chuẩn là bạn có thể dùng Bash, Fish hay bất cứ thứ gì mình muốn, thay vì một DSL vụng về gây khó chịu
      Những quyết định tệ như vậy lan ra toàn bộ hệ sinh thái Docker. DCS và các lựa chọn thay thế luôn dang dở của nó cũng là ví dụ. Thay vì dùng một giao thức ký đã được xác lập như Cosign, họ lại muốn tạo ra một hệ thống phức tạp, khó tự động hóa và đặc biệt khó xoay vòng khóa
    • Podman miễn phí. Docker cũng miễn phí, nhưng cài Docker mà không dùng Docker Desktop thì phiền phức
    • Tôi hiện vẫn đang chạy Docker và máy ảo KVM cùng với bridge, và nó cứ hoạt động bình thường, không ác mộng gì cả. Hơi lạ

  • Việc Podman được dùng rộng rãi hơn là điều đáng mừng. Quá nhiều công cụ được tạo ra với giả định rằng người dùng sẽ thêm nhóm sudo docker, nên chúng bị lỗi trong cấu hình Docker có ý thức bảo mật, kiểu không cấp bừa quyền root

    • Lúc nào tôi cũng thấy buồn cười khi cái tương lai tân tiến như serverless và container rốt cuộc lại được xây trên nền tảng chạy đủ thứ bằng root

  • Là một kỹ sư RHEL được chứng nhận, tôi đã dùng Podman được vài năm rồi
    Nói thật là với nhu cầu dùng container cá nhân thì tôi khá thích nó. Nhưng ở nơi làm việc, chúng tôi vẫn cung cấp Docker cho các lập trình viên. Cho đến nay vẫn chưa có cách nào cung cấp cho lập trình viên thứ gì sánh được với sự đơn giản của docker compose
    Khi tạo image container, trong pipeline CI chúng tôi cũng dùng buildah, nhưng xét từ góc độ người dùng cuối là lập trình viên thì docker compose vẫn đang thống trị

  • https://www.techrepublic.com/article/how-to-fix-the-docker-a...
    Tôi suýt nữa đã dính vì vấn đề này

    • Docker, chỉ với cấu hình và cài đặt mặc định, cũng đã động vào iptables. Đặc biệt khi muốn dùng nftables mới hơn, nó luôn là một chuyện đau đầu
    • Vì lựa chọn mặc định không an toàn của Docker, một container tự host cá nhân của một dự án GitHub vốn được ghi là chỉ dùng riêng qua VPN đã bị cài trình đào tiền mã hóa vào. Đến giờ vẫn còn bực
    • Nói về các vấn đề networking, từng có một sự cố lớn trong cấu hình lồng nhau khi bộ nhớ dành cho thiết bị mạng bị cạn, khiến phải khởi động lại hệ thống. Nếu không vì chuyện đó thì nó đã là một lựa chọn thay thế lxc tuyệt vời, thật đáng tiếc

  • Tôi vẫn chưa rõ vì sao Red Hat lại đầu tư vào việc tạo ra một giải pháp thay thế Docker, nhưng tôi thật sự thích kết quả
    Podman làm được gần như mọi thứ Docker làm, đồng thời còn có thêm các tính năng như pod, hoặc trong nhiều trường hợp cách làm của nó tốt hơn, chẳng hạn quy trình tạo container không cần daemon
    Vấn đề lớn nhất với lập trình viên thông thường có lẽ là Docker compose, nhưng nếu dùng file compose đơn giản thì có script podman-compose cố gắng tương thích với đặc tả Docker compose
    Cũng có cách dùng Podman làm backend cho docker-compose [1]. Nhìn chung, trong năm 2024 tôi không thấy lý do gì phải dùng Docker trên máy Linux. Tôi không rõ Podman trên macOS hay Windows thì thế nào
    [1] https://www.redhat.com/sysadmin/podman-docker-compose

    • Ban đầu Red Hat từng hợp tác với Docker để cố sửa nhiều vấn đề đã lộ ra trước đây, chẳng hạn vấn đề tương thích systemd trong một số trường hợp sử dụng cụ thể, nhưng không đạt được mấy kết quả
      Kết hợp với việc Docker trước đây cũng như hiện nay có rất nhiều vấn đề bảo mật một cách bất thường, trong khi container và image kiểu Docker lại được giới lập trình viên dùng cực kỳ rộng rãi, Red Hat gần như buộc phải tạo một triển khai riêng phù hợp hơn với giá trị và cách tiếp cận của RHEL
      Ví dụ Docker có thể chạy rootless nhưng đến nay vẫn không dùng làm mặc định. Trong môi trường được gia cố bảo mật, cả nhóm người dùng docker lẫn cách chạy không cần nhóm đều khó được chấp nhận về mặt bảo mật trong nhiều trường hợp sử dụng
      Docker thời kỳ đầu quá thiếu tích cực trong việc bảo đảm container không đặc quyền có được ít nhất mức cô lập tối thiểu, và ngay cả sau khi vấn đề đã được biết đến, họ cũng mất rất lâu để sửa. Cách nó tương tác với firewall, quy tắc mạng và SELinux cũng có nhiều vấn đề. Đây là lý do không hiếm công ty có quản trị viên hệ thống Linux chuyên trách coi trọng bảo mật cấm Docker
    • Tôi đang dùng Podman trên Windows. Docker trên Windows là chuỗi bực bội và thất vọng không hồi kết
      Ngay từ đầu, mọi tài liệu đều hướng người dùng một cách khá gắt sang trình cài đặt GUI không thân thiện. Nó khởi chạy các tiến trình nặng khi boot, vì lý do nào đó lại yêu cầu đăng ký tài khoản đám mây, rồi còn liên tục nhắc rằng không được dùng cái gọi là sản phẩm mã nguồn mở này cho công việc
      Phương án không được hỗ trợ để cài “chỉ Docker dòng lệnh” thì phức tạp một cách không cần thiết, và lần cuối tôi thử, hầu hết VM WSL ở trạng thái mặc định cũng không hỗ trợ
      Ngược lại, Podman chỉ cần winget install podman là xong và không làm phiền. Chỉ khi cần chạy container tôi mới khởi động Podman VM, còn khi không cần thì hệ thống hoạt động như trước
      Nếu cần chạy thứ gì đó bằng file compose thì có podman-compose. Có thể nó không xử lý được các cấu hình lạ, nhưng với nhu cầu của tôi thì chạy tốt
      Thứ Podman chưa làm tốt chỉ khoảng tích hợp VS Code, nhưng công sức để bắt Docker trên Windows chạy ngoan ngoãn còn khó chịu hơn nhiều so với việc mất vài phím tắt VS Code, nên không thành vấn đề
      Tôi khuyên dùng Podman làm giải pháp container mặc định trên Windows. Lý do để dùng Docker chỉ là công ty trả phí cho bạn, hoặc bạn có cấu hình compose phức tạp; nếu vậy thì cũng có thể đáng cân nhắc chuyển sang Kubernetes
    • Lý do Red Hat đầu tư là vì Docker quá xa rời cách mọi việc được xử lý trên Linux
      Nó làm những việc phá hệ thống, chật vật với rootless suốt nhiều năm, và cũng không thể bỏ qua khóa chặt nhà cung cấp
      Podman mở, tuân theo chuẩn và cũng khớp tốt với Kubernetes. Chỉ vì ra mắt sớm hơn trong thị trường container dễ dùng mà các lập trình viên đã đổ công sức vào Docker nhiều đến mức vô lý
    • Tôi hy vọng quan điểm “trên Linux không có lý do gì để dùng Docker” sẽ không trở thành quan điểm đa số. Docker không phải RedHat/IBM
      Nếu Docker biến mất, RedHat sẽ có thêm sức mạnh để áp đặt nghị trình doanh nghiệp của mình
      Podman có ưu điểm, nhưng trong quá trình RedHat cố thay thế mọi thứ của Docker, cũng có những phần được thực hiện không tốt
      Nhìn vào lịch sử cách RedHat tiếp cận lĩnh vực container, có khía cạnh là họ đã lãng phí thời gian và công sức vào nhiều dự án mà lẽ ra họ có thể đóng góp và cải thiện
      RedHat không phải công ty có nghị trình làm điều đúng đắn cho khách hàng, nên cần nghĩ xem trong bức tranh lớn hơn mình mong muốn điều gì
    • Tôi đang dùng Podman trên macOS. Nhìn chung trải nghiệm tốt hơn Docker, đặc biệt là về hỗ trợ các phiên bản macOS cũ
      Nhược điểm lớn duy nhất của Podman cho macOS là không thể dùng mạng của host từ container. Nhưng cũng hiếm khi người ta muốn dùng mạng host từ container
      Tuy vậy, nếu bạn đang thử nghiệm liên quan đến mạng bên trong container và muốn giữ cùng hostname và địa chỉ IP như host thì cần lưu ý. Dù vậy tôi vẫn đang dùng bằng cách обход qua giới hạn này

  • Tôi thích cách tiếp cận ưu tiên bảo mật và các quyết định của họ. Tôi thích việc cấu hình mặc định đã an toàn và vẫn hoạt động với docker compose
    Tuy nhiên, tôi tự hỏi liệu nếu Podman đủ phổ biến thì một ngày nào đó họ có đi theo hướng riêng về lệnh và định dạng yml hay không. Hiện giờ nó trông giống một công cụ dựa vào Docker và định dạng file Docker compose
    Tôi mong Podman có một giải pháp thay thế Swarm. Hiện tại, do thiếu orchestration nên Kubernetes có cảm giác như đang bị dùng làm cái nạng
    Với một đội ngũ suy xét kỹ về bảo mật, có lẽ họ có thể tạo ra một cách chạy container hợp lý và đơn giản ở quy mô nhỏ mà không cần đào sâu Kubernetes như làm luận án tiến sĩ, trong khi Kubernetes vốn không an toàn ngay từ mặc định. Đồng thời vẫn có thể duy trì tương thích với định dạng Docker compose

  • Đồng ý rằng container rootless và namespace được cô lập là những tính năng bảo mật quan trọng. Nhưng Docker rootless cũng làm được và không phức tạp. Chỉ cần cấu hình như vậy là được
    Tôi từng viết một bài về cách thiết lập Mastodon bằng docker rootless, áp dụng tất cả các best practice hiện có [1]
    Lợi thế của việc tiếp tục dùng Docker là tính dễ tiếp cận cao hơn. Có nhiều cộng đồng và blog hơn, cấu hình docker compose phổ biến rộng rãi, và xung quanh cũng có nhiều người biết dùng hơn
    Rốt cuộc thì cả Podman lẫn Docker đều chạy tiến trình trong namespace được cô lập của host
    [1]: https://du.nkel.dev/blog/2023-12-12_mastodon-docker-rootless...

  • Mong là đừng có hiểu lầm. Podman rất tuyệt và dạo này tôi dùng nó thay cho Docker, nhưng ban đầu tôi bắt đầu dùng vì nghĩ nó chỉ là một bản thay thế Docker đơn giản, rồi đã bị “dính đòn” nặng với ánh xạ UID/GID, policy SELinux, cấu hình DNS bị thiếu, v.v.
    Cũng đã vài lần tôi chạy system migrate để sửa lỗi rồi làm hỏng toàn bộ cấu hình. Nó có cả một hệ thống riêng liên quan đến ACL bảo mật, ánh xạ ID và label
    Nếu chạy chmod -R dưới thư mục home thì có lẽ tất cả container có thể chết hết
    Tôi hài lòng với kết quả, nhưng nó còn xa mới là giải pháp “cứ chạy là được” như Docker. Có lẽ từ khi tôi bắt đầu dùng đến nay nó đã được cải thiện nhiều

    • Tôi bắt đầu dùng từ năm nay, với mục đích cô lập nhiều môi trường phát triển và không để npm dễ dàng truy cập toàn bộ máy dev
      Theo tôi thì nó dễ dùng hơn Docker. Có vẻ hiện giờ đã cải thiện so với những tình huống bạn gặp ở trên

  • Nhìn ở bức tranh lớn, Podman tạo cảm giác như một thứ thiết yếu giống Linux ngày xưa
    Dù chỉ có rất ít người dùng, chỉ riêng sự tồn tại của nó cũng ngăn những người anh em phần mềm sở hữu độc quyền lớn hơn rất nhiều làm những điều tồi tệ
    Ở đây khi nói “Linux ngày xưa” không có nghĩa là Linux đã kém quan trọng hơn, mà là vì hiện nay nó thậm chí còn thiết yếu và trung tâm hơn

    • Nếu “những người anh em phần mềm sở hữu độc quyền lớn hơn rất nhiều” là nói đến Docker thì hơi mỉa mai. Vì RedHat và IBM cũng làm không ít điều tệ trong lĩnh vực mã nguồn mở