Apple Container: Trải nghiệm giống Docker trên Mac với 37K sao #

Khi Apple phát hành container vào ngày 30 tháng 5 năm 2025, cộng đồng nhà phát triển gần như im lặng. Không có sự ra mắt rầm rộ, không có keynote — chỉ duy nhất một kho lưu trữ trên GitHub, và rồi lặng lẽ tích lũy 37.130 sao, trở thành dự án mã nguồn mở mới từ Apple được theo dõi nhiều nhất trong nhiều năm.

Đây không phải là Docker cho Mac. Đây là một thứ hoàn toàn khác biệt.

container là một công cụ được xây dựng bằng Swift, chạy các container Linux dưới dạng máy ảo nhẹ trên Mac. Nó sử dụng framework Virtualization của macOS và tích hợp sâu với các thành phần hệ thống macOS — vmnet, XPC, Launchd, Keychain. Công cụ này tạo ra và tiêu thụ hình ảnh tương thích OCI, nghĩa là hình ảnh Docker của bạn sẽ hoạt động ở đây, và hình ảnh được xây dựng bằng container cũng chạy được trong Docker.

Nhưng kiến trúc của nó khác biệt cơ bản so với Docker Desktop, Colima hay OrbStack. Hãy cùng khám phá lý do tại sao các nhà phát triển đã gọi nó là “tương lai của containerization trên Mac.”

Tại sao Apple xây dựng điều này #

Apple luôn gặp khó khăn với containerization trên Mac. Mac không chạy Linux gốc, nên việc chạy container Linux luôn đòi hỏi một máy ảo Linux — và máy ảo đó luôn cồng kềnh. Docker Desktop cho Mac sử dụng một máy ảo Ubuntu đầy đủ ở tầng dưới. Colima đã giảm kích thước. OrbStack làm cho nó nhanh hơn. Nhưng không công cụ nào thay đổi được kiến trúc cốt lõi.

container tiếp cận theo hướng khác: một máy ảo nhẹ cho mỗi container.

Điều này có nghĩa là mỗi container nhận được sự cô lập ở mức máy ảo mà không chịu chi phí của một máy ảo dùng chung. Không còn vấn đề giao tiếp giữa các container, không còn bề mặt lỗ hổng nhân dùng chung, không còn rủi ro “thoát container” từ một hypervisor dùng chung.

Kiến trúc cốt lõi #

container không chạy các container bên trong một máy ảo Linux dùng chung. Thay vào đó, nó tạo một máy ảo chuyên dụng cho từng container bằng cách sử dụng framework Virtualization của Apple. Điều này có nghĩa thực tế như sau:

Bảo mật: Mỗi container có đặc tính cô lập của một máy ảo đầy đủ
Quyền riêng tư: Bạn chỉ mount những dữ liệu cần thiết vào từng VM, một cách chọn lọc
Hiệu năng: Thời gian khởi động tương đương container Docker, nhưng với sự cô lập ở mức VM

Công cụ này tiêu thụ và tạo ra hình ảnh container tương thích OCI, vì vậy bạn có thể kéo và chạy hình ảnh từ bất kỳ registry container tiêu chuẩn nào — Docker Hub, GitHub Container Registry, Google Container Registry, tùy bạn chọn.

Cài đặt và Thiết lập #

Yêu cầu hệ thống #

Bạn cần một Mac với chip Apple Silicon (M1/M2/M3/M4) và macOS 26 (hoặc macOS 15 với một số hạn chế). Đây là yêu cầu bắt buộc vì container sử dụng các tính năng mới trong framework Virtualization và mạng của macOS 26.

# Tải trình cài đặt mới nhất từ GitHub releases
# https://github.com/apple/container/releases

# Cài đặt gói đã được ký
# Nhấp đúp và làm theo hướng dẫn

# Khởi động dịch vụ hệ thống
container system start

Quá trình cài đặt đặt các tệp dưới /usr/local và đăng ký container như một dịch vụ hệ thống được quản lý bởi Launchd.

Cài đặt từ mã nguồn #

Dành cho các nhà phát triển muốn tự biên dịch:

# Clone repository
git clone https://github.com/apple/container.git
cd container

# Làm theo hướng dẫn trong BUILDING.md
swift build -c release
swift test

Dự án sử dụng Swift Package Manager và phụ thuộc vào gói Swift Containerization để quản lý container cấp thấp, hình ảnh và tiến trình.

Các tính năng cốt lõi #

1. Chạy container #

Câu lệnh cơ bản tương tự Docker:

# Kéo và chạy container
container run --rm docker.io/python:alpine python --version

# Chạy với giới hạn bộ nhớ và CPU tùy chỉnh
container run --rm --cpus 8 --memory 32g big

# Shell tương tác
container run -it --rm docker.io/ubuntu bash

