Windows Server 2012、Windows PowerShell 3.0、DevOps – Part 2


這是本系列文章(共兩篇)的第二篇文章。在第一篇文章當中,說明了有關 PowerShell 和 DevOps 的一些技術背景資訊。在這篇文章當中,則向您介紹一些相關細節。PowerShell 3.0 與 Windows Server 2012 類似,具有大量的新功能和增強功能,因此這裡僅僅簡略介紹部份內容。  
–Jeffrey

DevOps 一直是 PowerShell 所著重的重點,PowerShell 3.0 和 Windows Server 2012 已經將DevOps提升到一個新的水準。對於 Windows Server 2012 來說,我們已經將重心從單台伺服器的作業系統轉換為多台伺服器及其連接設備的雲端作業系統,無論這些設備是實體還是虛擬、是本地端的還是遠端。為了達成此一目標,我們在以下方面重點投入心力:

1. 達成所有任務自動化。

2. 達成可靠和敏捷度自動化。

3. 使維運人員更輕鬆的執行自動化。

4. 使開發人員能夠更輕鬆使用的開發工具。

達成所有任務自動化
Windows Server 2008/R2 內建了大約 230 個 Cmdlet。Windows Server 2012 內建的 Cmdlet 超過該數字的十倍,大約有 2,430 個。現在您幾乎可以自動執行伺服器所有方面的任務。這些 Cmdlet 涵蓋網路連接、儲存、叢集、RDS、DHCP、DNS、檔案伺服器、列印、SMI-S …等。如果您閱讀過 Windows Server 2012 的部落格文章,您就可以瞭解使用 PowerShell 可以做多少事情。如果您沒有及時瞭解相關資訊,請閱讀 Jose Barreto 的“檔案伺服器”部落格文章Yigal Edery 的“私有雲端”部落格文章Ben Armstrong 的 Virtual PC Guy 部落格文章“叢集和高可用性”部落格文章 Natalia Mackevicius 的“合作夥伴和顧客們”部落格文章,之後您就會瞭解我的意思。Windows Server 2012 是目前為止 Windows 的所有版本當中自動化程度最高的版本。

已經有大量的硬體和軟體合作夥伴發佈他們自己的 PowerShell Cmdlet,尚未發佈的合作夥伴將在其產品的後續版本中陸續發佈它們。在美國拉斯維加斯最近召開的 MMS 會議上已經非常清楚的說明了這一點,我認為您在 TechEd 大會上將會看到更多支援 Powershell Cmdlet 的廠商。在購買任何產品之前,您一定要確認該產品會提供一組完整的 PowerShell Cmdlet。如果沒有,則您應該要三思而後行並且做一些市場調查,確定您所購買的產品是最新的並且仍持續維護的。如果某些產品沒有提供 PowerShell,您需要考慮這些產品是否還缺少其它功能? 好消息是 Windows Server 2012 發佈時將有許多產品支援 PowerShell,已經提供 Cmdlet 的產品做到這一點很容易並得到非常積極的客戶意見反應。每個發佈 PowerShell Cmdlet 的產品都會在其下一版本中增加在 PowerShell 部份的投入。  
達成可靠和敏捷的自動化
WorkFlow
我們將 Windows Workflow Foundation 引擎整合到 PowerShell,以便簡單輕鬆的自動執行需要大量時間的任務、大規模的操作任務或者需要跨多台電腦協調的多步驟任務。傳統上,Windows Workflow 一直是開發人員的專用工具,該工具需要 Visual Studio 和許多程式碼才能建立一個解決方案。我們已經將其設計成一個解決方案,維運人員使用現有的 PowerShell 腳本技能便可以方便的建立解決方案。WorkFlow為並存執行、重試操作提供直接支援,並能夠掛起和復原操作。例如 WorkFlow可以檢測一個需要人工手動介入的問題,通知維運人員此一情況,然後掛起操作直到維運人員修正此問題並且復原WorkFlow為止。   
維運人員可以利用任何可用的WorkFlow設計器建立WorkFlow。不過我們進一步透過使用 workflow 關鍵字來擴充 PowerShell 語言,從而簡化解決方案的建立。任何維運人員或開發人員現在都可以使用所有 Windows SKU 中提供的工具方便建立WorkFlow。WorkFlow的行為與函數不同,它有更多的規則,但是如果您知道如何撰寫 PowerShell 函數,則有 80% 的把握可以撰寫WorkFlow。使用 PowerShell 建立 WorkFlow比使用 XAML 容易得多,並且比WorkFlow設計器工具更容易理解。還有一個好處是,您可以將WorkFlow貼到電子郵件讓其他人閱讀/檢查,並且無需安裝特殊工具。下面是一個在多台電腦上同時運作的範例WorkFlow,該WorkFlow在每台電腦上同時收集庫存資訊。

