|
原標(biāo)題：原來Zuul可以這樣簡化測試流程 OpenTelekomCloud是一個大型的歐洲OpenStack公有云。其子公司T-SystemsInternationalGmbH為德國電信集團提供服務(wù)。 OpenTelekomCloud架構(gòu)師ArtemGoncharov分享了OpenTelekomCloud為什么選擇Zuul，以及他們?nèi)绾螌⑵渑cGitHub和OpenStack一起使用。 Q：你的組織是怎么開始使用Zuuk的？ A：我們最開始使用Zuul開發(fā)OpenStack客戶端組件，如SDK、CLIs和其他內(nèi)部運維軟件組件。在設(shè)法將一些更改合并到Zuul中之后，我們將其高效地部署為我們的持續(xù)集成系統(tǒng)。現(xiàn)在，它是我們的CI系統(tǒng)，用于開發(fā)提供給客戶的所有開源工具。此外，Zuul目前用于監(jiān)控平臺服務(wù)質(zhì)量。為此，我們定期執(zhí)行一組測試。它還永久監(jiān)控我們的RefStack合規(guī)性。 我們?yōu)榘裐uul作為德國電信其他部門的內(nèi)部服務(wù)做準(zhǔn)備。我們在自己的公有云上運行Zuul，即OpenTelekomCloud，并在那里生成虛擬機。我們?nèi)际荗penStack！ Q：你們是如何使用Zuul的？ A：目前，我們有在與GitHub交互的公共域上工作的Zuul。盡管Gerrit的CI工作流非常強大，但我們注意到一些用戶困擾于其復(fù)雜性。因此，我們決定留在GitHub，讓更多的社區(qū)成員參與我們項目的開發(fā)。Nodepool為簡化OpenStack驅(qū)動程序的作業(yè)啟動虛擬機。 Q：你們現(xiàn)在的規(guī)模多大？ A：我們有一個五節(jié)點的zookeeper集群，每個節(jié)點有一個調(diào)度器、一個nodepool-builder和一個nodepool-launcher。目前兩個Zuul執(zhí)行器滿足了我們的需要。我們有大約10個項目由Zuul管理，但計劃很快增加到50個。我們平均每天生成50個build。 Q：你們從使用Zuul得到了什么好處？ A：我們在快速成長，項目在規(guī)模和復(fù)雜性上都有了清晰的布局，而且預(yù)計性會增加得很快。門控到位，確保所有的軟件始終都是經(jīng)過測試和一致的——這讓我們很放心，使我們能夠擴大所覆蓋的項目的數(shù)量。 其次，我們可以更好地控制構(gòu)建和測試過程在何處以及如何進行。我們正在測試真實的云場景，因此有實際云資源的憑據(jù)和訪問權(quán)限。通過Zuul和Nodepool，我們可以更好地控制這些虛擬機和存儲的數(shù)據(jù)。 最后，我們有一個相當(dāng)復(fù)雜的集成和部署工作流。我們構(gòu)建和打包的不僅僅是軟件，我們還創(chuàng)建其他工件，比如文檔、PyPI包，還有更多需要額外步驟的東西。我們喜歡使用Ansibleplaybook定義這些工作流所帶來的靈活性。 Q：挑戰(zhàn)是什么（你們是如何解決的）？ A：測試公有云的所有方面對我們來說都很重要。功能測試包括登錄域、創(chuàng)建資源和處理憑證的所有方面。由于這個安裝程序連接到GitHub，可以間接地供公眾訪問，因此我們對在執(zhí)行實際測試和構(gòu)建的同一平臺上運行Zuul安裝程序有點不安。因此，我們通過幾個專用的OpenStack域來隔離這些作用域，其中只有Zuul有API訪問權(quán)限。在最壞的情況下，如果憑據(jù)泄漏，我們只需清理并重置一個測試域，但Zuul基礎(chǔ)設(shè)施本身不受影響。為此，我們促進了OpenStackSDK的“項目清理”功能，我們也為此做出了貢獻。 我們還經(jīng)歷了refstack的功能測試或驗證，經(jīng)常會留下很多碎片——這些碎片沒有被代碼清理掉，有時甚至是因為OpenStack本身的API調(diào)用失敗。我們還利用“項目清理”來減輕這種行為。 Zuul還將日志文件中的許多信息發(fā)布到公共可讀的Swift容器中。我們的安全團隊對此表示不滿，即使大部分信息是無害的。在某些情況下，我們修補了Zuul或其作業(yè)，因此這些數(shù)據(jù)不會先累積。 出于運維和安全原因，我們希望盡可能地包含所有工作負(fù)載。Zuul配備了一組Docker容器。不幸的是，Nodepool-builder需要很多特權(quán)，這很難用普通的舊Docker實現(xiàn)。我們的方法是利用Podman作為替代方案。 Q：關(guān)于Zuul的未來計劃是什么？ A：Gerrit代碼審查系統(tǒng)實現(xiàn)了一個復(fù)雜的角色模型，它允許用戶進行代碼審查、升級修訂或授權(quán)最終合并。僅用GitHub實現(xiàn)這些訪問控制功能是一個大挑戰(zhàn)。作為暫時的解決方法，我們對拉取請求使用“/merge”注釋。 盡管Zuul的主要目的是實現(xiàn)自動化，但有時能夠手動干預(yù)也不錯。不幸的是，目前還沒有一個真正的UI來執(zhí)行管理任務(wù)，比如重新構(gòu)建一些工件。這將有助于遷移更多的Jenkins作業(yè)。 Zuul的運維很復(fù)雜，我們目前沒有一個專門的小組。我們通過實現(xiàn)Ansibleplaybooks來減少運維的工作量，但這是一項持續(xù)的工作。 我們致力于將Zuul轉(zhuǎn)變?yōu)槠渌聡娦抛庸竞晚椖康膬?nèi)部產(chǎn)品。我們也非常有興趣讓Kubernetes和OpenShift成為Zuul的運維平臺。這樣的挑戰(zhàn)來自于高可用性所需的多云問題。 Q：Zuul有沒有特別的功能吸引到你們？ A：Zuul推動了OpenStack的發(fā)展，這是一項了不起的工作，也是一個相當(dāng)大的責(zé)任。它的可伸縮性和靈活性給我們留下了深刻的印象，其架構(gòu)適應(yīng)了我們的內(nèi)部項目。相信還有更多的事情要做。 https://superuser.openstack.org/articles/zuul-a-t-systems-case-study/ |
- 關(guān)注天氣:
