OpenStack快速進(jìn)階教程

1、OpenStack快速進(jìn)階教程是當(dāng)下熾可熱的 IaaS 開源云計(jì)算項(xiàng)，使 OpenStack 可滿企業(yè)各種云服務(wù)需求，如私有云、混合云或公有云。通過本系列教程的學(xué)習(xí)，即使是個(gè)初云計(jì)算的業(yè)者也能迅速熟悉和掌握 OpenStack 的相關(guān)技術(shù)，提職業(yè)競(jìng)爭(zhēng)，成為名復(fù)合型才。本系列教程，分為四部分，共計(jì)15篇章。讀者可以從中汲取到完整的項(xiàng)經(jīng)驗(yàn)，從菜鳥到精通，這個(gè)達(dá)課幫您實(shí)現(xiàn)。第部分（1-4篇）：主要講解初學(xué)者如何參與 OpenStack 社區(qū)，進(jìn)有效的溝通交流，以及如何提交 Bug 和 Patch，快速提升個(gè)參與開源社區(qū)的能。第部分（5篇）：主要講解當(dāng)下主流的 OpenStack 產(chǎn)環(huán)境級(jí)的部署實(shí)施。

2、第三部分（6-14篇）：主要講解 OpenStack 全位，不同維度和層次的測(cè)試體系。涵蓋了性能測(cè)試、存儲(chǔ)測(cè)試、功能測(cè)試、單元測(cè)試以及Dashboard 動(dòng)化測(cè)試和開發(fā)動(dòng)化測(cè)試框架等內(nèi)容。第四部分（15篇）：主要講解如何使 Harbor 鏡像倉(cāng)庫(kù)管理 OpenStack Docker 鏡像等。徐超，某互聯(lián)公司任程師。技術(shù)出，三年多 OpenStack 運(yùn)維開發(fā)經(jīng)驗(yàn)，熟悉 Kubernetes、Docker、Ceph 存儲(chǔ)和 CI/CD。2017年初，出版OpenStack 最佳實(shí)踐測(cè)試與 CI/CD書。導(dǎo)讀：淺談 CI/CD和軟件測(cè)試知其然，知其所以然。相較于DevOps，CI/CD是個(gè)相對(duì)具

3、象的概念。在 IT 企業(yè)中，CI/CD的應(yīng)愈加泛，成為推動(dòng)軟件研發(fā)活動(dòng)的重要基礎(chǔ)設(shè)施服務(wù)，同時(shí)推動(dòng) DevOps 模式的實(shí)際落地。 在實(shí)踐 CI/CD 相關(guān)內(nèi)容之前，我們有必要先認(rèn)識(shí)下什么是 CI/CD。般傳統(tǒng)或者狹義、普遍的 CI/CD，是指持續(xù)集成（Continuous Integration，CI）和持續(xù)交付（Continuous Delivery，CD）。更加義、全的理解，是指持續(xù)集成（Continuous Integration，CI）、持續(xù)測(cè)試（Continuous Testing，CT）、持續(xù)交付（ContinuousDelivery，CD）和持續(xù)部署（Continuous De

4、ployment，CD）四個(gè)。通常，個(gè)軟件開發(fā)的流線如下圖所。Design：這階段完成軟件開發(fā)的需求分析和設(shè)計(jì)。Develop：這階段完成軟件開發(fā)的功能代碼，個(gè)最佳實(shí)踐是采測(cè)試驅(qū)動(dòng)開發(fā)（TDD）的法，測(cè)試代碼和功能代碼的編寫同時(shí)進(jìn)。需要注意的是，在 Develop 階段也會(huì)運(yùn)單元測(cè)試和其他型測(cè)試。Test：這階段完成軟件的各項(xiàng)型或?qū)ｍ?xiàng)測(cè)試，如界測(cè)試、API測(cè)試、性能測(cè)試和系統(tǒng)測(cè)試等。Release：這階段完成軟件產(chǎn)品的發(fā)布，并交付給戶使。 ）隨著敏捷開發(fā)的發(fā)展，持續(xù)集成在軟件項(xiàng)活動(dòng)中也益成為主流。顧名思義，持續(xù)集成是指每頻繁地（如天多次）將代碼集成到主分中。強(qiáng)調(diào)通過集成和測(cè)試的速度，快速給出個(gè)

5、集成的結(jié)果（是失敗還是成功），在代碼集成之前，必須先通過動(dòng)化測(cè)試驗(yàn)證，只要有個(gè)測(cè)試?yán)?，就不能集成。Martin Fowler 說過，“持續(xù)集成并不能消除Bug，是讓它們常容易被發(fā)現(xiàn)和改正”。這也正是持續(xù)集成的真諦所在。敏捷開發(fā)的核是指整個(gè)軟件開發(fā)活動(dòng)被劃分成系列短的迭代過程，每個(gè)迭代完成定數(shù)量的功能，迭代周期應(yīng)該盡量短。在軟件開發(fā)需求已經(jīng)確定的情況下，迭代應(yīng)該由測(cè)試驅(qū)動(dòng)開發(fā)（TDD）和集成反饋來驅(qū)動(dòng)。只有這樣，才能為質(zhì)量持續(xù)改進(jìn)奠定個(gè)良好的基礎(chǔ)。持續(xù)集成是和單元測(cè)試結(jié)合在起的，也就意味著，持續(xù)集成和單元測(cè)試需要并作。持續(xù)集成般由代碼每次 git push/review 觸發(fā)。先簽代碼就先看

6、到構(gòu)建結(jié)果，后簽，則要排在后。這就要求構(gòu)建時(shí)間不能太長(zhǎng)，否則在構(gòu)建時(shí)容易引起混亂，很難知道是誰的代碼破壞了集成，導(dǎo)致很難定位問題?？梢哉f，持續(xù)集成是敏捷開發(fā)的重要基礎(chǔ)環(huán)節(jié)，沒有持續(xù)集成，所謂的敏捷開發(fā)便失去了賴以存的壤，其實(shí)施效果也會(huì)打折扣。持續(xù)集成是種軟件開發(fā)實(shí)踐，團(tuán)隊(duì)成員頻繁集成他們開發(fā)的代碼，每次集成都會(huì)經(jīng)過動(dòng)構(gòu)建動(dòng)測(cè)試的驗(yàn)證，以盡快發(fā)現(xiàn)集成錯(cuò)誤。使這種法可以顯著減少集成引起的問題，并加快團(tuán)隊(duì)合作開發(fā)軟件的速度。（1）持續(xù)集成過程持續(xù)集成的作階段較明確，主要有三個(gè)的階段：持續(xù)集成準(zhǔn)備階段、持續(xù)集成使階段和持續(xù)集成測(cè)試階段。持續(xù)集成準(zhǔn)備階段的作主要包括：通過代碼評(píng)審系統(tǒng)（如 Gerrit）

