เหตุผลที่ฉันเปลี่ยนจาก Docker มาใช้ Podman

 (codesmash.dev)
14 คะแนน โดย GN⁺ 2025-09-06 | 8 ความคิดเห็น | แชร์ทาง WhatsApp
  • Docker ถูกวิจารณ์มาอย่างต่อเนื่องในเรื่องช่องโหว่ด้านความปลอดภัยและการใช้ทรัพยากร เนื่องจากมีโครงสร้างแบบ background daemon (dockerd)
  • Podman ใช้ สถาปัตยกรรมแบบไม่พึ่ง daemon ทำให้คอนเทนเนอร์รันโดยตรงภายใต้สิทธิ์ของผู้ใช้ ช่วยลดพื้นผิวการโจมตีและเพิ่มความเสถียร
  • รองรับ การทำงานร่วมกับ Systemd, การออกแบบที่เป็นมิตรกับ Kubernetes, และ ชุดเครื่องมือที่แยกตามแนวคิด Unix อย่าง Buildah/Skopeo ช่วยเพิ่มประสิทธิภาพในการปฏิบัติการ
  • ยังคงเข้ากันได้กับ Docker CLI ในระดับสูง ทำให้เวิร์กโฟลว์เดิมส่วนใหญ่ยังใช้งานได้ทันทีเพียงแค่ alias docker=podman
  • แม้ในสภาพแวดล้อมการใช้งานจริง ก็ช่วยให้การจัดการความปลอดภัยและทรัพยากรง่ายขึ้น และสำหรับโปรเจ็กต์ใหม่ Podman กำลังกลายเป็น ตัวเลือกที่สมเหตุสมผลและมองไปข้างหน้ามากกว่า

ข้อจำกัดและปัญหาด้านความปลอดภัยของ Docker

  • Docker มีโครงสร้างที่ daemon dockerd ต้องทำงานอยู่ตลอดด้วยสิทธิ์ root
    • หากพบช่องโหว่ใน daemon โฮสต์ทั้งเครื่องอาจตกอยู่ในความเสี่ยง
  • ตัวอย่างประเด็นด้านความปลอดภัยสำคัญ
    • 2019: runC container escape (CVE-2019-5736)
    • 2022: ช่องโหว่ Linux Dirty Pipe, cgroups v1 escape
    • 2024: runC “Leaky Vessels”, ช่องโหว่ BuildKit
    • 2024: แคมเปญ cryptojacking ผ่านการเปิดเผย Docker API
  • เหตุการณ์เหล่านี้เกิดซ้ำ ๆ จนสะท้อนให้เห็นถึง ความเสี่ยงเชิงโครงสร้างของสถาปัตยกรรมแบบพึ่ง daemon

สถาปัตยกรรม daemonless ของ Podman

  • Podman ไม่ใช้ background daemon
    • เมื่อรัน podman run คอนเทนเนอร์จะทำงานเป็น child process โดยตรง ของผู้ที่สั่งรันคำสั่ง
    • เนื่องจากรันในโหมด rootless แม้จะมีสิทธิ์ root ภายในคอนเทนเนอร์ แต่บนโฮสต์ก็ยังเป็นเพียงสิทธิ์ของผู้ใช้ทั่วไป
  • ข้อดี
    • เพิ่มความปลอดภัย: หากเกิด container escape ขอบเขตความเสียหายจะเล็กลง
    • เพิ่มความเสถียร: ต่อให้คอนเทนเนอร์หนึ่งล่ม คอนเทนเนอร์อื่นก็ไม่ถูกกระทบ
    • ใช้ทรัพยากรอย่างมีประสิทธิภาพ: ไม่มี daemon ที่ไม่จำเป็นต้องค้างอยู่ในระบบ จึงใช้หน่วยความจำน้อยลง

ความสามารถที่แตกต่างของ Podman

  • การทำงานร่วมกับ Systemd
    • ใช้ podman generate systemd เพื่อสร้างไฟล์ systemd unit อัตโนมัติ
    • จัดการบริการได้ด้วยคำสั่งมาตรฐาน systemctl
  • ความเป็นมิตรกับ Kubernetes
    • มีแนวคิด Pod ฝังมาเป็นพื้นฐาน จึงเหมาะกับการพัฒนาแอปแบบหลายคอนเทนเนอร์
    • ใช้ podman generate kube เพื่อสร้าง Kubernetes YAML ได้ทันที
  • แนวคิดแบบ Unix
    • Podman โฟกัสที่การรันคอนเทนเนอร์ ส่วนการ build image ใช้ Buildah และการจัดการ registry ใช้ Skopeo
    • ทำให้เลือกใช้เครื่องมือที่เหมาะกับแต่ละหน้าที่ได้

