對於每一個剛接觸到OpenStack的新人而言，安裝無疑是最困難的，同時這也客觀上提高了大家學習OpenStack雲端計算的技術門檻。想一想，自己3年前網上偶然接觸到OpenStack時，一頭茫然，手動搭建一個多節點環境時居然用了3個星期。

時至今日，真是感觸頗多，從某種角度而言，也很慶幸當時自己並未因困難而放棄OpenStack，否則，應該是去做其他領域了吧！

言歸正傳，咱們就來數落數落部署OpenStack都有哪些方式吧。這裡，我們根據使用者群體的不同型別來進行分類和歸納：

個人使用方面

DevStack
無疑，在可預見的未來時間內，DevStack仍將是眾多開發者們的首選安裝方式或工具。該方式主要是通過配置引數，執行shell指令碼來安裝一個OpenStack的開發環境。

Rdo
Rdo是由Red Hat開源的一款部署OpenStack的工具，同DevStack一樣，支援單節點和多節點部署。但Rdo只支援CentOS系列的作業系統。需要注意的是，該專案並不屬於OpenStack官方社群專案。

手動部署
手動部署all-in-one、multi-node、multi-HA-node環境。

其他

企業、團體方面

Puppet
Puppet由Ruby語言編寫。應當說，Puppet是進入OpenStack自動化部署中的早期一批專案，歷史還算悠久。目前，它的活躍開發群體們是Red hat、 Mirantis、UnitedStack等。

Red hat自從收購Ansible之後，如今仍然保持強勢勁頭在Puppet OpenStack專案中的Commit數量和質量，其技術實力不容小覷；Mirantis出品的Fuel部署工具中，大量的模組程式碼便使用的是Puppet。就國內而言，UnitedStack是Puppet社群貢獻和使用的最大使用者。

Ansible
Ansible是新近出現的自動化運維工具，已被Red Hat收購。基於Python開發，集合了眾多運維工具（puppet、cfengine、chef、saltstack等）的優點，實現了批量系統配置、批量程式部署、批量執行命令等功能，它一方面總結了Puppet的設計上的得失，另一方面也改進了很多設計。比如是基於SSH方式工作，故而不需要在被控端安裝客戶端。使得在和OpenStack結合上沒有歷史包袱，更加能夠輕裝上陣，未來發展潛力不容小覷號稱是“你一直尋找的下一代Iaas”的Zstack，使用到的部署工具也是基於Ansible。

Openstack-ansible專案，最早是由老牌Rackspace公司在Launchpad官網上註冊。
在最新的Ansible OpenStack專案社群Commit貢獻中，Rackspace也可謂是遙遙領先，而緊隨其後的是Red Hat、國內九州雲等公司。

SaltStack
SaltStack也是一款開源的自動化部署工具，基於Python開發，實現了批量系統配置、批量程式部署、批量執行命令等功能，和Ansible也是挺相近的。不同之一是，由於SaltStack的master和minion認證機制和工作方式，需要在被控端安裝minion客戶端，在加之其他原因，自然和Ansible相比，其優缺點便很明顯了。

需要注意的是，使用Saltstack部署OpenStack，並不屬於OpenStack社群專案。目前，主要還是處於使用者自研自用的階段。據筆者所知，目前國內的攜程應該是使用Saltstack部署OpenStack規模最大的使用者。

TripleO
Tripleo專案最早由HP於2013.4在launchpad上註冊BP。用於完成OpenStack的安裝與部署。TripleO全稱“OpenStack On OpenStack”，意思即為“雲上雲”，可以簡單理解為利用OpenStack來部署OpenStack，即首先基於V2P(和P2V相反，也就是指把虛擬機器的映象遷移到物理機上)的理念事先準備好一些OpenStack節點（計算、儲存、控制節點）的映象，然後利用已有openstack環境的裸機服務Ironic專案去部署裸機，軟體安裝部分的diskimage-builder，最後通過Heat專案和映象內的DevOps工具(Puppet Or Chef)再在裸機上配置執行openstack。