7、，實(shí)現(xiàn)代碼審查和集成反饋。通過版本控制系統(tǒng)（如 Git或 GitLab）建源碼倉(cāng)庫(kù)。通過構(gòu)建具運(yùn)相關(guān)構(gòu)建和測(cè)試（如 Python 項(xiàng)的 Tox 和 Pytest）。通過 CI系統(tǒng)（如 Jenkins）建 Job，將版本控制和構(gòu)建具整合，并設(shè)置構(gòu)建觸發(fā)條件。持續(xù)集成使階段的作主要包括：開發(fā)員向代碼評(píng)審系統(tǒng)（如 Gerrit）提交代碼。通過 CI系統(tǒng)監(jiān)聽代碼的提交，運(yùn)單元測(cè)試，反饋集成結(jié)果。通過構(gòu)建具對(duì)代碼進(jìn)編譯、打包和部署。通過版本控制具實(shí)現(xiàn)版本控制與管理。持續(xù)集成測(cè)試階段的作主要是，CI系統(tǒng)根據(jù)集成結(jié)果進(jìn)不同操作，如果成功，則將代碼合并到主分；如果失敗，則反饋給開發(fā)員修改重新提交。從中我們可以

8、看到，持續(xù)集成涉及的主要具類別包括：版本控制具實(shí)現(xiàn)源代碼管理、版本控制。構(gòu)建具實(shí)現(xiàn)代碼的動(dòng)化編譯、打包等，這是持續(xù)集成的核具。測(cè)試具實(shí)現(xiàn)代碼的動(dòng)化測(cè)試，以及型測(cè)試或?qū)ｍ?xiàng)測(cè)試。CI系統(tǒng)整合版本控制、構(gòu)建作和測(cè)試作，實(shí)現(xiàn)持續(xù)集成。（2）持續(xù)集成的好處主要有以下點(diǎn)：易于定位錯(cuò)誤。如當(dāng)持續(xù)集成失敗時(shí)，說明新提交的代碼引起了錯(cuò)誤，這樣也很容易知道是誰犯了錯(cuò)誤，可以找誰來討論。提團(tuán)隊(duì)的開發(fā)信。雖然整個(gè)系統(tǒng)還不是那么可，但少可以看到功能已經(jīng)在點(diǎn)點(diǎn)被集成了。提對(duì)進(jìn)度的控制和把握。這點(diǎn)常明顯，如果每天都在集成，當(dāng)然每天都可以看到哪些功能可以使，哪些功能還沒有實(shí)現(xiàn)。如果你是開發(fā)員，則不為在每 Scrum 晨會(huì)時(shí)說

9、完成了多少開發(fā)煩惱；如果你是 Scrum Master，那么也不再煩惱開發(fā)員說完成了代碼的40%到底是個(gè)什么概念。有助于代碼開發(fā)的質(zhì)量評(píng)估。如從開發(fā)質(zhì)量的評(píng)估圖表中，找出經(jīng)常出錯(cuò)的測(cè)試和源碼等。與測(cè)試具結(jié)合，做到每次提交都進(jìn)測(cè)試?？焖侔l(fā)現(xiàn)錯(cuò)誤。每完成點(diǎn)開發(fā)，就提交評(píng)測(cè)、代碼審查，可以快速發(fā)現(xiàn)錯(cuò)誤，及時(shí)修復(fù)，越盡早解決，成本越低。 ）持續(xù)測(cè)試作為軟件持續(xù)集成中的重要組成部分，為軟件項(xiàng)的成功提供了保證軟件質(zhì)量持續(xù)改進(jìn)的重要段。在持續(xù)集成中，更多的是運(yùn)型的單元測(cè)試，因此，關(guān)于其他測(cè)試將在后續(xù)章節(jié)中闡述。持續(xù)測(cè)試是指開發(fā)員提交代碼后動(dòng)運(yùn)相關(guān)單元測(cè)試，給出測(cè)試結(jié)果的反饋；如果失敗，則會(huì)在測(cè)試結(jié)果的詳情頁(yè)

10、中輸出錯(cuò)誤提。有了持續(xù)測(cè)試，我們才能實(shí)現(xiàn)真正的測(cè)試驅(qū)動(dòng)開發(fā)（TDD）。舉個(gè)例，當(dāng)開發(fā)員向代碼評(píng)審系統(tǒng)提交了代碼后，Jenkins hooks 監(jiān)聽到有代碼提交，動(dòng)運(yùn)單元測(cè)試，然后在頁(yè)視圖上顯測(cè)試的結(jié)果；如果測(cè)試失敗，開發(fā)員需要重新修改并再次提交測(cè)試，直成功。這也需要開發(fā)員在編寫功能代碼時(shí)，同時(shí)編寫測(cè)試代碼，這樣乎能夠在問題產(chǎn)之時(shí)就將其發(fā)現(xiàn)。不經(jīng)常運(yùn)測(cè)試通常就不怎么有效，因?yàn)閺漠a(chǎn)缺陷到發(fā)現(xiàn)該缺陷相隔時(shí)間很長(zhǎng)，但持續(xù)地（即每次代碼改變時(shí)）運(yùn)測(cè)試能確保快速地發(fā)現(xiàn)癥結(jié)。持續(xù)測(cè)試應(yīng)當(dāng)輸出測(cè)試報(bào)告，報(bào)告是將持續(xù)集成的運(yùn)情況以適當(dāng)?shù)男问秸宫F(xiàn)給相關(guān)員的基本式。報(bào)告是持續(xù)集成的晴表，所以它必須直觀、易懂，如開發(fā)

11、員從錯(cuò)誤志中找到代碼出錯(cuò)的位置和原因；QA 測(cè)試員發(fā)現(xiàn)測(cè)試的覆蓋率和執(zhí)情況；管理員從持續(xù)集成通過率的趨勢(shì)中了解到項(xiàng)的進(jìn)度和質(zhì)量。 ）持續(xù)交付和持續(xù)部署是兩個(gè)常容易混淆的概念。持續(xù)交付指的是頻繁地將軟件的新版本交付給 QA 測(cè)試團(tuán)隊(duì)或者運(yùn)營(yíng)團(tuán)隊(duì)，如果評(píng)審?fù)ㄟ^，代碼就進(jìn)發(fā)布、產(chǎn)階段。為了更加符合國(guó)內(nèi)軟件業(yè)的實(shí)際情況，我在這將 QA 和測(cè)試統(tǒng)稱為“QA 測(cè)試”。持續(xù)交付可以看作是持續(xù)集成、持續(xù)測(cè)試的延續(xù)，它強(qiáng)調(diào)的是不管怎么更新，軟件是隨時(shí)隨地可以交付的。通過嚴(yán)格的動(dòng)化測(cè)試，可以確保軟件開發(fā)的質(zhì)量和進(jìn)度。因?yàn)橥ㄟ^完全的動(dòng)化過程把每個(gè)變更動(dòng)提交到測(cè)試環(huán)境中，所以當(dāng)功能開發(fā)完成時(shí)，就有信只需要點(diǎn)擊次按鈕就

12、能保證發(fā)布和部署應(yīng)的質(zhì)量。（1）選擇持續(xù)交付具集在沒有制定出作流程時(shí)，便考慮選擇持續(xù)交付具集，是最不重要的決策。實(shí)際上，在設(shè)計(jì)好作流程和業(yè)務(wù)流程之后再選擇相匹配的具集即可。考慮到滿實(shí)際業(yè)務(wù)和作流程的情況，開發(fā)些諸如 Shell、Python 等腳本程序是常理性的做法。更重要的是，論是 CI還是 CT、CD 等，都可以使眾多的開源具，這樣做沒有被鎖定的風(fēng)險(xiǎn)，可以由切換等。（2）持續(xù)交付的和式產(chǎn)品持續(xù)交付的應(yīng)由 QA 測(cè)試員來?yè)?dān)任，開發(fā)員也需要參與到產(chǎn)品的某輪系統(tǒng)測(cè)試中，并隨時(shí)準(zhǔn)備 Bug 審查和 Bug 修復(fù)。最后，由 QA 測(cè)試員根據(jù)具體的產(chǎn)品缺陷、質(zhì)量情況等做出產(chǎn)品是否適合向戶交付、發(fā)布的決

