Share via

使用 Windows 容器來「容器化」現有的應用程式

  • 發行項

適用于：Windows Server 2022、Windows Server 2019、Windows Server 2016

Windows 容器提供將傳統或繼承應用程式現代化的絕佳機制。 雖然您可能會聽到這種方法稱為「隨即轉移至容器」，但隨即轉移隱喻源自將工作負載從實體移轉至虛擬機器，而且在參考移至雲端時，最近使用工作負載， (私人或公用) 。 現在，此字詞更適合用來移轉虛擬機器 (VM) 。 但容器不是 VM，而且將其視為 VM，可能會導致應用程式如何容器化，或甚至可以或應該容器化。

本主題提供將傳統應用程式移至 Windows 容器的實用指引。 其目標是透過預先說明特殊考慮，協助您排定應容器化的應用程式優先順序。

簡介

什麼是 Windows 容器，以及它們不是

一般詞彙容器是指虛擬化作業系統 (作業系統) 的技術。 此虛擬化提供與伺服器/主機本身 OS 的隔離等級，進而為應用程式開發人員和作業小組提供更大的靈活度。

Windows 容器是容器技術的特定實作。 它們提供與 Windows OS 隔離的虛擬化作業系統實例。 但容器和主機之間的完全相依性是不可能的：Windows 容器必須與 Windows OS 協調其資源和功能的需求。 為什麼這很重要？ 因為 Windows 容器不是整個虛擬化伺服器，所以您可能想要對應用程式執行的一些動作，只能使用虛擬化作業系統來完成。

您可以在 容器與虛擬機器中深入瞭解本主題。 但幾個可協助您記住容器與 VM 區別的良好重點如下：

  • 容器不是相當於傳統型應用程式虛擬化的解決方案。 它們僅支援不需要互動式會話的伺服器端應用程式。 因為它們在特製化容器映射上執行，所以僅支援不需要圖形化前端的應用程式。
  • 容器本質上是暫時的。 這表示，根據預設，沒有任何機制可儲存容器實例的狀態。 如果實例失敗，另一個實例會取代它。

容器技術從 Linux 開始，Docker 會以標準的形式出現。 Microsoft 與 Docker 密切合作，以確保容器功能在 Windows 上盡可能與合理相同。 Linux 與 Windows 之間的固有差異，在事實上只是 Linux 與 Windows 差異時，可能會以看似 Windows 容器限制的方式呈現。 另一方面，Windows 容器會提供一些獨特的實作，例如 Hyper-V 隔離，稍後將涵蓋此實作。 本主題將協助您瞭解這些差異，以及如何因應這些差異。

使用容器的優點

就像在單一實體主機上執行多個 VM 一樣，您可以在單一實體或虛擬主機上執行多個容器。 但不同于 VM，您不需要管理容器的 OS，這可讓您彈性地專注于應用程式開發和基礎結構。 這也表示您可以隔離應用程式，使其不受 OS 支援的任何其他進程影響。

容器提供輕量型方法來建立和動態停止運作的應用程式所需的資源。 雖然可以在應用程式需求增加時建立和部署 VM，但使用容器來相應放大會更快。使用容器時，您也可以在發生當機或硬體中斷時快速重新開機。 容器可讓您將任何應用程式從開發環境帶至生產環境，而不需要變更程式碼，因為它們會「包含」應用程式相依性，以便跨環境運作。 由於 Microsoft 開發人員工具之間的 Docker 整合，因此能夠以最少的程式碼變更來容器化現有的應用程式，也是應用程式開發和維護的強大因素。

最後，使用容器最重要的優點之一就是您針對應用程式開發取得的靈活度，因為您可以在相同主機上執行的應用程式版本不同，且不會發生資源衝突。

您可以在 Microsoft .NET 檔頁面上找到使用現有應用程式容器的更完整優點清單。

隔離等級的重要概念

Windows 容器提供與 Windows OS 的隔離，當您正在建置、測試及將應用程式升階至生產環境時，隔離會比較好用。 但是，在考慮將應用程式容器化時，達到隔離的方式很重要。

Windows 容器提供兩種不同的執行時間隔離模式：進程和 Hyper-V。 這兩種模式下的容器會以相同方式建立和管理，而且運作方式相同。 那麼，有何差異，以及您應該注意的原因為何？ 在進程隔離中，多個容器會在單一主機上同時執行，並透過命名空間、資源控制和其他功能所提供的隔離。 進程隔離模式中的容器會與主機以及彼此共用相同的核心。 這大致上與 Linux 容器執行的方式相同。

