開源的自動化部署工具探索

1      前言

即便是在傳統的企業當中，平常的備份、服務器狀態監控和日誌，經過手動的方式來進行的效率也很低，是一種人力的浪費。所以，自動化早已經是每一個運維都必須掌握的看家本領。

在不一樣的企業中，自動化的規模、需求與實現方式都各不相同，所以在技術細節層面，運維之間很難將別的企業的方法整個套用過來。然而在不少狀況下，自動化的思路是有共通之處的。

運維自動化前三階段

◆純手工階段：手工操做重複地進行軟件部署和運維。

◆腳本階段：經過編寫腳本、方便地進行軟件部署和運維。

◆工具階段：藉助第三方工具高效、方便地進行軟件部署和運維。

這幾個階段是隨着運維知識、經驗、教訓不斷積累而不斷演進的。並且，第2個階段和第3個階段能夠說是齊頭並進，Linux下的第三方工具雖然說已經很多了，可是Linux下的腳本編寫對運維工做的促進做用是絕對不能夠忽視的。

在DevOps出現以前，運維工做者在工做中仍是以這兩種方式爲主。

下面的研究，都是一些linux下開源的第三方工具，藉助第三方工具高效、方便地進行軟件部署和運維。

 

2      業界開源的自動化部署工具

2.1   chef

Chef 是一款自動化服務器配置管理工具，能夠對所管理的對象實行自動化配置，如系統管理，安裝軟件，基於ruby語言編寫的。

2.1.1    Chef的架構

2.1.2    Chef的工做原理：

Chef 由三大組件組成：Chef Server、Chef Workstation 和 Chef Node。

Chef Server 是核心服務器，維護了一套配置腳本（Cookbook），與每一個被管節點（Chef Node）交互並給出配置指令。

 

Chef Workstation 提供了咱們與 Chef Server 交互的接口：咱們在 Workstation 上建立定義 Cookbook，並將 Cookbook 上傳到 Chef Server 上以保證被管機器能從 Chef Server 上取得最新的配置指令。

 

Chef Node 是安裝了 chef-client 並註冊了的被管理節點，能夠是物理機或者虛擬機或者其餘對象。Chef Node 每次運行 chef-client 時都會從 Chef Server 端取得最新的配置指令（Cookbook）並按照指令配置本身。

若是忽略全部的細節,Chef是這樣工做的:

1在Workstation上定義各個Client應該如何配置本身,而後將這些信息上傳到中心服務器

2每一個Client連到中心服務器查看如何配置本身,而後進行自我配置。

2.1.3    優缺點

優勢：

          1.能夠部署雲計算的業務。

缺點：

1.     用戶須要瞭解比較多的ruby語言，用戶在 Workstation 上編寫 Cookbook。而後，經過 knife 命令上傳到 Chef Server。最後，在 Chef Client 上實施安裝和部署工做，可是Cookbook是基於ruby編寫的。（我的感受這個Cookbook就像咱們的配方同樣）。

2.     chef在配置中心服務器端須要依賴軟件比較多，須要couchdb、RabbitMQ和Solr，這樣連帶須要安裝java和erlang，這樣配置服務器過程要複雜不少。

 3.chef提供了擴展的方式就是Cookbook,咱們要安裝配置本身的應用，就去編寫一個Cookbook，而後上傳到Chef  Server, 彷佛沒有提供基於chef這個作二次編程開發。

2.1.4    關於chef詳細的內容，能夠查看如下的網站

chef基本入門的介紹講的很是好：

http://my.oschina.net/williamherrychina/blog/63576

關於check 的Cookbook的講解很是到位的網站：

http://www.ibm.com/developerworks/cn/cloud/library/1504_wangqw_chefcookbook/index.html

其他一些Chef相關的一些網站

http://it.taocms.org/07/4103.htm

http://www.csdn.net/article/2014-07-16/2820672

http://ju.outofmemory.cn/entry/49489

http://www.ibm.com/developerworks/cn/cloud/library/1506_wangqf_chefforweb/index.html

https://www.aliyun.com/zixun/content/3_12_517313.html

http://www.ithov.com/linux/136837.shtml