13、定。持續(xù)交付的標(biāo)不是要消滅缺陷，是要規(guī)范開發(fā)和測(cè)試的流程，從根源上提軟件質(zhì)量?？傊掷m(xù)集成、持續(xù)測(cè)試、持續(xù)交付和持續(xù)部署的核就是讓不間斷的“密集型、強(qiáng)度、信息及時(shí)反饋的持續(xù)性改進(jìn)”成為提軟件產(chǎn)品質(zhì)量的驅(qū)動(dòng)。前，持續(xù)交付的式般有：源代碼交付需要將源代碼下載到所需要的環(huán)境中，如 Python 的 py、Java 的 java等程序件。但這些件都不是標(biāo)準(zhǔn)的軟件包，不利于集中管理和運(yùn)。Linux 標(biāo)準(zhǔn)包交付通過 Linux deb 或者 RPM 對(duì)項(xiàng)的依賴進(jìn)管理。這種式相對(duì)更加規(guī)范和科學(xué)，但仍然需要解決包沖突問題。同時(shí)，這種式會(huì)經(jīng)常因服務(wù)器環(huán)境差異、構(gòu)建環(huán)境初始化失敗等問題導(dǎo)致法部署 Linux 標(biāo)

14、準(zhǔn)包。虛擬機(jī)鏡像交付在虛擬機(jī)中安裝測(cè)試軟件產(chǎn)品成功后，直接將該虛擬機(jī)鏡像（如VMware 的 vmdk、VirtualBox 的 ova、OpenStack 的 qcow2 等鏡像）進(jìn)交付、發(fā)布。顯然，這種式部署成功率接近100%，且隔離性好。但存在著虛擬機(jī)鏡像對(duì)服務(wù)器資源的消耗，同時(shí)容量較、不夠靈活等問題。Docker 鏡像交付這種式是對(duì)虛擬機(jī)鏡像交付的重改進(jìn)，在保證系統(tǒng)隔離的同時(shí)，Docker鏡像對(duì)服務(wù)器的資源消耗更低、更加輕量。這種交付式將成為主流趨勢(shì)。 ）持續(xù)部署是持續(xù)交付的后續(xù)階段，也是整個(gè)CI/CD環(huán)節(jié)中的最后環(huán)，指的是軟件通過測(cè)試后動(dòng)部署到產(chǎn)環(huán)境中。持續(xù)部署的標(biāo)是軟件在任何時(shí)刻都

15、是可部署的，可進(jìn)產(chǎn)階段，發(fā)布給戶使。持續(xù)部署的前提是能夠動(dòng)化完成集成、測(cè)試和交付等。它與持續(xù)交付的區(qū)別是，持續(xù)交付是將軟件部署到線上環(huán)境中，使的是動(dòng)式；持續(xù)部署強(qiáng)調(diào)的是動(dòng)化。換之，持續(xù)部署是持續(xù)交付的更階段，所有通過了測(cè)試驗(yàn)證的軟件都動(dòng)部署到產(chǎn)環(huán)境中。如果沒有制度的約束或其他條件的影響，團(tuán)隊(duì)都應(yīng)該以持續(xù)部署為標(biāo)，如下圖所。DevOps是種程化、理論集，是個(gè)抽象的概念；其范疇下的 CI/CD 則是它的具體實(shí)現(xiàn)和法，是種化抽象為形象的具集、流程圖。如果說 DevOps 是云計(jì)算，那么 CI/CD 就是計(jì)算、存儲(chǔ)和絡(luò)，OpenStack 則是其具體實(shí)現(xiàn)平臺(tái)。軟件項(xiàng)的研發(fā)有兩難題：是確定軟件的需求，即

16、確定標(biāo)；是確定當(dāng)前離標(biāo)還有多遠(yuǎn)，即確定剩余的作量。后者是項(xiàng)缺少可見性的問題。前者是持續(xù)性反饋的問題。如來戶需求的反饋、市場(chǎng)變化的反饋、項(xiàng)研發(fā)測(cè)試過程的反饋等。動(dòng)化是軟件研發(fā)測(cè)試中的重要式。持續(xù)集成最的優(yōu)點(diǎn)就是降低風(fēng)險(xiǎn)，提項(xiàng)研發(fā)過程的效率和質(zhì)量，迎合互聯(lián)時(shí)代信息快速更新的規(guī)律。持續(xù)集成本并不能幫助開發(fā)程師和 QA 程師解決Bug，是通過不斷的測(cè)試和反饋來盡早地發(fā)現(xiàn) Bug，問題發(fā)現(xiàn)得越早，處理問題的成本就越，也越容易解決。由于法證明通過了某次測(cè)試的代碼永遠(yuǎn)缺陷，因此，持續(xù)集成中的測(cè)試也就顯得常重要，好的測(cè)試能夠更多、更快地發(fā)現(xiàn)當(dāng)前版本中的錯(cuò)誤。根據(jù)持續(xù)集成的作業(yè)流，代碼從提交到產(chǎn)環(huán)境，整個(gè)過程分

17、為以下步。Commit）開發(fā)者向代碼倉(cāng)庫(kù)提交代碼。所有后的步驟都始于本地代碼的次提交。 整個(gè) CI系統(tǒng)配置了代碼倉(cāng)庫(kù)系統(tǒng)、Jenkins 系統(tǒng)和代碼評(píng)審系統(tǒng)的觸發(fā)器，只要提交代碼就會(huì)運(yùn)動(dòng)化測(cè)試。般這的測(cè)試有如下種。單元測(cè)試：針對(duì)函數(shù)或模塊的測(cè)試。集成測(cè)試：針對(duì)整個(gè)軟件的功能測(cè)試。代碼風(fēng)格測(cè)試：針對(duì)代碼的編寫風(fēng)格進(jìn)測(cè)試，如 Python 的 PEP 8 等。其他測(cè)試。）通過第1輪測(cè)試后，代碼就可以合并進(jìn)主分，推送到私有代碼倉(cāng)庫(kù) GitLab 系統(tǒng)中，進(jìn)下階段的構(gòu)建了。從開發(fā)員提交本地代碼，到測(cè)試通過，代碼合并到分，提交就算完成了。此時(shí)，就需要進(jìn)構(gòu)建進(jìn)第2輪測(cè)試。所謂構(gòu)建，指的是將源碼轉(zhuǎn)換為可以運(yùn)

