使用 PowerShell DSC 和 Ansible 在 Windows 中實現進階自動化

資訊科技數位 » recursos » 使用 PowerShell DSC 和 Ansible 在 Windows 中實現進階自動化

如果您從事 Windows 基礎架構相關工作，並且對PowerShell、DSC、Ansible 和自動化等術語耳熟能詳，那麼您可能已經知道，有效地結合使用這些技術可以徹底改變您管理伺服器的方式。從在 Windows 精靈中手動點擊操作，到完全聲明式且可重複的配置，這將使您擺脫疲於奔命的救火工作，擁有一個完全可控的環境。

本文將深入探討如何 PowerShell 的期望狀態配置 (DSC) 和 Ansible 完美契合 為了大規模管理 Windows（和 Linux），WinRM、Azure Automation、Terraform 或 cloud-init 等技術扮演著怎樣的角色？如何借助該模組從 Ansible 利用現有的 DSC 資源？ win_dsc您將看到實際範例、真實用例以及決定何時使用原生 DSC、Ansible 模組或其他自動化方法的標準。

概述：使用 PowerShell、DSC 和 Ansible 實現 Windows 自動化

PowerShell 和 Ansible 的目標相同：以可重複的方式自動化系統的設定和管理。差別在於它們的方法。 DSC 是整合到 PowerShell 中的設定管理平台，主要面向 Windows 系統（儘管它也可以透過 OMI 與 Linux 系統配合使用），而 Ansible 則是一個多用途、跨平台的自動化引擎，旨在從單一入口點協調混合異質基礎架構。

透過Red Hat Ansible 自動化平台，您無需安裝額外的代理程式即可實現 Windows 伺服器的自動化，它利用WinRM 或 OpenSSH作為連接通道，並可利用 DSC 資源、Ansible 模組和 PowerShell 腳本。所有這些都透過YAML playbook進行組織，您可以在 playbook 中定義每個主機（包括 Windows 和 Linux 主機）應達到的狀態。

另一方面，PowerShell 的所需狀態配置提供了數百個專門的資源，用於配置幾乎所有 Windows 元件：服務、系統功能、IIS、SQL Server、Active Directory、登錄、檔案等。這些資源封裝了檢查和應用所需狀態的邏輯，因此您只需聲明「您希望機器處於什麼狀態」。

關鍵在於，透過 Ansible，您可以直接透過模組使用這些 DSC 資源。 ansible.windows.win_dsc將 Ansible 的編排能力與 DSC 提供的 Windows 特定配置深度結合。這樣您就可以實現 兩全其美的 無需重複勞動。

WinRM 和 Windows 的遠端存取（用於 Ansible）

為了讓 Ansible 能夠管理 Windows 伺服器，必須了解WinRM（Windows 遠端管理）的工作原理。 WinRM 是微軟基於 HTTP/HTTPS 的內建遠端管理技術，也是 Ansible 在 Windows 機器上執行任務的標準通道。

第一步是在目標主機和執行 Ansible 的控制節點上正確設定 WinRM。這涉及調整身份驗證、加密、權限，通常還需要處理非互動式登入等功能，即在沒有活動用戶會話的情況下發出命令。這種非互動式會話環境會使諸如Windows 更新或雙向身分驗證等任務變得複雜，因為在這些場景中，您需要存取第二個遠端資源（例如，另一台伺服器上的共用）。

使用 Red Hat Ansible 自動化平台的優點在於，它允許您集中、安全地編寫憑證和驗證機制，從而簡化這些複雜情況的處理。此外，該平台還可以使用OpenSSH 存取 Windows Server，這在現代 Windows 版本中越來越普遍。

實際上，結合 WinRM、Ansible 的憑證管理和 DSC 功能，您可以建立強大的自動化流程，即使在安全限制較高的環境中也能無人值守。

PowerShell DSC：聲明式設定平台

PowerShell Desired State Configuration (DSC) 是一個整合到 Windows 中的宣告式設定管理平台。透過 DSC，您可以透過程式碼定義電腦的設定方式：安裝哪些角色和功能、啟動哪些服務、設定哪些登錄機碼參數、建立哪些檔案或目錄等等。

DSC配置描述了一組節點的期望狀態。每台受管電腦都執行一個本機設定管理員 (LCM)，該管理器負責讀取這些配置、檢查實際狀態並套用必要的變更。此外，您還可以設定一個拉取伺服器，該伺服器集中管理配置，節點透過該伺服器更新配置並報告合規性。