在 Hyper-V 隔離中，多個容器也會在單一主機上同時執行，但容器會在高度優化的虛擬機器內執行，每個容器都會有效地取得自己的核心。 此虛擬機器的存在實際上是「公用程式」VM， 提供每個容器與容器主機之間的硬體層級隔離。

如此一來，Hyper-V 隔離模式幾乎就像是 VM 和容器的混合式，提供一層額外的安全性，如果您的應用程式需要多租使用者，這特別有用。 但使用 Hyper-V 隔離模式的可能取捨包括：

  • 容器的啟動時間較長，而且可能會對整體應用程式效能造成影響。
  • 並非所有工具都能以原生方式搭配 Hyper-V 隔離運作。
  • 目前Azure Kubernetes Service (AKS) 或 Azure Stack HCI 上的 AKS 都不支援 Hyper-V 隔離。

您可以在隔離模式主題中深入瞭解這兩種隔離模式的實 作方式。 當您第一次將應用程式容器化時，您必須選擇這兩種模式。 幸運的是，稍後從某個模式變更到另一個模式很容易，因為它不需要對應用程式或容器進行任何變更。 但請注意，當您將應用程式容器化時，在兩種模式之間選擇是您必須執行的第一件事之一。

容器協調流程

在單一或多部主機上執行多個容器的能力不需考慮 OS 管理，可讓您有絕佳的彈性，協助您移至微服務架構。 不過，對於該彈性有一項取捨，就是以容器和微服務為基礎的環境可以快速擷取到許多移動元件， 太多而無法追蹤。 幸運的是，管理負載平衡、高可用性、容器排程、資源管理等等，是容器協調器的角色。

協調器可能命名錯誤;它們更像協調協調多個容器活動的協調者，讓音樂保持播放。 事實上，它們會以類似 OS 運作的方式處理容器的排程和資源配置。 因此，當您移至容器化應用程式時，您必須選擇支援 Windows 容器的協調器。 其中一些最常見的是 Kubernetes 和 Docker Swarm。

無法移至 Windows 容器的專案

當您考慮應用程式是否可以容器化時，最容易從完全排除 Windows 容器作為選項的因素清單開始。

下表摘要說明無法移至 Windows 容器的應用程式類型，以及為什麼無法移動。 在資料表之後的子區段中，會更完整地說明原因。 瞭解這些限制的原因可讓您更清楚瞭解什麼是容器，包括它們與 VM 有何不同。 這可協助您更妥善地評估 Windows 容器的功能，這些容器可與您可以容器化的現有應用程式搭配使用。

注意：下列清單不是完整清單。 相反地，它是 Microsoft 嘗試容器化的應用程式編譯。

不支援的應用程式/功能 為何不支援 您可以解決此問題嗎？
需要桌面的應用程式 容器不支援圖形使用者介面 (GUI) 如果應用程式只需要安裝 GUI，將它變更為無訊息安裝可能是解決方案
使用遠端桌面通訊協定的應用程式 (RDP) RDP 適用于互動式會話，因此上述原則也適用于這裡 您可以使用WINDOWS ADMIN CENTER (WAC) 或遠端 PowerShell 作為遠端系統管理的替代方案
具狀態應用程式 容器是暫時的 是，某些應用程式可能需要最少的變更，因此它們不會將資料或狀態儲存在容器內
資料庫應用程式 容器是暫時的 是，某些應用程式可能需要最少的變更，因此它們不會將資料或狀態儲存在容器內
Active Directory Active Directory 的設計和用途會排除在容器中執行 不會。 不過，與 Active Directory 相依的應用程式可以使用群組受控服務帳戶 (gMSA) 。 以下是 gMSA 的詳細資訊
舊版 Windows Server 僅支援Windows Server 2016或更新版本 不會。 不過，應用程式相容性可能是選項 – 大部分的 Windows Server 2008/R2 和較舊的應用程式會在較新版本的 Windows Server 上執行
使用 .NET Framework 2.0 版或更新版本的應用程式 需要特定容器映射才能支援.NET Framework，而且僅支援較新的版本 完全不支援早于 2.0 的版本，但如需更新版本所需的容器映射，請參閱下文
使用其他協力廠商架構的應用程式 Microsoft 不會特別認證或支援在 Windows 容器上使用非 Microsoft 架構 請洽詢特定架構或應用程式的廠商，瞭解 Windows 容器的支援原則。 如需詳細資訊，請參閱下方

讓我們再考慮這些限制。

需要桌面的應用程式

