OpenStack部署都有哪些方式

對於每個剛接觸到OpenStack的新人而言，安裝無疑是最困難的，同時這也客觀上提升了你們學習OpenStack雲計算的技術門檻。想想，本身3年前網上偶然接觸到OpenStack時，一頭茫然，手動搭建一個多節點環境時竟然用了3個星期。
時至今日，真是感觸頗多，從某種角度而言，也很慶幸當時本身並未因困難而放棄OpenStack，不然，應該是去作其餘領域了吧！
言歸正傳，我們就來數落數落部署OpenStack都有哪些方式吧。這裏，咱們根據使用者羣體的不一樣類型來進行分類和概括：

我的使用方面

DevStack
無疑，在可預見的將來時間內，DevStack仍將是衆多開發者們的首選安裝方式或工具。該方式主要是經過配置參數，執行shell腳原本安裝一個OpenStack的開發環境。
Github: 
Wiki: 

Rdo 
Rdo是由Red Hat開源的一款部署OpenStack的工具，同DevStack同樣，支持單節點和多節點部署。但Rdo只支持CentOS系列的操做系統。須要注意的是，該項目並不屬於OpenStack官方社區項目。
Docs：

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

其餘

企業、團體方面

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

2.Red
hat自從收購Ansible以後，現在仍然保持強勢勁頭在Puppet 
OpenStack項目中的Commit數量和質量，其技術實力不容小覷；Mirantis出品的Fuel部署工具中，大量的模塊代碼便使用的是
Puppet。就國內而言，UnitedStack是Puppet社區貢獻和使用的最大用戶。
Github：

Governance：
Wiki：


3.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、國內九州雲等公司。
Github：

4. SaltStack
SaltStack
也是一款開源的自動化部署工具，基於Python開發，實現了批量系統配置、批量程序部署、批量運行命令等功能，和Ansible也是挺相近的。不一樣之一
是，因爲SaltStack的master和minion認證機制和工做方式，須要在被控端安裝minion客戶端，在加之其餘緣由，天然和
Ansible相比，其優缺點便很明顯了。
須要注意的是，使用Saltstack部署OpenStack，並不屬於OpenStack社區項目。目前，主要仍是處於用戶自研自用的階段。據筆者所知，目前國內的攜程應該是使用Saltstack部署OpenStack規模最大的用戶。
Saltstack部署OpenStack示例：
Saltstack部署OpenStack模塊：

5.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下，可是社區尚未接受）。
在該項目的社區Commit貢獻上，Red hat可謂是遙遙領先，而緊隨其後的是IBM等公司。
Wiki：

6.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服務。

7.Fuel
Fuel 是針對OpenStack生產環境目標 
（非開源）設計的一個端到端」一鍵部署「的工具，大量採用了Python、Ruby和JavaScript等語言。其功能含蓋自動的PXE方式的操做系統
安裝，DHCP服務，Orchestration服務 和puppet 配置管理相關服務等，此外還有OpenStack關鍵業務健康檢查和log 
實時查看等很是好用的服務。
Fuel，這款讓不少人即愛且痛的工具，在國內外都很盛名。愛的緣由是，它確實很棒；痛的緣由是，要想完全掌握
它，可不是一件容易事（各個模塊集成度高、使用技術複雜）。既然提到Fuel，天然不能不提它的父母——Mirantis。Mirantis是一家技術實
力很是雄厚的OpenStack服務集成商，他是社區貢獻排名前5名中惟一一個靠OpenStack軟件和服務盈利的公司。同時，Fuel的版本節奏也很
快，平均每半年就能提供一個相對穩定的社區版。
從和筆者接觸到的一些狀況來看，國內研究、使用Fuel的我的、羣體仍是爲數很多的。很多國內OpenStack初創公司的安裝包就是基於Fuel去修改的。