在Windows平臺上實現云自動化

ny8p 9年前發布 | 26K 次閱讀 Windows

原文 http://www.infoq.com/cn/articles/cloud-automation-windows

對于如今的Windows自動化領域來說，可以以幾種不同的方式來看待它的發展。一種方式是將Windows自動化目前的狀況與五年之前進行比較，這種方式或許會令人對于這門技術的發展深受鼓舞，并對未來的發展充滿樂觀。另一種方式是將如今的Windows自動化生態系統與基于Linux的基礎設施中所用的工具進行比較。一眼看上去它們似乎沒什么不同，但隨著你更深入的觀察與更多的實踐之后，你開始意識到真實的情況，不可否認，Windows自動化的成熟度與Linux相比確實存在著差距。

這兩種比較方式都與當前的Windows自動化狀況背后的故事相關。在本文中，我將通過對當今實際應用中的Windows自動化場景的觀察，深入探索這兩種比較方式的意義。Windows自動化在2014年的發展情況如何？痛點在哪里？它與Linux平臺有著怎樣的不同？Windows和Linux 是否會最終形成一種近似的自動化方式，還是說它們依舊水火不容，各自在自己的市場中占據一席之地？

你采用的Windows自動化方式可能與我的不同

實現Windows自動化的方式多種多樣，不過這些方式最終可以歸結為這三類：

首先看一下第一種方式，用戶選擇不斷重復瑣事并決定不采用自動化。第二種方式能夠提供漂亮的報表，但要經過無數次的點擊，可能還會提供一個功能有限的可編程API界面。第三種方式通過原始代碼的集成提供了極大的靈活性，但往往提供的文檔很有限，并且需要編寫大量的自定義代碼才能夠創建一個完整的端到端解決方案。本文主要專注于第三種方式，因為我個人對這種方式最有經驗。

設置

首先讓我們來討論一下設置。雖然設置Windows環境的方式有很多，但我所展示的方式是我們在CenturyLink Cloud平臺上所應用的流程。由于我們的環境中混合使用了Linux與Windows服務器，因此需要一種能夠集成這兩種操作系統的解決方案。我們最終決定使用Chef作為配置管理工具，并且成為它們的機器資源產品 —— Chef Metal的beta版本的早期使用者。我們所使用的主要虛擬平臺是VMware vSphere。現在讓我們看一看這些技術是通過怎樣的方式結合在一起，對Windows和Linux機器進行設置的：

如圖所示，我們通過一個設置器節點保存著某個數據中心所有服務器的目錄（由Chef服務器提供），如果它察覺某個服務器沒有被正確設置，并且它存在于這個目錄之中，那么設置器就會使用Chef Metal對該節點進行設置。Chef Metal為Chef生態環境提供了一種新的“資源”，即機器資源。這種資源的定義包括核的數量、內存、VM鏡像的模板等屬性。

machine 'web' do
   machine_options :memory_mb => 4096, :num_cpus => 2
   recipe 'active_directory'
end

Chef Metal本身了解在Chef中的機器的通信情況，但它并不了解VMware的存在。使用者可以利用Chef Metal的插件模型創建一個驅動程序，它知道如何與ruby vSphere SDK（rbvmomi）進行交互，并且能夠將Chef Metal的高層次抽象轉換為實際的VM、數據存儲、集群、操作系統自定義模板等等。

驅動程序代碼在Chef Metal中表現為一種計算資源，Chef Metal從而了解如何在Chef客戶端中引導這一實例，并將其轉換為在我的配置中所定義的角色，它可以是一個web服務器、一個活動目錄服務器、一個文件服務器或其它任何角色。

總的來說，這套方案是可行的，但或許你只是希望能夠設置一臺Windows服務器，盡量避免搭建其它服務器，以及編寫自定義ruby代碼的復雜性。這種情況下可以采取一些其它輕量級的方式，我將為你展示其中的幾種。

Windows Azure PowerShell Cmdlets

如果你擁有一個Azure帳號，只需下載Azure PowerShell模塊，就能夠將在Azure web門戶網站上可進行的一切操作進行自動化，比如只需一行代碼就能夠創建一個Azure IaaS虛擬機：