18、的 Linux 標(biāo)準(zhǔn)軟件包，如安裝依賴、成配置件等，當(dāng)然也可以構(gòu)建成 Docker 鏡像。 構(gòu)建完成后，就要進(jìn)第2輪或多輪測(cè)試?？傊?，構(gòu)建部署在測(cè)試之前。此階段的測(cè)試最全，投資源最多，包括系統(tǒng)測(cè)試、功能/集成測(cè)試、性能測(cè)試等都會(huì)運(yùn)。需要強(qiáng)調(diào)的是，每個(gè)更新點(diǎn)都必須測(cè)試到。如果測(cè)試的覆蓋率不，進(jìn)后的部署和產(chǎn)階段后，很可能會(huì)出現(xiàn)嚴(yán)重的問題。通過多輪測(cè)試后，當(dāng)前代碼就是個(gè)可以直接部署的穩(wěn)定版本。將這個(gè)版本的所有件打包存檔（如 Fuel 的 iso，或其他研產(chǎn)品的iso、vmdk 乃 Docker 鏡像等），發(fā)布到成品庫(kù)服務(wù)器上。這的動(dòng)化部署具有 Ansible、Chef、Puppet 等。旦當(dāng)前軟件版

19、本發(fā)問題，就要回滾到上次構(gòu)建的版本，使上次構(gòu)建并發(fā)布的版本。CI/CD 很好地解決了代碼從動(dòng)化編譯打包、動(dòng)化構(gòu)建部署、動(dòng)化測(cè)試到快速交付產(chǎn)品4個(gè)階段。為此，需要做到：軟件包盡量輕。為了保證代碼在編譯、打包、構(gòu)建等階段做到快速、輕量，應(yīng)盡可能實(shí)現(xiàn)軟件的模塊化處理。典型的，如將OpenStack 的各個(gè)服務(wù)分別放在不同的 Docker 鏡像中。重視管理教育。在公司中，個(gè)團(tuán)隊(duì)/部門的程師素質(zhì)是良莠不齊的，不能讓少數(shù)影響到群、個(gè)整體，僅靠覺是完全不夠的，需要指導(dǎo)團(tuán)隊(duì)養(yǎng)成做事的好習(xí)慣。個(gè)常見的問題就是開發(fā)員不寫單元測(cè)試代碼，影響到整個(gè)軟件研發(fā)測(cè)試的質(zhì)量和周期。構(gòu)建作主要產(chǎn)出兩個(gè)東西：待測(cè)的軟件包和應(yīng)系統(tǒng)

20、（有的只有后者）。這兩個(gè)產(chǎn)出物有所不同，前者是構(gòu)建過程與環(huán)境關(guān)，且可重復(fù)，因此需要提供如 yum、npm、gem 等軟件包服務(wù)，讓構(gòu)建號(hào)和軟件包號(hào)建關(guān)聯(lián)，便于回溯。通過 IaaS 云或 Docker 容器將 CI/CD 環(huán)境以微服務(wù)的式運(yùn)，做到開箱即。CI/CD是軟件程的個(gè)重要實(shí)踐，可以幫助我們更早地發(fā)現(xiàn)問題、解決問題，降低成本，同時(shí)減少交付、發(fā)布過程中的不確定性，提團(tuán)隊(duì)的產(chǎn)效率。當(dāng)然，CI/CD 與其他具和法也緊密相關(guān)。每構(gòu)建（Daily Build）在反應(yīng)速度上沒有持續(xù)集成快，它更強(qiáng)調(diào)的是通過每天（通常是晚上）動(dòng)部署當(dāng)天開發(fā)所累積的代碼，并結(jié)合每測(cè)試（Daily Test）法進(jìn)動(dòng)化測(cè)試，于

21、評(píng)估和衡量項(xiàng)的進(jìn)度。持續(xù)集成特性決定了不可能在該階段加量的測(cè)試，每構(gòu)建則般是在夜執(zhí)的，那么這時(shí)就可以做更多的事情，如代碼質(zhì)量檢查、單元測(cè)試、測(cè)試覆蓋率、集成測(cè)試等。每構(gòu)建會(huì)把當(dāng)天所有的提交代碼都起做集成，不像持續(xù)集成那樣每提交次代碼就做次集成。持續(xù)集成屬于增量式構(gòu)建，每構(gòu)建則是次完全構(gòu)建。每構(gòu)建是項(xiàng)的跳線。般，通過每構(gòu)建我們可以看到項(xiàng)的進(jìn)度。如今天有10個(gè) Bug 的修復(fù)代碼都提交了，晚上進(jìn)動(dòng)部署并通過了動(dòng)化測(cè)試，第天上班時(shí)通過查看郵件我們就可以發(fā)現(xiàn)每構(gòu)建成功了，那么項(xiàng)就往前邁了步，開發(fā)作有了具體的進(jìn)展。具體的，每構(gòu)建就是在每天晚上動(dòng)化部署個(gè) OpenStack 環(huán)境（可以是all-in-on

22、e，也可以是 multi-node），然后運(yùn)型或?qū)ｍ?xiàng)測(cè)試，如 API性能測(cè)試、API接測(cè)試、功能測(cè)試、部署測(cè)試等。第01課：如何貢獻(xiàn) OpenStack社區(qū)OpenStack社區(qū)貢獻(xiàn)內(nèi)容包括但不限于：代碼 Review（審查）。代碼 Commit（提交）。社區(qū)檔翻譯、編寫和修改。創(chuàng)建 Blueprints。其他。 在開始貢獻(xiàn)之前，我們先來看看 OpenStack 的代碼審查的體流程，如下圖所。從 OpenStack 本地代碼提交到合并的流程主要如下：1. 開發(fā)員配置本地 Git 環(huán)境。2. 開發(fā)員克隆標(biāo)項(xiàng)的代碼并進(jìn)更改。3. 開發(fā)員提交本地代碼到遠(yuǎn)端 Gerrit。4. OpenStack 使

23、 Gerrit 作為代碼評(píng)審系統(tǒng)，使 Jenkins 系統(tǒng)對(duì)代碼進(jìn)動(dòng)化部署和測(cè)試，并反饋測(cè)試結(jié)果。5. 由核評(píng)審員給出意見，決定是否合并此次提交的代碼。基本步驟如下：1. 創(chuàng)建個(gè) Launchpad 賬號(hào)（Gerrit 使 Launchpad 賬號(hào)進(jìn)認(rèn)證登錄）。2. 登錄 Gerrit，完成其他配置。3. 簽署貢獻(xiàn)者許可協(xié)議。4. 安裝本地 Git 環(huán)境。說明：般情況下，只有當(dāng)修復(fù)某個(gè)代碼/檔 Bug 或發(fā)現(xiàn)有 Bug 時(shí)，才需要在Launchpad 上提交 Bug 信息。 注冊(cè)成功后，登錄 Launchpad，輸想要提交的 Bug 所屬的 OpenStack 項(xiàng)名稱。如這的 openstac

24、k-manual（OpenStack 檔項(xiàng)），如下圖所。在圖中，可以看到與該項(xiàng)相關(guān)的 Bug、Blueprints 和項(xiàng)概述信息等內(nèi)容。點(diǎn)擊“Reporta bug”，提交個(gè) Bug，如下圖所。緊接著，需要簡(jiǎn)要描述下該 Bug 的些關(guān)鍵信息，如下圖所。填寫相應(yīng)的Bug信息，如下圖所。如果想要修復(fù)這個(gè) Bug，可以將它指定給，如下圖所。注意這個(gè) Bug id 號(hào)，屆時(shí)向 OpenStack 社區(qū)提交代碼時(shí)需要。如此，這就是創(chuàng)建 Launchpad賬號(hào)和提交 Bug 的流程。如果想要修復(fù)這個(gè) Bug，那么繼續(xù)往下操作。配置賬號(hào)和提交代碼 Gerrit配置 Gerrit 公鑰認(rèn)證，將 SSH 的 P

