其中1、2、3主要是傳統IaaS層關(guān)注的工作內容，重點(diǎn)是計算、存儲、網(wǎng)絡(luò )的自動(dòng)化管理，4到8主要是PaaS層關(guān)注的工作內容，IaaS層和PaaS層相互結合，共同完成自動(dòng)化運維。

　　好了，終于到正題了，自動(dòng)化運維前世今生來(lái)了…..

　　新生代自動(dòng)化運維初探

　　下面重點(diǎn)介紹幾個(gè)自動(dòng)化運維工具或平臺：

　　Openstack

　　Openstack是IaaS層目前最活躍的一個(gè)開(kāi)源的云計算 IaaS 平臺，即云操作系統，類(lèi)似于A(yíng)WS（亞馬遜的云服務(wù)），通過(guò)各種開(kāi)源組件實(shí)現了不同功能，目前大部分云管理平臺均基于Openstack實(shí)現計算、網(wǎng)絡(luò )、存儲的統一管理，Openstack支持如下功能組件：

　　計算服務(wù)（Nova）：按需提供計算資源，創(chuàng )建和管理批量虛擬機 ，動(dòng)態(tài)虛擬機管理：創(chuàng )建、重啟、調整大小、遷移等。

　　對象存儲服務(wù)（Swift）：基于普通硬件的大規模存儲，無(wú)中心節點(diǎn)，分布式存儲、水平擴展，同時(shí)多數據備份，保證安全，通過(guò)API接口對外訪(fǎng)問(wèn)。

　　塊存儲服務(wù)（Cinder)：為虛擬機提供云硬盤(pán)。

　　網(wǎng)絡(luò )服務(wù)（Neutron）：為虛擬機提供網(wǎng)絡(luò )訪(fǎng)問(wèn)能力。

　　編排服務(wù)（Heat）：提供自動(dòng)化部署及管理服務(wù)。

　　數據庫服務(wù)（Trove）：提供數據庫管理服務(wù)。

　　認證服務(wù)（Keystone）：提供身份認證機制服務(wù)。

　　鏡像服務(wù)（Glance）：提供虛擬機鏡像存儲服務(wù)。

　　監控服務(wù)（Ceilometer）：提供計量與監控服務(wù)。

　　Dashboard（Horizon）：自服務(wù)、權限、圖形化界面。

　　1、Openstack版本眾多，如何選擇是一個(gè)難題。

　　例如存在社區版、發(fā)行版、商業(yè)公司定制版本等，如何選擇是一個(gè)難題，而且Openstack每半年一個(gè)穩定版本，演進(jìn)很快。一般認為對Openstack項目中的開(kāi)源代碼進(jìn)行修改定制是個(gè)不錯的主意，但這從長(cháng)期角度來(lái)看不一定優(yōu)質(zhì)?！岸ㄖ圃啤焙芸赡苄枰冻龈甙旱拇鷥r(jià)，不僅投資巨大、成本高昂，企業(yè)用戶(hù)還將被迫面對一大堆后續的管理及維護開(kāi)銷(xiāo)，并被綁定在單一供應商或版本身上。

　　建議企業(yè)如果有很強的技術(shù)能力的話(huà)，可以根據自己的需求做定制，但需要把握好和社區發(fā)展的關(guān)系。 一般來(lái)說(shuō)，需要根據自己的需求，選擇合適的版本，盡量不改變社區版本，定制化需求盡量在外圍進(jìn)行改動(dòng)。如果采用了廠(chǎng)商的版本，實(shí)際上也是某種綁定，可能離社區越來(lái)越遠。

　　2、需要慎重選擇相關(guān)組件合功能

　　由于Openstack理念是分布式、最終一致性，因此所有的原始功能組件都是基于這一設計，企業(yè)用戶(hù)考慮采納Openstack之前，必須對企業(yè)業(yè)務(wù)應用進(jìn)行分析：應用程序是否有可擴展性和彈性伸縮的要求？ 應用程序是否可以接受最終一致性？ 應用程序是否無(wú)狀態(tài)化？ 應用程序的性能要求？應用程序的可靠性要求？ 應用程序的安全要求？ 應用程序的容災備份需求？ 不同的要求決定了Openstack不同的計算、存儲、網(wǎng)絡(luò )等模塊設計。