容器適用于從其他應用程式叫用的暫時函式，包括具有使用者互動的函式。 但您無法將其用於具有 GUI 本身的應用程式。 即使應用程式本身沒有 GUI，但具有依賴 GUI 的安裝程式，也是如此。 一般而言，您可以使用 PowerShell 叫用 Windows Installer，但如果您的應用程式需要透過 GUI 進行安裝，該需求會將其排除為容器化的候選項目。

這不是實作 Windows 容器的方式問題，而是容器運作方式的基本概念。

如果應用程式需要 GUI API，則這是不同的問題。 即使這些 API 所提供的 GUI 不是，仍支援 API。 這在Nano Server x Server Core x Server - 哪一個基底映射適合您主題中更完整說明？

使用 RDP 的應用程式

由於遠端桌面通訊協定 (RDP) 的整個用途是建立互動式、視覺化會話，因此也適用剛才描述的 GUI 限制。 使用 RDP 的應用程式無法依原狀容器化。

不過，理想的替代方案是遠端系統管理工具，例如Windows Admin Center。 您可以使用Windows Admin Center來管理 Windows 容器主機，以及容器本身，而不需要 RDP。 您也可以開啟主機和/或容器的遠端 PowerShell 會話來管理它們。

具狀態應用程式

只有在您將所需的資料與一個會話隔離到下一個會話，並將它儲存在永續性儲存體中時，才可容器化需要保留狀態資料的應用程式。 這可能需要一些「重新架構」，這可能或可能不簡單，但繼續進行，將會消除容器化的此障礙。

狀態的範例是 Web 應用程式，會將影像或音樂檔案儲存到本機資料夾。 在傳統的 Windows 環境中，檔案會在寫入作業結束時儲存到磁片，因此，如果實例在此案例中 (VM) 失敗，您只要將它啟動，檔案仍會存在。 相較之下，如果執行寫入作業的容器實例失敗，新的容器實例就不會包含該檔案。 基於這個理由，您應該考慮使用持續性儲存體，讓所有容器實例都可以將狀態資料或檔案儲存到集中式持久位置。 這種類型的重新架構不需要您變更應用程式的程式碼，只是 Windows 實例所使用的儲存體類型。 如需詳細資訊，請參閱 儲存體上的Windows 容器檔案。

不過，這會帶入另一個相關主題...

資料庫應用程式

一般規則是資料庫應用程式不是容器化的絕佳候選項目。 雖然您可以在容器內執行資料庫，但基於兩個原因，將現有的資料庫容器化通常不是理想的。

首先，資料庫所需的效能可能需要主機可用的整個硬體資源，這會降低合併的優點。 其次，單一資料庫層的多個實例需要協調其寫入作業。 容器協調流程可以解決此問題，但對於現有的資料庫而言，協調流程可能會造成額外負荷。 大部分的資料庫，例如 Microsoft SQL Server，都有內建的負載平衡和高可用性機制。

Windows Server 上的基礎結構角色

Windows Server 基礎結構角色主要處理接近作業系統 (的功能，例如 AD、DHCP 和檔案伺服器) 。 因此，它們無法用於執行容器。 因此，需要這些角色的應用程式一律難以容器化。

有一些灰色區域。 例如，某些功能，例如 DNS 在 Windows 容器上運作，即使它們並非真的用於容器也一樣。 其他基礎結構角色只會從基底容器映射中移除，而且無法安裝，例如 Active Directory、DHCP 和其他角色。

Active Directory (AD)

Active Directory 在 Windows 2000 Server 上發行超過 20 年。 它會使用機制，其中每個裝置或使用者都以儲存在其資料庫中的物件表示。 此關聯性會緊密結合，而且物件會保留在資料庫中，即使實際的使用者或裝置不再運作也一樣。 Active Directory 的這種方法會直接與容器的暫時本質衝突，這預期會在關閉時短期或刪除。 維護與 Active Directory 的這個一對一關聯性不適合這些案例。

因此，Windows 容器無法加入網域。 因此，您無法在 Windows 容器上執行Active Directory 網域服務作為基礎結構角色。 您可以執行 PowerShell 模組，從遠端系統管理 Windows 容器內的網域控制站。

對於在 Active Directory 相依的 Windows 容器上執行的應用程式，您可以使用群組受控服務帳戶 (gMSA) ，進一步說明。

使用 .NET Framework 2.0 版或更新版本的應用程式

如果您的應用程式需要 .NET，則容器化的能力完全取決於它所使用的.NET Framework版本。 .NET Framework 2.0 之前的任何版本完全不受支援;較高版本需要使用特定映射，如稍後所述。

使用協力廠商 (非 Microsoft) 架構的應用程式

