在 Mac 上跑容器版 macOS 虛擬機

📌 本文重點

• macOS Container Machines 是「整台 macOS 的類容器」
• 用指令快速建立、多開、快照還原乾淨 macOS
• 特別適合多專案隔離、本地 LLM 與簡易 CI

用一句話先說清楚：macOS Container Machines 不是一般 Docker，而是把整個 macOS 放進「類容器」裡跑起來的新形態虛擬機，讓你在一台 Mac 上快速啟動多個乾淨系統環境做開發與測試。

官方文件：apple/container GitHub 專案

---

核心功能：用指令玩出多個乾淨 macOS

1. 用簡單指令建立 / 啟動 / 銷毀 macOS Container Machine

macOS Container Machines 的操作模式很接近 Docker，但底下跑的是完整 macOS 系統：

• 建立一個 macOS Container Machine（指定 macOS 版本與名稱）：

# 建立一台名為 dev-14-5 的 macOS 14.5 Container Machine
containerctl machine create \
  --name dev-14-5 \
  --system-version 14.5 \
  --disk-size 60G \
  --memory 8G \
  --cpu-count 4

💡 關鍵： 以 containerctl machine create 指定版本與資源，就能快速拉起一台完全隔離的 macOS 環境。

• 啟動並進入這台 Machine（類似 docker start + exec）：

# 啟動
containerctl machine start dev-14-5

# 用 SSH 登入（預設會產生使用者，可在設定檔中客製）
containerctl machine ssh dev-14-5

• 停止與銷毀：

containerctl machine stop dev-14-5
containerctl machine delete dev-14-5

可以把它想成：containerctl machine 是管理整台「容器版 macOS」，你在裡面再跑普通的 app、服務、測試工具。

實際指令名稱與旗標以最新官方文件為準，上面是方便理解的指令模板。

---

2. 支援的 macOS 版本、資源隔離與快照

（1）支援哪些 macOS 版本？
目前設計是讓你在 Apple silicon Mac 上跑 Apple silicon macOS 映像，常見會用到：

• macOS 14.x（Sonoma）
• 未來會陸續支援更新版本（請看 GitHub 文件對應 --system-version 或 image tag）

實務建議：

• 平常開發用：選 跟主機一樣或略新的版本（例如主機 14.4，Machine 用 14.5）
• 回溯測試：專門起一台 舊版本 macOS 做回歸測試

（2）資源隔離（CPU / 記憶體 / 磁碟）
每台 Machine 建立時都可以指定：

--cpu-count 4    # CPU 核心數
--memory 8G      # 記憶體
--disk-size 60G  # 磁碟容量

實際效果：

• 它會像一台獨立 Mac，有自己的檔案系統
• 不會直接動到你宿主機的 /usr、/System
• 可以用共享資料夾或網路服務跟宿主機互相傳檔

💡 關鍵： CPU、記憶體與磁碟都可獨立配置，確保每台 Machine 之間與宿主機互不污染。

（3）快照 / 回滾能力
最實用的是可以對整個 macOS Machine 做快照，踩壞環境直接回復：

# 在乾淨狀態建立快照
containerctl machine snapshot create dev-14-5 --name clean

# 玩壞了環境？一鍵回到快照狀態
containerctl machine snapshot restore dev-14-5 --name clean

適合：

• 試裝一堆實驗性工具、framework
• 跑「破壞性」測試（改系統設定、測 uninstall 流程）

---

適合誰用：4 個實戰場景

1. 前端 / 後端多版本環境測試

情境：你在 Mac 上要同時維護多個專案：

• 專案 A：Node 16 + 舊版 Xcode
• 專案 B：Node 22 + 全新工具鏈

傳統做法：在同一台 macOS 裝一堆 Node 版本管理 + 手動切換，容易互相污染。

用 macOS Container Machines 的做法：

1. 為每個專案開一台 Machine：

bash
containerctl machine create --name proj-a --system-version 14.4 --cpu-count 4 --memory 8G
containerctl machine create --name proj-b --system-version 14.5 --cpu-count 6 --memory 12G

1. 在各自的 Machine 裡用 nvm 或 asdf 裝需要的 Node / Java / Python。
2. 專案測試完，直接 stop，需要時再 start。

好處：專案 A 和 B 的依賴完全隔離，卸載 / 升級不怕互相影響。

---

2. 多語言開發環境：Python / Node / Java 各一台

如果你本機環境常被 Python 套件或 Java SDK 搞壞，可以直接用「一語言一 Machine」的策略：

• py-dev：專門裝 miniconda / poetry，跑資料科學、AI 專案
• node-dev：專門跑 Next.js、Vite、前端工具鏈
• java-dev：裝不同 JDK、Maven / Gradle

指令示例：

containerctl machine create --name py-dev --system-version 14.5 --memory 8G
containerctl machine create --name node-dev --system-version 14.5 --memory 8G
containerctl machine create --name java-dev --system-version 14.5 --memory 8G

這樣你在 py-dev 裝到壞掉（例如亂動 /usr/local），直接用快照回滾，不影響其他語言環境。

---

3. 本地部署 LLM / Agent 場景測試

很多本地 LLM/Agent 方案都需要：

• 安裝特定版本 Python + 一堆 C/C++ 編譯依賴
• 開多個後端服務（向量資料庫、API gateway、觀測工具）

你可以用 macOS Container Machines 建立一台 llm-lab：