以爲chef能夠參考下

2.2   puppet

     puppet是一個開源的軟件自動化配置和部署工具，它使用簡單且功能強大，正獲得了愈來愈多地關注，如今不少大型IT公司均在使用puppet對集羣中的軟件進行管理和部署，如google利用puppet管理超過6000臺地mac桌面電腦（2007年數據）。

Puppet是開源的基於Ruby的系統配置管理工具，基於C/S的部署架構。是一個爲實現數據中心自動化管理而設計的配置管理軟件，它使用跨平臺語言規範，管理配置文件、用戶、軟件包、系統服務等。客戶端默認每隔半小時會和服務器通訊一次，確認是否有更新。固然也能夠配置主動觸發來強制客戶端更新。這樣就把平常的系統管理任務代碼化了，代碼化的好處是能夠分享，保存，避免重複勞動，也能夠快速恢復以及快速的大規模部署服務器。

2.2.1    puppet的架構

2.2.2    Puppet的工做原理

     Puppet是一個C/S架構的配置管理工具，在中央服務器上安裝puppet-server軟件包（被稱做Puppet master）。在須要管理的目標主機上安裝puppet客戶端軟件（被稱做Puppet Client）。當客戶端鏈接上Puppet master後，定義在Puppet master上的配置文件會被編譯，而後在客戶端上運行。每一個客戶端默認每半個小時和服務器進行一次通訊，確認配置信息的更新狀況。若是有新的配置信息或者配置信息已經改變，配置將會被從新編譯併發布到各客戶端執行。也能夠在服務器上主動觸發一個配置信息的更新，強制各客戶端進行配置。若是客戶端的配置信息被改變了，它能夠從服務器得到原始配置進行校訂。

2.2.3    chef與puppet的對比

相同點：

一、都是基於ruby語言

二、對要配置的對象提供了跨平臺的抽象，用戶大部分時間只跟這些抽象的資源打交道，而不用心實現，如只需關心要添加什麼軟件或用戶，不須要關心這些用戶或軟件是怎麼添加上去的

三、都有配置中心服務器，在每臺要配置的客戶端上都須要安裝客戶端，客戶端跟服務器端用證書認證

四、配置應用過程都有兩個階段，第一個階段在配置中心進行，由配置中收服務器針對客戶端生成資源列表，第二個階段在客戶端運行，將應用收到的資源列表。

五、都提供了擴展的方式，puppet用的是模塊的方式，而chef用的是cookbook的方式。雖然感受(我沒有真正用過chef)chef的cookbook方式更靈活和易於分享，可是這二者實質是同樣的。

不一樣點：

一、puppet提供的配置語言更通用和高級一些，用戶不須要懂ruby語言。而對於chef，沒有專門的配置語言，用戶須要瞭解比較多的ruby語言。

二、puppet資源之間有顯式的依賴關係，按照這些關係去實現，而跟這些資源在配置文件的位置或先後沒有關係。而看了一下chef的一些例子，更像是ruby腳本，從前到後按順序執行

三、puppet安裝簡單，須要的支持軟件也少，服務器端也是這樣。而chef在配置中心服務器端須要依賴軟件比較多，須要couchdb、RabbitMQ和Solr，這樣連帶須要安裝java和erlang，這樣配置服務器過程要複雜不少

四、puppet服務端的配置都是一個一個的文本文件，這樣易於發佈、備份和擴展。而chef的服務器端的配置放在couchdb和solr索引等二進制文件中，經過遠程命令工具knife來操做這些配置。這樣，puppet更符合unix管理員的使用習慣。

五、puppet的用戶不少，象Google、Redhat等大公司都在用它。而chef的用戶就少多了，並且沒有什麼大的公司

我的以爲，因此chef和puppet的話，更推薦使用puppet，

2.2.4    關於puppet的相關的網站

http://369369.blog.51cto.com/319630/785895/

http://dongxicheng.org/cluster-managemant/puppet/

http://www.educity.cn/linux/1147307.html

http://os.51cto.com/art/201306/398025.htm

http://www.kisspuppet.com/

2.3   Ansible—輕量級的自動化部署工具

