共用方式為


Windows 上的容器平台工具

Windows 容器平台擴充了! Docker 是容器旅程的第一步,而現在我們要建立其他容器平台工具。

本文將討論 Windows 和 Linux 容器平台,以及每個容器平台工具。

Windows 和 Linux 容器平台

在 Linux 環境中,容器管理工具 (例如 Docker) 奠基於更細微的容器工具集:runccontainerd

Linux 上的 Docker 架構

runc 是 Linux 命令列工具,可根據 OCI 容器執行階段規格來建立和執行容器。

containerd 是可管理容器生命週期的精靈程式,從下載和解壓縮容器映像到容器執行和監督,皆涵蓋在內。

在 Windows 上,我們採取了不同的方法。 當我們開始使用 Docker 來支援 Windows 容器時,我們會直接在 HCS (主機運算服務) 上進行建置。 此部落格文章完整介紹了我們建立 HCS 的原因,以及為何我們一開始就對容器採用此方法。

Windows 上的初始 Docker 引擎架構

現在,Docker 仍然可以直接呼叫 HCS。 不過,之後的容器管理工具會擴充為包含 Windows 容器,而 Windows 容器主機可以呼叫 containerd 和 runhcs,如同在 Linux 上呼叫 containerd 和 runc 一樣。

runhcs

runhcsrunc 的分支。 如同 runcrunhcs 是一種命令列用戶端,用於執行根據開放容器計畫 (OCI) 格式封裝的應用程式,並且遵循開放容器計畫規格的規範。

runc 與 runhcs 之間的功能差異包括:

  • runhcs 在 Windows 上執行。 其會與 HCS 通訊,以建立及管理容器。

  • runhcs 可以執行各種不同的容器類型。

    • Windows 和 Linux 的 Hyper-V 隔離
    • Windows 程序容器 (容器映像必須符合容器主機)

使用方式:

runhcs run [ -b bundle ] <container-id>

<container-id> 是您要啟動的容器執行個體名稱。 名稱在您容器主機上必須是唯一的。

套件組合目錄 (使用 -b bundle) 是選擇性項目。 如同 runc,容器是使用套件組合來進行設定。 容器套件組合是具有容器 OCI 規格檔案 "config.json" 的目錄。 「組合套件」的預設值為目前的目錄。

OCI 規格檔案 "config.json" 必須要有兩個欄位,才能正確執行:

  • 容器的臨時空間路徑
  • 容器層目錄的路徑

runhcs 中可用的容器命令包括:

  • 用來建立和執行容器的工具

    • run 建立及執行容器
    • create 建立容器
  • 管理容器中執行程序的工具:

    • start 在建立的容器中執行使用者定義程序
    • exec 在容器內執行新的程序
    • pause 暫停容器內的所有程序
    • resume 繼續先前已暫停的所有程序
    • ps 顯示在容器內執行的程序
  • 用來管理容器狀態的工具

    • state 輸出容器的狀態
    • kill 傳送指定訊號 (預設值:SIGTERM) 至容器的 init 程序
    • delete 針對經常與已卸離容器搭配使用的容器,刪除其所持有的任何資源

針對多容器考量的唯一命令是 list。 其會列出 runhcs 搭配指定根啟動的執行中或已暫停容器。

HCS

GitHub 上有兩個包裝函式可與 HCS 互動。 由於 HCS 是 C API,因此包裝函式可讓您輕鬆地從較高層級的語言呼叫 HCS。

  • hcsshim - 以 Go 撰寫的 HCSShim 是 runhcs 的基礎。 從 AppVeyor 取得最新版本,或自行建立。
  • dotnet-computevirtualization - dotnet-computevirtualization 是 HCS 的 C# 包裝函式。

如果您想要使用 HCS (直接使用或透過包裝函式),或想要為 HCS 建立相關 Rust/Haskell/InsertYourLanguage 包裝函式,請留下註解。

如需深入了解 HCS,請觀賞 John Stark 的 DockerCon 簡報

containerd/cri

重要

CRI 支援僅適用於 Server 2019/Windows 10 1809 和更新版本。

OCI 規格定義單一容器的同時,CRI (容器執行階段介面) 會將容器描述為共用沙箱環境中的工作負載 (稱為 Pod)。 Pod 可以包含一個或多個容器工作負載。 Pod 可讓容器協調器 (例如 Kubernetes 和 Service Fabric Mesh) 處理群組的工作負載,而這些工作負載應與一些共用資源 (例如記憶體和 vNET) 位於相同的主機上。

containerd/cri 會啟用 Pod 的下列相容性矩陣:

主機 OS 容器作業系統 隔離 Pod 支援?
  • Windows Server 2019/1809
  • Windows 10 1809
Linux hyperv 是 - 支援真正的多容器 Pod。
Windows Server 2019/1809 process* 或 hyperv 是 - 如果每個工作負載容器 OS 都符合公用程式 VM 作業系統,則支援真正的多容器 Pod。
Windows Server 2016,
Windows Server 1709,
Windows Server 1803
hyperv 部分—支援 Pod 沙箱,如果容器 OS 符合公用程式 VM OS,則可對每個公用程式 VM 支援單一程序隔離容器。

*Windows 10主機僅支援 Hyper-V 隔離

CRI 規格的連結:

以 Containerd 為基礎的容器環境

雖然 runHCS 和 containerd 都可以在任何 Windows 系統伺服器 2016 或更新版本上進行管理,但支援 Pod (容器群組) 卻需要在 Windows 中進行容器工具的重大變更。 CRI 支援適用於 Windows Server 2019/Windows 10 1809 及更新版本。