containerctl machine create \
  --name llm-lab \
  --system-version 14.5 \
  --cpu-count 8 \
  --memory 24G \
  --disk-size 200G

裡面專心裝：

• Ollama / LM Studio / text-generation-webui 類工具
• Qdrant / Milvus 等向量資料庫
• 觀測與日誌工具

你可以同時開兩台 Machine：

• llm-lab-a：測 A 套框架 + A 套模型
• llm-lab-b：測 B 套框架

切換只要 start 不同 Machine，不需要在同一系統裡反覆安裝/移除。

---

4. 在自己 Mac 上做「簡易本地 CI 流水線」

沒有 CI 伺服器，也可以在 Mac 上模擬一套：

1. 建立一台 ci-runner Machine：

bash
containerctl machine create --name ci-runner --system-version 14.5 --cpu-count 6 --memory 12G

1. 在裡面裝：
2. git
3. 自動化腳本（bash / Python）

4. 測試工具（jest、pytest、JUnit 等）

5. 在宿主機寫一個腳本：

bash
# run-ci.sh
set -e
containerctl machine start ci-runner
containerctl machine ssh ci-runner "cd /ci/project && git pull && ./run-tests.sh"
containerctl machine stop ci-runner

這樣你每次 push 前跑 ./run-ci.sh，就等於在「乾淨 macOS 環境」重做一次安裝與測試，類似本地版 CI。

---

怎麼開始：10 分鐘跑起第一個 macOS Container Machine

1. 前置條件檢查

先確認你的 Mac：

1. 硬體：Apple silicon（M1 / M2 / M3）
2. 系統版本：建議 macOS 14（Sonoma）以上
3. 啟用虛擬化：
4. 系統偏好設定 → 隱私權與安全性 → 開發者模式 / 虛擬化（依版本可能不同）

5. 終端機確認：

   bash
sysctl kern.hv_support

   若輸出包含 kern.hv_support: 1，代表已支援 Hypervisor。

6. 命令列工具：

bash
xcode-select --install # 安裝 Command Line Tools

---

2. 取得專案與安裝 CLI

1. 取得專案來源（目前在 Apple GitHub）：
   👉 https://github.com/apple/container

2. 安裝 CLI（實際安裝方式以官方文件為準）：

常見方式會是：

bash
git clone https://github.com/apple/container.git
cd container
make install # 或官方指定的安裝指令

1. 安裝完成後確認：

bash
containerctl --help

能看到 machine 相關子命令，就表示工具已就緒。

---

3. 10 分鐘內啟動第一台 macOS Container Machine

以下是一套可以直接照抄、調整參數就能用的流程。

Step 1：拉一個基礎 macOS Image（如有提供）

containerctl image pull macos:14.5   # 實際名稱以官方為準

Step 2：建立一台開發用 Machine

containerctl machine create \
  --name my-dev-mac \
  --system-version 14.5 \
  --cpu-count 4 \
  --memory 8G \
  --disk-size 80G

Step 3：啟動並登入

containerctl machine start my-dev-mac
containerctl machine ssh my-dev-mac

進去後你就像在操控另一台 Mac：可以 xcode-select --install、brew install、建立專案…

Step 4：建立初始快照

設定好你想要的「標準開發環境」後：

containerctl machine snapshot create my-dev-mac --name baseline

以後只要環境被弄亂：

containerctl machine snapshot restore my-dev-mac --name baseline

💡 關鍵： 用一個 baseline 快照當標準模板，可以無限次還原與複製穩定的開發環境。

---

4. 常見坑與排查方式

1）磁碟空間不夠

• 每台 Machine 都要單獨配置磁碟（例如 60–200 GB），很容易占滿主機
• 檢查：

bash
df -h

• 建議：
• 專案和資料盡量放在共享資料夾（掛載宿主機目錄）
• 不用的 Machine 記得 containerctl machine delete 刪掉

2）網路問題（Machine 連不到外網 / 宿主機）

常見症狀：Machine 裡 curl、git clone 失敗。

排查：

1. 先確認宿主機本身有網路。
2. 看 container 網路設定（NAT / bridge），官方文件通常會提供：

bash
containerctl network list

1. 若要從宿主機存取 Machine 內服務（例如在 Machine 跑一個 Web 伺服器），要確認：
2. Machine 內服務綁在 0.0.0.0
3. 有對應 port mapping 或可透過 Machine IP 存取

3）權限問題（安裝 / 授權失敗）

• 安裝 CLI 需要 sudo 權限時，請用管理员帳號
• Machine 內如果需要 Full Disk Access、相機、麥克風等權限，目前會比本機更受限制 —— 適合做 CLI / server 端開發，比較不適合高度依賴 GUI 的 App 測試

---

小結

如果你在 Mac 上經常遇到「環境裝一裝就亂掉」「不同專案依賴互相打架」，macOS Container Machines 提供一個新的選項：直接在一台 Mac 上開多台「容器版 macOS」來做隔離與測試。

先從一台 my-dev-mac 開始，練習建立 / 啟動 / 快照 / 回滾，熟悉之後再把日常專案慢慢搬進不同 Machine，你會更敢大膽試新工具，也更容易維持一個乾淨穩定的主機環境。

🚀 你現在可以做的事

• 到 apple/container 看最新安裝方式與 containerctl 子命令說明
• 照文中流程建立一台 my-dev-mac，實際練習啟動、SSH 登入與建立快照
• 挑一個現有專案，為它專門開一台 Machine，體驗依賴完全隔離的開發流程