Ansible是新出現的運維工具是基於Python研發的糅合了衆多老牌運維工具的優勢實現了批量操做系統配置、批量程序的部署、批量運行命令等功能。

ansible是基於模塊工做的ansible自己沒有批量部署的能力。真正具備批量部署的是ansible所運行的模塊ansible只是提供一種框架。架構包括

鏈接插件connection plugins負責和被監控端實現通訊。

Host Inventory:指定操做的主機,是一個配置文件裏面定義監控的主機

各類模塊核心模塊command模塊自定義模塊

藉助於插件完成記錄日誌郵件等功能

PlayBooks:劇本執行多個任務時。並不是必需可讓節點一次性運行多個任務

2.3.1    ansible的架構

2.3.2    Ansible的優缺點

優勢：

1比起來其餘自動化集羣管理和運維工具 Puppet、Chef、Ansible 顯得很簡單而且輕量級, 可是 Ansible 又不像 Fab 那樣功能單一隻能作批量命令，也能夠和puppet同樣進行模塊擴展。

2輕量級的好處是學習門檻低、問題少、安裝快、執行快。操做徹底依賴 SSH 而不須要安裝 agent 。這樣的好處是再也不須要維護 agent 的狀態，不用擔憂 Agent 掛掉。而 SSH 是每臺服務器必備的服務。它很是適合安全補丁更新的場景。好比，100 臺服務器打 bash vulnerability 安全補丁只須要 10 分鐘。

3.Ansible 結合 Docker、Mesos、Puppet、Vagrant、Git 等系統能夠構建出很是好的自動化運維平臺。Ansible 比起其餘自動化運維工具更適合對 Docker 實例進行維護和管理。若是你的機器實例數量超過 1000，也能夠選擇Ansible 的 Web 控制工具 Ansible Tower 。

缺點：

1.一樣這樣的簡單設計的劣勢是沒有依賴管理功能（感受不適合咱們公司，或者和別的一塊兒用）。可是 Ansible 對於通常的使用場景已經足夠了。

 

2.3.3    Ansible的相關網站

http://cloud.51cto.com/art/201508/488525_all.htm

http://www.wtoutiao.com/p/t91hrd.html

http://ju.outofmemory.cn/entry/67581

 http://sofar.blog.51cto.com/353572/1579894/

http://www.aikaiyuan.com/6299.html

2.4   ControlTier

ControlTier是一個徹底開放源碼系統的自動化服務管理活動的多個服務器和多個應用層(代碼，數據，配置和內容) 。共同使用的ControlTier包括部署應用程序，控制它們的狀態，並運行按需行政工做在多個服務器上。ControlTier是跨平臺和工程一樣的物理服務器，虛擬機，或雲計算基礎設施。是基於java開發的

2.4.1    ControlTier的架構

 

因爲網上如今controlTier的資料較少，如今對其優缺點還不是很是清楚，有待研究。

ControlTier相關的網站

https://github.com/gschueler/controltier-wiki/wiki/ControlTier

http://blog.csdn.net/kongqz/article/details/6636697

http://www.docin.com/p-299917803.html

2.5   docker

Docker 是一個開源的應用容器引擎，讓開發者能夠打包他們的應用以及依賴包到一個可移植的容器中，而後發佈到任何流行的 Linux 機器上。

Docker是基於go語言開發的一個從新定義了程序開發測試、交付和部署過程的開放平臺，Docker則能夠稱爲構建一次，處處運行，這就是Docker提出的"Build once，Run anywhere"。

2.5.1    Docker總架構圖

Docker對使用者來說是一個C/S模式的架構，而Docker的後端是一個很是鬆耦合的架構，模塊各司其職，並有機組合，支撐Docker的運行。

用戶是使用Docker Client與Docker Daemon創建通訊，併發送請求給後者。

 

而Docker Daemon做爲Docker架構中的主體部分，首先提供Server的功能使其能夠接受Docker Client的請求；然後Engine執行Docker內部的一系列工做，每一項工做都是以一個Job的形式的存在。

 