25、ublic Key 粘貼到此處，如下圖所。簽署 ICLA 協(xié)議，如下圖所。在國(guó)內(nèi)絡(luò)的背景下，想要向社區(qū)代碼評(píng)審系統(tǒng)提交代碼，需要點(diǎn)技巧（VPN 戶可以忽略此步驟）。先需要登錄，然后在 Settings - HTTP Password 中成個(gè) HTTP 密碼，它應(yīng)該是個(gè)寫字母加數(shù)字的隨機(jī)字符串。創(chuàng)建個(gè) HTTP 協(xié)議的戶名和密碼，如下圖所。此時(shí)，賬號(hào)已經(jīng)創(chuàng)建和配置好，下即可提交修改后的代碼了。/cloneBug#git clone /openstack/openstack-manuals / bug/bug id# git checkout -b bug/1575714Switched to a

26、 new bra如果需要對(duì)之前提交的內(nèi)容再次進(jìn)修改（針對(duì)同個(gè) change-id），則執(zhí)如下命令。# git add .# git commit -amend# git review向社區(qū)提交代碼/檔，需要通過該項(xiàng)兩個(gè) Core（核開發(fā)者）的+2評(píng)分，才會(huì)被合并到GitHub 代碼倉(cāng)庫(kù)中，代表此次提交成功。反之，如果有給出-1、-2的評(píng)分或 Jenkins 測(cè)試提失敗等，那么你需要針對(duì)具體的問題修改提交的內(nèi)容，然后再次提交，如下圖所。 OpenStack 第02課：如何參與 OpenStack社區(qū)交流要想?yún)⑴c OpenStack 社區(qū)溝通交流，般最常的式是使 E-mail 和 IRC（Inte

27、rnet Relay Chat，互聯(lián)中繼聊天，理解為國(guó)內(nèi)的QQ 即可）。需要注意的是，由于中國(guó)時(shí)區(qū)和北美、歐洲時(shí)區(qū)存在10個(gè)時(shí)以上的差異，使 IRC 實(shí)時(shí)聊天具可能存在溝通障礙問題。下闡述如何通過這兩種式進(jìn)溝通交流。openstack，該郵件列表 OpenStack 社區(qū)通，般尋求幫助或者發(fā)布信息都可以通過該郵件列表溝通。openstack-announce，該郵件列表專門于接收 OpenStack 發(fā)布團(tuán)隊(duì)和 openstack 安全團(tuán)隊(duì)重要通告消息，如有關(guān) OpenStack 的發(fā)布，以及 OpenStack 解決了哪些安全漏洞等信息。openstack-operators，該郵件列表是為

28、 OpenStack 運(yùn)維員的討論話題建的個(gè)平臺(tái)，各公司運(yùn)維員可以在該郵件列表中交流關(guān)于 OpenStack 安裝、部署、運(yùn)維等的內(nèi)容。openstack-dev，該郵件列表是為 OpenStack 開發(fā)者交流技術(shù)設(shè)的，對(duì)開發(fā)者相當(dāng)重要。由于 OpenStack 項(xiàng)眾多，為了防郵件泛濫，通常在發(fā)送郵件時(shí)會(huì)在標(biāo)題上加上項(xiàng)名稱作為前綴來進(jìn)區(qū)別。如“nova”，表這個(gè)郵件內(nèi)容是與 Nova 相關(guān)的，如此來，開發(fā)者便可以更有針對(duì)性地閱讀郵件。openstack-qa，該郵件列表是專門為 QA 測(cè)試員討論測(cè)試?yán)O(shè)計(jì)、測(cè)試配置以及測(cè)試項(xiàng)、CI/CD 等技術(shù)交流設(shè)的。openstack-zh，這是個(gè)專門的中

29、郵件列表。于如何訂閱郵件，可以在 OpenStack Mailing List 頁(yè)中單擊 Subscribe 鏈接，或者直接單擊 OpenStack Dev Subscribe，如下圖所。在 OpenStack Dev Subscribe 頁(yè)中輸接收郵件的郵箱地址和名字（可選），即可訂閱成功。如，要想在 openstack-dev 郵件中提問題，只需要編輯郵件發(fā)送到 openstack-dev 郵箱即可，接下來需要做的就是等待別回答你的問題，并給予積極的回應(yīng)。 IRC（Internet Relay Chat）是種實(shí)時(shí)聊天具。由于使郵件法做到與社區(qū)實(shí)時(shí)互動(dòng)，所以郵件更適合拋出個(gè)問題或想法，系統(tǒng)性

