เปิดตัว Podman v6.0.0

 (blog.podman.io)
1 คะแนน โดย GN⁺ 3 시간 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Podman v6.0.0 เป็นเมเจอร์รีลีสที่ปรับแต่งประสบการณ์การจัดการคอนเทนเนอร์ให้ดีขึ้น โดยรวมทั้ง การทำให้โครงสร้างพื้นฐานหลักทันสมัยขึ้น และการปรับปรุงด้านความปลอดภัยและการใช้งาน
  • ระบบเครือข่ายย้ายจากแนวทางที่เน้น slirp4netns และ iptables ไปสู่พื้นฐาน Netavark, Pasta และ nftables เพื่อลดภาระการบำรุงรักษา และเตรียมพร้อมสำหรับการขยายฟีเจอร์ต่อไป
  • ฟีเจอร์ทดลอง Pesto rootless port forwarding รองรับการรักษา source IP ที่ถูกต้องในคอนเทนเนอร์แบบ rootless บนเครือข่ายแบบกำหนดเอง
  • Podman Machine ปรับปรุงการใช้งานกับผู้ให้บริการ VM หลายราย และทำให้สามารถรักษาสภาพแวดล้อม VM ให้เป็นเวอร์ชันล่าสุดได้ด้วย podman machine os update
  • Quadlet, การจัดการไฟล์ตั้งค่า, ความเข้ากันได้กับ Docker API และเอาต์พุตคำสั่งก็ได้รับการปรับปรุง ทำให้การจัดการผู้ใช้หลายคนและการย้ายจาก Docker ง่ายขึ้น

สิ่งที่เปลี่ยนไปใน Podman v6.0.0

  • สามารถดูรีลีสล่าสุดได้ที่ หน้ารีลีสบน GitHub และคาดว่าจะถูกเผยแพร่ผ่าน package manager ในเร็วๆ นี้

  • การทำให้ระบบเครือข่ายทันสมัยขึ้น

    • เปลี่ยนจาก slirp4netns และ iptables ไปสู่ Netavark, Pasta และ nftables
    • สแต็กเครือข่ายที่จัดระเบียบใหม่นี้ช่วยให้การบำรุงรักษาง่ายขึ้น และเป็นรากฐานสำหรับการเพิ่มฟีเจอร์ในอนาคต
    • การรองรับแบบทดลองสำหรับ Pesto rootless port forwarding ทำให้สามารถรักษา source IP ที่ถูกต้องในคอนเทนเนอร์แบบ rootless บนเครือข่ายแบบกำหนดเองได้

  • การปรับปรุง Podman Machine

    • ปรับปรุงการใช้งานให้จัดการผู้ให้บริการ VM หลายรายได้ราบรื่นขึ้น
    • สามารถรักษาสภาพแวดล้อม VM ให้เป็นเวอร์ชันล่าสุดได้ด้วยคำสั่ง podman machine os update
    • การปรับปรุงเพิ่มเติมที่เกี่ยวข้องจะถูกอธิบายอย่างละเอียดขึ้นในบทความแยกต่างหากในอนาคต

  • การขยาย Quadlet

    • เพิ่มการรองรับ REST API
    • ปรับปรุงการติดตามไฟล์ที่เกี่ยวข้อง ทำให้จัดการได้ง่ายขึ้น
    • ขยายความสามารถของยูนิต .volume
    • รวมพาธค้นหาเพิ่มเติมเพื่อให้ง่ายต่อการทำแพ็กเกจสำหรับการแจกจ่าย

การตั้งค่าและความเข้ากันได้กับ Docker

  • การจัดการไฟล์ตั้งค่า มีการเปลี่ยนแปลง ทำให้ผู้ดูแลระบบที่จัดการสภาพแวดล้อมหลายผู้ใช้ใช้งานได้ราบรื่นและเชื่อถือได้มากขึ้น
  • ความเข้ากันได้กับ Docker ก็ได้รับการปรับปรุงเช่นกัน
    • อัปเดตการรองรับ Docker API
    • ปรับแต่งเอาต์พุตคำสั่ง ทำให้ย้ายจาก Docker ไปยัง Podman ได้ง่ายขึ้น
  • รายการเปลี่ยนแปลงทั้งหมดสรุปไว้ใน บันทึกรีลีส Podman v6.0.0

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
click 3 시간 전

