คอนเทนเนอร์
Docker vs Podman: เอ็นจิ้นใดที่อยู่ในเซิร์ฟเวอร์ของคุณ?
Docker และ Podman ต่างก็ใช้คอนเทนเนอร์, อิมเมจ OCI และ CLI เดียวกันเป็นส่วนใหญ่ ดังนั้นตัวเลือกจึงไม่ใช่ความสามารถ แต่เป็นสถาปัตยกรรมและท่าทาง นักเทียบท่าจับคู่รูทดีมอนกับระบบนิเวศที่สมบูรณ์ที่สุด Podman จับคู่คอนเทนเนอร์แบบไม่มีรูท fork-exec กับการผสานรวมบริการ systemd-native นี่คือตารางการตัดสินใจที่ตรงไปตรงมาเบื้องหลังบทความเฉพาะทั้งสองบทความ
ประเด็นสำคัญ
- คำถาม daemon คือทางแยก: root daemon ของ Docker (docker.sock) เป็นจุดเดียวที่เทียบเท่ากับ root พร้อมด้วยประวัติการหาประโยชน์จริงในการปรับใช้แบบเปิดเผย และโมเดล fork-exec ของ Podman ไม่มีพื้นผิวสิทธิพิเศษแบบรวมศูนย์ที่เทียบเท่า หากคอนเทนเนอร์สัมผัสกับผู้ใช้ที่ไม่น่าเชื่อถือหรือทำงานในพื้นที่ที่ใช้ร่วมกัน การรูทมักจะชนะการโต้แย้งทันที
- ความเข้ากันได้สูงอย่างแท้จริง: คำศัพท์ CLI, รูปภาพ OCI และการลงทะเบียนเป็นพื้นที่ที่ใช้ร่วมกัน แรงเสียดทานอาศัยอยู่ในเครื่องมือของระบบนิเวศที่ถือว่า docker.sock (รัน CI บางตัว, GUI ผู้ดูแลระบบบางตัวเช่น Portainer ต้องใช้อะแดปเตอร์) แทนที่จะอยู่ในเอ็นจิ้นเอง
- Rootless มีความแตกต่างในพื้นผิวการทำงาน: Podman rootless ผ่านเนมสเปซของผู้ใช้จะเปลี่ยนไดรเวอร์หน่วยเก็บข้อมูลและช่วงพอร์ต (พอร์ตที่สูงจำเป็นต้องมีปุ่มที่ชัดเจนเช่น sysctl net.ipv4.ip_unprivileged_port_start) ในขณะที่โหมด rootless ของ Docker นั้นมีอยู่ แต่มีคำเตือนมากกว่า วางแผนเลเยอร์เครือข่ายบนโฮสต์ Podman แทนที่จะค้นพบมันในวันเปิดตัว
- การรวมบริการมีความแตกต่างกันในเชิงปรัชญา: systemd quadlets บนบริการคอนเทนเนอร์ด่วนฝั่ง Podman (นโยบายการรีสตาร์ท, การเปิดใช้งานซ็อกเก็ต, การควบคุมทรัพยากร) ในขณะที่ Docker บน systemd ใช้หน่วย wrapper รอบ ๆ daemon plus restart=always; ทั้งการทำงาน ความหมายของควอดเล็ตทำให้ผู้ตรวจสอบบัญชีพึงพอใจอย่างเป็นธรรมชาติมากขึ้น
- แรงโน้มถ่วงของระบบนิเวศคือคูน้ำที่แท้จริงของ Docker: บทช่วยสอน, อิมเมจ CI, เครื่องมือ GPU และการผสานรวม Docker Desktop ถือว่านักเทียบท่าเป็นอันดับแรก และนักพัฒนาแทบจะไม่สังเกตเห็น Podman จนกว่าพวกเขาจะกดเครื่องมือที่ฮาร์ดโค้ดไปยังเส้นทางซ็อกเก็ต เลือก Podman ต่อโฮสต์ที่มาตรการรักษาความปลอดภัยรับประกัน และปล่อยให้ CI เก็บ Docker ไว้ในที่ที่เครื่องมือต้องการ
- กฎการตัดสินใจที่เราใช้ในหมวดหมู่เหล่านี้: ตระกูล RHEL และมรดกที่ใช้ร่วมกันที่ไวต่อความปลอดภัยมีค่าเริ่มต้นเป็น Podman rootless; นักพัฒนาแบบผสมผสานและที่ดินจำนวนมากและ GPU ใด ๆ หรือการล็อคระบบนิเวศจะยังคงเป็น Docker เครื่องยนต์อยู่ร่วมกันอย่างหมดจดบนโฮสต์ที่แยกจากกัน ดังนั้นนี่คือการตัดสินใจต่อโฮสต์ ไม่ใช่ศาสนา
บันทึกจากหน้างาน
ผลลัพธ์ที่ตรงไปตรงมาสำหรับไคลเอนต์แบบสองด้าน: Docker ยังคงอยู่ในกลุ่มเวิร์กสเตชันของนักพัฒนา (เครื่องมือต้องการมัน) podman ที่ไม่มีรูทจะรันโฮสต์การผลิตที่เชื่อมต่อกับอินเทอร์เน็ต ทั้งสองฝ่ายแย้งว่าพวกเขาชนะ ทั้งสองถูกต้องและอสังหาริมทรัพย์มีความปลอดภัยมากขึ้นสำหรับการแยก
คำถามที่พบบ่อย
อันหนึ่งเร็วกว่าอันอื่นหรือไม่?
ประสิทธิภาพรันไทม์ของคอนเทนเนอร์นั้นเทียบเท่ากันโดยพื้นฐานแล้ว (ทั้งคู่ใช้รันไทม์ OCI เดียวกันเช่น crun/runc) ความแตกต่างปรากฏในพฤติกรรมแคชของบิลด์และเส้นทางเครือข่าย ไม่ใช่การให้บริการในสถานะคงที่
พวกเขาสามารถทำงานเคียงข้างกันบนโฮสต์เดียวได้หรือไม่?
ในทางเทคนิคแล้วใช่แต่ทำให้เกิดความสับสนในการปฏิบัติงาน (กราฟหน่วยเก็บข้อมูลสองกราฟ สองเครือข่าย) แนวปฏิบัติมาตรฐานคือหนึ่งเครื่องยนต์ต่อโฮสต์ ซึ่งกำหนดมาตรฐานตามเขตพื้นที่ ดังนั้นเครื่องมือและการตรวจสอบจึงมีความสอดคล้องกัน
จะเกิดอะไรขึ้นกับไฟล์เขียนของฉัน
พวกมันอยู่รอดได้ทั้งสองเครื่องยนต์ (การเขียนของ podman หรือการเขียนของ Docker) ความเจ็บปวดที่เหลืออยู่คือความแตกต่างเล็กน้อยในด้านเครือข่ายและพฤติกรรมการติดตั้งไดรฟ์ข้อมูลที่ปรากฏในกรณี Edge ซึ่งเป็นสาเหตุว่าทำไมการจัดเตรียมจึงมีอยู่
Podman เป็นเพียง 'Docker for RHEL' หรือไม่
มีสถาปัตยกรรมที่เหนือกว่า RHEL อีกต่อไป: มันเป็นกลไกที่แตกต่างพร้อมมาตรการรักษาความปลอดภัยแบบไม่ต้องรูทก่อน การรวมระบบ และความหมายของพ็อด สถานะเริ่มต้นของ RHEL มีความสำคัญต่อการสนับสนุน ไม่ใช่สำหรับสถาปัตยกรรม
Kinetikatech ช่วยเรื่อง คอนเทนเนอร์ ได้อย่างไร
นี่คือสิ่งที่เราทำทุกวัน: การจัดการ การประสานงาน และความปลอดภัยของคอนเทนเนอร์ในสภาพแวดล้อมโปรดักชัน บริการ การจัดการเซิร์ฟเวอร์และความปลอดภัยเซิร์ฟเวอร์ Linux ของเราดูแลครบวงจร ตั้งแต่ประเมิน ลงมือทำ ติดตาม 24 ชั่วโมง ไปจนถึงรับเรื่องฉุกเฉินภายใน 30 นาที