30、地闡述觀點(diǎn)，并不需要即得到他的幫助、建議和回復(fù)等場(chǎng)景。IRC頻道和項(xiàng)例會(huì)固然很好，但它們也有局限性，需要考慮到他因各種原因未在線的問題，還有時(shí)區(qū)問題，所以郵件可以起到個(gè)很好的彌補(bǔ)作。IRC 具種類繁多，既有 PC 端也有移動(dòng)端的具。下是些常且開源的 IRC 具。PC 客戶端具：Hexchat Free (Windows XP/Vista/7/8) (Linux)（推薦）Colloquy Free (Mac OS X 10.7)XChat Aqua/Azure (OS X 10-10.6)XChat Linux FreeIrssi Free (Linux, FreeBSD, Microsoft

31、Windows, Mac OS X)KVirc Free (Linux, Unix, Mac OS,Windows)Chatzilla Free (Firefox 3.5-20)移動(dòng)客戶端具：IRChon Free (iOS)（兼容iPod touch, iPad。需要iOS 2.2.1及以上版本）AndChat Free (Android)YAAIC Free (Android (beta)AndroIRC Free (Android)OpenStack IRCOpenStack 的 IRC 會(huì)議都有 Log 記錄，可以通過 IRC 來了解項(xiàng)的進(jìn)展。如果你沒有實(shí)時(shí)參與其中的討論，那么可以有空

32、時(shí)去查閱相關(guān)的記錄。/wiki/IRC/wiki/UsingIRC/wiki/Meetings/irclogs/openstack-infra/irc-meetings/meetings/OpenStack 社區(qū)使的 IRC 服務(wù)器地址是 ，端是6665和6666。除了以上提到的，使 E-mail 和 IRC 式和 OpenStack 社區(qū)交流之外，還可以參加諸如 Meetup 等會(huì)議。第03課：深理解 OpenStack社區(qū) CI/CD在介紹 OpenStack 社區(qū) CI/CD 平臺(tái)之前，有必要先直觀認(rèn)識(shí)下社區(qū)常運(yùn)營(yíng)的作量，這將有助于我們理解為什么社區(qū)要建設(shè)如此豐富、復(fù)雜的基礎(chǔ)設(shè)施服務(wù)。社

33、區(qū) CI規(guī)模500 Git 項(xiàng)倉(cāng)庫(kù)數(shù)5000 Jenkins Job 項(xiàng)任務(wù)數(shù)10 Jenkins Master 節(jié)點(diǎn)數(shù)1000 Jenkins Slave 節(jié)點(diǎn)數(shù)24000 每天執(zhí)的任務(wù)數(shù)5000 社區(qū)開發(fā)者數(shù)1000 虛擬機(jī)運(yùn)數(shù)量社區(qū) CI挑戰(zhàn)項(xiàng)多、Git 倉(cāng)庫(kù)多、分多（master、stable）。有各種項(xiàng)相關(guān)的 Job 任務(wù)。任務(wù)配置煩（多種后端、多種云環(huán)境、多個(gè)部署節(jié)點(diǎn)等）。CIPipeline（流線）復(fù)雜且繁多（如檢查、測(cè)試、發(fā)布和周期任務(wù)等）。針對(duì)所臨的規(guī)模和挑戰(zhàn)，OpenStack 社區(qū)構(gòu)筑了套完善的 CI/CD 平臺(tái)，被統(tǒng)稱為OpenStack Infra（OpenStack

34、 基礎(chǔ)設(shè)施平臺(tái)）。OpenStack 基礎(chǔ)設(shè)施平臺(tái)主要包括：Storyboard任務(wù)跟蹤系統(tǒng)，于管理那些彼此之間緊密聯(lián)系的系統(tǒng)。在 OpenStack這種內(nèi)部關(guān)系緊密的系統(tǒng)中，個(gè)功能或個(gè)Bug 都會(huì)少影響兩個(gè)項(xiàng)，所以這樣的問題需要在項(xiàng)間統(tǒng)跟蹤。Gerrit代碼評(píng)審系統(tǒng)，包括 Git 等系統(tǒng)。Zuul運(yùn) Jenkins 任務(wù)的組織系統(tǒng)（通過測(cè)試系統(tǒng)與代碼評(píng)審系統(tǒng)結(jié)合，反饋提交的代碼集成測(cè)試狀況等），包括觸發(fā)構(gòu)建等系統(tǒng)。Jenkins持續(xù)集成系統(tǒng)，包括 Jenkins 任務(wù)執(zhí)節(jié)點(diǎn)、Gearman 服務(wù)等系統(tǒng)。GitHub代碼倉(cāng)庫(kù)管理系統(tǒng)。DevStack個(gè)從源碼庫(kù)安裝 OpenStack 環(huán)境的具

35、。Nodepool負(fù)責(zé)管理 OpenStack 云平臺(tái)上虛擬機(jī)的命周期，構(gòu)建 VM 資源池以供DevStack 安裝使。ELK（Elasticsearch、Logstash 和 Kibana）社區(qū)志管理系統(tǒng)。Launchpad于跟蹤 OpenStack 相關(guān)事項(xiàng)的系統(tǒng)，包括 Bugs、Releases、Blueprints等系統(tǒng)。IRC社區(qū)開發(fā)員在線交流具。其中 Zuul、Jenkins-job-builder、Gearman Plugin、DevStack、Nodepool等都是由 OpenStack 基礎(chǔ)設(shè)施服務(wù)團(tuán)隊(duì)開發(fā)維護(hù)的。社區(qū) CI/CD 系統(tǒng)運(yùn)作流程如下圖所。這簡(jiǎn)要梳理下當(dāng)社區(qū)開發(fā)

36、員向代碼評(píng)審系統(tǒng)提交代碼之后，代碼會(huì)經(jīng)過哪些環(huán)節(jié)，系統(tǒng)會(huì)執(zhí)哪些任務(wù)，才會(huì)最終被合并到 GitHub 代碼倉(cāng)庫(kù)系統(tǒng)中。整體流程如下圖所。先是 PEP 8 代碼風(fēng)格測(cè)試。因?yàn)樯鐓^(qū)開發(fā)者數(shù)眾多，所以保證代碼風(fēng)格統(tǒng)是常重要的，需要確保家都使同樣的編碼式和風(fēng)格等。然后是單元測(cè)試。僅僅測(cè)試被變更的項(xiàng)，不考慮跟其他模塊交互的情況。社區(qū)會(huì)針對(duì)不同的平臺(tái)和軟件版本進(jìn)測(cè)試，包括 Python2.x 和 3.x，在不同操作系統(tǒng)上運(yùn)不同的軟件版本。最后是集成測(cè)試。社區(qū)在由 HP、Rackspace 等提供的 IaaS 云虛擬機(jī)上，使 DevStack安裝所有的組件，然后在這個(gè)單節(jié)點(diǎn)（all-in-one 環(huán)境）上運(yùn)不

37、同的模板。不同的模板對(duì)不同的模塊進(jìn)不同的配置，如使不同的數(shù)據(jù)庫(kù)、不同的消息隊(duì)列、不同的存儲(chǔ)類型，不過基本上只測(cè)試那些常的如 MySQL、PostgreSQL、RabbitMQ 等，當(dāng)然社區(qū)也在考慮引 ZeroMQ 的測(cè)試。集成測(cè)試所使的 VM 般配置為8GB內(nèi)存，系統(tǒng)是 Ubuntu ，然后讓 DevStack 在該VM 上安裝 OpenStack。Nodepool來管理VM，通過緩存來預(yù)備這些機(jī)器。同時(shí)將 DevStack 所需要的依賴軟件包等都預(yù)先下載到本地，這樣測(cè)試本就可以離線運(yùn)了。測(cè)試執(zhí)完之后，再銷毀這些 VM。實(shí)際創(chuàng)建的 VM 數(shù)量要運(yùn)成功的測(cè)試數(shù)量多，因?yàn)?Zuul的隨機(jī)機(jī)制，有時(shí)

38、候當(dāng)測(cè)試跑到半時(shí)才發(fā)現(xiàn)還需要些其他東西，于是測(cè)試執(zhí)不下去了，此時(shí)會(huì)刪除該 VM，啟動(dòng)個(gè)新的。致的例是，如果天跑10000個(gè)任務(wù)，那么啟動(dòng)的 VM 數(shù)量差不多在100000量級(jí)，即1:10的例。疑，社區(qū)在測(cè)試做出了嚴(yán)格的限制，即只有寫好了單元測(cè)試的代碼變更提交才能夠被接受。對(duì)于社區(qū)，未經(jīng)測(cè)試的變更就是有問題的和有風(fēng)險(xiǎn)的。因?yàn)楝F(xiàn)在 OpenStack 項(xiàng)發(fā)展很快，不斷催出新的組件，個(gè)錯(cuò)誤就可能會(huì)影響整個(gè)系統(tǒng)的運(yùn)。為了解決這些問題，社區(qū)使了 Test Repository 框架，讓多數(shù)單元測(cè)試在這個(gè)框架中可以并處理，并快速反饋測(cè)試結(jié)果。社區(qū) QA團(tuán)隊(duì)開發(fā)的 Zuul系統(tǒng)，可以并測(cè)試系列提交的代碼，同

