- Containerization เป็นเครื่องมือโอเพนซอร์สที่พัฒนาด้วย Swift ซึ่งช่วยให้สามารถรัน คอนเทนเนอร์ Linux บน macOS ได้
- ทำงานบน Mac ที่ใช้ Apple Silicon และใช้ Virtualization.framework เพื่อแยกคอนเทนเนอร์แต่ละตัวให้รันอยู่ภายในเครื่องเสมือนน้ำหนักเบา
- มีความสามารถหลากหลาย เช่น การจัดการอิมเมจ OCI, การเชื่อมต่อกับรีจิสทรีระยะไกล, การสร้างระบบไฟล์ ext4, การควบคุมสภาพแวดล้อมของคอนเทนเนอร์
- รองรับการรันโปรเซส x86_64 บน Apple Silicon ได้ด้วย Rosetta 2
- เพิ่มความยืดหยุ่นและประสิทธิภาพให้แก่นักพัฒนาด้วย การบูตที่รวดเร็วมาก, สภาพแวดล้อมแบบเบา, การปรับแต่งเวอร์ชันเคอร์เนล
ภาพรวมโปรเจกต์
- Containerization เป็นแพ็กเกจ Swift ที่ช่วยให้แอปพลิเคชันสามารถใช้ คอนเทนเนอร์ Linux ได้
- พัฒนาด้วยภาษา Swift และทำงานบน Mac ที่ใช้ Apple Silicon โดยอาศัย Virtualization.framework
- มี API ที่ให้ความสามารถดังต่อไปนี้
- การจัดการ อิมเมจ OCI
- การเชื่อมต่อกับ รีจิสทรีคอนเทนเนอร์ระยะไกล
- การสร้างและจัดวาง ระบบไฟล์ ext4
- การทำงานร่วมกับ Netlink socket family
- มี เคอร์เนล Linux ที่ปรับแต่งมาแล้ว เพื่อการบูตที่รวดเร็ว
- การสร้างและจัดการ เครื่องเสมือนน้ำหนักเบา
- การควบคุม สภาพแวดล้อมการทำงาน ของเครื่องเสมือน
- การสร้างและควบคุม โปรเซสแบบคอนเทนเนอร์ไรซ์
- การรันโปรเซส x86_64 บน Apple Silicon ด้วย Rosetta 2
- สามารถดูเอกสาร API ได้จากหน้าทางการ
การออกแบบและโครงสร้าง
- คอนเทนเนอร์ Linux แต่ละตัวจะรันอยู่ในเครื่องเสมือนที่เป็นอิสระต่อกัน
- สามารถกำหนด ที่อยู่ IP เฉพาะ ให้กับแต่ละคอนเทนเนอร์ได้ ทำให้จัดการเครือข่ายได้สะดวกโดยไม่ต้องพึ่งพา port forwarding
- ด้วย การตั้งค่าเคอร์เนลที่ปรับแต่งมาแล้ว และรูทไฟล์ซิสเต็มแบบเบา ทำให้สามารถ บูตคอนเทนเนอร์ได้ในเวลาไม่ถึง 1 วินาที
- vminitd เป็นซับโปรเจกต์ของ Containerization ทำหน้าที่เป็น ระบบ init แบบเบา ที่ทำงานเป็นโปรเซสเริ่มต้นภายในเครื่องเสมือน
- รองรับการตั้งค่าสภาพแวดล้อมการทำงานผ่าน GRPC API และช่วยจัดการการทำงานของโปรเซสคอนเทนเนอร์
- ส่งต่ออินพุต/เอาต์พุต, สัญญาณ, และการจัดการอีเวนต์กลับไปยังโปรเซสที่เรียกใช้งาน
ข้อกำหนด
- ต้องใช้เครื่อง Apple Silicon Mac
- สำหรับการบิลด์แพ็กเกจ ต้องใช้
- macOS 15 ขึ้นไป และ Xcode 26 Beta
- หรือ macOS 26 Beta 1 ขึ้นไป
- หากใช้งานบน macOS 15 ความสามารถต่อไปนี้จะถูกจำกัด
- เครือข่ายคอนเทนเนอร์แบบไม่แยกส่วน: คอนเทนเนอร์บนเครือข่าย vmnet เดียวกันจะไม่สามารถสื่อสารกันได้
ตัวอย่างการใช้งาน
- มีไฟล์รัน cctl ให้ใช้งาน: เป็น playground สำหรับทดลองความสามารถต่าง ๆ ของ API
- ตัวอย่างคำสั่งหลัก
- จัดการ อิมเมจ OCI
- ล็อกอินรีจิสทรีคอนเทนเนอร์
- สร้าง บล็อกรูทไฟล์ซิสเต็ม
- รัน คอนเทนเนอร์ Linux แบบง่าย
การตั้งค่า Linux kernel
- จำเป็นต้องมี Linux kernel เพื่อ รันเครื่องเสมือนน้ำหนักเบาสำหรับคอนเทนเนอร์
- การตั้งค่าเคอร์เนลที่ปรับแต่งแล้ว ที่ Containerization มีให้ จะอยู่ในไดเรกทอรี kernel
- การตั้งค่านี้มีเพียง ฟังก์ชันที่จำเป็นขั้นต่ำ เพื่อให้ บูตได้เร็วและใช้สภาพแวดล้อมแบบเบา
- มี API ให้กำหนด การตั้งค่าและเวอร์ชันของเคอร์เนล แยกตามคอนเทนเนอร์ได้ตามต้องการ
- จึงสามารถทดสอบเคอร์เนลหลายเวอร์ชันและหลายการตั้งค่าได้
- สามารถใช้เคอร์เนลที่คอมไพล์ไว้ล่วงหน้า เช่น vmlinux.container จากโปรเจกต์ Kata Containers ได้
- แต่ไดรเวอร์ VIRTIO ต้องถูกฝังมากับเคอร์เนล (compiled-in)
สรุปกระบวนการพัฒนาและทดสอบ
- ต้องเตรียมสภาพแวดล้อม เช่น Swift, Static Linux SDK
- สามารถบิลด์และทดสอบซอร์สโค้ดได้ (
make all, make test integration เป็นต้น)
- การรันทดสอบแบบรวมต้องใช้ kernel image
- รองรับการตั้งค่าดีเพนเดนซีที่ใช้เวอร์ชันเฉพาะซึ่งเกี่ยวข้องกับ gRPC/Protobuf
- มีฟังก์ชันสร้างเอกสาร API อัตโนมัติและพรีวิวแบบโลคัล
การมีส่วนร่วมในโอเพนซอร์สและสถานะของโปรเจกต์
- ยินดีรับการมีส่วนร่วม
- เวอร์ชัน 0.1.0 เป็นรีลีสทางการครั้งแรก และรับประกันความเสถียรของซอร์สเฉพาะ ภายในช่วงเวอร์ชันไมเนอร์ เท่านั้น
- มีความเป็นไปได้ที่นโยบายนี้จะเปลี่ยนในรีลีสไมเนอร์ในอนาคต
สรุป
- Containerization เป็น แพ็กเกจ Swift ที่โดดเด่น ซึ่งช่วยให้นักพัฒนาสามารถจัดการ รัน และพัฒนา คอนเทนเนอร์ Linux บน macOS ได้ใน สภาพแวดล้อมที่ปรับแต่งมาอย่างเหมาะสม
- การรันคอนเทนเนอร์แต่ละตัวภายในเครื่องเสมือนเฉพาะที่มีน้ำหนักเบา มอบข้อดีด้าน การแยกส่วน, ประสิทธิภาพ, เครือข่าย, และการปรับแต่งเคอร์เนล
- เป็นโซลูชันที่เหมาะสำหรับนักพัฒนาที่ต้องการขยายสภาพแวดล้อมคอนเทนเนอร์โอเพนซอร์สให้เป็นประสบการณ์แบบเนทีฟบน macOS
1 ความคิดเห็น
ความคิดเห็นใน Hacker News
ขอแชร์สิ่งที่คิดว่าน่าประหลาดใจและน่าสนใจที่สุด
มีความเห็นว่า Apple เข้าร่วมกับคอมมูนิตี้โอเพนซอร์สก็ไม่ใช่เรื่องน่าประหลาดใจขนาดนั้น
พร้อมยกว่ามีผลงานจากคอมมูนิตี้โอเพนซอร์สจำนวนมากที่มีส่วนกับ Swift และเฟรมเวิร์กที่เกี่ยวข้อง
เพราะโปรเจกต์นี้เกี่ยวข้องกับ Linux จึงมีมุมมองว่า copyleft ของ Linux (ไลเซนส์โอเพนซอร์สแบบเข้มงวด) ทำให้ Apple จำเป็นต้องเลือกแนวทางการร่วมมือเช่นนี้
แนะนำวิดีโอที่เกี่ยวข้องเป็นคลิปประกาศใน WWDC 2025 (https://developer.apple.com/videos/play/wwdc2025/346/)
โครงสร้างคือแต่ละคอนเทนเนอร์ถูกแยกเป็น Linux VM ขนาดเบา
สามารถดาวน์โหลดเครื่องมือ container มาลองรันได้โดยตรง (https://github.com/apple/container/releases) และต้องใช้ macOS 26
สิ่งที่ส่งมาครั้งนี้คือ https://github.com/apple/containerization ไม่ใช่โปรเจกต์ container
containerization มีไว้สำหรับการดีพลอยแอปพร้อม sidecar ของคอนเทนเนอร์ จึงเป็นข่าวที่น่าสนใจกว่า
ส่วน container มีจุดประสงค์ให้ดีเวลอปเปอร์ใช้สภาพแวดล้อมแบบ
docker run ...สำหรับ container มีเธรด HN แยกต่างหากอยู่ที่ https://news.ycombinator.com/item?id=44229239
มีข้อมูลว่าใช้กับ macOS 15 ได้เช่นกัน แต่ฟีเจอร์ด้านเครือข่ายบางอย่างอาจถูกจำกัด
ในข่าวประชาสัมพันธ์และเซสชัน WWDC มีการพูดถึงว่า CLI tool อยู่ที่ https://github.com/apple/container
ในฐานะคนที่สนใจเครื่องมือแนวนี้ ก็หวังว่าจะถูกใส่มาให้ใน Xcode Beta รุ่นล่าสุดเป็นค่าเริ่มต้น แต่ตอนนี้ยังไม่มี
ตอนนี้ prebuilt package กำลังเตรียมอยู่ และติดตามความคืบหน้าได้ใน issue สาธารณะ (https://github.com/apple/container/issues/54)
หลังจากคอมเมนต์นั้นเพียง 1 นาที ก็มีการแชร์ข่าวว่า prebuilt package ออกแล้ว (https://github.com/apple/container/releases/tag/0.1.0)
การพูดคุยที่เกี่ยวข้องกำลังดำเนินอยู่ในเธรด HN แยกต่างหากที่ https://news.ycombinator.com/item?id=44229239
สงสัยว่าในมุมของ Docker จะรู้สึกอย่างไร
นึกภาพว่าผู้ใช้ Docker for Desktop จำนวนมากก็น่าจะใช้ Mac กัน
มีความเห็นว่าการเปลี่ยนแปลงครั้งนี้กลับทำให้การพัฒนา Docker Desktop ง่ายขึ้นมาก
เพราะไม่จำเป็นต้องตั้งค่า Linux VM เองแบบแยกต่างหากอีกต่อไป จึงลดความยากในการพัฒนา
ถึงอย่างนั้นก็คาดว่าผู้ใช้จำนวนมากยังคงเลือก Docker Desktop เดิม เพราะคุ้นกับ CLI, Docker Compose และ UX เฉพาะตัวของ Docker หลายอย่าง
มีคำอธิบายว่าการเปลี่ยน container runtime ไม่ใช่เรื่องง่าย
มีการคาดเดาว่าในมุมของ Docker คงให้ความรู้สึกคล้ายตอนรับมือกับ podman
มีความเห็นว่าการที่ Docker Desktop เป็นซอฟต์แวร์เชิงพาณิชย์แบบปิดซอร์ส ขณะที่โปรเจกต์นี้เป็นซอฟต์แวร์เสรี ถือเป็นข่าวดีสำหรับผู้ใช้
สงสัยว่าเทคโนโลยีนี้จะใช้สำหรับ bundle Linux container เข้าไปในแอปบน MacOS ได้หรือไม่
ยกตัวอย่างว่าอาจจำเป็นสำหรับกรณีที่ให้เครื่องมืออย่าง GPT เข้าถึงสภาพแวดล้อม Linux ได้โดยไม่ต้องใช้คำสั่ง CLI ระดับ root
ถ้ายอมรับได้ว่าทำงานได้เฉพาะบน MacOS 26 ก็สามารถนำไปใช้กับจุดประสงค์ที่ต้องการได้ทันที
หรือจะใช้ Virtualization.framework โดยตรงก็ได้ แต่ต้องทำงานเพิ่มอีกพอสมควร
มีความมั่นใจว่าเทคโนโลยีนี้ถูกทำมาเพื่อจุดประสงค์แบบนี้โดยตรง
แม้จะเป็นโครงสร้างที่น่าสนใจ โดยแต่ละคอนเทนเนอร์รันอยู่ใน VM ที่แยกจากกัน ทำให้ได้ทั้ง isolation เต็มรูปแบบและ IP แยกอิสระ แต่การออกแบบแบบนี้ไม่ใช่สิ่งคุ้นเคยในโลก Linux หรือ Windows
ถ้าในทีมพัฒนามีแม้แต่คนเดียวที่ไม่ได้ใช้ Mac โมเดลการพัฒนาแบบโลคัลก็พังทันที
สรุปว่าไม่น่าจะแทน Docker/Compose ได้ง่าย ๆ
จากระบบปฏิบัติการเดสก์ท็อปหลัก 3 ตัว ตอนนี้มี 2 ตัวที่รองรับการรัน Linux VM อย่างเป็นทางการเพื่อให้รันแอปพลิเคชันแบบ Linux-native ได้แล้ว
ถ้ามองตามกระแสนี้ก็อาจบอกได้ว่า Linux ชนะไปโดยพฤตินัย
Linux system call API ตอนนี้แทบจะอยู่ในสถานะ API สากลที่ใช้งานได้แทบทุกที่
มีข้อโต้แย้งว่าการที่การพัฒนาแอปบนฐาน Linux ต้องไปเกิดขึ้นบน OS หลักที่ไม่ใช่ Linux ถึง 2 ตัวนั้น ไม่น่าจะเรียกว่าเป็น "ชัยชนะของ Linux" ได้
พร้อมเล่าประสบการณ์ว่าความเป็นจริงของ desktop Linux ยังไม่นิ่งและยังแนะนำได้ยาก
มีฟีดแบ็กตรงไปตรงมาว่าลองติดตั้ง Fedora/Ubuntu บนพีซีหรือแล็ปท็อปรุ่นใหม่ทุกปี แต่ก็ยังไม่รู้สึกถึงความใช้งานง่ายและความเสถียร
อีกมุมหนึ่งมองว่าการที่อีกสองแพลตฟอร์มเปิดทางให้ใช้ Linux ได้โดยไม่ต้องย้ายออกจากแพลตฟอร์มเดิม กลับยิ่งทำให้ส่วนแบ่งของ Linux เองในตลาดเดสก์ท็อปโตช้าลง
มีการเน้นข้อเสียว่ายังไม่มีโซลูชันที่ดีพอในด้านกราฟิก เสียง และ GUI
มีการตั้งคำถามว่า "ถ้าในเกมมีผู้เล่นอยู่แค่คนเดียว แบบนั้นเรียกว่าชนะหรือเปล่า"
พร้อมแซวว่าต่อให้ไปบอกผู้ใช้ Windows หรือ Mac ทั่วไป ส่วนมากก็ไม่รู้ด้วยซ้ำว่า Linux คืออะไร
มีความเห็นว่าแค่แนวคิด "macOS ที่มาพร้อม Linux" ก็มีอิมแพกต์ในตัวเองแล้ว
สงสัยว่าพวกเขาปรับเรื่องการจัดการหน่วยความจำไว้ด้วยหรือไม่ เช่น โครงสร้างที่ไม่ทำให้ VM ใช้หน่วยความจำเกินความจำเป็น
ไม่แน่ใจว่าเกิดจากขั้นตอนไหน แต่รู้สึกว่าความเร็วในการ build ช้ามาก
ลองเพิ่มทรัพยากร CPU/หน่วยความจำด้วยออปชัน
-c,-mแล้ว แต่แทบไม่รู้สึกถึงผลพร้อมแชร์ประสบการณ์ว่าเมื่อก่อนบน Mac แบบ Apple Silicon ร่วมกับ Rancher Desktop เคยเหมือนจะ build อิมเมจ x86 ได้ แต่พอเอาอิมเมจนั้นไปรันบนฮาร์ดแวร์ x86 จริงกลับทำงานไม่ถูกต้อง
ในเดโมสั้น ๆ (https://developer.apple.com/videos/play/wwdc2025/346) จุดที่บูต VM ได้ในระดับไม่กี่ร้อยมิลลิวินาทีนั้นน่าประทับใจ
มันทำงานบน Virtualization.framework ซึ่งเป็นเทคโนโลยีที่ Docker Desktop/Colima/UTM และอื่น ๆ ก็เลือกใช้อยู่แล้วเช่นกัน
จึงสงสัยว่าเมื่อรันคอนเทนเนอร์หลายตัวพร้อมกันแบบขนาน จะมี memory overhead มากแค่ไหน