DSC 不僅限於 Windows 系統：透過開放式管理基礎架構 ( OMI ) 伺服器，它也可以與Linux 系統搭配使用。然而，它真正的優勢在於 Windows 環境，而社群已經開發了大量的專門資源，用於配置 IIS、SQL Server 或 Active Directory等各種任務。

DSC 的一大優點在於它專注於結果而非步驟。您只需聲明狀態（例如，「此功能必須存在，此服務必須已啟動，此暫存器值必須已配置」），引擎便會負責實現該狀態，並在出現任何偏差時進行檢查和修正。

Ansible 如何與 DSC 整合：win_dsc 模組和編排

理論上，你可以單獨使用 DSC，但實際上，將其與Ansible 結合作為編排層會更有效。 Ansible 負責管理清單、有序執行任務、系統間協調以及與 CI/CD 管線的集成，而 DSC 則提供操作 Windows 內部機制所需的特定資源。

模塊 ansible.windows.win_dsc 它是連接兩個世界的橋樑。該模組調用了一個 DSC資源類 在目標 Windows 主機上。在 playbook 中，您只需定義：

• 資源名稱：您要使用的 DSC 資源的名稱（例如， File, WindowsFeature, Service, Registry, xWebsite等）。
• 其餘參數直接對應 DSC資源的屬性 （例如， DestinationPath, Ensure, Name, State等）。

當 Ansible 執行任務時，它會將這些參數轉換為臨時的 DSC 配置，將其套用到主機，並收集結果（包括是否發生了任何變更）。這樣，您就可以重複使用整個 DSC 資源目錄，而無需為每種情況編寫特定的 Ansible 模組。

底層執行流程遵循一致的模式：Ansible 透過 WinRM 發送任務，Windows 系統根據參數產生 DSC 配置，DSC 引擎首先調用 Test-TargetResource 檢查目前狀態，如果偵測到差異，則執行 Set-TargetResource 應用這些變更。 Ansible 會收到一份報告，其中指示是否有任何內容被修改以及任何相關的偵錯訊息。

當你們結合使用時，這種耦合作用尤其強大。 適用於 Windows 的 Ansible 原生模組 （如 win_file, win_service, win_regedit, win_psmodule等等）在 DSC 提供更精細的選擇或更強大的功能覆蓋範圍的領域，可以使用 DSC 資源。

DSC 屬性的類型以及如何在 Ansible 中對應它們

每個 DSC 資源都定義了一組屬性。 明確定義的類型 （字串、布林值、陣列、複雜的 PowerShell 類型等）。在使用 Ansible 時，您必須將這些屬性轉換為 YAML 語法 保持正確的類型。該模組 win_dsc 它能自動完成許多轉換工作，但了解一些關鍵案例還是很必要的。

對於像這樣的簡單類型 o 映射關係很簡單：YAML 風格的引號字串和小寫布林值（true, false），避免寫作 $true o $false 就像在 PowerShell 中一樣。對於類型的屬性 通常的做法是使用 ISO 8601格式 （例如， "2019-02-22T13:57:31Z"）並確保該值被序列化為字串，方法是用引號將其括起來。

類型屬性 它們是一種特例。由於這種類型無法直接序列化為 JSON，Ansible 使用了一個約定：定義兩個參數，並用後綴分隔。 _username y _password （例如， Credential_username y Credential_password該模組會產生物件。 PSCredential 在遠端主機上，基於這兩個值。

對於類型 這些表示基於自訂資源類別的字典；在 YAML 中，它們以鍵值映射的形式表示。您應該查看資源文件（通常在文件中）。 <nombre_recurso>.schema.mof）了解哪些鍵是允許的以及每個鍵的類型。實際上，它們被定義為： 嵌套字典 在模組內 win_dsc.

最後，類型屬性 以及數組 (], ]等等）以字典或 YAML 列表的形式表示。對於數組，建議使用 正版 YAML 列表 而不是用逗號分隔值的字串，因為這樣可以避免手動解析，並降低出現細微錯誤的機率。

使用 Ansible 中的 DSC 的實際範例

一旦你掌握了模組的基本結構 win_dsc你可以結合各種資源來建造 非常全面的配置手冊以下是一些適合使用DSC的常見場景：