39、時(shí)保持它們的測(cè)試順序不變。OpenStack Infra資料請(qǐng)參考。 ）OpenStack 社區(qū)使開源的 Jenkins 系統(tǒng)來負(fù)責(zé)持續(xù)集成。在應(yīng)中，Jenkins 使 Zuul和 Gearman 進(jìn)管理。其具體的任務(wù)配置管理，使 Jenkins-job-builder 基于 YAML 件格式來定義 Job 內(nèi)容，采命令創(chuàng)建和管理 Jenkins Job，Job 件采 Git 版本控制具進(jìn)管理。OpenStack 的使式為：使 YAML 件編寫 Job 內(nèi)容。使 Gerrit 管理 Job 定義的創(chuàng)建和變更。使 Jenkins-job-builder 定義創(chuàng)建多個(gè) Job。使 Puppet 推

40、送 Jenkins-job-builder 進(jìn)部署、更新 Jenkins 的 Job。PipelinePipeline 的字意思就是流線，是很好的個(gè) Jenkins 插件，將很多步驟按順序排列好，結(jié)束個(gè)后執(zhí)下個(gè)。在真實(shí)的作環(huán)境中有很多 Job，如先編譯，然后執(zhí)代碼靜態(tài)檢查、單元測(cè)試，最后部署服務(wù)、重啟服務(wù)、進(jìn) UI測(cè)試等。我們需要對(duì)這些 Job 進(jìn)些設(shè)置，將它們的上下游關(guān)系配置好。Pipeline 提供了圖形界，可以在界上形象地看到整個(gè)構(gòu)建任務(wù)的執(zhí)流程和完成度。例如下。Job模板：- job-template: name: gate-name-docs builders:- shell: gi

41、t checkout branch_nameJenkins-job-builder項(xiàng)定義：- project: name: project-name branch_name: new_branch jobs:- gate-name-docsJob分組管理：- job-group: name: name-tests jobs:- name-unit-tests- name-perf-testsJob定義：- job: name: foo-test project-type: freestyle builders:- make-test publishers:- archive可以在 Job 件中

42、增加模塊，如 Builder、Publisher 等，使宏（即批量處理，就是將些命令組織在起，作為個(gè)單獨(dú)命令完成某個(gè)特定任務(wù)）來定義 Jenkins 需要執(zhí)的任務(wù)。- builder: name: make-test builders: - shell: make test Jenkins-job-builderJenkins-job-builder（簡(jiǎn)稱 JJB）是來創(chuàng)建 Jenkins 任務(wù)的具。為了簡(jiǎn)化配置量 Jenkins任務(wù)的作量，OpenStack 采更容易閱讀的基于 YAML 或 JSON 格式的件來編輯任務(wù)，然后使 JJB 將 YAML 或 JSON 格式的配置轉(zhuǎn)化為可以被 J

43、enkins 理解的 XML格式的任務(wù)配置件，并更新到 Jenkins 中。實(shí)際上，Jenkins創(chuàng)建的任務(wù)是以 XML 件的格式保存在$JENKINS_HOME/jobs/ job-name/config.xml 中的，JJB 能夠?qū)?YAML 轉(zhuǎn)化為 XML 件（借助 Jenkins 提供的命令接），并更新到 Jenkins 中。這，以測(cè)試配置、更新任務(wù)以及刪除任務(wù)為例，闡述Jenkins-job-builder法的使。（1）先，安裝Jenkins-job-builder。# pip install jenkins-job-builder（2）測(cè)試配置任務(wù)。當(dāng)任務(wù)配置的 YAML 件編寫完

44、成之后，可以通過“jenkins-jobs test”測(cè)試配置格式和內(nèi)容是否正確。# jenkins-jobs test path/to/myjob.yaml若測(cè)試通過，將輸出 XML 格式的任務(wù)配置；如果想將測(cè)試的 XML 格式的任務(wù)配置輸出到件，則可以添加“-o”參數(shù)。# jenkins-jobs test -o output path/to/myjob.yamlJJB 將在與 myjob.yaml 相同的錄下新建個(gè)名為“output”的件夾，并在其內(nèi)創(chuàng)建個(gè) YAML 中定義的任務(wù)名命名的件，就是XML 格式的任務(wù)配置件。（3）更新任務(wù)。測(cè)試通過后，可以使“jenkins-jobs upd

45、ate”命令將 YAML 件定義的任務(wù)更新到 Jenkins中。# jenkins-jobs -conf jenkins_jobs.ini update path/to/job1.yamlUpdate 命令需要指定保存有 Jenkins 服務(wù)器信息的配置件，“-conf”來顯式指定該配置件，如果不顯式指定，則默認(rèn)讀取“/etc/jenkinsjobs/jenkinsjobs.ini”件。該配置件保存有 Jenkins 的 URL 和登錄信息，內(nèi)容如下：jenkins user=jenkins password=password url=http:/localhost:8081/jenkins從

46、 JJB 可以將任務(wù)更新到 ini 配置件指定的Jenkins系統(tǒng)中。路徑也可以是錄，那么就是更新指定錄下所有的YAML、YML和JSON件，多個(gè)路徑冒號(hào)隔開。（4）刪除任務(wù)。刪除任務(wù)使如下命令：# jenkins-jobs -conf jenkins_jobs.ini delete job1其中 job1 為任務(wù)名稱。 在 OpenStack 環(huán)境中，可以在 project-config:jenkins/jobs/ 錄下找到 YAML 腳本件。在該錄下有4種配置件。（1）defaults.yaml 件該件為全局默認(rèn)配置件，是所有 Jenkins 任務(wù)的全局屬性定義，即 name 為“glob

47、al”的屬性，如默認(rèn)的描述、任務(wù)是并執(zhí)的、任務(wù)超時(shí)時(shí)間為30分鐘等。（2）macros.yaml件該件保存了所有的宏定義，包括些較通的 builders 或 publishers，供各任務(wù)調(diào)，如下所。- builder:name: git-prepbuilders:- shell: /slave_scripts/git-prep.sh - publisher:name: console-logpublishe（3）.yaml 件該件為各個(gè)項(xiàng)的配置腳本，任務(wù)和任務(wù)模板定義在各個(gè)項(xiàng)的腳本件中。每個(gè)項(xiàng)都有個(gè)以項(xiàng)名命名的.yaml件，的內(nèi)容基本就是“-job:”和“- job-template:”，還

48、有“- job-groups:”。（4）projects.yaml件該件包含了所有項(xiàng)的 Job 配置，即所有項(xiàng)均集中配置在 projects.yaml 件中，各個(gè)項(xiàng)以字母順序排列，各項(xiàng)的 job 屬性來于任務(wù)和任務(wù)模板的定義。針對(duì) Jenkins-job-builder 的單獨(dú)介紹，請(qǐng)?jiān)L問。 ）Gearman 是個(gè)分布式隊(duì)列系統(tǒng)，負(fù)責(zé)將合適的任務(wù)分發(fā)到多臺(tái)機(jī)器上，以便快速分解完成型任務(wù)。Gearman 架構(gòu)意圖如下圖所。Gearman通常由三部分組成，即 Client、Worker 和 Job Server（任務(wù)服務(wù)器）。由 Worker執(zhí) Client 發(fā)來的 Job，再通過 JobServ

