Openstack 自動化部署puppet代碼管理

Openstack發展的很快,6個月就會release,每次release後不免升級到最新的版本。自動化部署是繞不開的一個問題。目前自動化部署使用的是puppet腳本,那麼什麼策略管理本地的自動化部署腳本一直困擾着我們。


我們的puppet代碼是從PuppetLabs的E版本開始的,當時只支持Ubantu,而且bug很多,我們在自己的分支上fix了很多bug。然而,社區發展Release很快,出了F版本以後,我們puppet代碼在自己的分支中實現了F版本的部署,在F版本的時候,我們還在自己的分支中支持了CentOS。後來剛做完,G版本出了,於是又開始對G版本進行自動化部署。期間還走了彎路,要在CentOS上支持python2.7(噩夢般的回憶... 重新打幾百個包)。 10月份社區又出了H版本,於是我們從12月底開始又要支持Havana的自動化部署。。。


其實自動化部署僅僅是很小的一部分,但是卻花費了我們很多精力。原因如下:
1. 在E,F版本時,puppetlabs的代碼存在很多bug,我們在本地修改後沒有合入upstream。
2. 我們自己修改的support CentOS,已經和社區越走越遠。

3. 我們支持CentOS時,RDO還發展不成熟,我們需要自己打RPM包。

4. 自己走了一些彎路。。。



自動化部署的代碼基本上可以分爲3部分:
#1. Openstack核心功能部分。
#2. DB和MQ集羣部署部分。
#3. 平臺監控,定製功能部分。


那麼每次release需要更新的部分主要在#1中。在升級H版本時,我們決定放棄我們維護的本地分支,使用PuppetLabs最新的代碼,並採取以下策略應對以後puppet升級問題:
1. 每次社區release新版本,3-6個月後,升級Openstack核心功能的自動化部署相關代碼。
2. 對於#2和#3部分自動化部署代碼,不做修改,僅進行功能測試。


使用這樣的策略,我們升級H版本的自動化部署代碼大約需要了1-1.5人月(不包含測試)。這樣的effort是可以接受的。當然我們是否真的需要升級Openstack版本,這是值得考慮的一個問題,對於私有云,我們其實並不需要最新的版本,只需要符合自己的需求就可以了。
在目前版本滿足需求的情況下,我們可以把更多的精力放在調優和穩定性優化上面。

發佈了64 篇原創文章 · 獲贊 9 · 訪問量 30萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章