• 檔案和目錄管理 利用資源 File建立資料夾結構，部署包含特定內容的設定文件，確保某些元素存在或已刪除。
• 安裝 Windows 角色和功能 同 WindowsFeature：IIS、.NET Framework、Telnet客戶端、管理工具等。
• 服務控制 利用資源 Service狀態（已啟動/已停止）、啟動類型（自動、手動）、服務帳戶等。
• 註冊表設定 同 Registry安全值、等待時間、協定參數、系統加固。
• 高級 IIS 設定 使用以下模組 xWebAdministration 和資源 xWebsite, xWebAppPool等等。

在所有這些情況下，Ansible 只是簡單地描述了 DSC 資源的參數，而 DSC引擎負責檢查和應用 狀態。此外，從 Ansible 2.8 開始，該模組 win_dsc 它會自動根據資源定義驗證參數：如果您使用錯誤的屬性名稱、將必填欄位留空或傳遞超出範圍的值，任務將失敗並顯示明確的錯誤。

如果你執行 Ansible 時 冗長繁複（例如， -vvv)輸出結果將包含詳細信息 invocation.module_args 有關已使用的選項和可用的選項的信息，對於偵錯和發現可以在每個資源中配置哪些欄位都非常有用。

另請注意，您可以使用該參數。 PsDscRunAsCredential 這樣一來，DSC 資源就可以以不同於系統的使用者身分運作。這對於存取註冊註冊表單元非常有用。 HKEY_CURRENT_USER Ansible 連接到的用戶，或在需要特定安全上下文的場景中。

自訂 DSC 資源和 PowerShell 函式庫

Windows 整合的 DSC 資源可以滿足許多需求，但真正的強大之處在於使用PowerShell Gallery 中發布的資源或第三方軟體包。這些模組幾乎涵蓋了所有方面：Active Directory、SQL Server、進階 IIS、安全性原則等等。

您可以使用 cmdlet 來發現可用資源 Find-DscResource 或直接瀏覽 PowerShell 函式庫。一旦確定了您感興趣的模組（例如， xWebAdministration o SqlServerDsc），您可以透過以下幾種方式將其安裝到主機上：

• 手動安裝 Install-Module 從目標伺服器上的 PowerShell 執行。
• 使用 Ansible 模組 win_psmodule 從 PowerShell Gallery 自動安裝。
• 提前下載並手動抄寫。 對於無法存取互聯網的伺服器，將模組保存在包含在以下目錄中： PSModulePath （例如， C:\Program Files\WindowsPowerShell\Modules).

在網路連線不良的環境中工作時，常見的策略是使用一台可以存取網路的伺服器。 儲存模組 Save-Module 在本機路徑中，然後將該目錄複製到生產機器。之後，進行配置。 PSModulePath 也可以使用 Ansible 進行調整，例如使用以下模組： win_path這樣 PowerShell 就可以在無需人工幹預的情況下偵測到這些資源。

安裝完成後，此模組 win_dsc 可以調用這些包中的任何資源 只需說出名字即可 resource_name這為重複使用成熟的解決方案（例如 Active Directory DSC 模組）來執行諸如此類的任務打開了大門。 建立使用者、組織單元、群組或設定策略一切都由你的戰術手冊掌控。

此外，還有一個 PowerShell 模組，可以讓你從 DSC 資源自動產生 Ansible 模組。其原理是檢查 DSC 資源，逐一建立映射其參數的 Ansible 模組，然後像使用標準模組一樣使用它。這些生成器可以從 PowerShell 庫下載資源，並建立數十個模組，進一步擴展 Ansible 在 Windows 自動化生態系統中的應用。

除了 DSC 和 Ansible 之外：Azure 中的其他自動化工具

如果您的基礎架構運行（或將要運行）在 Azure 上，那麼值得關註一下其他可以與PowerShell DSC 和 Ansible互補的工具。關鍵不在於選擇哪一個，而是了解它們如何融入整個流程：基礎架構創建、系統配置、應用程式部署和持續維運。

在「基礎架構即程式碼」領域，Terraform或 Azure 原生語言（ARM 範本和 Bicep）等解決方案可讓您使用聲明式檔案定義網路、虛擬機器、儲存和託管服務。 Terraform 使用其自身的 HCL 語言，而 Bicep 則簡化了舊版 ARM 範本的語法，但它們都能很好地整合到 CI/CD 管線中，並且可以與 Ansible 結合使用，在虛擬機器建立後對其進行配置。

階段 Linux機器的初始配置Azure 支援 云初始化它會在首次啟動時執行腳本並配置使用者、軟體包或設定檔。這些文件 #cloud-config通常採用 base64 編碼，與發行版無關，並且依賴每個發行版自己的軟體套件管理器，您無需擔心。

