OpenStack部署都有哪些方式
大?。?/span>0.5 MB 人氣：0 2017-10-12 需要積分：1
對于每一個剛接觸到OpenStack的新人而言，安裝無疑是最困難的，同時這也客觀上提高了大家學習OpenStack云計算的技術門檻。想一想，自己3年前網上偶然接觸到OpenStack時，一頭茫然，手動搭建一個多節點環境時居然用了3個星期。
時至今日，真是感觸頗多，從某種角度而言，也很慶幸當時自己并未因困難而放棄OpenStack，否則，應該是去做其他領域了吧！
言歸正傳，咱們就來數落數落部署OpenStack都有哪些方式吧。這里，我們根據使用者群體的不同類型來進行分類和歸納：
個人使用方面
DevStack
無疑，在可預見的未來時間內，DevStack仍將是眾多開發者們的首選安裝方式或工具。該方式主要是通過配置參數，執行shell腳本來安裝一個OpenStack的開發環境。
Rdo
Rdo是由Red Hat開源的一款部署OpenStack的工具，同DevStack一樣，支持單節點和多節點部署。但Rdo只支持CentOS系列的操作系統。需要注意的是，該項目并不屬于OpenStack官方社區項目。
Docs：https://www.rdoproject.org/install/quickstart
手動部署
手動部署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下，但是社區還沒有接受）。
在該項目的社區Commit貢獻上，Red hat可謂是遙遙領先，而緊隨其后的是IBM等公司。
Wiki：https://wiki.openstack.org/wiki/TripleO Docs：http://docs.openstack.org/developer/tripleo-incubator Governance ：http://governance.openstack.org/reference/projects/tripleo.html
Kolla
在國內一些互聯網資料上，?？吹疥P于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新版本的容器鏡像，停止老版本的容器服務，然后啟動新版本容器?；貪L也不需要重新安裝包了，直接啟動老版本容器服務就行，非常方便。
Kolla是通過Docker Compose來部署OpenStack集群的，現在主要是針對裸機部署的，所以在部署Docker Container時，默認的網絡配置都是Host模式。
首先，只需要通過一個命令就可以把管理節點部署完成，這個命令是調用Docker Compose來部署OpenStack的所有服務，然后我們可以在每一個計算節點上通過Docker Compose安裝計算節點需要的服務，就能部署一個OpenStack集群。因為Kolla的Docker Image粒度很小，它針對每個OpenStack服務都有特定的Image，所以我們也可以通過Docker Run來操作某個具體的OpenStack服務。
目前，我所在的公司九州云的一位同事近日獲得提名成為Kolla項目Core。為OpenStack社區中增添了一份來自于中國的力量。
Governance：http://governance.openstack.org/reference/projects/kolla.html
Wiki：https://wiki.openstack.org/wiki/Kolla
Fuel
Fuel是針對OpenStack生產環境目標 （非開源）設計的一個端到端”一鍵部署“的工具，大量采用了Python、Ruby和Java等語言。其功能含蓋自動的PXE方式的操作系統安裝，DHCP服務，Orchestration服務 和puppet 配置管理相關服務等，此外還有OpenStack關鍵業務健康檢查和log 實時查看等非常好用的服務。
Fuel，這款讓很多人即愛且痛的工具，在國內外都很盛名。愛的原因是，它確實很棒；痛的原因是，要想徹底掌握它，可不是一件容易事（各個模塊集成度高、使用技術復雜）。既然提到Fuel，自然不能不提它的父母——Mirantis。Mirantis是一家技術實力非常雄厚的OpenStack服務集成商，他是社區貢獻排名前5名中唯一一個靠OpenStack軟件和服務盈利的公司。同時，Fuel的版本節奏也很快，平均每半年就能提供一個相對穩定的社區版。
從和筆者接觸到的一些情況來看，國內研究、使用Fuel的個人、群體還是為數不少的。不少國內OpenStack初創公司的安裝包就是基于Fuel去修改的。
?
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%