一般而言，Microsoft 無法認證協力廠商架構或應用程式，或支援它們在 Windows 容器上執行，或針對該情況在實體和虛擬機器上執行。 不過，Microsoft 會針對多個協力廠商架構和工具的可用性執行自己的內部測試，包括 Apache、Cassandra、Chocolatey、Datadog、Django、Flask、Git、Golang、JBoss、Jenkins、Rust、Nodejs、Parquet、Python、Ruby、Tomcat 等等。

對於任何協力廠商架構或軟體，請向提供它之廠商驗證其 Windows 容器上的支援性。

適用于容器化的理想候選項目

既然我們已考慮容器化應用程式的硬性限制，更容易看到哪些類型的應用程式更輕鬆適用于 Windows 容器。 適用于 Windows 容器的理想候選項目，以及容器化它們的任何特殊考慮，如下表所示。

應用程式類型 為什麼這些是良好的候選項目 特殊考量
主控台應用程式 沒有 GUI 限制，主控台應用程式是容器的理想候選項目。 視應用程式的需求而定，請使用適當的基底容器映射。
Windows 服務 因為這些是背景進程，不需要任何直接的使用者互動 視應用程式的需求而定，請使用適當的基底容器映射。 您必須建立前景進程，讓任何容器化背景進程保持執行。 請參閱下面的背景服務一節。
Windows Communication Foundation (WCF) 服務 因為它們是也可以在背景中執行的服務導向應用程式 視應用程式的需求而定，請使用適當的基底容器映射。 您可能需要建立前景進程，讓任何容器化背景進程保持執行。 請參閱下面的背景服務一節。
Web 應用程式 Web 應用程式基本上是接聽特定埠的背景服務，因此是容器化的絕佳候選項目，因為它們可以利用容器所提供的延展性 視應用程式的需求而定，請使用適當的基底容器映射。

注意：即使是容器化的理想候選項目，也可能依賴 Windows 容器中需要以不同方式處理的核心 Windows 功能和元件。 下一節會進一步詳細說明這類實際考慮，將更妥善地為您準備利用 Windows 容器的功能。

可容器化之應用程式的實用考慮

應用程式修復專案通常會考慮特定應用程式是否可以透過應用程式商務功能的觀點來容器化。 但商務功能不是判斷技術上是否可行的因素。 應用程式架構很重要，也就是其依賴的技術元件。 因此，「我可以將 HR 應用程式容器化嗎？」這類問題沒有簡單的答案，因為它不是應用程式執行的動作，就是 (，以及它使用哪些 Windows 元件/服務) 來產生差異。

這是重要的區別，因為如果您的應用程式不是以微服務架構來建置，則可能難以容器化。 當您繼續進行容器化時，某些功能可能需要特殊處理。 有些可能是因為應用程式使用 Windows 容器中不支援的核心 Windows 元件和架構。 其他專案，例如事件記錄和監視，是因為 Linux 和 Windows 之間的固有差異只會在您容器化應用程式時才會變得明顯。 其他像是已排程的工作和背景服務，也必須從容器不是 VM 但暫時性的觀點瞭解，因此需要特殊處理。

下表提供在考慮容器化時需要特殊考慮之應用程式的元件/功能快速摘要。 後續的子區段提供您更多詳細資料，包括說明處理每個案例技巧的範例。 雖然下列清單涵蓋 Windows 容器上支援的案例，但這些案例仍然需要遵守上一章的指引。 例如，雖然支援背景服務，但不支援在 .NET Framework 1.1 上執行背景服務。

需要特殊處理的 Windows 功能/元件 原因
Microsoft 訊息中心佇列 (MSMQ) MSMQ 早于容器之前，而不是訊息佇列的所有部署模型都與容器架構相容。
Microsoft Distributed Transaction Coordinator (MSDTC) MSDTC 與容器之間的名稱解析需要特殊考慮。
IIS IIS 與在 VM 中相同，但在容器環境中執行 IIS 時有重要的考慮，例如憑證管理、資料庫連接字串等等。
排定的工作 Windows 容器可以執行排程的工作，就像任何 Windows 實例一樣。 不過，您可能需要執行前景工作，才能讓容器實例保持執行。 視應用程式而定，您可能想要考慮事件驅動方法。
背景服務 由於容器以暫時進程的形式執行，因此您需要額外的處理，才能讓容器保持執行
先前.NET Framework和 .NET (.Net Core) 請務必使用正確的映射來確保相容性，如以下小節所述

其他支援元件