Mỗi container chạy trong một máy ảo riêng biệt. Phân bổ mặc định là 1GB RAM và 4 CPU, nhưng bạn có thể ghi đè bằng --memory và --cpus.

2. Xây dựng hình ảnh #

Việc xây dựng hình ảnh sử dụng cú pháp Dockerfile quen thuộc:

# Xây dựng hình ảnh cục bộ
container build --tag myapp:latest --file Dockerfile .

# Xây dựng cho nhiều kiến trúc
container build --arch arm64 --arch amd64 \
  --tag registry.example.com/fido/web-test:latest \
  --file Dockerfile .

# Thử chạy với kiến trúc cụ thể
container run --arch arm64 --rm \
  registry.example.com/fido/web-test uname -a

Đầu ra hiển thị thông tin kernel của VM:

Linux 7932ce5f-ec10-4fbe-a2dc-f29129a86b64 6.1.68 #1 SMP Mon Mar 31 18:27:51 UTC 2025 aarch64 GNU/Linux

3. Xây dựng đa nền tảng #

Một trong những tính năng mạnh mẽ nhất là xây dựng hình ảnh chéo nền tảng. Bạn có thể tạo một hình ảnh duy nhất chạy trên cả Mac Apple Silicon và máy chủ x86-64:

# Xây dựng hình ảnh đa nền tảng
container build --arch arm64 --arch amd64 \
  --tag myapp:latest .

# Đẩy lên registry
container push myapp:latest

Hình ảnh kết quả hoạt động trong Docker, Containerd và bất kỳ runtime tương thích OCI nào.

4. Quản lý volume #

Chia sẻ tệp host với container bằng --volume hoặc --mount:

# Mount thư mục bằng --volume
container run --volume ${HOME}/Desktop/assets:/content/assets \
  docker.io/python:alpine ls -l /content/assets

# Mount bằng --mount (cú pháp key=value)
container run --mount source=${HOME}/Desktop/assets,target=/content/assets \
  docker.io/python:alpine ls -l /content/assets

Sự khác biệt chính so với Docker: bạn chỉ mount dữ liệu cần thiết vào từng VM, không phải mọi thứ mà VM có thể cần.

5. Quản lý builder #

Với các bản xây dựng tốn nhiều tài nguyên, bạn có thể tùy chỉnh VM builder:

# Khởi động builder với tài nguyên tùy chỉnh
container builder start --cpus 8 --memory 32g

# Dừng và khởi động lại nếu cần
container builder stop
container builder delete
container builder start --cpus 8 --memory 32g

VM builder mặc định nhận 2GB RAM và 2 CPU — đủ cho các dự án đơn giản nhưng không đủ cho các bản build nặng.

Tính năng nâng cao #

Mạng container #

container tích hợp với framework vmnet của macOS cho mạng ảo:

# Liệt kê mạng
container network ls

# Tạo mạng tùy chỉnh
container network create mynet

# Chạy container trên mạng cụ thể
container run --network mynet myapp

Giao tiếp giữa các container qua mạng ảo hoạt động trên macOS 26. Trên macOS 15, các container được cô lập với nhau theo mặc định.

Dịch vụ hệ thống #

Chạy container như các dịch vụ liên tục:

# Khởi động dịch vụ hệ thống
container system start

# Dừng dịch vụ hệ thống
container system stop

# Kiểm tra trạng thái
container system status

container-apiserver chạy như một Launchd agent và quản lý tài nguyên container và mạng thông qua các helper XPC.

Nâng cấp và hạ cấp #

# Nâng cấp lên phiên bản mới nhất
/usr/local/bin/update-container.sh

# Hạ cấp xuống phiên bản cụ thể
container system stop
/usr/local/bin/uninstall-container.sh -k
/usr/local/bin/update-container.sh -v 0.3.0
container system start

Gỡ cài đặt #

# Xóa không bao gồm dữ liệu
/usr/local/bin/uninstall-container.sh -k

# Xóa kèm xóa sạch dữ liệu
/usr/local/bin/uninstall-container.sh -d

So sánh với các giải pháp thay thế #

Hãy so sánh container với các lựa chọn hiện có:

Tính năng	Apple Container	Docker Desktop	Colima	OrbStack
Mô hình VM cơ sở	1 VM per container	Linux VM dùng chung	Linux VM dùng chung	Linux VM dùng chung
Ngôn ngữ	Swift	Go	Go	Rust
Tương thích OCI	Có	Có	Có	Có
Yêu cầu macOS	Apple Silicon + macOS 26	Intel + Apple Silicon	Apple Silicon	Apple Silicon + Intel
Sử dụng bộ nhớ	Phân bổ theo container	Pool dùng chung	Pool dùng chung	Pool dùng chung
Cô lập container	Mức VM đầy đủ	Nhân dùng chung	Nhân dùng chung	Nhân dùng chung
Xây dựng đa nền tảng	Có (arm64 + amd64)	Có	Có	Có
Miễn phí	Có	Trả phí ($5/tháng)	Có	Trả phí

