ผู้ใช้ Podman ค้นพบวิธีแก้ไขสำหรับการรองรับ BuildKit แต่ชุมชนผลักดัน Quadlets เป็นทางเลือกที่ดีกว่า

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

ความท้าทายเดิมเกิดจากตัวเลือก Docker Compose สองแบบของ Podman ที่มีข้อจำกัดสำคัญ Docker Compose CLI อย่างเป็นทางการขาดการรองรับ BuildKit เมื่อเชื่อมต่อกับ Podman และขาดฟีเจอร์เช่น additional contexts ในขณะเดียวกัน podman-compose แม้จะรองรับ BuildKit แต่ขาดฟีเจอร์สำคัญอื่นๆ รวมถึง reset, configs และ service referencing ใน additional contexts

ตัวเลือกความเข้ากันได้ของ Podman Docker Compose:

ความก้าวหน้าในการรวม BuildKit

วิธีการใหม่ช่วยให้ Docker Compose CLI ทำงานกับ Podman โดยใช้ BuildKit ผ่านการข้าม podman-compose wrapper โดยสิ้นเชิง วิธีนี้เกี่ยวข้องกับการสร้าง Docker context โดยตรงที่ชี้ไปยัง Podman socket และเปิดใช้งาน BuildKit ผ่าน systemd services แนวทางนี้ประสบความสำเร็จในการเปิดใช้งานฟีเจอร์การสร้างขั้นสูงที่ไม่สามารถใช้ได้ใน Podman environments ก่อนหน้านี้

อย่างไรก็ตาม โซลูชันนี้นำความซับซ้อนมาด้วยการต้องการ BuildKit daemon ซึ่งขัดแย้งกับปรัชญาไร้ daemon ของ Podman เพื่อแก้ไขปัญหานี้ นักพัฒนาได้สร้างเครื่องมือเช่น Bakah ที่แปลงโครงการ Docker Compose เป็นคำอธิบายการสร้างแบบ JSON ทำให้สามารถสร้างได้โดยไม่ต้องใช้ daemon ถาวร

คำสั่งการติดตั้งสำหรับการรวม BuildKit:

## ติดตั้งแพ็กเกจที่จำเป็น (Arch Linux)
pacman -S docker-compose docker-buildx buildkit

## เริ่ม Podman socket
systemctl --user start podman.socket

## สร้าง Docker context สำหรับ Podman
docker context create podman --docker host=unix://$XDG_RUNTIME_DIR/podman/podman.sock
docker context use podman

## ทางเลือก: ใช้บริการ BuildKit ของระบบ
systemctl --user start buildkit.service
docker buildx create --name local unix://$XDG_RUNTIME_DIR/buildkit/rootless
docker buildx use local

ชุมชนสนับสนุน Quadlets

แม้จะมีความสำเร็จทางเทคนิคเหล่านี้ ชุมชนยังคงสนับสนุนระบบ Quadlet ดั้งเดิมของ Podman มากกว่าเลเยอร์ความเข้ากันได้ของ Docker Compose Quadlets ให้การรวม systemd สำหรับการจัดการคอนเทนเนอร์ โดยเสนอแนวทางที่เป็นธรรมชาติของแพลตฟอร์มมากกว่าการพยายามจำลอง Docker workflows

Podman compose เป็นความพยายามที่จะดึงดูดผู้ใช้ Docker โดยการนำไอเดียที่ไม่ดีมาใช้ แทนที่จะทำเช่นนั้น ให้เรียนรู้วิธีการสร้าง 'quadlets' แล้วคุณจะไม่อยากแตะต้อง docker อีกเลย

สมาชิกชุมชนหลายคนรายงานประสบการณ์ที่เหนือกว่ากับ Quadlets เมื่อเปรียบเทียบกับทางเลือก Docker Compose การรวม systemd ช่วยให้คอนเทนเนอร์สามารถจัดการได้เหมือนกับ system service อื่นๆ โดยให้ความน่าเชื่อถือที่ดีกว่าและการบำรุงรักษาที่ง่ายกว่าสำหรับการปรับใช้ในการผลิต

ปัญหาความเข้ากันได้ที่ยังคงอยู่

การอภิปรายเผยให้เห็นความผิดหวังที่ยังคงอยู่กับความเข้ากันได้ของ Docker Compose ใน Podman การแก้ไขข้อบกพร่องล่าสุดแก้ไขปัญหาสำคัญเช่นการจัดการ dependency ที่ไม่เหมาะสมในการปิด service และการขาดการรองรับสำหรับการสร้างแบบ URL-based ปัญหาเหล่านี้ซึ่งบางอย่างมีอยู่เป็นปีก่อนที่จะได้รับการแก้ไข เน้นย้ำถึงความท้าทายในการรักษาความเข้ากันได้ระหว่าง container ecosystems ที่แตกต่างกัน

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

บทสรุป

ชุมชนคอนเทนเนอร์ดูเหมือนจะแบ่งออกระหว่างโซลูชันความเข้ากันได้เชิงปฏิบัติและการใช้เครื่องมือดั้งเดิม ในขณะที่วิธีแก้ไขทางเทคนิคขณะนี้เปิดใช้งานฟีเจอร์ BuildKit ขั้นสูงใน Podman แนวโน้มที่กว้างขึ้นแสดงให้เห็นว่าการยอมรับโซลูชันดั้งเดิมของ Podman เช่น Quadlets อาจให้ประโยชน์ระยะยาวที่ดีกว่าการรักษาความเข้ากันได้ของ Docker Compose สำหรับองค์กรที่พิจารณาการเปลี่ยนแปลง การเลือกระหว่าง Docker workflows ที่คุ้นเคยและแนวทางรวม systemd ของ Podman น่าจะขึ้นอยู่กับความต้องการการปรับใช้เฉพาะของพวกเขาและความเต็มใจที่จะใช้เครื่องมือใหม่

อ้างอิง: Using Podman, Compose and BuildKit