สำรวจ 'Podman' ทางเลือกแทน Docker ที่เสริมความปลอดภัยยิ่งขึ้น

 (betterstack.com)
6 คะแนน โดย GN⁺ 2024-01-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

เปรียบเทียบ Podman กับ Docker

  • ทั้ง Podman และ Docker ต่างก็สามารถรัน จัดการ และดีพลอยคอนเทนเนอร์ได้อย่างมีประสิทธิภาพและขยายระบบได้
  • Podman ใช้สถาปัตยกรรมแบบไม่มีเดมอน ทำให้ผู้ใช้จัดการคอนเทนเนอร์ได้โดยตรง
  • Podman ทำงานผสานกับ Systemd เพื่อจัดการวงจรชีวิตของคอนเทนเนอร์
  • สามารถใช้ Podman Compose ซึ่งให้ความสามารถคล้ายกับ Docker Compose เพื่อประสานการทำงานของคอนเทนเนอร์หลายตัวได้
  • ในด้านความปลอดภัย Podman มีการตั้งค่าเริ่มต้นที่เข้มแข็งกว่า Docker

การติดตั้ง Podman

  • Podman สามารถใช้งานได้บน macOS, Windows และลินุกซ์ดิสทริบิวชันหลัก
  • บนลินุกซ์จะทำงานได้แบบเนทีฟ ส่วนบน Windows และ macOS จะทำงานผ่านเครื่องเสมือน
  • ขั้นตอนการติดตั้งดำเนินการด้วยคำสั่ง sudo apt update และ sudo apt install podman

การรันคอนเทนเนอร์ตัวแรก

  • ใช้อิมเมจ "Hello World!" เพื่อตรวจสอบว่าการติดตั้ง Podman ทำงานได้อย่างถูกต้อง
  • Podman ปฏิบัติตามมาตรฐาน OCI(Open Container Initiative) จึงเข้ากันได้กับอิมเมจ Docker

การใช้ชื่ออิมเมจแบบสั้น

  • Podman แนะนำให้ใช้งานชื่อแบบเต็มเมื่ออ้างอิงอิมเมจ
  • หากใช้ชื่อแบบสั้น Podman จะอ้างอิงไฟล์ตั้งค่าเพื่อตรวจสอบชื่ออิมเมจแบบ fully qualified

การใช้งานรีจิสทรีอิมเมจส่วนตัว

  • Podman สามารถใช้งานร่วมกับรีจิสทรีส่วนตัวได้เช่นเดียวกับ Docker
  • สามารถใช้บัญชี Docker Hub เพื่อทำตามตัวอย่างการตั้งค่ารีจิสทรีส่วนตัวได้

การประสานการทำงานของคอนเทนเนอร์หลายตัว

  • สามารถใช้ Podman Compose เพื่อประสานการทำงานของคอนเทนเนอร์หลายตัวได้
  • Podman Compose มอบความสามารถคล้าย Docker Compose และเข้ากันได้กับไฟล์ docker-compose.yml ที่มีอยู่เดิม