　　3、Openstack對PaaS層和物理機管理較弱，需借助其他工具實(shí)現

　　Openstack已經(jīng)能夠支持很多的IaaS自動(dòng)化運維和部分PaaS自動(dòng)化運維任務(wù)，但不能滿(mǎn)足全部，如批量運維、深入監控、軟件管理等功能缺少，特別是對物理機運維較弱，一般需要結合其他PaaS層管理進(jìn)一步完善自動(dòng)化運維體系。

　　SaltStack+定制

　　PaaS層自動(dòng)化運維工具就太多了，例如監控就有Nagios、Ganglia、Zabbix等，運維工具則有Puppet、Chef、SaltStack、Ansible等，不同企業(yè)根據企業(yè)自身開(kāi)發(fā)實(shí)力、結合配置管理工具的資源豐富程度、依賴(lài)復雜程度考慮，會(huì )有不同的選擇。通過(guò)對運維工具本身的研究，結合運維人員的運維經(jīng)驗和評估企業(yè)未來(lái)的規模，下面以開(kāi)源SaltStack+定制實(shí)現的方案進(jìn)行介紹。

　　SaltStack是繼 Puppet、Chef 之后新出現的S配置管理及遠程執行工具，與 Puppet 相比，SaltStack較為輕量；不像 Puppet有一套自己的 DSL 用來(lái)寫(xiě)配置，SaltStack 使用 YAML 作為配置文件格式，相對簡(jiǎn)單，同時(shí)也便于動(dòng)態(tài)生成；此外，SaltStack 在遠程執行命令時(shí)的速度快，由于使用了ZeroMQ，這個(gè)下發(fā)過(guò)程可以并行執行，速度比Ansible的無(wú)agent ssh通信快得多，是一個(gè)分布式遠程執行系統，用來(lái)在遠程節點(diǎn)（可以是單個(gè)節點(diǎn)，也可以是任意規則挑選出來(lái)的節點(diǎn)）上執行命令和查詢(xún)數據。

　　從部署結構上看，SaltStack的在部署上可以分為master和minion兩個(gè)部分，其中master相當于統領(lǐng)所有機器的總管，而minion則是部署在被管理機器上面的agent進(jìn)程，master通過(guò)網(wǎng)絡(luò )將配置管理相關(guān)的操作下發(fā)到minion，由minion在對應機器的本地執行。典型的部署例子如下圖所示：

　　容器

　　有了Openstack和SaltStack為代表的的PaaS層自動(dòng)化工具還不夠，針對應用自動(dòng)化運維場(chǎng)景，如彈性伸縮、DevOps（開(kāi)發(fā)運維一體化、開(kāi)發(fā)測試一致的環(huán)境、自動(dòng)資源調度、應用日志統一管控、應用服務(wù)的編排、微服務(wù)管理等），此時(shí)出現了容器技術(shù)，容器技術(shù)實(shí)現有很多種，但最流行的是Docker。

　　傳統容器技術(shù)相較虛擬機優(yōu)勢不是特別大。Docker能夠流行一大重要因此就是它的創(chuàng )新–Docker鏡像。Docker構建了一整套構建、發(fā)布、運行體系：容器（Container）、倉庫（Repository）、鏡像（Images）。傳統容器只解決了容器運行（run）的問(wèn)題。而Docker定義了一套容器構建（build）分發(fā)（ship）的標準，使應用管理非常便捷，尤其適合微服務(wù)管理。

　　注意容器對應用有特定的要求，并不是所有應用都適合，例如需要無(wú)狀態(tài)化、鏡像文件不能太大等。

　　自動(dòng)化運維需要注意的幾點(diǎn)：

　　自動(dòng)化運維工具眾多，各有所長(cháng)，應結合熟悉程度、技術(shù)特點(diǎn)進(jìn)行針對性選擇。

　　多層的自動(dòng)化管理工具，多頭的配置管理是個(gè)難題，建議考慮定制化，設計統一的CMDB，做到一點(diǎn)配置，多點(diǎn)更新。