但凡伺服器上了一定規模（百臺以上），普通的ssh登入管理的模式就越來越舉步維艱。試想Linux釋出了一個高危漏洞的補丁，你要把手下成百上千臺機器都更新該補丁，如果沒有一種自動化方式，那麼至少要耗上大半天時間。雖然你編寫了大量的shell（或python，perl）指令碼來實現各種自動化場景，但最後會發現你又陷入了指令碼的汪洋大海之中，管理和維護這麼多的指令碼的成本也不小。你需要一款基礎設施自動化工具，希望它能具有以下功能。
批量執行。這個不多說了吧，試想要為每一臺機器打補丁的情形吧。
任務編排。現在稍微複雜點的應用都需要N臺伺服器來部署，而部署的過程中肯定有個先後的依賴順序。那麼由此看來任務編排肯定必不可少。
對業務場景的抽象，也就是DSL化。之所以拋棄自己用shell(或其它語言的)指令碼來實現各種自動化的原因之一就是這些指令碼很難懂，除了你以外其他人幾乎無法修改。而作為一個成熟的工具，自然對我們們複雜的應用場景要做抽象，比如對伺服器節點、角色的抽象，對伺服器上的各種安裝、配置操作的抽象，對不同環境的抽象等。通過抽象出來的DSL，大家很容易達成一致，協同工作。
安全機制。既然是基礎設施自動化工具，免不了包含各種敏感資訊，如何去敏也是挺重要的。而且既然能控制整個伺服器叢集，控制方式也要絕對安全。
除了這幾個基本功能以外，當然我們還希望有更多功能，比如指令碼重用、審計功能、完善的文件等。這裡就不多說了。
類似的工具肯定已經有了，現在市場上比較流行的開源軟體有Puppet、Chef、Ansible、SaltStack等。關於它們的優劣不是這篇文章的重點。
而談起叢集管理，大家似乎預設的都是對Linux系統叢集的管理，對於Windows叢集則很少涉及。我想這大抵有兩方面的原因，一方面是大部分公司中機器叢集型別大都是Linux系統，另一方面是Windows機器在批量化管理方面天然有缺陷，比如缺乏各種方便的指令碼命令、很難對機器配置完全指令碼化等。但對Windows叢集的管理問題無法迴避，因為在企業中Windows叢集的確存在。微軟也在致力改善這些問題，比如Window PowerShell就是為了解決校本化的問題。
而筆者的上一個專案就涉及對數百臺Windows和Linux叢集的管理。Windows叢集的主要作業系統是Windows Server 2008，Linux叢集的主要作業系統是Ubuntu 12.04。要實現對這樣的叢集的自動化配置和管理，筆者積累了一些經驗，特意分享給大家。
自動化工具的選型
凡是牽扯到工具選型的時候，如果你發現你處於一個非常糾結的地位，那可能是因為競品工具沒有一個能突出重圍，導致你在它們各自的優缺點之間難以取捨。我也理解，工具選型要考慮的因素太多。這個專案的選型其實沒經過太大波折，很快就決定使用Chef。原因我可以簡單說一下，Puppet的API太不友好，ansible和salt對windows的支援程度未知，而根據我以前的經驗，Chef對windows的支援還是比較成熟的。所以我們就快刀斬亂麻選擇了Chef。
搭建Chef生態環境
既然決定了Chef，那麼接下來很多問題都不得不考慮。
使用自建的Chef Server
原因很簡單，因為客戶不會把自己的node暴露在公共的chef server之上。所以我們在企業內網搭建了一個Chef server，放置在一臺ubuntu機器上。
workstation選擇windows機器(windows 7)
考慮到我們要同時管理Linux叢集和Windows叢集，所以workstation的選擇也很重要。在bootstrap一個node的時候，workstation和linux node的通訊方式是ssh，而和windows node的通訊方式是通過WinRM。如果使用Linux通過WinRM和Windows系統通訊，理論上是可行的，我們可以藉助一些第三方工具實現，但過程肯定比較曲折。而如果使用Windows機器和Linux及Windows系統通訊，則沒有太大問題。
搭建自己的軟體倉庫
對於Linux系統而言有很多成熟的包管理工具，想要安裝什麼軟體基本上一條命令即可。而對於Windows系統而言，雖然有chocolatey之類的工具，但在分發一些企業內部的軟體方面仍捉襟見肘。所以我們選擇搭建自己的軟體倉庫。剛開始為了簡便起見就搭建了一個ftp伺服器作為軟體倉庫。後期會考慮遷移到Sonatype Nexus之類能提供更多功能的包管理伺服器上去。
建立Chef repo並納入原始碼管理之類的事情由於沒有太多特殊性，所以這裡就不展開了。
應用Chef管理windows叢集
使用Chef來管理windows叢集肯定沒有像管理Linux叢集那麼容易，以下是幾個需要注意的點。
配置Windows node開啟WinRM服務
WinRM服務是微軟提供的用於進行遠端通訊的服務（Windows 7及以後的系統內建支援），你可以簡單理解為Windows版的SSH。在Windows server 2008 R2作業系統中，WinRM服務預設是關閉的，我們需要啟用它。首先需要修改兩個組策略。在組策略的計算機配置->策略->Windows元件->Windows遠端管理(WinRM)->WinRM服務中，選擇“允許自動配置監聽器”，把該策略選為啟用，並修改IPv4和IPv6過濾器為*。然後在控制皮膚中選擇windows防火牆，單擊例外選項卡，選擇Windows 遠端管理核取方塊。如果看不到該核取方塊，請單擊新增程式以新增 Windows 遠端管理。 （具體請參見http://www.briantist.com/how-to/powershell-remoting-group-policy/）
這兩項的配置也可以通過PowerShell指令碼來實現。想要了解的可以參見這篇文章https://powertoe.wordpress.com/2011/05/16/enable-winrm-with-group-policy-but-use-powershell-to-create-the-policy/。
然後就可以啟用和配置WinRM了。只需要在PowerShell終端輸入winrm quickconfig -q即可。另外Chef還推薦對WinRM進行一些進階配置，具體請參見https://github.com/Chef/knife-windows#requirementssetup。
使用windows cookbook
windows cookbook是Chef專為windows平臺寫的cookbook。裡面包含了非常多的針對windows平臺特性的功能，是操縱windows平臺不可或缺的利器。比如解壓縮檔案、執行batch(PowerShell)命令、安裝認證、安裝解除安裝windows包、配置執行計劃任務……
使用方式也很簡單，安裝可以通過chef的supermarket執行，具體參見https://supermarket.chef.io/cookbooks/windows#knife。如果在其它cookbook需要使用該cookbook的模組，只需在其它cookbook的metadata.rb中加入depends ‘windows’即可。
升級Windows node上的PowerShell版本
PowerShell之於Windows就相當於shell之於Linux。Windows Server 2008 R2上的PowerShell預設版本是3.0，最好能夠升級到高階版本。而https://github.com/opscode-cookbooks/powershell中的cookbook則可以方便的對Windows node的PowerShell進行升級和配置,以及安裝各種PowerShell module，執行PowerShell指令碼等。
實現對軟體的靜默安裝
Linux上的每種軟體基本都有通過命令列靜默安裝的方式。而Windows下的軟體卻不盡然。如果軟體是以.msi方式打包的，那麼可以使用Windows Installer來實現靜默安裝。如果是以.exe的方式來打包的，倒也不被驚慌，可以仔細分析其是否是以inno、NSIS、installshield等方式打包的，然後根據各自方式的靜默方式實現自動化安裝。如果以上皆不適用，則可以分析該軟體是否為綠色軟體，嘗試把安裝後的整個資料夾打包放置於軟體倉庫之上，以後安裝只需要解壓縮即可。如果軟體既沒有規範的打包方式，也不是綠色軟體，那麼就比較麻煩了，需要分析安裝後建立了那些檔案，以及執行了那些指令碼，然後嘗試把這些操作命令列化（不過這樣的軟體非常少，不必過於擔心）。
使用push jobs功能
通常我們需要對節點進行批量化操作，而通過chef-client的方式功能有限。chef提供了push jobs這樣的擴充套件功能，允許我們對節點進行隨心所欲的批量操作。詳情請參見https://docs.chef.io/push_jobs.html。
熟練使用PowerShell指令碼
之前我說過，PowerShell在Windows上的地位就如同Shell在Linux上的地位。Windows PowerShell提供了對COM組建和WMI元件的完全訪問，而且可以輕鬆呼叫.net framework框架中的功能，而且也包含強大的文件。如果你想配置一個DHCP伺服器，或者配置一個IIS網站服務，抑或修改登錄檔，使用PowerShell能輕鬆讓你達到目標，徹底擺脫圖形化介面。
總體來說，Chef對於Windows平臺的支援力度還是相當完善的，如果你想實現對Windows叢集的自動化管理，那麼Chef不失為一種可行的方案。至於其它幾種自動化工具，筆者有時間也會進行深入調研，再出具報告。