自動化工具的比較

虛擬化技術日益普及，基於行業標準的服務器功能越來越強大，加上雲計算的出現，這些因素共同導致了企業內外需要加以管理的服務器數量大幅增長。過去我們只要管理內部數據中心裡面的物理服務器機架，而現在我們要管理多得多的服務器，它們有可能遍佈全球各地。

　　這時候，數據中心協調和配置管理工具就派得上用場。在許多情況下，我們管理大批同樣的服務器，它們運行同樣的應用程序和服務。這些服務器部署在企業內部的虛擬化框架上，或者作為雲計算或託管實例在遠程數據中心運行。在一些情況下，我們可能談論的是完全為了支持超大應用系統而存在的大型環境，或者是支持無數小型服務的大型環境。不管怎麼樣，讓它們都乖乖聽從管理員的指揮這種能力不可小視。這是管理這些越來越龐大的基礎設施的方式。

Puppet、Chef、Ansible和Salt都是為了實現這個目標而開發的：讓用戶極容易配置和維護數十臺、數百臺、乃至數千臺服務器。這倒不是說小公司就不會得益於這些工具，因為自動化和協調技術通常可以簡化任何規模的基礎設施的正常運行。

　　深入測評這四款工具中的每一款，探究各自的設計和功能，可以發現：雖然一些工具的得分更高，但每款工具都有一席之地，這取決於部署的目的。

Puppet

Puppet也許是四款工具中最深入人心的。就可用操作、模塊和用戶界面而言，它是最全面的。Puppet呈現了數據中心協調的全貌，幾乎涵蓋每一個運行系統，為各大操作系統提供了深入的工具。初始設置比較簡單，只需要在需要加以管理的每個系統上安裝主服務器和客戶端代理軟件。

命令行接口(CLI)簡單直觀，允許通過puppet命令下載和安裝模塊。然後，需要對配置文件進行更改，好讓模塊適合所需的任務;應接到指令的客戶端與主服務器聯繫時，會更改配置文件，或者客戶端通過立即觸發更改配置文件的推送(push)來進行更改。

還有一些模塊可以提供和配置雲服務器實例和虛擬服務器實例。所有模塊和配置都使用基於Ruby的Puppet專屬語言或者Ruby本身構建而成，因而除了系統管理技能外，還需要編程專業知識。

Puppet企業版擁有最全面的Web用戶界面，允許使用主服務器上的預製模塊和菜譜(cookbook)，實時控制被管理的節點。Web用戶界面很適合用於管理，但是不允許對模塊進行諸多配置。報告工具非常完善，提供了詳細信息，以便了解代理軟件運行如何、已做出什麼樣的變更。

Chef

Chef的總體概念類似Puppet，因為在被管理的節點上安裝有主服務器和代理軟件，但實際部署又不一樣。除了主服務器外，安裝的Chef環境還需要工作站來控制主服務器。代理軟件可以藉助使用SSH來部署的knife工具從工作站加以安裝，減輕了安裝負擔。之後，被管理的節點通過使用證書，完成與主服務器之間的驗證。

Chef的配置離不開Git，所以對Chef運作而言，瞭解Git如何工作是先決條件。與Puppet一樣，Chef同樣基於Ruby，所以還需要了解Ruby。與Puppet一樣，模塊可以下載，也可以從頭開始編寫，可以在所需配置之後部署到被管理的節點。

與Puppet不一樣，Chef還沒有一項完善的推送功能，不過提供了測試版代碼。這意味著需要配置代理軟件，以便與主服務器進行聯繫，實際上不可能立即應用變更的內容。

企業版Chef的Web用戶界面很實用，但不提供更改配置的功能。這個Web用戶界面不如Puppet企業版來得全面，缺少報告及其他功能，但允許庫存控制和節點組織。

與Puppet一樣，Chef得益於一大批的模塊和配置菜譜，那些模塊和配置菜譜又高度依賴Ruby。由於這個原因，Chef非常適合注重開發的基礎設施。

SaltStack