Những điểm khác biệt chính #

VM cho mỗi container: Khác với Docker, Colima hay OrbStack sử dụng một máy ảo Linux dùng chung, container tạo một VM dành riêng cho mỗi container. Điều này tốn tài nguyên hơn cho mỗi container nhưng cung cấp sự cô lập thực sự ở mức VM.
Tích hợp gốc macOS: Tích hợp sâu với framework Virtualization của macOS, vmnet, XPC, Launchd và Keychain có nghĩa là nó tận dụng các tính năng macOS mà các công cụ bên thứ ba không thể truy cập.
OCI-first: Được sinh ra như một công cụ OCI gốc, không phải wrapper của Docker. Điều này có nghĩa là hình ảnh thực sự tuân thủ OCI, chứ không chỉ là “hình ảnh Docker giả dạng OCI.”
Hệ sinh thái Swift: Được xây dựng bằng Swift với gói Containerization Swift, mở ra cánh cửa tích hợp công cụ macOS native mà các công cụ dựa trên Go không thể sánh kịp.

Kiến trúc kỹ thuật #

Kiến trúc container bao gồm nhiều thành phần:

┌─────────────────────────────────────────────────────┐
│                  container CLI                       │
└────────────────┬────────────────────────────────────┘
                 │ XPC Communication
┌────────────────▼────────────────────────────────────┐
│           container-apiserver (Launchd agent)        │
├────────────────┬─────────────────┬──────────────────┤
│                │                 │                  │
│ container-     │ container-      │ container-       │
│ core-images    │ network-vmnet   │ runtime-linux    │
│ (image mgmt)   │ (network mgmt)  │ (per-container)  │
└────────────────┴─────────────────┴──────────────────┘
                 │
┌────────────────▼────────────────────────────────────┐
│        macOS Virtualization + vmnet frameworks       │
└─────────────────────────────────────────────────────┘

container-apiserver là bộ điều phối trung tâm. Nó khởi động khi bạn chạy container system start và quản lý:

container-core-images: Quản lý hình ảnh và kho lưu trữ nội dung cục bộ
container-network-vmnet: Quản lý mạng ảo qua vmnet
container-runtime-linux: API quản lý theo từng container

Mỗi thành phần giao tiếp thông qua XPC, hệ thống giao tiếp giữa các tiến trình của Apple. Đây là điều cho phép tích hợp chặt chẽ với các dịch vụ hệ thống macOS.

Hạn chế và sự cố đã biết #

Quản lý bộ nhớ #

Framework Virtualization của macOS chỉ hỗ trợ memory ballooning một phần. Khi bạn phân bổ 16GB cho một container nhưng nó chỉ sử dụng 2GB, các trang bộ nhớ giải phóng không được trả về macOS:

Hiện tại, các trang bộ nhớ được giải phóng cho hệ điều hành Linux bởi các tiến trình chạy trong VM của container không được hoàn trả cho host. Nếu bạn chạy nhiều container nặng bộ nhớ, bạn có thể cần thỉnh thoảng khởi động lại chúng để giảm mức sử dụng bộ nhớ.

Đây là hạn chế cơ bản của framework Virtualization của Apple, không phải thứ mà container có thể tự khắc phục.

Hạn chế trên macOS 15 #

Trên macOS 15 (Sonoma), một số tính năng bị giới hạn:

Không có giao tiếp giữa các container — các container được cô lập với nhau
Không có mạng tùy chỉnh — tất cả container sử dụng mạng vmnet mặc định
Vấn đề mạng — xung đột IP container có thể gây mất hoàn toàn mạng

Quan điểm của Apple rất rõ ràng: macOS 15 được hỗ trợ nhưng các vấn đề không thể tái hiện trên macOS 26 “sẽ không được giải quyết.”

Phát triển đang diễn ra #

Dự án vẫn đang trong giai đoạn phát triển tích cực với phiên bản 1.0.0 vừa được công bố gần đây. Các bản phát hành phiên bản nhỏ có thể bao gồm các thay đổi gây vỡ (breaking changes):

Độ ổn định, cả khi tiêu thụ dự án như một gói Swift và công cụ container, chỉ được đảm bảo trong phạm vi các phiên bản vá, chẳng hạn như giữa 0.1.1 và 0.1.2.

Tại sao điều này quan trọng đối với ngành #

Sự tham gia của Apple vào lĩnh vực containerization có ý nghĩa quan trọng vì nhiều lý do:

