對於每個剛接觸到OpenStack的新人而言,安裝無疑是最困難的,同時這也客觀上提升了你們學習OpenStack雲計算的技術門檻。想想,本身3年前網上偶然接觸到OpenStack時,一頭茫然,手動搭建一個多節點環境時竟然用了3個星期。 時至今日,真是感觸頗多,從某種角度而言,也很慶幸當時本身並未因困難而放棄OpenStack,不然,應該是去作其餘領域了吧! 言歸正傳,我們就來數落數落部署OpenStack都有哪些方式吧。這裏,咱們根據使用者羣體的不一樣類型來進行分類和概括: 我的使用方面 DevStack 無疑,在可預見的將來時間內,DevStack仍將是衆多開發者們的首選安裝方式或工具。該方式主要是經過配置參數,執行shell腳本來安裝一個OpenStack的開發環境。 Github: https://github.com/openstack-dev/devstack Wiki: https://wiki.openstack.org/wiki/DevStack 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社區貢獻和使用的最大用戶。 Github: https://github.com/openstack/puppet-keystone Governance: Wiki: https://wiki.openstack.org/wiki/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、國內九州雲等公司。 Github:https://github.com/openstack/openstack-ansible SaltStack SaltStack 也是一款開源的自動化部署工具,基於Python開發,實現了批量系統配置、批量程序部署、批量運行命令等功能,和Ansible也是挺相近的。不一樣之一 是,因爲SaltStack的master和minion認證機制和工做方式,須要在被控端安裝minion客戶端,在加之其餘緣由,天然和 Ansible相比,其優缺點便很明顯了。 須要注意的是,使用Saltstack部署OpenStack,並不屬於OpenStack社區項目。目前,主要仍是處於用戶自研自用的階段。據筆者所知,目前國內的攜程應該是使用Saltstack部署OpenStack規模最大的用戶。 Saltstack部署OpenStack示例:https://github.com/luckpenguin/saltstack_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 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去修改的。