กระบวนการย้ายและความเข้ากันได้

  • การย้ายจาก Docker ไป Podman ทำได้แบบ แทบไม่สะดุด
    • CLI เข้ากันได้ จึงสามารถใช้ podman แทน docker ได้ตรง ๆ
    • Dockerfile เดิมก็ยังทำงานได้เหมือนเดิม
  • จุดที่ต่างกัน
    • ในโหมด rootless จะ bind พอร์ตต่ำกว่า 1024 ไม่ได้ → แนะนำให้ใช้ reverse proxy
    • ต้องจัดการสิทธิ์ของ volume
    • เครื่องมือที่พึ่งพา Docker socket สามารถใช้โหมด Docker API compatibility ของ Podman ได้

การนำไปใช้จริงและข้อดี

  • หลังจากใช้ Podman ในสภาพแวดล้อมการปฏิบัติงานจริง
    • ภาระในการตรวจสอบด้านความปลอดภัยลดลง และได้ rootless security เป็นค่าพื้นฐาน
    • รูปแบบการใช้ทรัพยากรง่ายขึ้นและคาดการณ์ได้มากขึ้น
  • แม้ Docker จะยังได้รับความนิยม แต่ ถ้าเป็นโปรเจ็กต์ใหม่หรือมีอิสระในการเลือกเทคโนโลยี Podman เหมาะสมกว่า
    • ผสานเข้ากับระบบจัดการของ Linux ได้อย่างเป็นธรรมชาติ
    • รองรับสถาปัตยกรรมที่มุ่งไปทาง Kubernetes
    • มอบสภาพแวดล้อมการรันคอนเทนเนอร์ที่ปลอดภัยและสมเหตุสมผลกว่า

สรุปคู่มือย้าย FastAPI

  • ใช้ Dockerfile เดิมได้ทันที
  • แทนที่ด้วย podman build, podman run ได้อย่างง่ายดาย
  • ใช้ podman generate systemd เพื่อลงทะเบียนเป็นบริการ systemd
  • รองรับสภาพแวดล้อมหลายบริการ เช่น DB โดยใช้ Pod
  • เวิร์กโฟลว์ Docker Compose สามารถรองรับได้ด้วย podman-compose หรือการแปลงผ่าน kompose

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

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

 
shortstories 2025-09-09

ที่นี่เขียนไว้ว่าสามารถเปลี่ยนผ่านได้โดยไม่ต้องหยุดระบบ แต่พอเป็นสภาพแวดล้อมใช้งานจริงกลับมีอะไรแปลกๆ เยอะพอสมควรครับ ตัวอย่างเช่น บนสภาพแวดล้อม mac เมื่อใช้การตั้งค่าเริ่มต้นที่ใช้การบีบอัด zstd อิมเมจที่ build ขึ้นมาจะไปกินพื้นที่ใน registry ค่อนข้างมากอะไรทำนองนั้น..
 
codemasterkimc 2025-09-08

ทั้ง Docker และ Podman....

securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL

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

จริง ๆ แล้วความเข้ากันได้กับ Docker ยังไม่ค่อยดี เลยทำให้การใช้งานไม่ได้ดีขนาดนั้น...
เพราะคิดเรื่อง rootless เลยย้ายไปใช้ Podman แล้วสุดท้ายก็กลับมาใช้ Docker อีกครับ
อย่างที่ท่านอื่นบอก ถ้าจะใช้กับ Kubernetes ก็ใช้ containerd ไปเลยดีกว่า
 
click 2025-09-08

ผมก็สงสัยเหมือนกันว่า ถ้า Docker compose ทำงานได้ไม่ดีและข้อดีก็คือเข้ากันได้กับ Kubernetes มากกว่า แบบนั้นใช้ Kubernetes ไปเลยไม่ดีกว่าเหรอ
ผมเองก็เคยจะลองใช้ แต่เพราะมันไม่สามารถทำงานได้ในครั้งเดียว และยังแมปพอร์ตต่ำกว่า 1024 ได้โดยตรงไม่ได้ด้วย เลยใช้ k3s ควบคู่กับ nerdctl สำหรับบิลด์อิมเมจแทน
 