Tuân thủ tiêu chuẩn OCI: Bằng cách tạo ra các hình ảnh OCI tiêu chuẩn, Apple đang truyền tải thông điệp rằng container là một tiêu chuẩn mở, không phải hệ sinh thái của Docker. Điều này xác nhận phong trào container mã nguồn mở.
Mac như một nền tảng phát triển hạng nhất: Apple lâu nay đã dẫn đầu trong vai trò máy Mac trong thế giới phát triển. container thúc đẩy xu hướng này bằng cách mang đến cho nhà phát triển Mac cùng quy trình container mà họ có trên máy chủ Linux.
Phát triển hệ sinh thái Swift: Gói Swift Containerization có thể trở thành nền tảng cho một hệ sinh thái container macOS-native rộng lớn hơn.
Thiết kế ưu tiên bảo mật: Mô hình VM cho mỗi container giải quyết một mối lo ngại bảo mật thực sự — bề mặt lỗ hổng nhân dùng chung. Đối với các tổ chức có yêu cầu bảo mật nghiêm ngặt, điều này rất quan trọng.

Bắt đầu: Hướng dẫn thực tế #

Dưới đây là quy trình hoàn chỉnh từ đầu:

# 1. Khởi động dịch vụ hệ thống
container system start

# 2. Kéo hình ảnh tiêu chuẩn
container pull docker.io/nginx:alpine

# 3. Chạy với ánh xạ cổng
container run -d --name webserver \
  --cpus 2 --memory 2g \
  -p 8080:80 \
  docker.io/nginx:alpine

# 4. Kiểm tra đang chạy
container ps

# 5. Xem nhật ký
container logs webserver

# 6. Tự xây dựng hình ảnh
mkdir myapp && cd myapp
echo -e "FROM docker.io/python:alpine\nCMD ['python', '--version']" > Dockerfile
container build --tag myapp:latest .
container run --rm myapp:latest

# 7. Đẩy lên registry (cần thiết lập xác thực)
container push myapp:latest

Nguồn và đọc thêm #

Tuyên bố miễn trừ #

Bài viết này dựa trên thông tin công khai từ kho lưu trữ GitHub apple/container. Tất cả dữ liệu (sao, fork, số phiên bản) đã được xác minh qua GitHub API vào ngày 15 tháng 6 năm 2026. Tác giả chưa tự kiểm thử container trên Mac nhưng dựa vào tài liệu chính thức và báo cáo từ cộng đồng.

Câu hỏi thường gặp #

Q: container có hoạt động trên Mac Intel không? A: Không. container yêu cầu Apple Silicon (M1/M2/M3/M4). Nó sử dụng framework Virtualization của macOS được tối ưu hóa cho Apple Silicon.

Q: Tôi có thể chạy tệp Docker Compose không? A: Không trực tiếp. container hiện không hỗ trợ tệp docker-compose. Tuy nhiên, vì nó hỗ trợ hình ảnh OCI, bạn có thể xây dựng và chạy từng hình ảnh riêng lẻ. Quy trình đa container yêu cầu điều phối thủ công.

Q: container có miễn phí không? A: Có, container là mã nguồn mở dưới giấy phép Apache-2.0. Không cần đăng ký hoặc thanh toán.

Q: Tôi có thể dùng cho sản xuất không? A: Dự án vừa đạt phiên bản 1.0.0 nhưng vẫn đang phát triển tích cực. Apple khuyến nghị sử dụng các phiên bản vá (patch versions) để đảm bảo ổn định. Sử dụng cho sản xuất là khả thi nhưng đi kèm lưu ý rằng các phiên bản nhỏ có thể bao gồm thay đổi gây vỡ.

Q: So với OrbStack thì sao? A: OrbStack nhanh hơn cho quy trình container đơn và hỗ trợ Mac Intel. container cung cấp sự cô lập thực sự ở mức VM và tích hợp sâu với macOS. Đối với hầu hết nhà phát triển, OrbStack dễ thiết lập hơn. Đối với các nhóm chú trọng bảo mật, mô hình cô lập của container vượt trội.

Q: Tôi có thể chạy container Windows không? A: Không. container chỉ chạy container Linux. Nó tạo ra hình ảnh Linux tương thích OCI. Container Windows không được hỗ trợ.

Q: Điều gì xảy ra khi bộ nhớ được giải phóng bên trong container? A: Các trang bộ nhớ giải phóng không được trả về host macOS. Bạn có thể cần khởi động lại container định kỳ để thu hồi bộ nhớ nếu chạy nhiều container nặng bộ nhớ.

Bạn có quan tâm đến nhiều đánh giá công cụ AI và hạ tầng nhà phát triển hơn không? Tham gia cộng đồng Telegram của chúng tôi để nhận cập nhật hàng ngày và quyền truy cập sớm vào các bài viết mới.