需要特殊處理的元件 原因 替代方法
事件記錄/監視 因為 Windows 寫入事件和記錄的方式原本與 Linux stdout 不同 使用新的記錄監視器工具來正規化資料，並從 Linux 和 Windows 合併
Windows 容器安全性 雖然許多安全性做法都相同，但容器需要額外的安全性措施 採用用途建置的登錄和映射掃描工具 – 稍後更詳細資料
Windows 容器的備份 容器不應該有資料或狀態 備份容器所使用的任何持續性儲存體，以及容器映射

Windows 元件/功能

現在讓我們深入探討可容器化的應用程式和元件詳細資料，但確實需要額外的處理。

MSMQ

如果您的應用程式相依于 MSMQ，您是否可以將其容器化，取決於其 MSMQ 部署案例。 MSMQ 包含多個部署選項。 私用與公用佇列、交易式或驗證類型的因素，形成 MSMQ 最初設計來支援的案例矩陣。 並非所有專案都可以輕鬆地移至 Windows 容器。 下表列出支援的案例：

範圍 事務？ 佇列位置 驗證類型 傳送和接收？
私人 是 單一容器 (單一容器) 匿名 Yes
私人 是 永久性磁碟區 匿名 Yes
私人 是 網域控制站 匿名 Yes
私人 是 單一主機 (兩個容器) 匿名 Yes
公開 No 兩部主機 匿名 Yes
公開 Yes 兩部主機 匿名 Yes

這些受支援案例的一些注意事項，這些案例已由 Microsoft 的內部開發小組驗證：

  • 隔離模式：用於隔離的進程模式和 Hyper-V 模式都適用于上述案例。
  • 最低 OS 和容器映射：建議搭配 MSMQ 使用的最小 OS 版本是 Windows Server 2019。
  • 永續性磁片區：上述案例是在Azure Kubernetes Service (AKS) 使用 Azure 檔案進行永續性儲存體時，驗證在 MSMQ 上執行。

當您將這些考慮與上表放在一起時，您可以看到唯一不支援的案例是針對需要 Active Directory 驗證的佇列。 目前不支援 gMSA (群組受控服務帳戶與 MSMQ) 整合，因為 MSMQ 與 Active Directory 相依性尚未就緒。

或者，請使用 Azure 服務匯流排，而不是 MSMQ。 Azure 服務匯流排是完全受控的企業訊息代理程式，具有訊息佇列和發佈/訂閱主題 (在命名空間中)。 從 MSMQ 切換至Azure 服務匯流排需要程式碼變更和應用程式重新架構，但可讓您靈活移至新式平臺。

MSDTC

Microsoft Distributed Transaction Coordinator (MSDTC) 在大型企業的 Windows 繼承應用程式中大量使用。 MSDTC 可以安裝在 Windows 容器上，但在某些情況下無法運作，而且無法在 Windows 容器上重現。

  • 建立容器時，請務必將 --name 參數傳入 docker run 命令。 這個名稱參數可讓容器透過 Docker 網路進行通訊。 如果使用 gMSA，則名稱必須符合必須符合 gMSA 帳戶名稱的主機名稱。
    • 以下是搭配 gMSA 執行命令的範例：
docker run -d --security-opt "credentialspec=file://contoso_webapp01.json" --hostname webapp01 -- name webapp01 mcr.microsoft.com/windows/servercore:ltsc2022
  • 容器必須能夠使用 NETBIOS 名稱彼此解析。 如果這種解決方式有任何困難，就是將容器的名稱和 IP 新增至彼此的主機檔案。
  • 這兩個容器上的 msdtc uuid 必須是唯一的。 您可以在容器上的 PowerShell 中執行 「Get-Dtc」 來找到 uuid。 如果它們不是唯一的，解決方式之一是在其中一個容器上卸載並重新安裝 msdtc。 您可以使用這些 powershelll 命令 – 「uninstall-dtc」、「install-dtc」。
  • 目前 Azure Kubernetes Services 不支援 MSDTC。 如果您有在 AKS 上執行 MSDTC 的特定需求，請在 GitHub 上的 Windows 容器存放庫 上開啟 am 問題，讓 Windows 容器小組知道。

IIS 在容器與 VM 中的運作方式