clip_image001[11]

下列的指令將從 servers.txt 中包含的伺服器清單中獲得此庫存資訊,並將結果輸出到一個檔案。如果其中任一伺服器無法存取,WorkFlow將會每 60 秒嘗試連接一次該伺服器,並且持續一小時。

clip_image002[7]

WorkFlow正是 DevOps 實作人員需要可靠和重複執行的操作。DevOps 的關鍵技術之一是 A/B 測試。這種測試技術會部署一個軟體的兩個版本並且運作一段時間。然後比較一些指標(例如銷售的增加量),將勝出的版本部署到所有電腦。WorkFlow功能允許 PowerShell 長時間對大量電腦執行操作,這樣可以方便的自動執行 A/B 測試。   
計畫的作業
我們還無縫式的整合了任務計畫程式和 PowerShell 作業,以便簡單而輕鬆的自動執行調度作業或者當特定事件法發生時自動執行某些作業。下面是持久運作的WorkFlow。該WorkFlow收集組態設定資訊(磁碟資訊)然後自行掛載。WorkFlow已經啟動並且取一個眾所周知的名稱“CONFIG”。我們將使用任務計畫程式復原此WorkFlow。在本範例當中,我們註冊一個 ScheduledJob,使其在每週五下午 6 點和系統每次啟動時運作。當發生某個特定觸發事件時,將運作計畫的作業執行復原該WorkFlow。然後,該WorkFlow收集組態設定資訊,將資訊放在一個新檔案中,並且再次自行掛載。

clip_image003[5]

可靠的網路連接
在以前的版本當中,PowerShell 預設情況下會停用遠端功能,維運人員需要親自到每台電腦前執行 Enable-PSRemoting Cmdlet 才能遠端管理系統。作為雲端作業系統,現在透過 PowerShell 遠端來管理伺服器已經是主流方案,因此我們減少所需的步驟並在所有伺服器組態設定中預設啟用 PowerShell 遠端功能。我們進行了廣泛的安全性分析和測試,確保此功能是安全的。

在 Wojtek Kozaczynski 的 “標準管理”部落格文章 當中,他介紹了我們如何將 WS-MAN 作為主要管理協定,並保持 COM 和 DCOM 的相容性。WS-MAN 是一個使用 HTTP 和 HTTPS 的 Web Service 協定。儘管這些是有效的 REST 協定,但是 PowerShell 仍在這些協定之上建立了一個工作階段來進行遠端過程以提高效能和利用 Session 狀態。這些 Session 在應付普通網路中斷時非常可靠,但是,如果維運人員在大樓之間漫遊時使用可擕式電腦透過 Wi-Fi 網路管理伺服器,則偶爾會發生中斷。我們已經增強了 WSMAN 的工作階段層。預設情況下,它可以忍受長達 3 分鐘的網路中斷。還向 PowerShell Session 增加中斷連接 Session 支援,使用者可以選擇從活動遠端 Session 斷開然後再重新連接到同一 Session ,而不會遺失狀態或被迫終止任務的執行。您甚至可以從其他電腦連接到 Session (就像遠端桌面 Session 一樣)。   
讓維運人員更輕鬆的執行自動化
我們希望大幅降低成功自動執行複雜解決方案所需的技術水準要求。最後希望創造這樣的一個環境,也就是維運人員只要想到所需的東西,點選幾下鍵盤按鍵即可得到。每位客戶的需求和情境各不相同,因此他們需要撰寫自己的解決方案。我們的目標是簡單而輕鬆的撰寫可以與面向高級任務的抽象概念緊密結合的腳本,簡化撰寫腳本的首要因素是 Cmdlet 的覆蓋範圍。因此 Windows Server 2012 附帶了大約 2,430 個 Cmdlet,這極大的方便了自動化作業。其中許多 Cmdlet 在處理實際資料中心內的各種狀況時非常有效。我們將 Cmdlet 與 REST API 和 JSON 物件一起使用,甚至根據需要從管理應用程式獲取、解析和發佈網頁。

