Apple giới thiệu "Container Machine": Trải nghiệm kiểu WSL dành cho nhà phát triển Mac

Apple đã giới thiệu tính năng "container machine" (máy container) tại hội nghị WWDC tuần này, mang đến cho các nhà phát triển Mac một giải pháp chạy các máy ảo Linux bền vững. Tính năng này có nhiều điểm tương đồng với Hệ thống Con cho Linux (WSL) trên hệ điều hành của Microsoft.

Apple giới thiệu Container Machine tại WWDC

Các nhà phát triển sử dụng macOS cũng giống như những người dùng Windows, đều gặp phải vấn đề rằng phần lớn các ứng dụng được triển khai trên môi trường Linux. Điều này tạo ra sự khác biệt giữa máy phát triển và mục tiêu triển khai. Mặc dù macOS cũng giống như Linux ở chỗ đều dựa trên nền tảng Unix, nhưng sự "ma sát" trong quá trình phát triển vẫn tồn tại.

Giải pháp của Apple được xây dựng dựa trên dự án Container (Container) được giới thiệu trước đó tại WWDC năm ngoái. Phiên bản 1.0 đã được phát hành tại WWDC năm nay, hoàn chỉnh với tính năng container machine mới. Dự án này sử dụng các tiêu chuẩn container của Sáng kiến Container Mở (OCI), và cả container lẫn container machine đều chạy trên các máy ảo (VM) nhẹ, mang lại khả năng cô lập dữ liệu mạnh mẽ.

Cách thức hoạt động và tích hợp

Tên gọi "container machine" nhằm thể hiện rằng tính năng này kết hợp cả một container và một máy ảo. Tính năng này sử dụng khung ảo hóa (virtualization framework) gốc của Apple, và giao diện dòng lệnh tích hợp tốt với macOS. Sau khi cài đặt, lệnh container machine run sẽ mở một thiết bị đầu cuối trong container machine mặc định.

Một lựa chọn khác là chạy một lệnh như container machine run uname -a, lệnh này sẽ thực thi trong container machine mặc định nhưng không cần rời khỏi shell của macOS. Mã nguồn được viết bằng ngôn ngữ Swift và là mã nguồn mở trên GitHub theo giấy phép Apache 2.0. Nó sử dụng một gói Swift khác gọi là containerization, cũng là mã nguồn mở.

Trên Windows, WSL là một công cụ quan trọng đối với các nhà phát triển. Liệu container machine có thể tạo ra tác động tương tự cho các nhà phát triển Mac? Có tiềm năng đó, nhưng Apple vẫn còn việc phải làm cả về tính năng và tài liệu hướng dẫn, hơn nữa dự án hiện vẫn đang được "giấu kín" trên GitHub thay vì được trình bày như một phần của macOS.

Trải nghiệm thực tế

Giao diện dòng lệnh và quy trình làm việc với Container Machine

Chúng tôi đã thực hiện một thử nghiệm nhanh, cài đặt bản phát hành 1.0 từ gói phát hành trên GitHub lên macOS 26. Chỉ có macOS 26 được hỗ trợ. Sau khi cài đặt, lệnh container machine create được kích hoạt, tuy nhiên chỉ những container có chương trình khởi tạo hệ thống /sbin/init mới hoạt động được. Nhiều hình ảnh container được thiết kế để chạy ứng dụng thay vì dùng làm VM bền vững thường không bao gồm chương trình này. Giải pháp là xây dựng một hình ảnh container tùy chỉnh từ Dockerfile, tài liệu hiện tại đã có các ví dụ về việc này.

Chúng tôi đã sử dụng Dockerfile được cung cấp trong một hướng dẫn thiết lập một container machine dựa trên Ubuntu 24.04 bao gồm Swift SDK, sau đó thực hiện các bước phát triển bằng Visual Studio Code trên macOS và kết nối với container machine thông qua tính năng remoting của VS Code. Quá trình này hoạt động và chúng tôi có thể xây dựng một dự án trên Linux và chạy nó bằng VS Code và Safari trên máy Mac, tuy nhiên các điểm ngắt (breakpoints) gỡ lỗi không hoạt động. Chúng tôi đã thử lại với một dự án .NET và việc gỡ lỗi đã hoạt động chính xác.

Các vấn đề về Bảo mật và Bộ nhớ

Theo mặc định, một container machine sẽ gắn thư mục home của macOS với quyền đọc-ghi. Điều này rất tuyệt vời để truy cập mã hoặc tài nguyên khác từ cả macOS và container machine, nhưng không tốt cho bảo mật. Một gói độc hại được cài đặt trên Linux, ví dụ, có thể dễ dàng thu thập thông tin đăng nhập từ thư mục .ssh trên macOS. Điều này có thể cấu hình thông qua đối số --home-mount. Cài đặt quyền truy cập thành "none" sẽ an toàn hơn.

Bộ nhớ khả dụng cho một container machine mặc định là một nửa bộ nhớ hệ thống. Trong trường hợp của chúng tôi là 32 GB, nhưng sau khi khởi động VM và khởi chạy PostgreSQL, bộ nhớ thực tế sử dụng theo Activity Monitor chỉ là 1 GB. Bộ nhớ bổ sung sẽ được sử dụng khi cần, nhưng một hạn chế được mô tả trong tổng quan kỹ thuật là bộ nhớ không thể được giải phóng lại cho máy chủ. Nói cách khác, việc sử dụng bộ nhớ sẽ tăng lên trong quá trình sử dụng và chỉ có thể được giải phóng bằng cách khởi động lại VM.

WSL hỗ trợ các ứng dụng giao diện đồ họa (GUI) thông qua hệ thống đồ họa X11 hoặc Wayland. Một vấn đề được người dùng đưa ra về các ứng dụng GUI trong container đã bị đóng với lý do là các nhà phát triển có thể cài đặt XQuartz, một dự án chạy hệ thống cửa sổ X trên macOS, và sau đó sử dụng mạng container-to-host để kết nối, mặc dù chúng tôi không thử điều này. Hỗ trợ GUI dường như không phải là mục tiêu của dự án.

Đánh giá chung

Các nhà phát triển Mac hiện nay đã có nhiều cách để chạy container hoặc máy ảo Linux, bao gồm hệ sinh thái trưởng thành xung quanh Docker, Podman, Colima, UTM, VirtualBox và OrbStack, cũng như tùy chọn sử dụng SSH để kết nối với máy ảo Linux từ xa. Điều đó có nghĩa là Apple cần nỗ lực để thiết lập các công cụ container gốc của mình, và bây giờ là container machines, như những giải pháp thay thế nghiêm túc.

Về mặt tích cực, hệ thống này nhẹ nhàng, bên cạnh việc không thể giải phóng bộ nhớ, và hoạt động tốt trong trải nghiệm ngắn của chúng tôi. Một video tại WWDC có thêm chi tiết, cùng với tài liệu trên GitHub.