IIS 在 Windows 容器上的運作方式與 VM 中的相同。 不過，在容器環境上執行時，應該考慮執行 IIS 實例的一些層面：

  • 本機資料的永續性儲存體：應用程式寫入/讀取檔案至/來源的資料夾是您在 IIS 實例的 VM 中保留的專案的絕佳範例。 使用容器時，您不希望任何資料直接寫入容器中。 容器會針對本機儲存體使用「暫存空間」，而當新容器針對相同應用程式啟動時，就無法從先前的容器存取該區域。 基於這個理由，您應該針對 Web 應用程式需要存取的資料使用永續性儲存體，因此任何容器實例都可以存取該儲存體。
  • 憑證：雖然您可以在容器實例上擁有本機憑證，但應該避免這麼做，因為如果需要更新憑證，您必須重建容器映射。 或者，您可以使用容器協調器搭配輸入控制項。 輸入控制器可以套用網路原則，也可以處理裝載于其後方網站的憑證管理。 缺點是您將憑證生命週期管理與網站管理分離。
  • 資料庫連接字串：針對傳統 IIS 部署，您可以將 DB 連接字串當做應用程式部署的一部分傳遞。 雖然 Windows 容器可讓您遵循該模型，但建議您考慮將 DB 連接字串從容器分離至容器協調器所提供的集中式設定，讓應用程式可以從中讀取。 這可讓您從應用程式獨立管理及更新 DB 連接字串。 如果 DB 變更為隨即轉移至雲端的情況 (，例如，) 您可以輕鬆地變更連接字串，而不需要重建容器映射。 這種方法也可讓您 (保留秘密，例如連線到秘密存放區上 DB) 的使用者名稱和密碼。
  • 水準自動調整：當負載增加時，計算系統在嘗試處理同時要求時，通常會降低察覺到的效能。 通常有兩種方式可避免效能影響–垂直或水準縮放。 垂直縮放會增加現有計算實例可用的資源， (更多 CPU、記憶體等) 。 水準調整會增加支援要求 (更多實體主機、VM 或容器) 的實例數目。 針對 IIS 之類的 Web 層，水準調整通常比垂直更有效率，但內部部署環境可能會遇到資源限制和負載平衡問題。 使用雲端環境時，水準調整會比較容易，因為資源可供使用， (額外的成本) ，而雲端提供者通常會以水準規模來設計其負載平衡機制。 Windows 容器可以利用 IIS 的水準調整，但容器的暫時層面扮演著重要的角色。 您的容器必須具有相同的設定，而且不會儲存任何狀態或資料，以允許相應增加或減少支援 Web 應用程式的實例數目。

排定的工作

排程的工作可用來在 Windows 環境中隨時呼叫程式、服務或腳本。 傳統上，您隨時都會啟動並執行 Windows 實例，並在符合觸發程式時執行工作。 這在 Windows 容器中是可行的，除了您需要透過 Azure PowerShell 設定和管理排程工作之外，它們的運作方式完全相同。

不過，使用微服務方法時，您有幾個選項可避免讓容器繼續執行以等候觸發程式：

  • 使用事件驅動 PaaS (平臺即服務) ，例如 Azure 函式來儲存您的程式碼，並定義該應用程式的觸發程式。 Azure Functions甚至支援符合觸發程式時執行的 Windows 容器映射。
  • 搭配容器協調器使用 Windows 容器。 只有在符合觸發程式並從應用程式的其他部分呼叫時，容器才能執行。 在此情況下，容器協調器會處理應用程式的排程和觸發程式。
  • 最後，讓 Windows 容器保持執行，以執行排程的工作。 您需要前景服務 (，例如服務監視器) ，才能讓容器保持執行。

背景服務

雖然容器通常適用于暫時進程，但您可以容器化背景長時間執行的應用程式，前提是您建立前景進程來啟動它，並讓它保持執行。

其中一個絕佳的範例是 ServiceMonitor，這是一個 Windows 可執行檔，其設計目的是在容器中執行 IIS 時做為進入點進程。 雖然它是針對 IIS 所建置，但 ServiceMonitor 工具提供模型，也可用來監視其他服務，但有一些限制。

如需 ServiceMonitor 的詳細資訊，請參閱 Github 上的檔。

.NET Framework 和 .NET

Windows 容器支援先前.NET Framework和 .NET (.NET Core) 。 .NET 小組會在 Windows 基底容器映射之上，為這兩個架構建立自己的官方映射。 選擇適當的映射是確保相容性的關鍵。 .NET 小組提供 Server Core 基底容器映射之上的 .Net Framework 映射，以及 Server Core 和 Nano Server 基底容器映射之上的 .NET 映射。 Server Core 具有比 Nano Server 更大的 API 集合，其允許更高的相容性，但也允許較大的映射大小。 Nano Server 具有大幅減少的 API 介面，但影像大小較小。

在某些情況下，您可能需要在 Windows 或伺服器基底容器映射上建置自己的.NET Framework或 .NET 映射。 如果您的應用程式不僅具有架構相依性，還具有 OS 相依性，則可能是必要的。 您可以使用特定的基底容器映射來測試應用程式，以偵測任何這類相依性。