SaltStack類似Ansible，因為它也是基於CLI的工具，採用了推送方法實現客戶端通信。它可以通過Git或通過程序包管理系統安裝到主服務器和客戶端上。客戶端會向主服務器提出請求，請求在主服務器上得到接受後，就可以控制該客戶端了。

SaltStack可以通過普通的SSH與客戶端進行通信，但如果使用名為minion的客戶端代理軟件，可以大大增強可擴展性。此外，SaltStack含有一個異步文件服務器，可以為客戶端加快文件服務速度，這完全是SaltStack注重高擴展性的一個體現。

與Ansible一樣，你可以直接通過CLI，向客戶端發出命令，比如啟動服務或安裝程序包;你也可以使用名為state的YAML配置文件，處理比較複雜的任務。還有“pillar”，這些是放在集中地方的數據集，YAML配置文件可以在運行期間訪問它們。

你可以直接通過CLI，向客戶端請求配置信息，比如內核版本或網絡接口方面的詳細信息。只要使用名為“grain”的庫存元素，就可以描述客戶端;這樣一來，管理員可以輕鬆向某一種類型的服務器發出命令，不需要依賴已配置群組。比如說，只要使用一個CLI命令，你就可以向運行某個內核版本的每個客戶端發送命令。

與Puppet、Chef和Ansible一樣，SaltStack也提供了大量的模塊，以處理特定的軟件、操作系統和雲服務。自定義模塊可以用Python或PyDSL來編寫。除了Unix管理外，SaltStack的確提供Windows管理功能，但它還是更擅長管理Unix和Linux系統。

SaltStack的Web用戶界面Halite非常新，功能不如其他系統的Web用戶界面來得全面。它提供了事件日誌和客戶端狀態的視圖，能夠在客戶端上運行命令，但除此之外乏善可陳。

SaltStack的較大優點在於可擴展性和彈性。你可以有多個級別的主服務器。上游主服務器可以控制下游主服務器及其客戶端。另一個優點在於對等系統，讓客戶端可以向主服務器提出問題，然後主服務器從其他服務器得到答案，提供全面信息。如果需要在實時數據庫中查詢數據，以便完成客戶端的配置，這個優點就很方便。

Ansible

Ansible極其類似SaltStack，而不太類似Puppet或Chef。Ansible關注的重點是力求精簡和快速，而且不需要在節點上安裝代理軟件。因此，Ansible通過SSH執行所有功能。Ansible基於Python;相比之下，Puppet和Chef基於Ruby。

Ansible可以通過Git軟件庫克隆，安裝到Ansible主服務器上。安裝完畢後，需要管理的節點被添加到Ansible配置環境，SSH授權密鑰被附加到每個節點上，這與運行Ansible的用戶有關。一旦完成了這步，Ansible主服務器可以通過SSH與節點進行通信，執行所有必要的任務。為了與默認情況下不允許根SSH訪問的操作系統或發行版協同運行，Ansible接受sudo登錄信息，以便在那些系統上以根用戶的身份運行命令。

Ansible可以使用Paramiko(基於SSH2協議的Python實現)或標準SSH用於通信，不過還有一種加速模式，允許更快速、更大規模的通信。

針對確保服務在運行，或者觸發更新和重新啟動之類的簡單任務，Ansible可以從命令行來運行，不需要使用配置文件。至於比較複雜的任務，Ansible配置通過名為Playbook的配置文件中的YAML語法來加以處理。Playbook還可以使用模板來擴展其功能。

Ansible有一大批模塊，可用於管理各種系統以及亞馬遜彈性計算雲(EC2)和OpenStack等雲計算基礎設施。可以用幾乎任何一種語言來編寫自定義Ansible模塊，只要模塊輸出是有效的JSON。

Ansible的Web用戶界面以AnsibleWorks AWX的形式出現，但AWX與CLI並不直接聯繫在一起。這意味著，除非進行了同步過程，否則CLI裡面的配置元素不會出現在Web用戶界面中。你可以使用那個內置的同步工具，讓兩者保持一致，但需要按照預定計劃運行同步工具。