ผมคิดไว้ว่าถ้า podman compose ใช้งานได้ดีพอก็คงจะย้ายไปใช้ แต่ไม่รู้เลยว่าเมื่อไหร่มันจะใช้งานได้ดีจริง ๆ
ทุกวันนี้ผมคิดว่าการรันด้วย docker run โดยตรงมีไว้แค่สำหรับคอนเทนเนอร์ชั่วคราวหรือการรันทดสอบเท่านั้น ดังนั้นการรองรับ compose ที่ยังไม่ดีจึงเป็นจุดอ่อนใหญ่
ถ้าต้องการการตั้งค่าที่ยืดยาวและการจัดการที่แน่นอน ใช้ k8s ไปเลยน่าจะดีกว่า
ในยุคปี 2026 เสน่ห์ของ docker หรือ podman คือการกำหนดสแต็กที่แอปหนึ่งใช้ทั้งหมดได้ด้วยไฟล์ตั้งค่า yml ไฟล์เดียวแบบง่าย ๆ โดยไม่ต้องนิยาม resource หลายอย่างของ k8s
ถ้าจะชูเรื่องความเข้ากันได้กับ k8s งั้นใช้ implementation ของ k8s แบบเบาที่รันบนเครื่อง local อย่าง k3s, minikube หรือ microk8s ไปเลยจะดีกว่ามาก
ผมคิดว่าปัญหาไม่ใช่เรื่อง rootless
 