例如，Server Core 和 Nano Server 基底容器映射只有一個字型可供使用，以減少影像大小。 如果您的應用程式需要不同的字型，您必須 安裝該字 型，或使用已設定較大的 API 且包含所有預設 Windows 字型的伺服器或 Windows 映像。 從相容性的觀點來看，這可讓幾乎任何應用程式 (，只要它們遵守容器的本質，例如無 GUI) 才會容器化。 在缺點中，其大小將會大很多，這可能會影響效能。

驗證要容器化的應用程式是否可在 Windows 容器上運作時，Microsoft 建議下列各項：

針對此架構 先使用此容器映射進行測試 如果第一個容器映射無法運作，請後援至此容器映射 Base image
.NET Framework 2.X 和 3.X 版 .NET Framework 4.x .NET Framework 3.5 Windows Server Core
.NET Framework 4.x 版 .NET Framework 4.x 使用伺服器或 Windows 映像建置您的.NET Framework容器映射 Windows Server Core
.NET 6 或 7 分別為 .NET 6 或 7 使用 Windows 或 Server 基底映射建置 .NET 容器映射 Windows Nano Server 或 Server Core

其他支援元件

下列元件和主題會提供其他指引，以取得與一起或更清楚瞭解 Windows 容器的專案。

事件記錄

Windows 和 Linux 使用不同的方法來儲存和呈現記錄檔和事件給其使用者。 傳統上，Windows 已使用 EVT 格式，以結構化方式檢視事件檢視器。 相反地，Linux 提供標準輸出 (stdout) 的簡化方法，例如 Docker 依賴的其他工具。

Docker 一律具有從 Linux 容器擷取記錄的機制。 使用 「docker logs」 命令搭配預設 stdout 組態，Docker 會將應用程式記錄帶入容器中，而不需以互動方式開啟容器。 不過，在開機記錄監視器工具之前，相同的技術無法在 Windows 上運作。

記錄監視器工具會以 stdout 格式呈現 Windows 記錄，讓 Docker 等其他工具可以收集顯示它所需的資訊。 使用記錄監視器的其他優點包括：

  • 能夠篩選您想要在 stdout 上公開的事件/記錄類型。 例如，只有在對「資訊」事件不感興趣時，您才能篩選應用程式記錄檔中的「錯誤」和「警告」訊息。
  • 從事件記錄檔、自訂記錄檔或 Windows 事件追蹤 (ETW) 中選擇的能力。 如果您的應用程式在不同的記錄來源上寫入，這特別有用。 例如，IIS 記錄位於 「C：\inetpub」 資料夾。
  • 記錄監視器讓 Windows 容器的行為非常類似 Linux 容器，因此尋找 stdout 並與容器執行時間函式互動的工具會如預期般運作。 例如，如果您從 Docker 移至 ContainerD 作為容器執行時間，則仍應該透過 (從容器主機看見記錄，例如) 「crictl logs」。

您可以在 此部落格文章中深入瞭解記錄監視器工具。

Windows 容器安全性

Windows 容器是以與在實體或虛擬機器上執行的 Windows 實例相同的基底建置。 瞭解容器實作方式的詳細資料，特別是其共用核心本質，可協助您保護容器化應用程式：

  • 共用元件。 Windows 容器會共用部分主機元件以供安全性之用。 這包括 Windows 防火牆、Windows Defender (防毒軟體) 和其他資源存取限制。 您不需要直接在容器上設定這些元件，因為容器主機會根據您的容器工作負載進行必要的調整。 例如，如果容器提出 Web 要求，容器主機會透過其防火牆轉送必要的流量，讓容器可以存取 Web。
  • 隔離模式。 如前所述，Windows 容器可以在處理或 Hyper-V 隔離模式中部署，而 Hyper-V 可提供最安全的隔離。 在進程隔離中，容器會與其主機共用其核心、檔案系統和登錄，讓提升許可權的 (系統管理員) 程式與容器進程和服務互動。 為您的應用程式選擇正確的隔離模式很重要，以確保適當的安全性模型。
  • Windows 更新。 由於服務堆疊不存在於 Windows 容器上，所以 Windows 容器不會收到更新，例如一般 Windows 實例。 相反地，您需要使用最新的可用基底容器映射來重建 Windows 容器。 客戶可以針對該目的利用 DevOps 管線。 Microsoft 會在每個月更新其所有官方映射的基底容器映射，並遵循修補程式星期二的步調。
  • 容器使用者帳戶。 根據預設，Windows 容器內的應用程式會在 ContainerAdmin 使用者帳戶下以提高的許可權執行。 這有助於在容器映射內安裝和設定必要的元件。 不過，在執行不需要提高許可權的應用程式時，您應該考慮將使用者帳戶變更為 ContainerUser。 針對特定案例，您也可以建立具有適當許可權的新帳戶。
  • 映射和執行時間掃描。 容器需要存放庫和容器實例上的映射安全。 Microsoft 建議您針對容器使用Microsoft Defender進行映射掃描和執行時間掃描。 適用于容器的 Defender 支援 Windows 容器，以使用登錄掃描進行弱點評估，並使用威脅偵測進行執行時間保護。