在維運自動化領域，Azure Automation 扮演著重要的角色。它使用運行手冊（通常是 PowerShell 或 Python 腳本），這些運行手冊可以按需執行，也可以按計劃執行，既可以在 Azure 資源上執行，也可以使用混合運行手冊工作器在本地環境中執行。此外，它還提供託管的 DSC服務，讓您可以發布配置並監控一組機器的合規性。

最後，Azure DevOps、Jenkins、Chef、Puppet 和 Packer等 CI/CD 和應用程式生命週期管理工具完善了整個生態系統。它們各自負責一部分工作：從編譯和測試程式碼到產生自訂機器鏡像，再到透過自動化測試確保合規性。

Windows 更新、軟體套件和應用程式管理

對於任何系統團隊來說，最關鍵的任務之一就是確保 Windows 系統及時更新修補程式和修補程式。微軟提供 Windows 更新程序，在許多企業環境中也使用 Microsoft Configuration Manager (SCCM) 來管理部署。然而，當需要多次重啟、維護窗口期緊張或需要複雜的編排方案時，這些機制可能會失效或變得不可靠。

Ansible 自動化平台能夠控制更新的執行，與 Windows 更新集成，並自動管理必要的重啟，從而使單一任務可以安裝數十個或數百個補丁，同時保持對節點最終狀態的控制。

在應用程式安裝方面，Windows 缺乏像 Linux 發行版那樣統一的原生軟體套件管理器。 Microsoft Store 並非為自動化批次部署而設計：它缺乏成熟的命令列工具，並且嚴重依賴圖形介面，這使得它在自動化流程中難以使用。

為了克服這一限制，Ansible 整合了多個模組，實現了Windows 系統中基本的軟體包管理功能，尤其值得一提的是，它與Chocolatey 或Winget 等 Windows解決方案配合使用效果極佳，提供了類似於傳統軟體包管理器的冪等性。透過結合 Chocolatey、DSC 和 Ansible playbook，您可以輕鬆實現伺服器或 VDI 軟體目錄的標準化，而無需進行太多人工幹預。

如果再加上使用 DSC 資源來強制執行與這些應用程式相關的註冊表配置、服務和策略，就可以在 Windows 環境中實現軟體生命週期的全面自動化，從初始安裝到強化配置和定期更新。

Windows Teams 的訓練、最佳實務與應用

在許多純粹基於 Windows 的 IT 團隊中，管理工作仍然始於圖形控制台和精靈的點擊操作。通常會有幾十甚至幾百台虛擬機器運行在 VMware 或 Hyper-V 上，伺服器建立過程都是手動完成的。向自動化的轉變通常發生在團隊成員厭倦了重複相同的任務，開始編寫PowerShell 腳本的時候。

在這種情況下，一個合理的問題出現了：「我是繼續單獨使用 PowerShell，還是切換到 DSC，再配置 Ansible……或者乾脆全部都做？」最務實的答案通常是將它們結合起來：利用現有的 PowerShell 和 DSC 知識，同時引入 Ansible 作為編排層，以獲得標準化能力以及與其他平台的集成能力。

針對 Windows 管理員，有一些專門的課程從 Ansible 的零基礎開始，重點講解以下內容：如何設定 Windows 系統以使用 Ansible 進行管理，如何編寫有效的 playbook，如何整合Ansible Tower 或 AWX以從集中且安全的 Web 介面啟動自動化，以及如何重複使用這些 playbook 中的 DSC 程式碼，以免浪費的工作程式碼。

在實務中，許多團隊採用漸進式策略：首先自動化簡單的任務（服務、角色、PowerShell 模組安裝），然後利用 DSC 資源進行重複配置（IIS、AD、SQL、安全性策略），並逐步將自動化整合到應用程式交付管道和重複性操作任務中。

定義樣式指南、原始碼控制以及劇本和 DSC 配置的測試也很重要，這樣自動化才能真正成為“基礎設施即程式碼”，而不僅僅是一些沒有版本控製或修訂的鬆散腳本。

透過整合PowerShell DSC、Ansible 模組、WinRM、Chocolatey 和 Azure 工具，我們建立了一個強大的生態系統，在這個系統中，機器建立、詳細配置、應用程式部署和持續維護不再依賴手動 RDP 會話。最終，我們獲得了一個更一致、可審計和可複現的環境，其中變更會自動記錄在程式碼中，並大幅減少了人為錯誤。