ความเห็นจาก GN⁺:

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

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

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

 
GN⁺ 2024-01-14
ความคิดเห็นจาก Hacker News

  • Podman และ systemd

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

  • ความเข้ากันได้ด้านเครือข่ายของ Podman

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

  • ความนิยมของ Podman ที่เพิ่มขึ้นเรื่อย ๆ

    • เครื่องมือจำนวนมากถูกสร้างมาโดยตั้งสมมติฐานว่าสามารถเพิ่มกลุ่ม sudo docker ได้ แต่ในสภาพแวดล้อม Docker ที่คำนึงถึงความปลอดภัย สิ่งนี้กลับสร้างปัญหา
    • Podman ใช้งานได้โดยไม่ต้องมีสิทธิ์ root จึงเป็นข้อดีในแง่ความปลอดภัย

  • ประสบการณ์ใช้งาน Podman ของวิศวกร RHEL

    • ในฐานะวิศวกร RHEL ที่ได้รับการรับรอง ผู้แสดงความคิดเห็นชอบใช้ Podman กับงานคอนเทนเนอร์ส่วนตัว
    • แต่สำหรับนักพัฒนายังคงใช้ Docker อยู่ เพราะยังไม่มีอะไรมาแทนความเรียบง่ายของ Docker Compose ได้
    • ใน CI pipeline ใช้ Buildah แต่สำหรับผู้ใช้ฝั่งนักพัฒนา Docker Compose ก็ยังเหนือกว่าอยู่ดี

  • ช่องโหว่ความปลอดภัยของ Docker และ UFW

    • เกือบได้รับผลกระทบจากช่องโหว่ความปลอดภัยของ Docker และ UFW

  • ความสำคัญของคอนเทนเนอร์แบบ rootless และเนมสเปซที่แยกอิสระ

    • คอนเทนเนอร์แบบ rootless และเนมสเปซที่แยกอิสระเป็นฟีเจอร์ด้านความปลอดภัยที่สำคัญ
    • Docker เองก็ใช้แบบ rootless ได้ และการตั้งค่าก็ไม่ได้ซับซ้อน
    • ข้อดีของการยึด Docker ต่อไปคือเข้าถึงได้ง่ายกว่า: มีชุมชนใหญ่กว่า บล็อกมากกว่า การตั้งค่า Docker Compose ให้ใช้มากมาย และมีเพื่อนร่วมงานที่รู้วิธีใช้
    • ท้ายที่สุดแล้วทั้ง Podman และ Docker ต่างก็รันโปรเซสในเนมสเปซที่แยกจากโฮสต์

  • Podman ในฐานะทางเลือกแทน Docker ของ Red Hat

    • ไม่ชัดเจนนักว่าเหตุใด Red Hat จึงต้องสร้างทางเลือกแทน Docker ขึ้นมา แต่ก็ชอบ Podman
    • Podman ทำได้เกือบทุกอย่างที่ Docker ทำได้ และบางอย่างก็มีฟีเจอร์มากกว่า (เช่น พ็อด) หรือทำได้ดีกว่าในแบบของตัวเอง (เช่น กระบวนการสร้างคอนเทนเนอร์แบบไม่มี daemon)
    • สำหรับนักพัฒนา ปัญหาหลักอาจอยู่ที่ Docker Compose แต่ถ้าใช้ไฟล์ Compose แบบง่าย ก็มีสคริปต์ podman-compose ที่พยายามให้เข้ากันได้กับสเปกของ Docker Compose
    • ยังสามารถใช้ Podman เป็นแบ็กเอนด์ของ Docker Compose ได้ด้วย ณ ปี 2024 อย่างน้อยบน Linux ก็ดูไม่มีเหตุผลที่จะต้องใช้ Docker แล้ว ส่วนบน macOS หรือ Windows จะเป็นอย่างไรนั้นยังไม่แน่ใจ

  • แนวทางที่เน้นความปลอดภัยของ Podman

    • ชอบแนวทางที่เน้นความปลอดภัยของ Podman รวมถึงการตัดสินใจบางอย่างของมัน เพราะมีค่าเริ่มต้นที่ปลอดภัยตั้งแต่ต้นและยังเข้ากันได้กับ Docker Compose
    • หาก Podman ได้รับความนิยมมากพอ ก็อาจพัฒนาแนวทางของตัวเองสำหรับคำสั่งและไฟล์ yml ได้ ตอนนี้ยังดูเหมือนเป็นเครื่องมือที่ "พึ่งพา" รูปแบบคำสั่งและไฟล์ของ Docker กับ Docker Compose อยู่
    • Podman จำเป็นต้องมีทางเลือกแบบ swarm เพื่อทดแทนการขาด orchestration นอกเหนือจาก k8s ซึ่งน่าจะเป็นวิธีที่เรียบง่ายและสมเหตุสมผลในการรันคอนเทนเนอร์ขนาดเล็กจากมุมมองด้านความปลอดภัยที่ดี

  • ปัญหาที่เจอระหว่างใช้ Podman

    • Podman นั้นยอดเยี่ยม แต่ตอนเริ่มใช้แทน Docker ก็เจอปัญหาเรื่องการแมป UID และ GID, นโยบาย SELINUX และการตั้งค่า DNS ที่หายไป
    • ระหว่างพยายามแก้ปัญหา เคยรันการย้ายระบบจนทำให้การตั้งค่าพังมาหลายครั้ง มีปัญหาซับซ้อนเกี่ยวกับ ACL ด้านความปลอดภัย การแมป ID และ label
    • แม้จะพอใจกับผลลัพธ์ แต่ก็ไม่ได้เป็นโซลูชันแบบ "ใช้แล้วทำงานเลย" เหมือน Docker อย่างไรก็ตาม น่าจะมีการปรับปรุงไปมากแล้วตั้งแต่เริ่มใช้งาน

  • Podman และ Apple Silicon

    • ต่างจาก Docker, Podman ยังไม่มีความสามารถในการรันอิมเมจ x86 บน Apple Silicon ผ่าน Rosetta
    • QEMU ช้าเกินไปสำหรับการใช้งานจริง