GN⁺ 3 시간 전
ความเห็นจาก Hacker News

  • ไม่เข้าใจว่าทำไม Docker ถึงยังนิยมมากกว่า Podman อยู่มาก ทั้งที่ถ้าดูจากตัว implementation แล้ว Podman ดีกว่าอย่างชัดเจน และฟีเจอร์เครือข่ายใหม่ก็เป็นการปรับปรุงที่น่ายินดี

    • เหตุผลหลักน่าจะเป็นเพราะการ deploy ยุ่งยากกว่าเล็กน้อย และมีหลายขั้นตอนที่แยกจากกันมากกว่า โดยเฉพาะถ้าจะใช้แบบ rootless ซึ่งจริง ๆ ก็ควรทำแบบนั้น
      สำหรับคนที่ไม่ได้ใช้ Linux เป็นหลัก เช่นนักพัฒนามือใหม่ที่กำลังเรียนรู้การทำแอปให้เป็นคอนเทนเนอร์ การต้องจัดการไฟล์ยูนิต systemd หรือการตั้งค่า kubelet สร้างบัญชี service ภายในเครื่องเฉพาะทาง และยังต้องจำให้เปิด linger อีก มันน่าหวาดหวั่นกว่าการติดตั้ง Docker แล้วสร้างไฟล์ docker compose จากนั้นกด “start” มาก
      เข้าใจว่าทำไมถึงเลือกแนวทางนี้ แต่ก็ค่อนข้างแข็งกระด้างและไม่เป็นมิตร
    • fuse-overlayfs ช้ากว่า overlayfs configuration ของ Docker อย่างเห็นได้ชัด อาจมีวิธี reconfigure ก็ได้ แต่ช่วงหลังไม่ได้ลองเช็ก
      ตอน build ghostty ด้วย Zig เหมือนจะพังบน Podman ด้วย error กำกวมอย่าง “unknown file” แล้วสุดท้ายก็พบว่า fuse-overlayfs ไม่รองรับบาง attribute ที่มันพยายามตรวจสอบ
      ทุกครั้งที่พยายามย้ายมาใช้ ก็มักจะติดปัญหาเล็ก ๆ แบบสุ่มพวกนี้ตลอด ตอนนี้เลยใช้กับงานง่าย ๆ เท่านั้น
    • ตอนที่เช็กล่าสุด podman compose ยังเหมือนแค่มีหน้าตาคล้าย docker compose เท่านั้นเอง พวกอย่าง inotify ก็ดูเหมือนจะพังแบบสุ่มค่อนข้างบ่อยฝั่ง Podman
      อยากแนะนำ Podman นะ แต่ความเข้ากันได้กับ docker compose ยังไม่ดี และถ้าไม่มี inotify บน volume ประสบการณ์ของนักพัฒนาก็มีปัญหามาก
    • ชื่อแบรนด์ที่แข็งแรงกว่าน่าจะเป็นอีกเหตุผลหนึ่ง บน macOS นั้น Docker Desktop ใช้งานได้ตรงไปตรงมามากกว่า แต่ช่วงหลัง error บ่อยมาก และการจัดการ file mount หรือ network rule ก็ล้มเหลวแบบสุ่ม หรืออยู่ ๆ ก็ช้ามากจนต้องรีสตาร์ต VM
      Podman บน macOS ให้ความรู้สึกว่ายังขัดเกลามาไม่ดีเท่า และ OrbStack เป็นตัวเลือกที่ดีกว่ามาก
      ผมใช้ Podman บน Linux เท่านั้น และที่นั่นมันเร็วมาก ถึงอย่างนั้นก็ดูเหมือนว่าฟีเจอร์ส่วนใหญ่ถูกออกแบบมาให้ผูกกับ systemd เพื่อใช้แทน Kubernetes ขณะที่การรองรับ docker compose กลับยังไม่เสถียร และ TUI/UX ก็ยังตามต้นฉบับไม่ทัน
    • เลิกใช้ Podman ด้วยเหตุผลเล็ก ๆ หลายอย่าง อย่างหนึ่งคือมันเลือกจัดการ SELinux ต่างจาก Docker เลยต้องไปแก้ security label ของ SELinux บนระบบ CentOS พื้นฐาน ซึ่งรับไม่ได้สำหรับการนำมาใช้
      อีกปัญหาคือความต่างเล็ก ๆ น้อย ๆ จาก Docker ซึ่งมากพอให้ Docker compose แบบแพ็กเกจใช้งานตรง ๆ ไม่ได้ พอสลับกลับไปใช้ Docker ก็รันได้ทันทีและทำงานต่อทั้งวันได้เลย เลยไม่อยากเสียเวลาไปดีบักเรื่องนี้

  • หลังจาก Docker Desktop อยู่ ๆ ก็เริ่มกินหน่วยความจำมหาศาลแบบสุ่มอีกครั้ง ผมก็ย้ายไปใช้ Podman และมันง่ายแค่ติดตั้งแล้วชี้ไปที่ docker-compose.yml
    ไม่ต้องแก้อะไรเลย และตอนนี้ก็ไม่จำเป็นต้องเปิดเดมอนไว้ตลอดอีกด้วย เป็นซอฟต์แวร์ที่ยอดเยี่ยมมาก

    • colima ดีกว่า Docker Desktop และ Orbstack ก็ดีกว่า colima จากนั้นก็ไปเจอ smolvm microVM ของ https://smolmachines.com's
    • สุดท้ายความ ทำอะไรเพี้ยน ๆ เรื่อง AI ของ Docker ก็ทำให้ผมข้ามเส้นและลองย้ายไป Podman แต่ก็เจอปัญหาความเข้ากันได้อยู่บ้าง จำรายละเอียดไม่ได้แล้วเพราะเป็นเรื่องเมื่อหลายเดือนก่อน
      เลยลองใช้ Rancher Desktop และถ้าไม่นับว่าชอบลืมชื่อมันบ่อย ๆ ก็ถือว่าใช้งานได้ดีเฉย ๆ เป็นอีกตัวเลือกง่าย ๆ สำหรับคนที่ต้องการ

  • ชอบ Quadlet มาก ตลอดหลายปีที่ผ่านมาโฮสต์คอนเทนเนอร์แบบ rootless ด้วย Hetzner, Ansible, SystemD, RockyLinux โดยไม่มีปัญหา และได้แยก configuration นั้นออกมาเป็น template repository แล้ว
    [1] https://github.com/Mati365/hetzner-podman-bunjs-deploy

    • เปลี่ยนโฮมเซิร์ฟเวอร์จาก k3s มาเป็น quadlet แล้ว การใช้พลังงานลดลง 8%

  • อยากรู้ประสบการณ์ของคนที่ย้ายจาก Docker ไป Podman
    ที่กังวลที่สุดคือมีไฟล์ compose เยอะมากในโฮมแล็บ/งานอัตโนมัติ

    • ย้ายจาก Docker ไป Podman เมื่อราว 15 เดือนก่อน และไม่คิดจะกลับไปอีกเลย ส่วนตัวชอบ quadlet หรือก็คือการผสานกับ systemd มาก ทำให้มอนิเตอร์ชุดบริการที่กำลังรันอยู่ได้ง่ายกว่ามาก ไม่ว่าจะเป็น systemd service ปกติหรือคอนเทนเนอร์
      การรันแบบ rootless ก็ตรงไปตรงมามาก และ Podman ก็เร็วมาก ส่วนตัวไม่ได้คิดถึง docker compose มากนัก แต่ก็เข้าใจว่าการไม่มี docker compose อาจเป็นเรื่องใหญ่สำหรับบางคน ไม่เคยลองใช้ compose plugin ของ Podman
    • เปลี่ยนไฟล์ docker compose ขนาดใหญ่ในโฮมแล็บมาเป็น podman quadlet แล้ว เท่าที่จำได้ ตอนย้ายไม่กี่บริการแรกใช้เวลาพอสมควร เพราะเอกสารและตัวอย่างของ quadlet ยังมีน้อยเมื่อเทียบกับไฟล์ compose แต่หลังจากนั้นก็ง่ายมาก แนะนำอย่างยิ่ง
      ปัญหาเดียวคือการตรวจสอบความถูกต้อง ไม่มีคำสั่งในตัวที่สะดวกสำหรับตรวจสอบไฟล์ quadlet และ systemd ก็ไม่ได้เตือนเมื่อสร้างไม่สำเร็จ ต้องรัน --dry-run ก่อน หรือทำคำสั่งเต็มเป็น alias ที่เหมาะสม ไม่ก็ไปดูข้อผิดพลาดใน journal
    • ย้ายมาตั้งแต่หลายปีก่อน ก่อน 5.0 และไม่เคยมองกลับไปอีก ไฟล์ compose ก็น่าลองพิจารณาใช้ quadlet
      ถ้าจะเปลี่ยนแบบเร็ว ๆ จะใช้ podman-compose ตรง ๆ ก็ได้ หรือจะตั้งค่า docker compose ให้ชี้ไปที่ Podman socket ก็ได้[0]
      ยังมี podlet[1] ที่แปลงไฟล์ compose เป็น native quadlet ได้ด้วย โดยทั่วไปไฟล์ compose ที่เรียบง่ายหรือซับซ้อนระดับกลาง ๆ จะจัดการให้ได้ดีและใช้งานได้ทันที มีการคุยกันด้วยว่าจะทำสิ่งนี้ให้อยู่ในรูปแบบไลบรารี เพื่อให้เครื่องมืออื่นแปลงไฟล์ compose เป็น quadlet แบบโปร่งใสได้ ก็คาดหวังว่าจะมีเครื่องมือแนวนี้ออกมาอีกในอนาคต
      ถ้าคุ้นกับไฟล์ systemd unit อยู่บ้าง การเขียนไฟล์ Quadlet เองก็ไม่ยาก อาร์กิวเมนต์ส่วนใหญ่ของ docker run หรือ podman run มีคู่เทียบใน quadlet โดยตรง ดังนั้นพอคุ้นกับรูปแบบ INI แทน YAML แล้ว ก็ไม่ยากที่จะดูไฟล์ compose แล้วเขียน quadlet ที่เทียบเท่ากันออกมา
      [0] https://www.redhat.com/en/blog/podman-docker-compose
      [1] https://github.com/containers/podlet
    • ย้ายทั้งหมดมาเป็น rootless Podman เมื่อ 1–2 ปีก่อน คอนเทนเนอร์บางตัวมีปัญหาเรื่องสิทธิ์ตอนอ่านข้อมูลเก่า ซึ่งสาเหตุคือเคยรันด้วย UID อื่น
      ปัญหาที่เจอจริง ๆ ก็มีแค่นี้ และถึงจะย้ายจาก Docker แบบ root ไป rootless Docker ก็น่าจะเจอปัญหาเดียวกัน ไม่เสียใจเลยและไม่มีวันกลับไปแน่นอน
    • รู้สึกขอบคุณ Podman พอ ๆ กับ git
      Podman มีความเป็นผู้ใหญ่และสมเหตุสมผล ถ้าคอนเทนเนอร์ของใครสักคนพึ่งพาสิทธิ์ su ก็โทษคนนั้น ไม่ใช่ Podman

  • สิ่งที่ไม่ชอบใน Podman คือมันทำเหมือนว่า เข้ากันได้กับ Docker แต่จริง ๆ แล้วมีความต่างเล็ก ๆ น้อย ๆ ที่ตามมาสร้างปัญหาทีหลัง ผู้ใช้โปรเจกต์ที่อิง Docker จะพยายามรันด้วย Podman แล้วสุดท้ายก็มาบ่นกับฝั่งโปรเจกต์

    • ความต่างส่วนใหญ่ไม่ได้มาจาก socket API, พฤติกรรมเชิงตรรกะ หรือความต่างของคำสั่ง CLI แต่มาจากการที่ Docker ถูกสมมติว่ารันด้วยสิทธิ์ root ในขณะที่ Podman ไม่ได้เป็นแบบนั้นโดยปริยาย
      เพราะงั้นการแก้ความไม่เข้ากันระหว่าง Podman/Docker ส่วนใหญ่ก็คือจัดการกับสมมตินี้ เช่น เพิ่มแฟลกบางอย่างให้คำสั่ง Podman เพื่อเปลี่ยนวิธีแมป user namespace ระหว่างคอนเทนเนอร์กับโฮสต์
    • ใช้ Podman บน Mac และ Linux มา 3 ปีแล้ว และน่าเสียดายที่ปัญหานี้เป็นจริงมาตลอด ผมยินดีจะไล่หาต้นตออย่างจริงจังแล้วส่งบั๊ก แต่สำหรับคนจำนวนมากมันคงดูเหมือนพังไปเลย
      ล่าสุดคือ Netavark ทำงานไม่ตรงกับ Docker ในเรื่องการรับ broadcast traffic บนพอร์ตที่ publish ไว้
    • ใช่ เรื่องนี้แหละที่ทำให้ผมลังเลกับ Podman มาหลายปี ตอนนี้คิดว่ามันมีแนวคิดที่ฉลาด และถ้าใช้ RHEL ก็คงเป็นตัวเลือกที่ชัดเจน แต่ควรบอกกันตรง ๆ มากกว่านี้ว่าต้องมีช่วงปรับตัว
      โดยเฉพาะถ้าย้ายจาก Docker แบบ root ไป Podman แบบ rootless

  • อยากรู้ว่าช่วงนี้ Podman เป็นยังไงบ้าง บน macOS ตอนนี้ใช้ OrbStack อยู่และรู้สึกว่าเร็วกว่าเยอะ ถ้า macOS 27 เพิ่ม Linux container ที่เนทีฟและแรงกว่าโดยใช้ microVM คล้าย WSL ก็ไม่รู้ว่าภาพรวมจะเปลี่ยนไปแค่ไหน

    • บน macOS ไม่ค่อยรู้ แต่บน Linux มันเข้ากับการใช้งานของผมได้ลื่นมาก เรื่องเดียวที่ควรรู้คือ Podman Compose ใช้ docker-compose เป็น provider โดยปริยาย
      ไม่เคยลอง provider ที่เป็น podman-compose และชื่อก็ชวนสับสนเพราะคล้ายกับ Podman Compose มาก Podman Compose เป็น abstraction ชั้นบนของ docker-compose หรือ podman-compose อีกที ถ้าจำเป็นก็ยังใช้ Podman ให้รันคอนเทนเนอร์ผ่าน Docker engine ได้
    • คำถามเดียวกัน สถานการณ์เดียวกัน เคยลองใช้บน MacOS แล้วต้องมุดลึกเข้าไปในฟอรัมของ Redhat เพื่อทำความเข้าใจปัญหาแรกที่เจอ การย้ายไป OrbStack แทบเป็นทางเลือกที่ชัดเจน แต่ก็มี trade-off ด้านฟีเจอร์ที่เห็นได้ชัด

  • Quadlet และ rootless containers คือเหตุผลใหญ่สองข้อในการย้ายจาก Docker ไป Podman

    • rootless คือเหตุผลที่ย้ายไป Podman เมื่อหลายปีก่อน มันลื่นไหลมาก และตอนนี้ก็ไม่ต้องกังวลกับปัญหาสิทธิ์แปลก ๆ หรือ service error อีกแล้ว

  • Podman นั้นดี แต่ไม่เข้าใจว่าทำไมถึงใช้สีตัวอักษรเทาแบบนั้น ดูไม่ดี แถม อัตราความต่างคอนทราสต์ 4.96:1 ทำให้อ่านยาก และยังไม่ถึงระดับ WCAG AAA ด้วย

  • รันโฮมเซิร์ฟเวอร์ด้วย podman + quadlets มาเกือบ 2 ปีแล้ว และเห็นบางอย่างใน release note ที่น่าตามดู
    podman quadlet list ถูกเพิ่มเข้ามาใน v5.6.0 ใช้แสดงรายการ quadlet และคอนเทนเนอร์ของมัน
    podman system migrate --migrate-db เป็นแฟลกที่เพิ่มใน v5.8.0 ก่อนหน้านี้เคยเห็นคำเตือนเรื่องเลิกซัพพอร์ต bolt DB แต่ยังไม่มีเครื่องมือย้ายไป sqlite ตอนนี้มีแล้ว หรือถ้าอัปเกรดเป็น podman 6.0.0 มันก็จะจัดการให้อัตโนมัติ

  • อยากรู้ว่ามีใครเคยใช้ Podman เพื่อบิลด์อิมเมจสำหรับ CRI runtime ที่ไม่ใช่ Docker บ้างหรือไม่
    ถ้าบิลด์อิมเมจด้วย Podman แล้ว จะสามารถรันบน cri-o, Docker และรันไทม์อื่น ๆ ได้ไหม?
    เนื่องจาก docker build ต้องใช้ sudo จึงค่อนข้างยุ่งยากในเวิร์กโฟลว์แบบเอเจนต์ เลยกำลังชั่งใจว่าจะบิลด์อิมเมจด้วย Podman แบบ rootless ดีหรือไม่