Job的運行過程當中，當須要容器鏡像時，則從Docker Registry中下載鏡像，並經過鏡像管理驅動graphdriver將下載鏡像以Graph的形式存儲；當須要爲Docker建立網絡環境時，經過網絡管理驅動networkdriver建立並配置Docker容器網絡環境；當須要限制Docker容器運行資源或執行用戶指令等操做時，則經過execdriver來完成。

 

而libcontainer是一項獨立的容器管理包，networkdriver以及execdriver都是經過libcontainer來實現具體對容器進行的操做。

 

當執行完運行容器的命令後，一個實際的Docker容器就處於運行狀態，該容器擁有獨立的文件系統，獨立而且安全的運行環境等。

 

2.5.2    Docker優缺點

優勢：

一、簡化程序：Docker讓開發者能夠打包他們的應用以及依賴包到一個可移植的容器中，而後發佈到任何流行的 Linux 機器上，即可以實現虛擬化。

Docker改變了虛擬化的方式，使開發者能夠直接將本身的成果放入Docker中進行管理。方便快捷已是Docker的最大優點，過去須要用數天乃至數週的任務，在Docker容器的處理下，只須要數秒就能完成。

二、避免選擇恐懼症：若是你有選擇恐懼症，仍是資深患者。Docker幫你打包你的糾結！好比Docker鏡像；Docker鏡像中包含了運行環境和配置，因此Docker能夠簡化部署多種應用實例工做。好比Web應用、後臺應用、數據庫應用、大數據應用好比Hadoop集羣、消息隊列等等均可以打包成一個鏡像部署。

三、節省開支：一方面，雲計算時代到來，使開發者沒必要爲了追求效果而配置高額的硬件，Docker改變了高性能必然高價格的思惟定勢。Docker與雲的結合，讓雲空間獲得更充分的利用。不只解決了硬件管理的問題，也改變了虛擬化的方式。

另外一方面，Docker可以是自願額達到充分利用。舉個簡單地例子：凌晨三點的時候只有不多的人會去訪問你的網站，同時你須要比較多的資源執行夜間的批處理任務，經過Docker能夠很簡單的便實現資源的交換。

Docker採用了一種特別的方式，以即可以整合到大多數DevOps（開發運營）應用程序當中，包括Puppet、Chef、Vagrant和Ansible。或者能夠獨自使用，以管理開發環境。

主要賣點是，它簡化了一般由另外這些應用程序執行的好多任務。具體來講，有了Docker，人們就能夠搭建與活動服務器如出一轍的本地開發環境，從同一個主機運行多個開發環境（每一個開發環境有獨特的軟件、操做系統和配置），在新的或不一樣的服務器上測試項目，以及讓任何人均可以在設置如出一轍的狀況下處理同一項目，不管本地主機環境怎樣。」

缺點：

可能最大的障礙在於管理實例之間的交互。因爲全部應用組件被拆分到不一樣的容器中，全部的服務器須要以一致的方式彼此通訊。這意味着任何人若是選擇複雜的基礎設施，那麼必須掌握應用編程接口管理以及集羣工具，好比Swarm、Mesos或者Kubernets以確保機器按照預期運轉並支持故障切換。

Docker是基於Linux 64bit的，沒法在32bit的linux/Windows/unix環境下使用

LXC是基於cgroup等linux kernel功能的，所以container的guest系統只能是linux base的

隔離性相比KVM之類的虛擬化方案仍是有些欠缺，全部container公用一部分的運行庫

網絡管理相對簡單，主要是基於namespace隔離

cgroup的cpu和cpuset提供的cpu功能相比KVM的等虛擬化方案相比難以度量(因此dotcloud主要是按內存收費)

docker對disk的管理比較有限

container隨着用戶進程的中止而銷燬，container中的log等用戶數據不便收集

對linux系統的內核要求過高了，要3.8版本的linux內核。

2.5.3    Docket的相關網站

一個講解docker很是好的網站，很是到位

http://www.infoq.com/cn/articles/docker-source-code-analysis-part1/

其他一些網站

http://www.infoq.com/cn/news/2013/04/Docker/

http://www.docker.org.cn/docker/71.html

2.6   AppOSS

AppOSS(Easy Commander) 是一個自動化的通用運維平臺，它的目的是協助devops減小重複勞動，積累運維工做實踐。