ndrgrd 2025-09-07

แม้จะรู้สึกอยากเปลี่ยนมาใช้มาสักพักแล้ว แต่ตอนที่เคยลองก่อนหน้านี้กลับพบว่าไม่เหมือนอย่างที่นักพัฒนาพูดกัน เพราะมีโปรเจ็กต์ docker compose จำนวนมากเกินไปที่ทำงานได้ไม่ถูกต้อง...
 
afewgoodman 2025-09-07

ก็ Docker ไม่รองรับ network นี่นา
 
devsepnine 2025-09-07

เท่าที่ทราบ มันน่าจะรองรับฟีเจอร์ด้านเครือข่ายได้เหมือนกับ Docker
ตอนนี้ยังมีอะไรที่ใช้งานได้ไม่สมบูรณ์อยู่ไหม?
 
GN⁺ 2025-09-06
ความเห็นจาก Hacker News
  • ในช่วงปี 2001/2002 ฉันต้องสร้างกล่อง WiFi hotspot ตอนนั้นเป็นแฟน OpenBSD และอยากทำดิสโทรที่เขียนด้วย Python ให้เบาที่สุดเท่าที่จะทำได้ ไม่อยากเจอทั้งการคัดลอกไฟล์ที่ไม่จำเป็นและปัญหา dependency เลยเลือกแนวคิด chroot กับ jail โค้ดสำหรับ deploy ของฉันจะรันซอฟต์แวร์จากนอกสภาพแวดล้อม jail แล้วใช้ ptrace เฝ้าดูไฟล์ที่โปรเซสเปิด จากเอาต์พุตนี้ก็สรุปรายการ dependency ออกมาแล้วแพ็กเกจมัน ผลลัพธ์คือ deployment มีขนาดเล็ก คงสภาพไม่เปลี่ยนแปลง และปลอดภัยขึ้น พอ Docker ออกมาก็ทำให้นึกถึงวิธีเก่า ๆ และสงสัยว่ามีเครื่องมือคล้ายกันไหมที่คอยมอนิเตอร์การใช้งานไฟล์ของคอนเทนเนอร์ Docker เพื่อลดขนาดชุด deploy จริง ๆ
    • CI/CD pipeline ที่ดีที่สุดที่ฉันเคยใช้คือการ deploy งานฟรีแลนซ์ Django ใช้ git post receive hook เพื่อทำให้การ build static files และรีสตาร์ต httpd เป็นอัตโนมัติทุกครั้งที่มี git push แค่ git push live master ก็ deploy ได้แล้ว ฉันใช้ Docker มาเยอะ แต่แบบนี้ง่ายที่สุดสำหรับการ deploy ฉันเข้าใจข้อดีของ Docker แต่การตั้งค่า HTTP บน Ubuntu หรือ OpenBSD ก็ไม่ได้ยากขนาดนั้น เลยสงสัยว่าความสามารถในการทำซ้ำได้แบบ Docker คุ้มกับภาระในการดูแลที่เพิ่มขึ้นจริงหรือไม่
    • ผลลัพธ์อันดับแรกของ Google Search คือ slimtoolkit/slim ที่มี 22k ดาว
    • ในสภาพแวดล้อม OpenWrt มีเครื่องมือชื่อ ujail ซึ่งถ้าส่ง ELF executable เข้าไป มันจะ parse dependency ของไลบรารีที่จำเป็น แล้ว mount เฉพาะไฟล์ที่จำเป็นแบบ read-only ลงบน tmpfs
      ลิงก์ไปยังโค้ดที่เกี่ยวข้อง
  • สำหรับฉัน Podman เป็นประสบการณ์ที่ยอดเยี่ยมจริง ๆ การใช้ Docker รู้สึกว่ายากและมีหลุมพรางเยอะ แต่ Podman ไม่ได้ด้อยกว่าเลย ที่สำคัญที่สุดคือบริษัทที่ฉันสังกัดไม่ต้องกังวลเรื่องไลเซนส์ ถือว่า win-win เต็ม ๆ
    • สงสัยว่าบริษัทกังวลเรื่องไลเซนส์จริงหรือ Docker Desktop มีนโยบายไลเซนส์แบบเสียเงินที่สมเหตุสมผล ถ้ามีพนักงานน้อยกว่า 250 คน หรือรายได้ต่ำกว่า 10 ล้านดอลลาร์ ก็ใช้ฟรีได้ ต่อให้ค่าไลเซนส์ปีละ $90 พอมองจากเงินเดือนนักพัฒนาในสหรัฐฯ ก็แทบไม่ถึงค่ามื้อกลางวัน แถมยังได้ใช้เครื่องมือที่มีซัพพอร์ตอย่างเป็นทางการบนทุก OS
    • จริง ๆ แล้วบริษัทแทบไม่ต้องกังวลเรื่องไลเซนส์ด้วยซ้ำ Docker Engine เป็นโอเพนซอร์สเต็มรูปแบบและใช้ฟรี ต้องมีไลเซนส์แยกเฉพาะกรณีใช้ Docker Desktop ในองค์กรเท่านั้น แต่ฟีเจอร์ส่วนใหญ่ก็ใช้ได้จาก Docker Engine อยู่แล้ว
    • Podman ดีกว่า Docker มาก ไม่ต้องกังวลเรื่องการจัดการสิทธิ์ผู้ใช้/กลุ่มหรือปัญหาความปลอดภัยของโปรเซสรูท และไม่ต้องส่งข้อมูลไปให้เดมอนด้วย
    • ในบางเครื่อง PC ตัว uninstaller ของ Podman บน Windows ลบคอมโพเนนต์ออกไม่หมด ทำให้พอรันใหม่ก็เกิดข้อผิดพลาด แม้จะลบบริการด้วยตนเองก็ยังมีปัญหาอยู่ เป็นเรื่องน่าหงุดหงิดที่เจอบ่อยพอสมควร
  • ฉันชอบ Podman มาก แต่ไม่ได้หมายความว่ามันจะทำงานได้ดีเสมอกับทุกคอนเทนเนอร์ ตัวอย่างเช่นคอนเทนเนอร์ขนาดใหญ่อย่าง gitlab มักพึ่งพาประวัติและพฤติกรรมเฉพาะตัวที่ซับซ้อนของ Docker เลยทำให้เกิดข้อผิดพลาดบน podman อยู่บ่อย ๆ ส่วน image ที่สร้างเองส่วนใหญ่คิดว่ารันบน podman ได้ดี คอนเทนเนอร์ที่มีปัญหาก็เลี่ยงด้วยการเปิด incus VM แล้วรันข้างในนั้น ทั้ง Podman และ Docker ก็ยังจัดการการเข้าถึง GPU ได้ไม่ค่อยสม่ำเสมอจนน่ารำคาญ ถึงอย่างนั้นก็ยังคิดว่า podman ดีกว่านิดหน่อย โดยเฉพาะเรื่อง rootless ที่เป็นจุดเด่นมาก
    • เดาว่าปัญหาส่วนใหญ่มาจาก image ที่เริ่ม PID 1 เป็นรูท Podman เป็น rootless โดยค่าเริ่มต้น เลยเกิดปัญหาแบบนี้ ถ้าอยากใช้ image แบบรูทโดยไม่ใช้ Docker ก็แยก Podman เป็นโหมด rootful และ rootless แล้วใช้แฟลก --connection เพื่อเลือกสภาพแวดล้อมที่ต้องการได้ ถ้าจำเป็น Podman ก็สร้าง VM อัตโนมัติให้ได้ด้วย (ใช้ lima) และ Podman Desktop ก็มีเลเยอร์เข้ากันได้กับ Docker เพื่อลดปัญหาความเข้ากันได้
    • การที่มีบางคอนเทนเนอร์ใช้กับ podman ไม่ได้ นั่นแหละน่าจะเป็นแรงจูงใจให้เขียนบล็อกโพสต์นี้ ถ้าฐานผู้ใช้ใหญ่พอ สุดท้ายก่อน publish ก็น่าจะมีธรรมเนียมตรวจบนสภาพแวดล้อม podman ด้วย
    • เรารันทั้ง GitLab server และ runner บน podman อยู่ทั้งหมด ส่วนตัวอยากย้าย runner ไป k8s แต่ตอนนี้ใช้ Traefik แล้วทำงานได้ดี
    • ฉันใช้ฟีเจอร์ที่เกี่ยวกับ buildx เยอะมาก แม้ภายนอกจะเหมือนว่า podman ก็รองรับ แต่ในทางปฏิบัติกลับใช้ไม่ค่อยได้
  • ปัญหาใหญ่ที่สุดของการรองรับ podman บน Ubuntu คือ เวอร์ชัน podman ที่มากับ Ubuntu เก่าเกินไปจนใช้งานตรง ๆ ไม่ได้ ฉันใช้ podman v5, GitHub Actions ใช้ v3 และเพื่อนร่วมงานใช้ docker สุดท้ายเลยต้องทำให้สคริปต์ของฉันรันได้ทั้งบน podman รุ่นเก่า podman รุ่นใหม่ และ docker ซึ่งเพิ่มความซับซ้อนขึ้นมาก
    • ไม่มีแหล่งแจกจ่าย .deb build ที่เชื่อถือได้ ไม่มี .deb ทางการ และเท่าที่หาได้ก็ล้าสมัยหรือเป็นแหล่งที่บอกว่าจะไม่อัปเดตต่อแล้ว ถ้าอย่างนั้นก็ยิ่งเกิดคำถามว่า ทำไม Podman ไม่ช่วยให้ติดตั้งง่ายกว่านี้ ความคิดของฉันคือ RedHat คงไม่อยากทุ่มทรัพยากรพัฒนาเพื่อรองรับผลิตภัณฑ์ของคู่แข่ง ซึ่งก็เข้าใจได้ แต่ก็ดูเหมือนว่านอก ecosystem ของ RedHat แล้วจะถูกมองเป็นพลเมืองชั้นสอง
    • ฉันคิดว่านี่คือปัญหาใหญ่ที่สุด นอกจากการรับรู้ของตลาดที่น้อยกว่า Docker แล้ว ปัญหาเวอร์ชันไม่ตรงกันนี่แหละที่ทำให้ Podman กลายเป็นของเฉพาะกลุ่มมากกว่า ดิสโทรอย่าง Ubuntu มักให้ซอฟต์แวร์รุ่นเก่า ซึ่งผู้ดูแลแพ็กเกจต้องเป็นคนแก้ แต่ฝั่ง Podman เองก็ไม่ได้ขยับในเรื่องนี้มากนัก ด้วยเหตุนี้ฉันถึงกับเปลี่ยนโฮมเซิร์ฟเวอร์ไปใช้สาย Red Hat เพื่อจะได้ใช้ Podman รุ่นล่าสุด
    • การที่ไม่มี .deb จาก upstream อย่างเป็นทางการและต่อเนื่อง ทำให้เราไม่สามารถใช้ Podman ภายในองค์กรได้ Docker มี repo .deb ทางการที่ดูแลดี เลยน่าอิจฉา
    • นี่เป็นหนึ่งในเหตุผลที่ฉันไม่ใช้ Ubuntu/Debian เพราะอัปเดตช้าเกินไป ถึงจะใช้ผ่าน flatpak ได้ก็เถอะ แต่ซอฟต์แวร์แบบนี้ก็ควรมีให้เป็นค่ามาตรฐานมากกว่า
    • Podman เป็นโอเพนซอร์ส ดังนั้นฝั่ง Ubuntu เองก็แพ็กเกจและอัปเดตได้เอง การที่ RedHat จะไม่อยากมารับภาระแพ็กเกจซอฟต์แวร์สำหรับคู่แข่งด้วยตัวเองก็พอเข้าใจได้
  • เมื่อไม่นานมานี้ฉันได้ลองเซ็ตอัป Podman เพราะงานบริษัท และมันเป็นหนึ่งในประสบการณ์ที่แย่ที่สุด rootless Podman + SELinux + ผู้ใช้ทั่วไปภายในคอนเทนเนอร์ เป็นนรกชัด ๆ
    • จริงอยู่ว่าถ้าอยากทรมานตัวเองก็ทำให้ทุกอย่างพังได้ แต่ในทางปฏิบัติแล้วส่วนใหญ่ก็ใช้งานได้ดี บนเครื่อง RHEL10 ที่เปิด SELinux ฉันรันหลายบริการแบบ rootless container หลัง nginx reverse proxy ได้สบาย ๆ เช่น Forgejo, runner, uptime-kuma เป็นต้น
    • ฉันไม่เคยรู้สึกถึงข้อดีของ rootless เลย ถ้าเครื่องอยู่ใน security domain เดียวกัน ก็รันเป็น root ไปเลยก็ไม่น่าเป็นไร แต่ถ้าไม่ใช่ ก็ควรใช้สภาพแวดล้อมแยกจริงจังอย่าง Firecracker/Kata VM เป็นต้น rootless ดูเหมือนสร้างความลำบากมากกว่าประโยชน์ที่ชัดเจน
    • ฉันก็เจอสถานการณ์เดียวกันในบริษัท แต่ถ้าแก้ตามแนวทางเฉพาะของ podman (ดู docs) ก็พอใช้ได้ ประเด็นสำคัญคือต้องดูเอกสารของเวอร์ชันล่าสุด
    • ฉันใช้ podman บน Fedora มาเกิน 7 ปีแล้ว
    • องค์กรของเราย้ายทั้งหมดจาก Docker ไป Podman และแม้จะมีเสียงรบกวนระหว่างทาง แต่ด้วยความสามารถของทีม SysDev ก็แก้ได้อย่างราบรื่น
  • มีคนชอบบอกว่าถ้า workflow ของ Docker Compose ซับซ้อนเกินไป ก็แปลงไปเป็น Kubernetes YAML เลย แต่จากประสบการณ์ของฉัน K8s YAML ซับซ้อนกว่า docker compose มาก และไม่ใช่ทุกคนที่ใช้ Kubernetes
    • ฉันเห็นต่าง K8s YAML มีความซับซ้อนใกล้กับ docker compose หรือบางครั้งอาจง่ายกว่าด้วยซ้ำ มันแค่ยืดยาวมาก 100 บรรทัดของ compose อาจแตกเป็น YAML 20 ไฟล์ (ไฟล์ละ 50 บรรทัด) ถ้า kubectl มีฟีเจอร์ sugar สำหรับแปลง YAML แบบง่าย/ซับซ้อนไปมาได้ก็คงดี
    • เวลาจะแปลง docker compose ไปเป็น k8s yaml ถ้าใช้ LLM เป็นเลเยอร์ช่วย มันทำงานได้ดีมาก อ้อ แล้ว podman เองก็มีฟีเจอร์สร้าง k8s yaml ด้วย เลยย้ายต่อได้ค่อนข้างธรรมชาติ
    • ฉันสร้าง compose file ไม่เป็น แต่สร้าง k8s yaml ได้ เพราะงั้น compose เลยรู้สึกว่า "ซับซ้อน" กว่าเสียอีก
  • คำสั่ง podman generate systemd ที่บทความพูดถึง ตอนนี้ deprecated แล้ว ทางเลือกคือ Podman Quadlets ซึ่งทำงานคล้าย docker-compose.yaml ที่นิยามอยู่ในไฟล์ unit ของ systemd
    • การส่งเรื่อง Compose/orchestration ไปให้ systemd จัดการถือว่าสมเหตุสมผล เพราะมันไม่ใช่โครงสร้างแบบ client-server เหมือน docker แต่เป็นโปรเซสของผู้ใช้จริง ๆ เลยเป็นทางเลือกที่เข้าท่าชัดเจน
    • ปัญหาคือแทบไม่มีเอกสารเลย
  • การแมปคอนเทนเนอร์แบบหลาย UID เข้ากับผู้ใช้โฮสต์เพียงคนเดียวทำได้ยาก โดยปกติ root ภายในคอนเทนเนอร์จะถูกแมปเป็นผู้ใช้ที่รันบนโฮสต์ แต่ช่วงหลังแอปจำนวนมากเริ่มใช้ผู้ใช้ non-root ภายในคอนเทนเนอร์ เช่น www-data หรือผู้ใช้หมายเลข 1000 ผู้ใช้เหล่านี้จะถูกแมปไปยัง secondary ID บนโฮสต์ ทำให้เวลาแมปโวลุ่มแล้วเจ้าของไฟล์ดูเหมือนกลายเป็น orphan จนสับสนมาก อยากได้ตัวเลือกง่าย ๆ ที่แมปทุก UID ไปยังผู้ใช้เดียว แต่ตัวเลือกที่มีอยู่ตอนนี้ (เช่น uidmap ของ crun, userns) กลับทำงานได้ไม่ดี เลยสงสัยว่าการแมป secondary ID มีประโยชน์จริงแค่ไหน
    • ถ้าเข้าใจถูก นี่เป็นข้อจำกัดของ Linux namespaces ถ้าเครื่องมืออย่าง Docker หรือ Podman จะรองรับการแมปแบบนี้ ก็ต้องให้ Linux รองรับก่อน เหตุผลที่การแมป UID แบบ 1:1 สำคัญก็เพราะถ้าผู้ใช้ 1000 และ 0 ภายในคอนเทนเนอร์ถูกแมปไปเป็นผู้ใช้โฮสต์คนเดียวกัน ข้อมูลเจ้าของไฟล์จะปั่นป่วน
    • อาจลองดู idmapped mount ก็ได้ มันรองรับเฉพาะการ remap ระดับ filesystem แต่ไม่ช่วยเรื่อง system call ของเคอร์เนล
    • คงดีถ้ามีวิธีให้คอนเทนเนอร์ทำงานเป็น "ตัวเองจริง ๆ" ได้ โดยให้เจ้าของใน log แสดงออกมาตรง ๆ แบบนั้น
    • ใช้ตัวเลือก ignore_chown_errors จะช่วยให้แมปรูทไปเป็น user ID ได้ง่าย โดยไม่ต้องมีการแมปเพิ่มเติมมากนัก
  • ฉันพยายามย้ายไป Podman หลายครั้งแต่ก็ล้มเหลวในหลายจุด อย่างแรก ประสิทธิภาพของ podman บน VPS เครื่องเล็กของฉันแย่กว่า docker มาก (ขอละรายละเอียด) อย่างที่สอง ecosystem ฝั่งพัฒนา ยังตามมาไม่ทันเต็มที่ เครื่องมือหลายตัวพึ่งพา Docker socket แต่ podman มักทำงานไม่ได้ดีเพราะปัญหาสิทธิ์หรือความเข้ากันได้ของ API podman ยังไม่ใช่ตัวแทนแบบ drop-in ที่สมบูรณ์
    • เครือข่ายที่ช้าเวลาใช้ rootless podman อาจมาจาก slirp4netns pasta เป็นวิธีที่เร็วกว่า Docker ตั้งค่าเครือข่ายผ่าน privileged daemon โดยค่าเริ่มต้น เพราะงั้นถ้าใช้ podman เป็นรูท ความต่างด้านประสิทธิภาพก็ควรจะไม่มี
    • ปัญหา SELinux permission error ของ podman และ quadlet ยังคงเป็นเรื่องปวดหัวไม่เลิก ถ้าเป็นไปได้ การสร้างพ็อดที่มีสิทธิ์ระดับโฮสต์ทั้งก้อน แล้วแมปเฉพาะ /dev ที่ต้องใช้ และเปิดให้โปรแกรมที่จำกัดมาก ๆ เข้าถึงผ่านเครือข่ายที่แยกขาด อาจจะง่ายกว่า
    • น่าสนใจที่ในระบบทรัพยากรจำกัดของฉัน podman กลับทั้งเร็วกว่าและใช้ทรัพยากรน้อยกว่า docker มาก ดูเหมือนจะเป็นผลจากความต่างระหว่าง crun กับ runc และ podman ก็เบากว่าเพราะไม่มีเดมอน
  • เลิกใช้ทั้ง Docker และ Podman แล้วหันไปใช้ FreeBSD Jails แทน
    • ดูข้อมูลเพิ่มเติมและเครื่องมือจัดการได้ที่ นี่,
      นี่,
      นี่,
      นี่
    • ภายใน FreeBSD jail สามารถรัน MS SQL Server หรือ Docker container หลายพันตัวได้ทันทีไหม การเลือก FreeBSD ต้องแลกมาด้วยต้นทุนก้อนใหญ่ (เช่นข้อจำกัดด้านความเข้ากันได้) และนี่ก็เป็นเหตุผลที่ jails ยังไม่แพร่หลาย
    • ต้องตั้งค่าเยอะมาก เลยสงสัยว่า FreeBSD มีอะไรคล้าย containerd ไหม
    • FreeBSD jails เป็นฟีเจอร์ที่ผูกกับดิสโทรเฉพาะทาง
    • สงสัยว่า FreeBSD jail ต่างจากการรัน VM บน Linux host อย่างไร