OpenStack快速進階教程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

30、地闡述觀點，并不需要即得到他的幫助、建議和回復(fù)等場景。IRC頻道和項例會固然很好，但它們也有局限性，需要考慮到他因各種原因未在線的問題，還有時區(qū)問題，所以郵件可以起到個很好的彌補作。IRC 具種類繁多，既有 PC 端也有移動端的具。下是些常且開源的 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)移動客戶端具：IRChon Free (iOS)（兼容iPod touch, iPad。需要iOS 2.2.1及以上版本）AndChat Free (Android)YAAIC Free (Android (beta)AndroIRC Free (Android)OpenStack IRCOpenStack 的 IRC 會議都有 Log 記錄，可以通過 IRC 來了解項的進展。如果你沒有實時參與其中的討論，那么可以有空

32、時去查閱相關(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 等會議。第03課：深理解 OpenStack社區(qū) CI/CD在介紹 OpenStack 社區(qū) CI/CD 平臺之前，有必要先直觀認識下社區(qū)常運營的作量，這將有助于我們理解為什么社區(qū)要建設(shè)如此豐富、復(fù)雜的基礎(chǔ)設(shè)施服務(wù)。社

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

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

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

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

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

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

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

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

41、t checkout branch_nameJenkins-job-builder項定義：- 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 等，使宏（即批量處理，就是將些命令組織在起，作為個單獨命令完成某個特定任務(wù)）來定義 Jenkins 需要執(zhí)的任務(wù)。- builder: name: make-test builders: - shell: make test Jenkins-job-builderJenkins-job-builder（簡稱 JJB）是來創(chuàng)建 Jenkins 任務(wù)的具。為了簡化配置量 Jenkins任務(wù)的作量，OpenStack 采更容易閱讀的基于 YAML 或 JSON 格式的件來編輯任務(wù)，然后使 JJB 將 YAML 或 JSON 格式的配置轉(zhuǎn)化為可以被 J

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

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

45、ate”命令將 YAML 件定義的任務(wù)更新到 Jenkins中。# jenkins-jobs -conf jenkins_jobs.ini update path/to/job1.yamlUpdate 命令需要指定保存有 Jenkins 服務(wù)器信息的配置件，“-conf”來顯式指定該配置件，如果不顯式指定，則默認讀取“/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件，多個路徑冒號隔開。（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 件該件為全局默認配置件，是所有 Jenkins 任務(wù)的全局屬性定義，即 name 為“glob

47、al”的屬性，如默認的描述、任務(wù)是并執(zhí)的、任務(wù)超時時間為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 件該件為各個項的配置腳本，任務(wù)和任務(wù)模板定義在各個項的腳本件中。每個項都有個以項名命名的.yaml件，的內(nèi)容基本就是“-job:”和“- job-template:”，還

48、有“- job-groups:”。（4）projects.yaml件該件包含了所有項的 Job 配置，即所有項均集中配置在 projects.yaml 件中，各個項以字母順序排列，各項的 job 屬性來于任務(wù)和任務(wù)模板的定義。針對 Jenkins-job-builder 的單獨介紹，請訪問。 ）Gearman 是個分布式隊列系統(tǒng)，負責將合適的任務(wù)分發(fā)到多臺機器上，以便快速分解完成型任務(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é)點上。Gearman和 Jenkins 系統(tǒng)集成意圖如下圖所。流程如下：先，Jenkins Master 節(jié)點通過 Gearman Plugin 和 Gearman Server 系統(tǒng)建交互。其次，Zuul系統(tǒng)將構(gòu)建請求提交到 Gearman Server 系統(tǒng)。最后，Gearman 系統(tǒng)再將 Job 任務(wù)分發(fā)到 Jenkins Slave 作節(jié)點上執(zhí)。 ）簡單，Zuul是個

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

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

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

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

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

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

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

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