最近糾結於在 Puppet、Chef、SaltStack、Ansible 等一干配置管理工具中如何選擇。考慮到一旦開始沒有選好，以後更改又是一堆麻煩事，所以就稍微有些慎重。

Puppet 和 SaltStack 看過介紹，不是十分符合預期，所以先行排除。至於 Chef，雖然老早就聽說過，但卻一直沒有找到機會嘗試。翻了翻文檔，Chef 跟 Puppet 及 SaltStack 也是一樣採用服務端/客戶端模式，對於在現有一定數量的機器上部署仍然有 些麻煩。最後落單到 Ansible 上。經過對 Ansible 的把玩，我感覺 Ansible 於我比較相投。我喜歡 Ansible 的方面包括：

• 充分利用現有設施。使用 Ansible 無需安裝服務端和客戶端，只要 SSH 即可。這意味著，任何一臺裝有 Ansible 的機器都可以成為強大的管理端。我覺得，這種去中心化的思路顯得更為靈活。可能有人會擔心 SSH 的效率，Ansible 的並行執行及加速模式或許可以打消你的顧慮。

• 使用簡單，快速上手相當容易。我在用 Puppet 之前，就沒少花時間鑽研它。想想吧，我們使用這類自動化管理工具不就是想把自己從重複的、複雜的事情中解放出來麼？為了簡化一件事，而沉入另一件複雜的 事，是不是有些不划算？從我的體驗來看，Ansible 上手十分快，用 Ad-Hoc 可以應付簡單的管理任務，麻煩點的也可以定義 Playbook 文件來搞定。

• 採用人類易讀的格式。Ansible 的主機定義文件使用 INI 格式，支持分組，能夠指定模式；此外也能動態生成，這對管理雲主機應當很有用。而 Playbook 則是 YAML 格式，我覺得它比 Puppet 的 DSL 要易讀易寫多了。

• 能夠使用你熟悉的語言來編寫模塊。雖然 Ansible 是使用 Python 開發的，但它不會將你限制到某種具體的編程語言，Bash、Python、Perl、Ruby 等等都可以，你擅長什麼就用什麼。

一言以蔽之，Ansible 背後的簡單化哲學深得我心。這也比較符合我選擇軟件的一貫原則。可能還有人會比較關心目前 Ansible 都有誰在用。畢竟，榜樣的力量是無窮。Puppet 不正是因為 Google 在用而吸引了不少眼球麼？據我所知，當前使用 Ansible 較為知名的用戶包括 Fedora、Rackspace、Evernote 等等。

安裝Ansible

管理主機的要求：

1. 安裝了 Python 2.6 或 Python 2.7

2. 主機的系統可以是 Red Hat, Debian, CentOS, OS X, BSD的各種版本,等等

3. ansible使用了更多句柄來管理它的子進程,對於OS X系統,你需要增加ulimit值才能使用15個以上子進程,方法 sudo launchctl limit maxfiles 1024 2048,否則你可能會看見”Too many open file”的錯誤提示.

以Liunx為例源碼安裝Ansible：

1、首先需要有在服務器中安裝git -->"yum install git -y"

2、源碼下載ansible

$ git clone git://github.com/ansible/ansible.git --recursive$ cd ./ansible

3、環境變量

$ source ./hacking/env-setup

4、如果沒有安裝pip, 請先安裝對應於你的Python版本的pip:

$ sudo easy_install pip

$ sudo pip install paramiko PyYAML Jinja2 httplib2 six

注意,當更新ansible版本時,不只要更新git的源碼樹,也要更新git中指向Ansible自身模塊的 “submodules” (不是同一種模塊)

$ git pull --rebase$ git submodule update --init --recursive

一旦運行env-setup腳本,就意味著Ansible從源碼中運行起來了.默認的inventory文件是 /etc/ansible/hosts.inventory文件也可以另行指定

$ echo "127.0.0.1" > ~/ansible_hosts$ export ANSIBLE_HOSTS=~/ansible_hosts

5、測試是否完成

ansible all -m ping --ask-pass

後續的使用會接著寫下去。

閱讀更多 心欲無痕 的文章

關鍵字: Python 編程語言 雲計算