clip_image004

為了減少執行操作所需的步驟和語法,PowerShell 3.0 簡化語言和實用程式 Cmdlet,下面的範例顯示了舊語法和新的簡化語法執行操作的方式。

clip_image005

PowerShell3.0 改進維運人員用來撰寫腳本和建立WorkFlow所需的撰寫工具,PowerShell-ISE 現在支援豐富的 IntelliSense、程式碼片段、協力廠商可擴充性和“顯示指令”視窗,使用該視窗可以輕鬆的找到完成任務所需的準確指令和參數。

clip_image006

讓開發人員能夠更輕鬆的建構工具
由於 PowerShell 功能強大、使用 C 語言慣例並且具備對 .Net 物件的程式設計能力,因此開發人員喜歡使用 PowerShell 撰寫腳本。PowerShell 3.0 解決處理 .NET 和物件過程中的大量介接的問題,並允許開發人員在更廣泛的應用情境中使用 PowerShell。   
增強建構工具
PowerShell 3.0 現在有一個 抽象語法樹 (AST)。得以應用新的智慧工具來建立、分析和操作 PowerShell 腳本成為可能。大量Microsoft 雲端服務中有一個服務依賴大量的 PowerShell 腳本來運作該各式各樣的服務。他們的開發團隊使用 AST 開發出一個腳本分析工具。該工具能夠確保維運人員執行的腳本符合最佳時間規範。公開的 AST 是 IntelliSense 異常強大的原因。IntelliSense 使用 AST 檢查程式的實際行為。   
我們修改了 PowerShell 的許多關鍵領域,使開發人員更容易使用和擴充以客製撰寫自己的工具。這包括存取我們的序列化程式、API 改進,以及 PowerShell_ISE 的可擴充性模型。   
增強腳本功能
PowerShell 3.0 現在使用 .NET 動態語言執行 (DLR) 技術。PowerShell 監控腳本的執行方式並動態編譯腳本或部分腳本以優化執行效能。腳本的效能各不相同,但某些腳本在 3.0 中的運作速度比以前快了 6 倍。   
IntelliSense(和命令列上的 Tab 自動補齊)現在可以與 .NET 命名空間和類型一起使用。

clip_image007

它可以尋找相關程式的原因並且使用變數類型推斷改進 IntelliSense 的品質。

clip_image008

我們使用兩個變體擴充了雜湊表構造,這可以讓開發人員更方便的獲取他們需要的行為:

clip_image009

增強平台建構功能
為了支援委派管理方案,我們已經簡化此過程。使用 PowerShell 3.0 可以註冊遠端端點,組態設定提供的指令並且指定運作這些指令的憑據。這樣可以讓一般使用者能夠使用管理員權限執行一組定義好的 Cmdlet。我們已經使用聲明式的 Session 設定檔案簡化定義可用 Cmdlet 的過程。   
PowerShell 3.0 還可以作為 WINPE 的一個可選元件來提供。   
Windows Server 2012 和 PowerShell 3.0 是優秀的 DevOps 工具
DevOps 是一個新術語,關於它會帶來什麼效益目前存在一些分歧意見,但是在本質上它完全是透過自動化保證變化的安全性並且彌合維運人員和開發人員之間的差別。在該領域有許多工作要做,但 Windows Server 2012 和 PowerShell 3.0 為達成這些目標取得了大幅度的進步。PowerShell 不會是您 DevOps 工具箱中的唯一工具,但它是每個 DevOps 工具箱中不可或缺的工具。請立即 下載 Windows Server 2012 RC 版本 並且親自體驗一下。   
Chrees!

Jeffrey Snover  
Windows Server 團隊傑出工程師及首席架構師

Comments (1)

  1. Anonymous says:

    thank you

Skip to main content