$cred=Get-Credential AzureAdmin
New-AzureQuickVM –ServiceName ServiceTest1 -Windows -Name MyVM `
   -ImageName 3a50f22b388a4ff7ab41029918570fa6__Windows-Server-2012-Essentials-20131217-enus `
   -Password $cred.GetNetworkCredential().Password -AdminUsername $cred.UserName `
   -Location "West US" –WaitForBoot

Hyper-V PowerShell 模塊

如果你的膝上電腦安裝了Windows 8專業版，那么就可以通過其中自帶的hypervisor實現Windows設置的自動化。如果你還沒有完成這一步，請按照以下方式打開這一功能：

dism.exe /Online /Enable-Feature:Microsoft-Hyper-V /All
dism.exe /Online /Enable-Feature:Microsoft-Hyper-V-Management-PowerShell

隨后創建你的VM：

New-VM -Name "myVM" -MemoryStartupBytes 1GB -NewVHDPath "D:\VHDs\w81.vhdx" -NewVHDSizeBytes 60GB
Set-VMDvdDrive -VMName myVM -Path "C:\ISOs\EVAL_EN-US-IRM_CENA_X64FREE_EN-US_DV5.iso"
Start-VM "myVM"

無需許可

手頭上碰巧沒有可用的Windows ISO？不要緊。你可以從微軟的TechNet或MSDN網站下載Windows免費評估版本的ISO或VHD文件。這些鏡像在幾個月之后才會過期，當然不要在生產環境中使用這些鏡像，但我一直使用它們進行測試。

關于Windows更新的提示

將Windows更新預先安裝在你的基礎鏡像文件中，這可以省去你幾個小時的時間用于等待更新完成。你需要一種自動化流程，能夠對這些鏡像文件進行日常更新。我強烈建議你研究一下某些工具的使用，例如packer.io。Packer在Linux世界中已經廣為人知，不過近期在Windows社區中也得到了一定的關注。它是一種用于創建基礎VM鏡像的工具，通過一個配置文件告訴packer如何創建這個鏡像。這種方式很像配置管理，但操作的對象是鏡像，而不是機器。實際上packer能夠與許多流行的配置管理工具進行集成，例如Chef，從而利用配置管理解決方案中提供的DSL創建你所需的鏡像。

打造新的Windows實例

現在你有了一個空的Windows VM，那么接下來呢？正如我之前所指出的，我們使用Chef在CenturyLink Cloud平臺上創建Windows機器。從技術層面上說，你需要編寫一些Ruby代碼，但多數情況下只需使用DSL就夠了，對于 Ruby的專業知識要求幾乎沒有。Chef將組成一臺服務器的多種通用抽象概念以構建塊的形式進行公開，它們被稱為資源。你可以將它們組合成為更大的資源，在Chef的術語中稱為recipe及cookbook。

以下代碼表現了一個注冊表鍵的資源：

# Disable the ServerManager.
registry_key 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ServerManager' do
   values [{
     :name => 'DoNotOpenServerManagerAtLogon',
     :type => :dword,
     :data =>  0x1
     }]
end

以下代碼將某個用戶加入一個組資源中：

group "administrators" do
   action :modify
   members node['platform_ftp']['fileshare_user']
   append true
end

順便說一句，這種方式在Windows或Linux上都能夠運行。實際上大多數資源都是平臺無關的，只依靠于某個底層提供者模型，它將具體實現委托給特定的平臺。

資源的概念不僅僅限于Chef

資源這種抽象概念并非Chef所獨有的，在其它配置管理工具中也使用了相同的術語，例如流行的Puppet和在PowerShell 4及更高版本中內置的微軟DSC（期望狀態配置）。PowerShell團隊還有許多地方需要向Puppet、Chef、CFEngines等工具看齊，但他們追趕的腳步非常快，現已推出了可用于Windows上的新資源可供下載，名為資源wave包，最新的版本是wave 7。

在許多配置管理工具中，除了資源之外還有許多復雜的工作。例如報表、版本控制、節點引導、打包等等。實際上，像Chef這樣的工具已經圍繞著自身打造了一個完整的開源生態系統，為測試、依賴管理和各種小型插件提供了額外的工具，能夠填補Windows服務器本身與各種特定的業務需求之間的差距。微軟已認識到這種差距的存在，于是和Chef等產品進行了緊密合作，并通過Chef recipe將它的DSC資源進行公開。這也意味著，一方面能夠利用由DSC資源所提供的某些特別的Windows自動化能力，同時也能夠利用Chef的跨平臺功能，包括它的報表、企業服務器特性，甚至能夠與它的開源社區完全實現對接。

如果想了解關于在Chef中實現DSC，以及使用基于PowerShell的測試工具對自動化過程進行測試的詳細內容，請閱讀這一篇博客文章，它將一步步地帶你了解這一主題。

獲取Chocolaty

如果你無意克服配置管理工具那陡峭的學習曲線，而只是想通過它完成幾個應用的自動化，那么你可以對Windows在包管理方面所提供的功能進行一番調查。

多年以來，Windows包格式的事實標準是MSI文件，但說句實話，它的功能無法與apt-get或yum相提并論。幾年之前，我的朋友Rob Reynolds就意識到，人們需要一些更簡單，并且能夠更好地支持http的工具，因此他開始開發Chocolatey。雖說我遇到的Windows技術專家中有許多人從沒有聽說過Chocolatey，這一點總是讓我感覺很吃驚，但它已經在Windows高級用戶群體中獲得了很高的流行度，甚至微軟PowerShell團隊也在最新版本的PowerShell中創建了一個Chocolatey客戶端。沒錯，下個版本的Windows將自帶Chocolatey。

讓我們觀察一下這些命令：

cinst googlechrome
cinst git
cinst ruby
cinst vagrant
cinst VisualStudio2013ExpressWeb

它們的作用是在后臺安裝所列出的各種軟件，而無需圖形用戶界面的介入，不必一路點擊“下一步”、“下一步”、“完成”。正如apt-get一樣，你能夠發現、下載并升級你最常用的Windows應用。

雖然Chocolatey的技術沒得說，并且開發工作也十分活躍，但它最大的弱點在于它的生態系統。請不要誤解我的意思，和Windows OSS一樣，Chocolatey的社區同樣十分活躍。但與apt-get等工具不同的是，Chocolatey包多數是由社區進行開發及維護的，而不是由包軟件作者本人進行維護，當然也有一些例外。這意味著有些情況下，包或許沒有得到及時更新，或者會試圖從失效的URL中下載軟件。在多數情況下這種情況并不嚴重，但有時經常會遇到這種問題。

不過，正如我們已經看到DSC的崛起使得配置管理技術成為了Windows的主流，我敢打賭，在包管理方面也會看到同樣的進展。一旦在 Windows中出現了這種工具，并且能夠讓Windows用戶通過TechNet上的白皮書開始學習示例，那么讓包管理工具成為日常工具的日子也就不遠了。

使用Boxstarter進行Chocolatey風格的機器構建

繼續回到剛才的話題，怎樣能夠創建一個Windows環境，而又避免使用繁重的配置管理工具呢？讓我們快速地瀏覽一下這個工具，它利用了 Chocolatey的功能，并且能夠解決在搭建新的Windows環境時在機器引導時所經常遇到的各種痛苦。首先我要曝光一點：我就是這個工具的作者。

Boxstarter為Chocolatey包加入了重啟后自動恢復的功能，并且提供了一些額外的命令，它能夠增加底層的功能并且進行自定義。避免在安裝類似SQL Server、Visual Studio等應用，或是在打開Windows特性以及安裝Windows更新時經常出現的機器構建錯誤。

Boxstarter與Chocolatey接受同樣的安裝命令字符串，它能夠檢測到等待重啟的情況、自動進行重啟、在必要時重新登錄用戶，并返回包的安裝過程。Boxstarter最受歡迎的特性之一在于，你無需創建一個包、也不必安裝Chocolatey、Boxstarter或其它任何先決條件，就能夠實現這一功能，通過一個URL就能夠完成一切操作。舉例如下：

http://boxstarter.org/package/nr/url?https://gist.githubusercontent.com/mwrock/
8518683/raw/43ab568ff32629b278cfa8ab3e7fb4c417c9b188/gistfile1.txt

以上鏈接將提供一個微軟ClickOnce風格的應用作為引導程序，以提供Boxstarter的安裝，隨后將緊隨Boxstarter URL 后的gist URL中的內容進行打包。你也可以選擇安裝Boxstarter PowerShell模塊，使用這些模塊通過Chocolatey設置遠程Windows環境。它依然能夠優雅地對重啟進行處理，并允許你使用在本地常用的PowerShell搭建環境。

你也許不會僅僅通過Boxstarter或Chocolatey用于設置和管理運行中的服務器，但對于每個開發者機器來說是非常優秀的工具。

SSH在哪里？

如果你曾經在Unix或Linux中進行過實戰，你也許會認為Windows已經默認實現了SSH服務器的功能。雖然從技術上來說它并不是SSH，但其概念是相同的。許多人對于微軟沒有從一開始就使用SSH感到困惑不解，如果你想知道微軟為什么不使用SSH，請聽一下這個播客音頻、PowerShell的作者Jeffrey Snover對此進行了深入探討。

為了獲得與SSH相近似的功能，Windows使用了winrm（Windows 遠程管理），這是一個基于SOAP的web service，能夠通過HTTP(s)發送或獲取消息，并將其轉換為本地命令行。這一功能最早出現于PowerShell v2.0中，在隨后的每個新版本中都對功能進行了增強（當前的PowerShell版本是beta v5），用戶可以使用“PowerShell Remoting”，它的功能建立于winrm之上，并且提供了一個互動性的遠程控制臺，與SSH會話的使用幾乎沒有差別。

現在我已經遠程連接到某一臺Azure VM：

有人可能會爭辯（包括我自己在內）道，遠程PowerShell的功能比起SSH更為先進，因為它在遠程與本地shell之間提供了更高精度的通信與操作能力。

我個人的體驗是，遠程PowerShell的主要缺點在于它不像SSH那么容易順利上手，尤其是在老版本的Windows系統上，但即使在近期的系統，例如Windows 2008 R2上也不那么容易使用。在獲得授權的Linux機器上，SSH可以直接使用，而在Windows系統上則需要進行適當的配置。在Windows 2012 R2上雖然不必再進行任何配置，但前提是已經滿足了某些條件，例如已經加入了域、在同一個子網中，或是需要其它某些組策略設置。

如果你打算嘗試從非Windows平臺上遠程訪問Windows系統，那么即使使用遠程PowerShell也無能為力，你唯一的選擇就是直接調用winrm web service。不過還有一些跨平臺的API可以選擇，用Ruby開發的WinRM就是一個流行的選擇，我個人也經常使用它，Shawn Neal也非常積極地維護著這個項目。

require 'winrm'
endpoint = 'http://mywinrmhost:5985/wsman'
krb5_realm = 'EXAMPLE.COM'
winrm = WinRM::WinRMWebService.new(endpoint, :kerberos, :realm => krb5_realm)
winrm.cmd('ipconfig /all') do |stdout, stderr|
   STDOUT.print stdout
   STDERR.print stderr
end

我難道不能夠使用Vagrant嗎？

簡短的回答是：可以！如果你還不熟悉Vagrant，就先簡單介紹一下：Vagrant是一種對虛擬化進行抽象的工具，能夠簡化個人機器設置的過程，通常用于開發或測試目的，可以在團隊成員之間很方便地進行共享。如果你還沒有使用過Vagrant，很難用語言有效地表現出它的功能與簡易性。許多不熟悉它的人會表示，“我很滿意目前使用的 hypervisor（VMware、virtual box、Hyper-V等等），為什么還要引進其它工具？” Vagrant能夠很方便地共享一個1K左右大小的單一文件（通常在源代碼控制系統中管理），它能夠以一種易讀的DSL表示在何處獲取初始的VM鏡像、如何配置網絡，以及如何為基礎鏡像加入額外的自動化能力。在你的團隊中或許有成員使用了不同的虛擬化技術，但“vagrantfile”通過抽象消除了它們之間的差異。

VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| 
   config.vm.box = "mwrock/Windows8.1-amd64"
   config.vm.box_url = "https://wrock.blob.core.Windows.net/vhds/win8.1-vbox-amd64.box"
   config.vm.guest = :Windows 
   config.winrm.username = "vagrant"
   config.winrm.password = "vagrant"
   config.winrm.port = 55985
end

這是一個非常簡單的vagrantfile示例，它的作用是設置一個Windows 8.1的vagrant環境。從URL就可以看出來，這個基礎鏡像是由我的Windows Azure Storage帳號提供的。Vagrant會將所有對端口號55985的請求轉發到vitual box VM上“真正”的winrm端口號5985。

Vagrant最近剛剛對Windows實現了第一等的支持，我個人的感覺是Vagrant對Linux系統的支持更好，但這種情況在每次發布后都有所改善。為了演示通過Vagrant設置Windows系統有多方便，首先下載vagrant，然后執行以下命令：

vagrant init mwrock/Windows8.1-amd64
vagrant up

這個命令將設置一個Windows系統，無論你使用的是VirtualBox或是Hyper-V（你至少需要用到其中一種技術）。如果你還沒有獲取基礎鏡像，那么不必麻煩，在調用這段命令時會自動下載該鏡像。在這里你實際上已經開始感覺到它應用在Windows系統中的不便了，典型的Windows 基礎鏡像經過壓縮后約為3.5GB，這個文件尺寸非常大，通常來說比Linux鏡像大30倍以上。不過，這個下載過程通常是一次性的，Vagrant會將它緩存在本地，因此無需進行重復下載。

容器化

如果不談談容器化技術或是Docker，我就無法結束這個話題。Docker能夠明顯減少設置一個計算實例所需的時間，并且它承諾能夠充分簡化打包應用的過程。

目前在Windows系統上還不存在容器。對于某些人來說，這一事實就足以讓他們決定遠離Windows，或開始從Windows環境中向外遷移。在CenturyLink Cloud環境中，我們將所有基于Linux的基礎設施都通過Docker進行了初始化服務器構建測試。而團隊中的每個人都會告訴你，對Windows服務器的自動化進行測試與調整遠比Linux麻煩得多，其原因就是在Windows環境中無法使用Docker這一事實。

有一家公司對于如何將容器化特性引入Windows環境投入了巨大的調研力量，那就是spoon.net。早在虛擬桌面領域中，他們就開始投入這一概念的研發了，但很快他們就在服務器環境中加速了這一進程。你可以創建一個spoon容器，它提供了一個隔離的文件系統以及注冊表，其命令行界面也很有Docker的風格。目前在服務與網絡功能上還存在著一些不足，但許多問題在本文發布時或許已經得到解決了。我的期望是有一天能夠將Windows容器與我的Chef自動化工作流整合在一起。

Spoon的CEO Kenji Obata最近在推ter上的一篇帖子中發布了關于容器化Chef客戶節點的幾張截圖。

自從這篇帖子最初發布之后，關于在Windows上實現容器化的進程出現了更有趣的變化，微軟剛剛宣布將與Docker展開合作，將Windows容器引入Docker生態系統。至于什么時候能夠實現，以及它的工作方式如何還不清楚。不過微軟能夠公開性地做出這一承諾，這一點確實很令人振奮。看起來，Windows容器將來必將以某種方式出現在我們面前。

先鋒時代已來臨

對于Windows自動化來說，現在正是一個非常激動人心的時刻。當我最近剛剛離開微軟加入CenturyLink，開始完全進入跨平臺之旅時，我感覺似乎自己似乎已經站上了一個高點，正準備目擊一個服務器自動化文明的出現。雖然有多種方式能夠描述這一景象，但我喜歡想象為自己已經大踏步邁進了西大荒準備進行開墾。雖然前進的道路并不平坦，但我感覺Windows自動化的時機和創新條件已邁向成熟。我非常期待著看到它能夠將我們帶往何處。

關于作者

Matt Wrock在設計大規模、分布式、高流量的web應用程序的架構以及自動化環境設置及部署方面已經具有超過15年的經驗。不久之前，Matt在軟件擔任高級軟件工程師。如今他到了CenturyLink Cloud開展工作，專注于數據中心的自動化。Matt也是http://boxstarter.org項目的創始人，以及http://chocolatey.org的代碼貢獻者。你可以在推ter上通過@mwrockx關注他，或是閱讀他的博客hurryupandwait.io。

查看英文原文：Cloud Automation in a Windows World

本文由用戶 ny8p 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。

轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。

本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！

本文地址：http://www.baiduhome.net/news/view/e66cf5

Windows