- Containerization là công cụ mã nguồn mở dựa trên Swift, cho phép chạy container Linux trên macOS
- Hoạt động trên Mac dùng Apple Silicon, tận dụng Virtualization.framework để cô lập và chạy từng container trong các máy ảo gọn nhẹ
- Bao gồm nhiều tính năng như quản lý image OCI, tích hợp registry từ xa, tạo hệ thống tệp ext4, điều khiển môi trường container
- Có thể hỗ trợ chạy tiến trình x86_64 trên Apple Silicon nhờ Rosetta 2
- Giúp tăng tính linh hoạt và hiệu năng cho lập trình viên với khởi động cực nhanh, môi trường nhẹ, tùy biến phiên bản kernel
Tổng quan dự án
- Containerization là gói Swift giúp ứng dụng sử dụng container Linux
- Được triển khai bằng ngôn ngữ Swift và hoạt động trên Mac dùng Apple Silicon thông qua Virtualization.framework
- API cung cấp các chức năng sau
- Quản lý image OCI
- Tích hợp container registry từ xa
- Tạo và triển khai hệ thống tệp ext4
- Tương tác với Netlink socket family
- Cung cấp Linux kernel tối ưu hóa để khởi động nhanh
- Tạo và quản lý máy ảo gọn nhẹ
- Điều khiển môi trường chạy của máy ảo
- Tạo và điều khiển tiến trình được container hóa
- Chạy tiến trình x86_64 trên Apple Silicon bằng Rosetta 2
- Tài liệu API có thể xem tại trang chính thức riêng
Thiết kế và cấu trúc
- Mỗi container Linux chạy bên trong một máy ảo độc lập
- Có thể gán địa chỉ IP riêng cho từng container, giúp quản lý mạng dễ dàng mà không cần port forwarding
- Nhờ cấu hình kernel tối ưu hóa và root filesystem nhẹ, có thể khởi động container dưới 1 giây
- vminitd là một subproject của Containerization, đóng vai trò là hệ thống init gọn nhẹ chạy như tiến trình khởi tạo trong máy ảo
- Thiết lập môi trường chạy qua GRPC API và hỗ trợ vận hành, quản lý tiến trình container
- Chuyển tiếp xử lý nhập/xuất, signal và event đến tiến trình đã gọi
Yêu cầu
- Cần thiết bị Apple Silicon Mac
- Để build package, cần
- macOS 15 trở lên và Xcode 26 Beta
- hoặc macOS 26 Beta 1 trở lên
- Khi dùng trên macOS 15, các tính năng sau sẽ bị hạn chế
- Mạng container không cô lập: không thể giao tiếp giữa các container trên cùng mạng vmnet
Ví dụ sử dụng
- Cung cấp file thực thi cctl: dạng playground để thử nghiệm nhiều tính năng khác nhau của API
- Ví dụ các lệnh chính
- Thao tác với image OCI
- Đăng nhập container registry
- Tạo khối root filesystem
- Chạy container Linux đơn giản
Cấu hình Linux kernel
- Cần Linux kernel để chạy máy ảo gọn nhẹ cho container
- Cấu hình kernel tối ưu do Containerization cung cấp nằm trong thư mục kernel
- Cấu hình này chỉ chứa các chức năng tối thiểu để mang lại khởi động nhanh và môi trường nhẹ
- Có sẵn API để tùy theo nhu cầu có thể chỉ định cấu hình và phiên bản kernel khác nhau cho từng container
- Có thể thử nghiệm nhiều phiên bản và cấu hình kernel khác nhau
- Có thể dùng kernel biên dịch sẵn như vmlinux.container do dự án Kata Containers cung cấp
- Tuy nhiên, driver VIRTIO phải được tích hợp sẵn trong kernel (compiled-in)
Tóm tắt quy trình phát triển và kiểm thử
- Cần chuẩn bị môi trường như Swift, Static Linux SDK, v.v.
- Có thể build và test mã nguồn (
make all, make test integration, v.v.)
- Cần kernel image để chạy integration test
- Hỗ trợ cấu hình dependency sử dụng các phiên bản cụ thể liên quan đến gRPC/Protobuf
- Tích hợp khả năng tự động sinh tài liệu API và xem trước cục bộ
Đóng góp mã nguồn mở và tình trạng dự án
- Hoan nghênh đóng góp
- Phiên bản 0.1.0 là bản phát hành chính thức đầu tiên, và độ ổn định của mã nguồn chỉ được đảm bảo trong phạm vi minor version
- Chính sách này có thể thay đổi trong các bản phát hành minor sau này
Tóm tắt
- Containerization là gói Swift mang tính đột phá giúp lập trình viên quản lý, chạy và phát triển với container Linux trên macOS trong môi trường tối ưu hóa
- Bằng cách chạy từng container trong máy ảo riêng gọn nhẹ, nó mang lại lợi thế về cô lập, hiệu năng, mạng và tùy biến kernel
- Đây là giải pháp phù hợp cho các nhà phát triển muốn mở rộng môi trường container mã nguồn mở sang trải nghiệm native trên macOS
1 bình luận
Ý kiến trên Hacker News
Chia sẻ điều được cho là phần đáng ngạc nhiên và thú vị nhất
Có ý kiến cho rằng không cần quá ngạc nhiên về việc Apple tham gia cộng đồng mã nguồn mở
Đồng thời nhắc đến thực tế là Swift và các framework liên quan của nó cũng đã nhận được rất nhiều đóng góp từ cộng đồng mã nguồn mở
Vì dự án này xử lý Linux, có quan điểm cho rằng chính tính chất copyleft của Linux (giấy phép mã nguồn mở mạnh) khiến Apple gần như buộc phải chọn cách cộng tác
Gợi ý xem video liên quan là bài trình bày tại WWDC 2025 (https://developer.apple.com/videos/play/wwdc2025/346/)
Cấu trúc là mỗi container được tách riêng thành một Linux VM nhẹ
Có thể tải công cụ container để tự chạy trực tiếp (https://github.com/apple/container/releases), cần macOS 26
Mục được gửi lần này là https://github.com/apple/containerization chứ không phải dự án container
containerization dùng cho việc triển khai ứng dụng kèm sidecar container nên là tin còn thú vị hơn
Trong khi đó, container nhằm phục vụ nhà phát triển dùng môi trường kiểu 'docker run ...'
Với container thì đã có một luồng HN riêng (https://news.ycombinator.com/item?id=44229239)
Cũng có thể chạy trên macOS 15, nhưng cần lưu ý một số tính năng mạng có thể bị hạn chế
Trong thông cáo báo chí và phiên WWDC có nhắc rằng công cụ CLI nằm tại https://github.com/apple/container
Với người rất quan tâm đến kiểu công cụ này, đã kỳ vọng nó sẽ được tích hợp sẵn trong Xcode Beta mới nhất, nhưng hiện vẫn chưa có
Gói prebuilt hiện đang được chuẩn bị, và có thể theo dõi tiến độ trong issue công khai (https://github.com/apple/container/issues/54)
Đúng 1 phút sau bình luận đó, có người chia sẻ tin gói prebuilt đã phát hành (https://github.com/apple/container/releases/tag/0.1.0)
Thảo luận liên quan đang diễn ra trong một luồng HN riêng (https://news.ycombinator.com/item?id=44229239)
Tò mò không biết từ góc nhìn của Docker thì họ sẽ cảm thấy thế nào
Có thể hình dung phần lớn người dùng Docker for Desktop đều đang dùng Mac
Có ý kiến cho rằng thay đổi lần này ngược lại còn khiến việc phát triển Docker Desktop dễ dàng hơn nhiều
Giờ đây không còn phải tự thiết lập Linux VM riêng nữa nên độ khó phát triển được giảm bớt
Dù vậy, dự đoán vẫn sẽ có nhiều người dùng thích Docker Desktop hiện tại hơn vì CLI quen thuộc, Docker Compose và nhiều UX riêng của Docker
Việc thay đổi container runtime không phải chuyện dễ dàng
Có suy đoán rằng từ phía Docker, cảm giác này sẽ tương tự như khi đối mặt với podman
Vì Docker Desktop là phần mềm thương mại mã nguồn đóng, còn dự án lần này là phần mềm tự do, nên từ phía người dùng đây là tin tốt
Tò mò liệu công nghệ này có thể dùng để đóng gói Linux container vào ứng dụng macOS hay không
Ví dụ như khi cần cho một công cụ kiểu GPT truy cập vào môi trường Linux mà không cần lệnh CLI ở quyền root
Nếu chấp nhận chỉ chạy trên macOS 26 thì có thể dùng ngay cho đúng mục đích đó
Nếu không thì cũng có thể dùng trực tiếp Virtualization.framework, nhưng sẽ cần thêm nhiều công sức hơn
Có người quả quyết rằng đây chính xác là công nghệ được tạo ra cho mục đích như vậy
Mỗi container chạy trong một VM tách biệt riêng, có cách ly hoàn toàn và được cấp IP độc lập, đây là cấu trúc khá thú vị nhưng không quen thuộc với Linux hay Windows
Nếu trong đội phát triển có dù chỉ một người không dùng Mac thì mô hình phát triển cục bộ sẽ bị phá vỡ
Kết luận là sẽ không dễ để thay thế Docker/Compose
Trong ba hệ điều hành desktop lớn thì nay đã có hai nơi chính thức chạy Linux VM để thực thi ứng dụng native Linux
Nhìn theo xu hướng này có thể nói Linux thực chất đã thắng
API system call của Linux giờ gần như ở vị trí một API phổ quát hoạt động ở khắp nơi
Có phản biện rằng việc phát triển ứng dụng dựa trên Linux phải diễn ra bình thường trên hai hệ điều hành lớn không phải Linux tự nó không đủ để gọi là "chiến thắng của Linux"
Cũng có chia sẻ trải nghiệm rằng thực tế của desktop Linux vẫn còn thiếu ổn định và khó có thể khuyến nghị
Thành thật mà nói, năm nào cũng thử cài Fedora/Ubuntu lên PC hoặc laptop mới nhất nhưng vẫn chưa cảm nhận được tính khả dụng và độ ổn định như mong đợi
Ngược lại, có quan điểm cho rằng chính việc hai nền tảng kia cung cấp cách dùng Linux mà không cần rời khỏi hệ của họ lại làm chậm sự gia tăng thị phần của chính Linux trên desktop
Nhược điểm được nhấn mạnh là vẫn chưa có giải pháp thật sự tốt cho đồ họa, âm thanh và GUI
Có người đặt câu hỏi: "Nếu người chơi tham gia trò chơi chỉ có một mình mình, thì có thể gọi là thắng không?"
Kèm câu đùa rằng với người dùng Windows hay Mac bình thường thì nói vậy họ còn chẳng biết Linux là gì
Có ý kiến cho rằng bản thân việc có "macOS cùng với Linux" đã là một điều rất có sức nặng
Tò mò không biết họ có tối ưu cả việc quản lý bộ nhớ hay không, chẳng hạn cấu trúc để VM không dùng quá nhiều RAM hơn mức cần thiết
Không rõ chính xác quy trình nào đang diễn ra, nhưng cảm giác tốc độ build quá chậm
Đã thử tăng thêm tài nguyên CPU/bộ nhớ bằng tùy chọn -c, -m nhưng hiệu quả cảm nhận được không nhiều
Đồng thời chia sẻ trải nghiệm trước đây với Mac Silicon + Rancher Desktop: có vẻ như đã build image x86 được, nhưng khi chạy những image đó trên phần cứng x86 thật thì chúng lại không hoạt động đúng
Trong bản demo ngắn (https://developer.apple.com/videos/play/wwdc2025/346) khả năng khởi động VM chỉ trong vài trăm mili giây là điều khá ấn tượng
Nó chạy trên Virtualization.framework, vốn cũng là công nghệ mà Docker desktop/Colima/UTM v.v. từng dùng theo lựa chọn
Khi chạy song song nhiều container thì khá tò mò về phần overhead bộ nhớ