- Công cụ tạo và chạy Linux container trên Mac dưới dạng máy ảo nhẹ
- Container Machine mới được bổ sung tại WWDC26 có thể chạy môi trường Linux nhanh, nhẹ và có tính bền vững, với thư mục home và kho lưu trữ được tự động mount
- Khác với container theo từng ứng dụng trước đây, tính năng này mô hình hóa toàn bộ môi trường Linux (tương tự WSL2)
- Có thể chạy hệ thống init của image để đăng ký các dịch vụ chạy dài hạn hoặc kiểm thử ứng dụng dưới trình quản lý tiến trình
- Trên image đã cài
systemd, có thể chạy các dịch vụ Linux thực như systemctl start postgresql
- Tự động ánh xạ tên người dùng và thư mục home, giúp chia sẻ kho lưu trữ và dotfile giữa macOS và Linux
- Kho lưu trữ nằm trong macOS
$HOME và được mount vào /Users/<username> bên trong, cho phép chỉnh sửa bằng editor·IDE trên macOS trong khi build và chạy bên trong
- Các công cụ macOS native như profiler, trình duyệt, GUI debugger nhận diện cùng một tập tin, nên không cần bước sao chép giữa build và kiểm tra
- Có thể tạo Container Machine cho nhiều bản phân phối đích như
alpine, ubuntu, debian, và mỗi môi trường đều chia sẻ cùng $HOME và dotfile để kiểm thử nhanh trên nhiều distro
- Có thể dùng trực tiếp mọi Linux image có chứa
/sbin/init làm Container Machine image
- Vì sử dụng và tạo OCI-compatible container image, nên có thể pull·push Docker image từ registry container tiêu chuẩn
- Các ứng dụng tương thích OCI khác cũng có thể chạy image đó
- Việc quản lý container·image·process ở mức thấp phụ thuộc vào gói Swift Containerization
- Cần Mac dùng Apple silicon để chạy, được hỗ trợ trên macOS 26
- Tận dụng các tính năng mới và cải tiến về ảo hóa, mạng của macOS 26; không hỗ trợ các phiên bản macOS trước đó
- Giấy phép Apache-2.0
Các lệnh hoạt động
container machine create alpine:latest --name dev
container machine run -n dev whoami # your host username, not root
container machine run -n dev pwd # /home/<you> — your Mac home dir, mounted in
container machine run -n dev # interactive shell; cd into your repos in $HOME
container machine ls # list all container machines
container machine inspect dev # JSON detail for one
container machine stop dev # stop the container machine
container machine rm dev # delete, including its persistent storage
container machine set -n dev cpus=4 memory=8G
container machine stop dev
container machine run -n dev -- nproc
- Containerization là framework Swift mã nguồn mở được công bố tại WWDC 25, đóng vai trò nền tảng để chạy Linux container trên macOS
- Được thiết kế để cung cấp cách ly dựa trên máy ảo cho từng container, với máy ảo nhẹ mang lại hiệu năng nhanh và thời gian khởi động dưới 1 giây
- Container machine là tính năng mới được xây dựng trên Containerization, kết hợp tính tiện dụng và tốc độ của container với tính bền vững của máy ảo, đồng thời nhờ khả năng tích hợp mà môi trường Linux mang lại cảm giác như phần mở rộng của macOS
-
Nguyên tắc thiết kế
- Container machine phải nhanh và nhẹ để có thể tích hợp vào workflow hiện có
- Cần cho phép chuyển đổi dễ dàng giữa macOS và Linux
- Người dùng phải có thể nhanh chóng tạo và tùy biến môi trường mới, nhờ đó nhiều dự án có thể có môi trường chuyên biệt mà không lo xung đột dependency hay toolchain
- Vì công cụ và dependency cần thiết có thể thay đổi trong suốt vòng đời phát triển, người dùng phải có thể thêm công cụ vào môi trường bền vững và tái sử dụng về sau
- Khi phát triển cho nhiều nền tảng, không nên cần chuyển ngữ cảnh lớn hay phải học công cụ mới
3 bình luận
Liệu hiệu năng có đủ tốt không?
Dù nhìn kiểu nào thì cũng giống như bản Mac của WSL2, nhưng không biết khi ánh xạ volume của host thì có bị tụt mạnh hiệu năng I/O không nhỉ?
Ngay cả bây giờ tôi cũng đang dùng
limactlđể chạy container trên VM, nên cũng có cảm giác là nó sẽ không khác biệt nhiều lắm.Ý kiến trên Hacker News
Để làm rõ vài điểm ở đây, cái này không chỉ nói về container OCI
Container Machines hỗ trợ tính bền vững và gắn kết hệ thống tệp, nên nó trở thành một môi trường Linux nhẹ rất tốt cho các nhà phát triển dùng macOS
Chi tiết ở đây: https://developer.apple.com/videos/play/wwdc2026/389
OrbStack rất hợp với tôi
Tôi tò mò không biết hiệu năng của nó so với cái này sẽ ra sao
Thay vì Virtualization.framework, chúng tôi trực tiếp dùng một ngăn xếp ảo hóa viết bằng Rust với thiết bị và giao thức tùy chỉnh cho các tính năng như chia sẻ hệ thống tệp
Đây là một ngăn xếp tích hợp dọc được tối ưu hóa rất mạnh, chuyên cho việc chạy máy Linux và container
Lợi ích lớn nhất về hiệu năng/tài nguyên là bộ nhớ động, vì nó trả lại phần bộ nhớ không dùng đến cho macOS, giúp giảm đáng kể mức dùng RAM
Những lựa chọn khác, bao gồm Containerization, không hỗ trợ điều này
Khi thử Container Machines, tôi thấy nó gần với container OCI có bind mount mặc định hơn nhiều so với máy của OrbStack
Nó có ít tính năng tích hợp hơn và không chạy systemd hay hệ thống init thông thường, nên khó chạy dịch vụ
Hiện giờ tôi thà dùng Podman hoặc Colima hơn
Theo tôi thấy thì khá giống nhau
Bạn cũng có thể tùy chọn chạy dockerd, và https://github.com/cpuguy83/crucible chạy buildkitd hoặc dockerd bằng framework Containerization rồi kết nối với CLI docker/buildx hoặc công cụ client bạn muốn
Framework Containerization là một thư viện đặt trên Virtualization framework, nên mỗi container là một VM riêng
Machine là công cụ chạy nhiều tác vụ trên các container bên trong VM phía trên framework Containerization
Các container này có dùng chung kernel không? Hay mỗi cái chạy trong một VM riêng?
Chỉnh sửa: mỗi container là một VM https://github.com/apple/container/blob/main/docs/technical-...
Container của Apple rất phù hợp để cung cấp sandbox cho tác nhân lập trình AI
Tôi đã làm nó thành MCP để mọi tác nhân lập trình đều có thể dễ dàng tìm thấy
https://github.com/instavm/coderunner
Tôi từng tự hỏi liệu có thể chuyển volume container sang thứ như ổ đĩa ngoài hay không
Hiện tôi đang làm vậy bằng QMEU và image qcow2, và nó hoạt động khá ổn
Tôi tự hỏi vì sao macOS không thử cách tiếp cận kiểu WSL1
Tôi hiểu vì sao nó không hoàn toàn thành công trên Windows, nhưng macOS lại là một *nix khác, nên nhiều phần từng khó trên Windows có vẻ sẽ dễ hơn trên Mac
Chỉ cần thêm một ít API mới thì có vẻ phần lớn ứng dụng Linux có thể chạy native trên macOS
BSD thực ra đã có thứ như vậy rồi
ABI đơn giản và ổn định hơn rất nhiều so với kernel Linux
Liệu cái này có thể thay thế kiểu Docker Desktop, để loại bỏ VM Linux đắt đỏ đang chạy bên cạnh không?
Overhead của Docker Desktop khá nặng, nên sẽ rất tuyệt nếu thứ này được đưa vào DD theo kiểu native
Nhìn vào việc Docker trong lịch sử từng cố cải thiện hiệu năng rồi nhanh chóng phải chấp nhận giới hạn của nền tảng, điều này có vẻ khả thi, và việc chuyển DD sang phía container trông khá tự nhiên
Tôi đã thử chuyển workload Podman của mình sang Apple container: https://gist.github.com/jmonster/39e14585e107dbf990a90966c0f...
Tóm lại là giảm RAM/dung lượng lưu trữ và gần như không gây chú ý
Cái khổ khi phải lách quanh Docker Desktop là rất lớn
Có cảm giác như vài ngày một lần tôi lại phải
rm -rf ~/.colimaTôi ngạc nhiên vì Apple lại quan tâm đủ nhiều để làm việc này
Dù vậy tôi vẫn muốn dùng Linux, nhưng giá trị của MacBook là rất lớn
Có thể tôi sẽ dùng công cụ này
Mỗi lần thấy Apple phô diễn container Linux, tôi khó mà xem đó là gì khác ngoài thừa nhận thất bại
Nếu họ còn đủ năng lực thì lẽ ra Darwin cũng đã đủ dùng
Vì sao một nhà phát triển nghiêm túc lại muốn dùng mã nguồn đóng mà họ không thể debug và sửa, đặc biệt là trên máy chủ production?
Cũng vì lý do đó mà các nhà phát triển hay hacker nghiêm túc không dùng macOS
Một trong những cốt lõi của việc làm nhà phát triển là có thể đào sâu vào bất kỳ tầng mã nào để debug và sửa nó
Apple đã từ bỏ thị trường máy chủ 10 năm trước, và ngay cả trước đó họ cũng hầu như không có hỗ trợ thực sự
Kể cả có hỗ trợ container Darwin thì điều đó cũng có ý nghĩa gì? Nói theo nghĩa đen thì chẳng ai build cho mục tiêu đó cả, và Linux đã thắng
Đây là tính năng mới à?
Tôi cứ nghĩ nó đã có từ trước
Khi tôi thử nghiệm, hiệu năng hệ thống tệp trong môi trường phát triển Node/Rust với rất nhiều thao tác
stattrên các tệp nhỏ là không đủ tốt để dùngCập nhật: điểm mới là lệnh con
container machineTôi định thử nhưng trong môi trường của mình thì container hoàn toàn không chạy được: https://github.com/apple/container/issues/1681
Vẫn còn việc phải làm, nhưng chúng tôi rất hoan nghênh các workload thử nghiệm
Chúng tôi đã đầu tư rất nhiều công sức để tối ưu các tệp nhỏ và workload phổ biến của lập trình viên trong giao thức chia sẻ hệ thống tệp tùy chỉnh của OrbStack
Nó không dùng virtiofs tiêu chuẩn
Nó dùng framework container sẵn có để chạy máy
Có thể dùng cả chế độ rootful lẫn rootless