AppOSS設計的初衷是對大型的、混合多種類型的互聯網應用系統進行運維，它雖然誕生於淘寶的內部需求，但實際場景並不比別人更特別，所以我但願可以對其它相似的場景也有幫助。

從功能角度看，AppOSS僅僅是一個基於Web的ssh併發執行工具（感受過於簡單，不適合咱們的系統），這意味着它不會對你的運維工做作過多的干預，你可使用任何你以爲合適的技術和框架來操做本身的系統。

AppOSS做爲一個運維自動化平臺，主要包括兩個部分：Center 和 Agent。前者是一個基於Ruby on Rails的 web 應用，後者是一個基於 erlang 的併發 ssh 處理進程，這個項目是center部分。

AppOSS相關網站

http://www.open-open.com/lib/view/open1403058352090.html

 

2.7   disconf ----分佈式管理配置平臺

disconf 是基於java開發能夠爲各類業務平臺提供統一的配置管理服務。

專一於各類 分佈式系統配置管理 的通用組件/通用平臺, 提供統一的配置管理服務。包括 百度、滴滴打車、銀聯、網易、拉勾網 等知名互聯網公司正在使用!

1部署極其簡單：同一個上線包，無須改動配置，便可在 多個環境中(RD/QA/PRODUCTION) 上線

2部署動態化：更改配置，無需從新打包或重啓，便可 實時生效

3統一管理：提供web平臺，統一管理 多個環境(RD/QA/PRODUCTION)、多個產品 的全部配置

4支持微服務架構

 

2.7.1    Disconf的架構圖：

重要功能特色

·         支持配置（配置項+配置文件）的分佈式化管理

·         配置發佈統一化

·         配置發佈、更新統一化（雲端存儲、發佈）:配置存儲在雲端系統，用戶統一在平臺上進行發佈、更新配置。

·         配置更新自動化：用戶在平臺更新配置，使用該配置的系統會自動發現該狀況，並應用新配置。特殊地，若是用戶爲此配置定義了回調函數類，則此函數類會被自動調用。

 

·         配置異構系統管理

·         異構包部署統一化：這裏的異構系統是指一個系統部署多個實例時，因爲配置不一樣，從而須要多個部署包（jar或war）的狀況（下同）。使用 Disconf後，異構系統的部署只須要一個部署包，不一樣實例的配置會自動分配。特別地，在業界大量使用部署虛擬化（如JPAAS系統，SAE，BAE） 的狀況下，同一個系統使用同一個部署包的情景會愈來愈多，Disconf能夠很天然地與他自然契合。

·         異構主備自動切換：若是一個異構系統存在主備機，主機發生掛機時，備機能夠自動獲取主機配置從而變成主機。

·         異構主備機Context共享工具：異構系統下，主備機切換時可能須要共享Context。可使用Context共享工具來共享主備的Context。

 

·         極簡的使用方式（註解式編程 或 XML代碼無代碼侵入模式）：咱們追求的是極簡的、用戶編程體驗良好的編程方式。目前支持兩種開發模式：基於XML配置或才基於註解，便可完成複雜的配置分佈式化。

·         須要Spring編程環境

 

2.7.2    disconf項目信息

CLIENT 端：

Java: 目前惟一支持語言

python：打算支持

PHP：暫未支持

WEB 管理端：

Java SpringMvc 實現，先後端分離 實現方式(基於Spring 4.1.7.RELEASE)

2.7.3    Disconf相關網站

Disconf介紹比較好的網站，就是github上面的

https://github.com/knightliao/disconf

其他的網站

https://github.com/knightliao/disconf/tree/master/disconf-web

http://blog.csdn.net/wanggang421338916/article/details/45889561

 

3      總結

其實還有不少一些相關的開源的自動化部署的工具，好比slatstack與ansible很是像，就沒有詳細介紹了 ，ansible沒有依賴管理，有點不適合咱們的業務。Chef與puppet的話，puppet可能更好一點，AppOss也是過於簡單，感受能夠puppet、docker、controlTier，disconf均可以再好好的研究下，看是否適合咱們的業務。