和其他部署工具不同的是，TripleO利用OpenStack本來的基礎設施來部署OpenStack，基於Nova、 Neutron、Ironic和Heat，來自動化部署和伸縮OpenStack叢集。

應當確切的說，TripleO專案屬於當前OpenStack社群主推的“Big Tent”開發模式下的big tent project（OpenStack下的專案分為三種，core project: nova/neutron等核心專案，big tent project: 非核心專案，但也被OpenStack 基金會接受；第三種就是其它專案，只是放在OpenStack下，但是社群還沒有接受）。

Kolla
在國內一些網際網路資料上，常看到關於kolla是TripleO專案的一部分這樣的描述，其實是不準確的。真實的是，Kolla專案起源於Tripleo專案，時至今日，與它沒有任何關係（雖然它們的目標都是做自動化部署，但走的道路卻不同）。比之於Tripleo和其他部署工具，Kolla走的是docker容器部署路線。

kolla專案起源於TripleO專案，聚焦於使用docker容器部署OpenStack服務。該專案由Cisco於2014年9月提出，是OpenStack的孵化專案。當前Kolla專案在Kollaglue repo提供了以下服務的docker映象。
# docker search kollaglue

Kolla的優勢和使用場景，體現在如下幾個方面：
原子性的升級或者回退OpenStack部署；
基於元件升級OpenStack；
基於元件回退OpenStack；

這裡，我們予以拆分來理解：

Kolla的最終目標是為OpenStack的每一個服務都建立一個對應的Docker Image，通過Docker Image將升級的粒度減小到Service級別，從而使升級時，對OpenStack影響能達到最小，並且一旦升級失敗，也很容易回滾。升級只需要三步：Pull新版本的容器映象，停止老版本的容器服務，然後啟動新版本容器。回滾也不需要重新安裝包了，直接啟動老版本容器服務就行，非常方便。

Kolla是通過Docker Compose來部署OpenStack叢集的，現在主要是針對裸機部署的，所以在部署Docker Container時，預設的網路配置都是Host模式。

首先，只需要通過一個命令就可以把管理節點部署完成，這個命令是呼叫Docker Compose來部署OpenStack的所有服務，然後我們可以在每一個計算節點上通過Docker Compose安裝計算節點需要的服務，就能部署一個OpenStack叢集。因為Kolla的Docker Image粒度很小，它針對每個OpenStack服務都有特定的Image，所以我們也可以通過Docker Run來操作某個具體的OpenStack服務。

目前，我所在的公司九州雲的一位同事近日獲得提名成為Kolla專案Core。為OpenStack社群中增添了一份來自於中國的力量。

Fuel
Fuel是針對OpenStack生產環境目標 （非開源）設計的一個端到端”一鍵部署“的工具，大量採用了Python、Ruby和JavaScript等語言。其功能含蓋自動的PXE方式的作業系統安裝，DHCP服務，Orchestration服務 和puppet 配置管理相關服務等，此外還有OpenStack關鍵業務健康檢查和log 實時檢視等非常好用的服務。

Fuel，這款讓很多人即愛且痛的工具，在國內外都很盛名。愛的原因是，它確實很棒；痛的原因是，要想徹底掌握它，可不是一件容易事（各個模組整合度高、使用技術複雜）。既然提到Fuel，自然不能不提它的父母——Mirantis。Mirantis是一家技術實力非常雄厚的OpenStack服務整合商，他是社群貢獻排名前5名中唯一一個靠OpenStack軟體和服務盈利的公司。同時，Fuel的版本節奏也很快，平均每半年就能提供一個相對穩定的社群版。

從和筆者接觸到的一些情況來看，國內研究、使用Fuel的個人、群體還是為數不少的。不少國內OpenStack初創公司的安裝包就是基於Fuel去修改的。

本文得到九州雲官方授權釋出，作者徐超，九州雲資訊科技有限公司OpenStack工程師。更多OpenStack乾貨文章請留意微信公眾賬號“九州雲99Cloud”

責編：魏偉，關注OpenStack，歡迎投稿，郵箱[email protected]