如需上述主題的詳細資訊，請參閱 Windows 容器 檔頁面。

Windows 容器的備份

使用容器時，您需要以不同的方式考慮備份。 如先前所述，容器不應該用來儲存狀態或資料，因為其暫時本質。 如果您將狀態和資料與容器實例分開，您的備份考慮不在容器實例的執行時間之外，可以使用所有必要永續性儲存體的新實例來取代。

不過，您仍負責備份的元件;包括應用程式、容器映射，以及建置容器映射的 dockerfile。 這些作業大部分都是由您執行生產與開發工作負載的平臺所處理。 採用 DevOps 方法時，請考慮最常見的案例：

  • 應用程式：您的應用程式可能位於 GitHub 或 Azure DevOps 等來源存放庫中。 這些存放庫提供版本控制，可讓您還原回特定版本的應用程式。 如果您擁有來源存放庫，請務必遵循其備份和管理建議。
  • 容器映射：針對生產環境，您的容器映射應該位於集中式映射存放庫中，例如Azure Container Registry (ACR) 。 您可以將容器映射推送至 ACR，使其可供其他主機提取。 ACR 會處理容器映射的可用性，並做為備份選項，不過請記住，雖然 ACR 處理映射的可用性，但不會防止映射遭到刪除或覆寫。 針對任何其他本機或內部部署映射存放庫，請遵循廠商針對備份現有登錄的建議。
  • Dockerfile：Dockerfiles 會建置新的容器映射，而且通常會與應用程式來源一起儲存。 由於 dockerfile 可能尚未使用應用程式建立，特別是當它是容器化的現有應用程式時，您必須負責確保 dockerfile 儲存在安全且備份的位置。 您也應該確定應用程式在容器中運作所需的任何其他資產都會進行備份;例如：Kubernetes、Docker Swarm 和 Azure ARM 範本的 YAML 和 JSON 檔案遵循上述相同的指導方針。

規劃隨即轉移程式

評估應用程式的容器化整備程度之後，請使用下列一般指引來規劃程式：

  1. 判斷您需要的 Windows 作業系統基底映射： Windows Server Core、 Nano Server、 Windows或 Server 映射。
  2. 判斷容器的隔離模式類型：選擇進程或 Hyper-V 隔離模式。 注意：Azure Stack HCI 上的 AKS 和 AKS 目前僅支援進程隔離的容器。 在未來的版本中，Azure Stack HCI 上的 AKS 和 AKS 也會支援 Hyper-V 隔離的容器。 如需詳細資訊，請參閱隔離模式。
  3. 為應用程式選擇正確的 Windows Server 版本，以進行應用程式相容性。 容器的最低 Windows Server 版本是Windows Server 2016，但 Windows Server 2019 和 Windows Server 2022 是唯一在 Azure Stack HCI 上的 AKS 和 AKS 上支援的容器主機作業系統。
  4. 請確定您公司的安全性原則已適用于容器環境。 這包括適應容器特定需求，例如登錄掃描和威脅偵測。
  5. 請考慮負載平衡需求。 容器本身不會移動;您可以改用協調器來自動啟動或停止叢集節點上的容器，或使用自動水準調整來管理負載和可用性的變更。
  6. 請考慮協調流程需求。 一旦容器化，您的應用程式可能需要 Azure Stack HCI 上的 Kubernetes、AKS 或 AKS 等工具提供的自動化管理。 如需在工具之間選擇的完整討論和指南，請參閱 Windows 容器協調流程概觀 。
  7. 將應用程式容器化。
  8. 將應用程式推送至映射存放庫。 這可讓容器主機在任何環境中下載映射，包括開發、測試和生產環境。

Azure Migrate 可以提供探索、評估和移轉現有 Windows 應用程式的引導式程式，以Azure Kubernetes Service。 如需詳細資訊，請參閱 Azure Migrate 檔頁面。