49、er 返回給 Client。Gearman 提供了 Client、Worker 的 API，利這些 API與 Job Server 通信。Gearman 接收到來 Jenkins 的分發(fā)任務(wù)后，將 Job 發(fā)送到具體的作節(jié)點(diǎn)上。Gearman和 Jenkins 系統(tǒng)集成意圖如下圖所。流程如下：先，Jenkins Master 節(jié)點(diǎn)通過 Gearman Plugin 和 Gearman Server 系統(tǒng)建交互。其次，Zuul系統(tǒng)將構(gòu)建請(qǐng)求提交到 Gearman Server 系統(tǒng)。最后，Gearman 系統(tǒng)再將 Job 任務(wù)分發(fā)到 Jenkins Slave 作節(jié)點(diǎn)上執(zhí)。 ）簡(jiǎn)單，Zuul是個(gè)

50、向多項(xiàng)配置與動(dòng)化檢測(cè)代碼測(cè)試是否通過的系統(tǒng)。它同時(shí)與Gerrit、Jenkins 進(jìn)消息通信，使layout.yaml 件進(jìn)靈活配置，適合多種項(xiàng)的動(dòng)化操作，可以并執(zhí)系列變更的測(cè)試。Zuul有兩個(gè)主要組件分別為 scheduler 和 merger。Zuul保證合并進(jìn)源代碼庫(kù)的代碼變更都是通過測(cè)試的。如通過監(jiān)測(cè) Gerrit 的事件以觸發(fā)相應(yīng)的 Pipeline 及其對(duì)應(yīng)的 Job，從代碼的提交，到社區(qū)員評(píng)審的 -1/+1、-2/+2 等事件流觸發(fā)相應(yīng)操作。如下是社區(qū)的 OpenStack Nova 計(jì)算項(xiàng)的個(gè) Zuul配置件。projects: - name: OpenStack/nova c

51、heck:- gate-nova-pep8- gate-nova-docs- gate-nova-Python27- gate-Tempest-devstack-vm-full gate:這有個(gè)特性是預(yù)測(cè)執(zhí)，即預(yù)測(cè)并提前執(zhí)可能需要的任務(wù)，以便加速整個(gè)處理過程。這個(gè)特性在 Pipeline 中得到了泛使，以提整體效率。如 Nodepool會(huì)預(yù)先在 OpenStack 云環(huán)境中創(chuàng)建好相應(yīng)的虛擬機(jī)；DevStack 會(huì)事先將相應(yīng)的依賴包和其他項(xiàng)源碼下載下來，以便快速安裝單節(jié)點(diǎn)的 OpenStack 測(cè)試環(huán)境。個(gè) Check Pipeline 件內(nèi)容如下：pipelines: - name: chec

52、k manager: IndependentPiplelineManager precedence: low trigger:Gerrit:- event: patchset-created success:Gerrit:個(gè) Gate Pipeline 件內(nèi)容如下：pipelines: - name: name manager: DependentPiplelineManager precedence: high trigger:Gerrit:- event: comment-addedapproval:個(gè) Zuul任務(wù)隊(duì)列的件內(nèi)容如下：projects: - name: OpenStack/

53、nova gate:- gate-nova-Python27- gate-Tempest-devstack-vm - name: OpenStack/glance gate:- gate-glance 在回答該問題之前，我們需要先認(rèn)識(shí)下 OpenStack 代碼的提交與合并過程。先，開發(fā)員克隆相關(guān)的 OpenStack 項(xiàng)（如 Keystone、Nova 等），做了代碼（也包括 rst 檔）修改后，使 git 命令提交到代碼評(píng)審系統(tǒng)中。然后，Jenkins 做動(dòng)化測(cè)試。Jenkins 可能會(huì)運(yùn)個(gè)或多個(gè)作任務(wù)來執(zhí)不同類型的測(cè)試，以驗(yàn)證這些提交的 Patch（補(bǔ)丁）是否安全、正確。這些作便被稱為“

54、Gate Job”。這 Gate 可以被形象地理解為“看門”。社區(qū)開發(fā)員提交的 Patch 是否得到批準(zhǔn)，是根據(jù) Jenkins Gate Job 執(zhí)的測(cè)試結(jié)果來確定的。然后基于測(cè)試結(jié)果，將 -1/+1 的投票反饋到代碼評(píng)審系統(tǒng)（Gerrit）中。在這，我們可以找到 OpenStack 每個(gè)項(xiàng)的 Gate Job 配置件，這些配置件均采YAML 件格式編寫。這是。 如果想知道向社區(qū)提交代碼后，Jenkins 會(huì)執(zhí)哪些任務(wù)，個(gè)直接的辦法是在 Gerrit 系統(tǒng)中查看。還有個(gè)辦法則是查看項(xiàng)的配置件：project-config/zuul/layout.yaml。通過，可以找到 OpenStack

55、項(xiàng)的模板件內(nèi)容。 先需要選擇哪些項(xiàng)屬于這個(gè) Job。在 projects.yaml 件中可以看到所有項(xiàng)的 Job。點(diǎn)擊獲得鏈接地址：。如將個(gè)名稱為“abregman-new-job”的 Job 添加到“devstack-jobs”項(xiàng)下。jobs:- gate-Tempest-dsvm-namejob-suffix:pipeline: gatename: abregman-new-jobnode: devstack-centos7job-suffix: 件中的“node:devstack-centos7”于告訴 Jenkins 在哪些節(jié)點(diǎn)上運(yùn)任務(wù)。devstack-centos7只是個(gè)節(jié)點(diǎn)的標(biāo)簽

56、。所以，當(dāng)Job 運(yùn)時(shí)，它將尋找標(biāo)簽為“devstack-centos7”的節(jié)點(diǎn)。假設(shè)每次提交 Patch 時(shí)，都要運(yùn)“openstack-dev/devstack”這個(gè) Job，則可以這樣編寫：- name: openstack-dev/devstack gate: - gate-Tempest-abregman-new-job現(xiàn)在，我們添加了個(gè) Job（gate-Tempest-abregman-new-job）到“openstack-dev/devstack”項(xiàng)中，并在 Gate Pipeline Job下。這樣，當(dāng)上述代碼內(nèi)容提交并合并后，就可以提交 Patch 到 openstack

57、-dev/devstack 項(xiàng)中，來觀察它們的 Job 是如何運(yùn)的。個(gè)全局的社區(qū) ZuulJob 運(yùn)狀態(tài)如下圖所。 ）社區(qū)采了開源的 Gerrit 系統(tǒng)于代碼評(píng)審，以及細(xì)粒度的開發(fā)者權(quán)限控制等。第三系統(tǒng)與 Gerrit 的集成主要通過 Webhooks、event-stream、REST API等式交互。通常，Gerrit評(píng)審系統(tǒng)上的代碼有如下種狀態(tài)。代碼已提交，正等待審核。代碼處于 Jenkins 的動(dòng)化測(cè)試驗(yàn)證階段。代碼處于審核階段。代碼處于接受認(rèn)可階段。代碼被合并。相應(yīng)地，Gerrit 的觸發(fā)類型有如下種。合并代碼同步復(fù)制到GitHub倉(cāng)庫(kù)。修改合并。添加評(píng)論（處于評(píng)審狀態(tài)時(shí)）。引更新（包括分、標(biāo)簽等）。 與 通常將 Gerrit 評(píng)論頁(yè)中顯的 Jenkins Job 執(zhí)結(jié)果和耗時(shí)時(shí)間，作為代碼評(píng)審的依據(jù)。還有個(gè) Gerrit 的輔助配置具 Jeepyb，它是個(gè)幫