適用於：Windows Server 2025、Windows Server 2022、Windows Server 2019、Windows Server 2016
Windows 容器提供將傳統或舊版應用程式現代化的絕佳機制。 雖然您可能會聽到這種方法稱為「隨即轉移至容器」，但隨即轉移的隱喻源自將工作負載從實體移轉至虛擬機，並用於參考將工作負載移至雲端。 目前，此字詞會更適當地套用至移轉虛擬機（VM）。 但是容器不是 VM，並將它們視為 VM，可能會導致應用程式容器化的方式或是否可以容器化，或應該容器化的混淆。
本主題提供將傳統應用程式移至 Windows 容器的實際指引。 其旨在透過預先說明特殊考慮，協助您排定應容器化的應用程式優先順序。
介紹
什麼是 Windows 容器，以及它們不是
泛型詞彙容器是指虛擬化操作系統 （OS） 的技術。 此虛擬化提供伺服器/主機本身OS的隔離等級，進而為應用程式開發人員和作業小組提供更多靈活度。
Windows 容器是容器技術的特定實作。 它們提供與 Windows OS 隔離的虛擬化作業系統實例。 但容器和主機之間的完全相互依賴是不可能的：Windows 容器必須與 Windows OS 協調其資源和函式的需求。 為什麼這很重要？ 因為 Windows 容器不是整個虛擬化的伺服器，而且有些您可能想對應用程式執行的操作僅透過虛擬化的 OS 是無法完成的。
您可以在 容器與虛擬機中深入瞭解本主題。 但一些有助於您記住容器與 VM 區別的好點如下：
- 容器不是相當於傳統型應用程式虛擬化的解決方案。 它們僅支援不需要互動式會話的伺服器端應用程式。 因為它們在特製化容器映像上執行，因此僅支援不需要圖形化前端的應用程式。
- 容器本質上是暫時的。 這表示根據預設，沒有任何機制可儲存容器實例的狀態。 如果實例失敗，另一個實例將會取代它的位置。
容器技術從Linux開始，Docker會以標準的形式出現。 Microsoft 與 Docker 密切合作，以確保 Windows 上的容器功能能夠儘可能地相似。 Linux 和 Windows 之間的固有差異可能會以 Windows 容器的限制的方式呈現，而實際上它們只是 Linux 與 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管理，可讓您有極大的彈性，協助您走向微服務架構。 不過，這種彈性的一個取捨是，以容器和微服務為基礎的環境可以迅速擴展成為許多變動的部分，多到難以掌控。 幸運的是，管理負載平衡、高可用性、容器排程、資源管理等等，是容器協調器的角色。
協調器或許被誤稱為;他們更像是管弦樂隊的指揮者，因為他們協調多個容器的活動，以保持音樂播放。 從某種意義上說，它們會以類似於操作系統運作的方式處理容器的排程和資源配置。 因此，當您移至容器化應用程式時，您必須選擇支援 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 的應用程式無法容器化 as-is。
不過，理想的替代方案是遠端管理工具，例如 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 同時推出。 它會使用機制，其中每個裝置或使用者是由儲存在其資料庫中的物件表示。 此關聯性緊密結合，而且物件會保留在資料庫中，即使實際使用者或裝置不再運作也一樣。 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、Pearl、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分散式交易協調器 （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 容器。 下表列出支援的案例：
| 範圍 | 交易型？ | 佇列位置 | 驗證類型 | 傳送和接收？ |
|---|---|---|---|---|
| 私人 | 是的 | 相同容器 （單一容器） | 匿名 | 是的 |
| 私人 | 是的 | 永續性磁碟區 | 匿名 | 是的 |
| 私人 | 是的 | 域控制器 | 匿名 | 是的 |
| 私人 | 是的 | 單一主機 （兩個容器） | 匿名 | 是的 |
| 公共 | 不 | 兩部主機 | 匿名 | 是的 |
| 公共 | 是的 | 兩部主機 | 匿名 | 是的 |
關於這些支援案例的一些注意事項，這些案例已由Microsoft的內部開發小組驗證：
- 隔離模式：用於隔離的程式模式和 Hyper-V 模式都適用於上述案例。
- 最低 OS 和容器映射：建議搭配 MSMQ 使用的最小 OS 版本是 Windows Server 2019。
- 永續性磁碟區：上述案例在 Azure Kubernetes Service （AKS） 上執行 MSMQ 時，已使用 Azure 檔案來驗證永續性儲存。
當您將這些考慮與上表放在一起時，您可以看到唯一不支援的案例是使用 Active Directory 進行驗證的佇列。 目前不支援 gMSA（群組受管理的服務帳戶）與 MSMQ 整合，因為 MSMQ 與 Active Directory 相依性尚未就緒。
或者，使用 Azure 服務總線，而不是 MSMQ。 Azure 服務總線是完全受控的企業訊息代理程式，其中包含消息佇列和發佈-訂閱主題（在命名空間中）。 從 MSMQ 切換至 Azure 服務總線需要程式碼變更和應用程式重新架構，但可讓您靈活移至新式平臺。
MSDTC
Microsoft分散式交易協調器 （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 實例的一些層面：
- 本地數據的持久性儲存：應用程式進行檔案寫入或讀取的資料夾，是在 VM 中為 IIS 實例保留的一個絕佳範例。 使用容器時，您不希望任何數據直接寫入容器中。 容器會針對本地儲存使用「暫存空間」，當新的容器為相同應用程式啟動時，無法存取之前容器的該區域。 因此，針對 Web 應用程式需要存取的數據使用永續性記憶體，讓任何容器實例都可以存取該記憶體。
- 憑證：雖然您可以在容器實例上擁有本機憑證，但請避免這樣做，因為如果需要更新憑證，您必須重建容器映像。 或者，您可以使用容器協調器搭配入口控制。 入口控制器可以套用網路政策，並處理在其後方裝載的網站的憑證管理。 缺點是您將憑證生命週期管理與網站管理分離。
- 資料庫連接字串：針對傳統 IIS 部署，您可以傳遞資料庫連接字串作為應用程式部署的一部分。 雖然 Windows 容器可讓您遵循該模型，但建議您考慮將 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 基底容器映射只有一個字型可供使用，以減少影像大小。 如果您的應用程式需要不同的字型，您必須 安裝該字型 或使用伺服器或 Windows 映像，這些映像具有較大的 API 集，並包含所有預設的 Windows 字型。 從相容性的觀點來看，這幾乎允許任何應用程式（只要它們尊重容器的本質，例如 no-GUI）才能進行容器化。 在缺點中，它們的大小會大得多，這可能會影響效能。
驗證要容器化的應用程式是否可在 Windows 容器上運作時，Microsoft建議下列各項：
| 此架構 | 先使用此容器映像進行測試 | 如果第一個容器映像檔無法運作，則切換至此容器映像檔。 | 基底映像 |
|---|---|---|---|
| .NET Framework 2.X 和 3.X 版 | .NET Framework 4.x | .NET Framework 3.5 | Windows 伺服器核心 |
| .NET Framework 4.x 版本 | .NET Framework 4.x | 使用 Server 或 Windows 映像來建置您的 .NET Framework 容器映像 | Windows 伺服器核心 |
| .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 提供最安全的隔離。 在進程隔離中，容器會與主機共用其核心、文件系統和登錄，這可讓提升許可權的 （admin） 進程與容器進程和服務互動。 為您的應用程式選擇正確的隔離模式非常重要，以確保適當的安全性模型。
- Windows 更新。 由於服務堆疊不存在於 Windows 容器上，因此 Windows 容器不會收到更新，例如一般 Windows 實例。 相反地，您必須使用最新的可用基底容器映像來重建 Windows 容器。 客戶可以針對該目的利用 DevOps 管線。 Microsoft 每個月遵循 Patch Tuesday 的更新節奏，更新其所有官方映像的基底容器映像。
- 容器用戶帳戶。 根據預設，Windows 容器內的應用程式會以 ContainerAdmin 用戶帳戶下提升的許可權執行。 這有助於在容器映像內安裝和設定必要的元件。 不過，在執行不需要提高許可權的應用程式時，您應該考慮將使用者帳戶變更為 ContainerUser。 針對特定案例，您也可以建立具有適當許可權的新帳戶。
- 映像和運行時間掃描。 容器要求存放庫上的映像和容器實例是安全的。 Microsoft 建議您使用 Microsoft Defender for Containers 來進行映像掃描和運行時掃描。 適用於容器的 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 檔案遵循與上述相同的指導方針。
規劃提升與轉移過程
評估應用程式的容器化整備程度之後，請使用下列一般指引來規劃程式：
- 判斷您需要的 Windows 操作系統基底映射：Windows Server Core、Nano Server、Windows或 Server 映射。
- 判斷容器的隔離模式類型：選擇進程或 Hyper-V 隔離模式。 注意：目前，Azure Stack HCI 上的 AKS 和 AKS 僅支援進程隔離的容器。 在未來版本中，AKS 和在 Azure Stack HCI 上的 AKS 都將支援 Hyper-V 隔離的容器。 如需詳細資訊，請參閱 隔離模式。
- 為您的應用程式選擇正確的 Windows Server 版本，以用於應用程式相容性。 容器的最低 Windows Server 版本是 Windows Server 2016，但 Windows Server 2019 和 Windows Server 2022 是唯一在 AKS 和 Azure Stack HCI 上支援的容器主機操作系統。
- 請確定您公司的安全策略已適用於容器環境。 這包括適應容器特定需求，例如登錄掃描和威脅偵測。
- 請考慮負載平衡需求。 容器本身不會移動;您可以改用協調器來自動啟動或停止叢集節點上的容器，或使用自動水平調整來管理負載和可用性的變更。
- 請考慮統籌需求。 容器化後，您的應用程式可能需要透過 Azure Stack HCI 上的 Kubernetes、AKS 或 AKS 等工具提供自動化管理。 如需在工具之間選擇的完整討論和指南，請參閱 Windows 容器協調流程概觀。
- 容器化應用程式。
- 將應用程式推送至映像存放庫。 這可讓容器主機在任何環境中下載映像，包括開發、測試和生產環境。
Azure Migrate 可以提供探索、評估和將現有 Windows 應用程式移轉至 Azure Kubernetes Service 的引導式程式。 如需詳細資訊，請參閱 Azure Migrate 文件頁面。