蘋果推出基於 Swift 的 macOS Docker 替代方案

蘋果推出了一個由 Swift 驅動的開源替代方案，取代 Docker 在 macOS 上運行 Linux 容器，重點放在安全性和隔離性上。

蘋果悄悄地發布了一個新的開源專案，可能會顯著改變在 macOS 上運行容器的方式。這個專案簡單地命名為 container，它引入了一個由 Swift 支援、蘋果原生的容器運行環境，專門為 macOS 系統設計，尤其是運行在 Apple Silicon 的系統。

本質上，container 允許使用者拉取、建構、運行以及推送符合 OCI 標準的 Linux 容器。然而，不同於 Docker 通常依賴共享虛擬機來運行 macOS 上的所有容器，Apple 的做法是將每個容器運行在自己的輕量級微型虛擬機中，並配備獨立的 Linux 核心和網路堆疊。根據該專案的 GitHub 頁面：

該工具消耗並生成符合 OCI 規範的容器映像，因此您可以從任何標準容器註冊表中拉取並運行映像。您也可以將自己構建的映像推送到這些註冊表，並在任何其他符合 OCI 規範的應用程式中運行這些映像。

這個模型反映了由 Firecracker 等工具推廣的微虛擬機（microVM）概念，但它已經透過 macOS 的 Virtualization.framework，也就是 Apple 的原生虛擬機管理程式介面，進行了緊密整合。

雖然蘋果並未將此工具標榜為 Docker 的完整替代品，但它確實涵蓋了本地開發使用案例中的大部分功能。CLI 相當熟悉且易於使用：可以使用像 container image pull alpine 或 container run -ti alpine sh 這樣的命令。

這個工具的獨特之處在於它能無縫整合到 macOS 作業系統本身。與其使用外部工具模擬 Linux 環境，蘋果的解決方案在大部分用戶空間中使用 Swift，包括一個名為 vminitd 的微型初始化系統，可以在毫秒內啟動容器。

該專案還包括一個 Swift 套件「Containerization」，它提供管理映像檔、卷、網路和啟動流程的低階 API，為進階使用者和工具開發者提供強大的基礎。

好吧，到目前為止一切順利，但現在，讓我分享一些我自己對這個主題的想法。老實說，我對蘋果的這個舉動有點困惑。我會立刻說明原因。

首先，我們先說清楚一件事——除了 Linux，其他操作系統並不存在真正的原生容器化，原因很簡單。Docker 依賴 Linux 特有的核心功能，如 cgroups、命名空間和覆蓋檔案系統，而 macOS 的核心無法提供這些功能。

因此，新的蘋果專案使用一個獨立的輕量級 Linux 虛擬機來運行每一個容器。與此同時，Docker 的做法是將所有內容都運行在單一虛擬機中（由 LinuxKit 構建），該虛擬機承載 Docker 引擎和所有容器。

所以，在蘋果的情況下，每個容器都在自己的獨立虛擬機中，這意味著會有很多虛擬機（無論它們多輕量），這似乎不是最有效的做法。

另一方面，獨立的虛擬機確實有一些好處。例如，蘋果新專案的一個主要優勢是它為每個容器提供自己的專屬 Linux 核心，這不同於 Docker，Docker 是在所有容器間共用同一個核心（無法為每個容器混合使用不同的核心版本）。

此外，它還使用原生的 macOS 網路堆疊，而 Docker 通常依賴帶有 NAT 或橋接網路的虛擬機。為了讓這一點更清楚，我整理了一個簡單的比較表：

儘管存在各種差異，核心理念在兩種情況下都是相同的——建構、運行以及操作符合 OCI 規範的容器映像。從這個角度來看，Docker 仍然比蘋果的新專案提供更多的靈活性和功能。

例如，尚未有 docker-compose 的對應工具，工具生態系統（例如，沒有 GUI 儀表板、編排功能有限）仍需開發和改進。

所以，我想知道為什麼蘋果會投入如此多的精力來創造這個東西。除了「Apple 製造」之外，他們似乎還想從這個幾乎完全被 Docker 主導的龐大利基市場中分一杯羹，方法是提供更好的 macOS 整合、使用系統原生 API 而不是第三方守護進程，最終還有更好的安全隔離，從而減少攻擊面。

由於這個專案仍處於早期階段，觀察它如何發展將會很有趣——以及它是否能最終取代 Docker 或 Podman，成為 macOS 開發者首選的容器工具，以滿足 Apple 的期望。