發展中磚的Runbot CI的解決方案

Runbot持續集成(CI)是一個定製的解決方案專為磚的需求開發的。最初在2019年,開發Runbot逐步取代了詹金斯老化的基礎設施性能、可伸縮的和用戶友好的服務的使用者和維護者。這篇文章將探討背後的動機發展Runbot,走進它的核心設計決策,以及如何用它來大大提高組織內部Databircks工程經驗的開發人員。

背景:為什麼Runbot ?

詹金斯問題

傳統上,磚使用詹金斯作為主要組件的CI管道驗證拉請求(PRs)在合並之前的主人。詹金斯是一種廣泛使用的軟件進行戰鬥,,磚好多年。隨著時間的推移我們已經建立了一些輔助服務和基礎設施周邊:

然而,隨著時間的推移,詹金斯的弱點越來越明顯。盡管我們盡了最大努力穩定和改善用戶體驗,我們麵臨著不斷抱怨詹金斯基礎設施內部調查:

“測試基礎設施經常被打破。”

“詹金斯錯誤消息不是。”

“詹金斯測試結果很難探索“

“我猜,每周或每兩周我要調整我的工作流程或優先級與基礎設施建設要解決一個問題。”

詹金斯是成為我們開發團隊不斷的眼中釘。新人繼續旅行在同一已知特性是不固定的。資深開發人員繼續浪費時間,效率低下的工作流。我們的團隊傾向於CI係統本身需要花時間響應中斷,防守問題由於糟糕的用戶體驗,或管理慢性片狀測試工具不足等問題。

為什麼我們不能修複它?

盡管許多多年來試圖改進它,這種情況一直沒有太大的變化。數周甚至數月的工作嚐試,如我們的測試基礎設施更好地集成Github檢查界麵,或更好地管理資源使用的詹金斯的主人,已經證明成功。整個過程仍然笨拙和不穩定,越來越明顯,更多的精力消耗以同樣的方式總是有相同的結果。工作在詹金斯的局限性與輔助服務和集成不再是足夠的,我們需要嚐試不一樣的東西,如果我們想要提供一個顯著改善的經驗使用磚CI公司周圍。

詹金斯的問題與我們的基礎設施在很大程度上可以歸結為兩個主要問題:

1. 詹金斯的基礎設施是複雜和困難的工作。microservices、開源軟件(OSS)和定製,JVM和Python, kubernetes raw-EC2。這使得任何改進一個緩慢的過程,時間爭吵服務和ETL而不是我們想要的麵向用戶的功能。
2. 詹金斯是操作上很難控製。詹金斯服務器長時間運行的穩定性,可用性和複雜性問題,我們沒有設法解決或緩解,及其基本架構使它似乎不太可能我們會設法解決令我們滿意

我將依次討論每個。

複雜性預防改善

多年來,我們已經實現了許多常見的CI功能作為一個獨立的服務專業磚的具體需求:

1. 我們的自動定量服務代表工作實例池、自動定量池job-balancing上下延遲和成本
2. 定製JJB /巴澤爾配置管道配置通過config-as-code詹金斯,我們盡量避免“手動”通過web UI配置工作
3. 我們自己的Github事件消費者服務處理編製工作引發的基於拉請求詳細信息:文件改變了,標簽,作者、業主等。
4. 一個定製的Github web鉤、動作隊列和Github接收機處理與Github的集成服務
5. 測試資源管理器服務提供有用的Web ui視圖和切割測試結果,探討破損或片狀

雖然詹金斯本身提供了許多的這些特性,我們經常發現我們自己的需求或特定需求,詹金斯及其插件沒有滿足。我們會喜歡沒有建立和維護這些東西,但我們不得不采取行動的需要團隊和組織。

這個龐大的複雜性使得增量改善困難,諸如:

1. 新的視圖來幫助管理我們的核心工作和保持我們的主分支綠色。例如,儀表板顯示多個作業的曆史,幫助我們區分局部片狀,單個作業破損,整個係統的破壞的基礎設施或被測試的代碼。
2. 最新的測試結果在測試資源管理器服務。這樣做不能由於異步ETL需要從詹金斯中提取數據。這意味著我們有一個用戶界麵查看測試結果很醜,但目前,和一個曆史視圖漂亮但延遲;在一起,沒有單一的UI開發人員可以瀏覽看到測試結果良好的開發經驗。
3. 看到這些工人是運行在一個特定的工作。這是非常有用的:有時候一個工人(我們重複使用性能)進入一個糟糕的狀態,導致分散片狀失敗,困惑,直到你注意到他們都在相同的節點上。有時你需要SSH到工人調試一個特別棘手的問題,隻有出現在CI和需要知道去哪一個。

一般來說,如果你想做一個小改變磚的CI的經驗,沒有一個“東西”的地方。詹金斯的源代碼是外部和非平凡的為我們的需求修改,和所有的各種服務我們轉了一個好的平台來實現通用CI-related特性。Beplay体育安卓版本數據、用戶界麵和業務邏輯被分散在集群microservices和web的他們之間的集成。

現在,這些問題沒有不可逾越的,例如multi-job-history儀表板,我們最終打開多個瀏覽器在我們辦公室牆上的指示板,定位他們煞費苦心地並排,然後打開每一個不同的詹金斯工作:

離開幾個小時/天,詹金斯的“藍色海洋”界麵有時會神秘地停止更新,我們安裝了一個自動刷新瀏覽器chrome插件在一個時間間隔。甚至有時詹金斯的“藍海”web UI會降低整個OSX操作係統(!)如果開太久太多選項卡(n > 4)迫使我們控製運行儀表板的mac mini !它工作,但是它不能工作好吧。

改善這種經曆與我們目前的服務架構非常困難。

除了我們自己的群microservices,詹金斯本身是一個擴張的功能。與多個HTML ui,多個配置子係統,無盡的插件,都與自己的缺陷和不直觀的方式進行交互。雖然這是所有預期從一個項目越來越多的十年半,這肯定對那些試圖征收稅收理解如何相互配合。

考慮上麵所示的multi-browser詹金斯儀表板。假設我們想要添加一個工具提示顯示每個作業運行多久之前被排隊是一個工人嗎?或者想象我們要提交列在Github回到提交頁麵的鏈接。簡單描述,但可怕的實現:我們叉詹金斯的修補其藍海UI ?編寫一個Chrome插件,我們要求每個人都要安裝?寫一個單獨的web服務,它將詹金斯的數據通過其API來呈現為HTML ?所有的這些都是糟糕的選擇對一個剛想添加一個提示或鏈接!

多年來我們已經多次試圖改善CI開發者體驗,隻有邊際成功。本質上,試圖增加麵向用戶的功能我們的CI係統陷入ETL數據管道,microservice基礎設施部署和其他細節,矮的實際業務邏輯功能要實現。

架構和操作穩定性

除了難以前進,現有的體係結構問題對我們是想管理服務操作。特別是,詹金斯是一個操作性頭痛,導致頻繁的中斷和不穩定,由於它的一些基本性質:

1. 一個有狀態的“大師”的過程,協調工作節點的一個或多個池
2. 主存儲狀態內存或者磁盤上的一個文件夾樹的XML文件
3. 每個工人不斷通過SSH連接到主連接

這種架構有以下後果:

1. 是不可能有多個主節點,或者超過一個主過程中,由於內存的狀態
2. 主節點CPU /內存/磁盤/過程非常重,管理其內存和磁盤上的XML數據存儲狀態
3. 單一主停機導致所有正在進行的工作失敗

這些後果引起我們定期疼痛:

1. 我們的主在最好的情況下是150 + gb的內存為了工作,偶爾和這個數字將上升高到足以把整個過程停頓下來
2. 每次詹金斯主需要重啟,所有正在進行的工作運行失敗,導致頻繁的不便我們開發人員試圖測試他們的代碼。
3. 我們不能輕易地自旋向上複製品詹金斯大師分享負載,並接近限製亞馬遜網絡服務(AWS)實例垂直規模大小我們的單詹金斯的主人
4. 我們不能升級詹金斯不會造成停機時間和給我們的用戶帶來不便

在實驗中,我們發現詹金斯可以管理100 - 200工人實例之前主人的穩定性開始惡化,獨立於這些工人做了什麼。失效模式是多種多樣的:線程爆炸、堆爆炸,ConnectionClosedExceptions通過監測等。試圖隔離問題,分析堆轉儲等在很大程度上是不成功的。

隨著工程的增長,我們發現詹金斯主摔倒每隔幾天,總是導致正在進行的測試運行失敗,有時需要大量的手工努力恢複。這些中斷甚至發生在詹金斯時載荷最小(如周末)。磚的定製集成有時也會引起問題,例如,測試瀏覽器ETL作業中斷引起的。隨著工程繼續增長,我們預計係統穩定性問題變得越來越CI係統上的負載進一步增加。

目標、非目標和要求

目標

在尋找替代詹金斯的基礎設施,我們有以下高級目標:

1. 係統應該能夠運行在自己的用最少的人工故障診斷,隨著負載的增加擴大平穩,沒有用戶體驗惡化
2. 我們應該能夠做出改變,升級,改進我們的CI經驗沒有導致任何停機時間或不便我們的開發人員
3. 實習生應該能夠提供一個新功能的CI係統一個星期,僅僅知道Scala中,SQL, HTML和CSS,不知道我們的雲基礎設施的複雜性
4. 使用上麵的屬性,我們應該能夠快速地改進和簡化常見的工作流程,建立一個連貫的開發人員的經驗來減少的數量CI-related問題問

非目標

在任何計劃,你希望做什麼,完成隻是故事的一半。以下是一些明確的非目標——我們決定的事情,我們不想做完成:

1. 我們不需要重新實現整個CI係統;一些組件工作得很好,沒有問題的開銷。我們想成為戰略取代那些讓我們最問題(測試瀏覽器,詹金斯等)而其他地方
2. 我們不需要實現詹金斯的廣度和插件的功能。正如上麵提到的,我們已經提取各種詹金斯的特性,隻留下一個很小的子集詹金斯的特性,我們依靠
3. 我們不想支持任意複雜的管道建設。絕大多數的CI工作簡單,運行pre-merge PRs或post-merge主人,並沒有其他工作上遊或下遊。基於執行引擎是酷,但超出了這個項目的範圍。
4. 我們不需要一個可伸縮係統。東西可以處理當時的CI負載(~ 500天工作運行,~ 50個並發運行),連同另一個1 - 2個數量級的增長,就足夠了。我們總是可以進化係統如果使用增加
5. 我們不需要更換Github UI。磚使用Github UI作為“集線器”對於任何用戶試圖合並公關,公關/提交每個CI工作運行狀態顯示。我們隻是為了改善經驗,除此之外,例如,挖掘工作,看看失敗,或挖掘工作/測試曆史調查片狀或破壞但Github UI的一麵偉大的工作,不需要更換

需求

任何CI係統我們最終選擇需要做以下事情:

1. 運行shell命令:在響應github事件,觸發,或時間表,
2. 操作簡單:部署(不是太多的移動部件),管理和更新(零停機時間)
3. Configuration-as-code:所以可以更改配置
   版本控製和代碼複審。我們使用Jsonnet-generated-YAMLs在其他公司和工作流非常滿意
4. 使用相同的EC2 / AMI-based測試環境中,我們已經使用,我們的工人和Devboxes詹金斯。我們有一個大的和混亂的代碼庫,支持大量的AWS雲基礎設施(建立緩存,kubernetes集群,等等),並不想花時間代理或者做一個雲間遷移。
5. 有一個漂亮的UI用於查看服務的狀態,工作,個人經營,或日誌;這基本上是所有我們使用詹金斯。
6. 很容易擴展和定製的特點:大(例如,概述儀表板,片狀測試視圖,等等)和小(提示、鏈接等)。我們不可避免地會想定製係統Databricks-specific需求和工作流程,並繼續進化為使用模式改變了。
7. 自動定量一個工人池,因為CI係統的使用是通過自然變量在工作日和工作時間。
8. 工程師可以勝任地創建或修改工作,而不需要成為一個專家在特定係統(不可能與詹金斯的Groovy配置!)

選擇

構建自己的定製的CI係統是一個大的項目,而不是一個你想做的如果你有任何其他選擇。甚至在考慮這項工作之前,我們調查的選擇:

• Kubernetes船首:這是最徹底的調查,包括一個完整的測試部署運行一些示例工作。我們發現可用性並不大,例如,需要運行kubectl re-trigger工作運行,它沒有流日誌查看器正在進行的日誌。也有一些內建的基礎設施,似乎硬編碼到穀歌的雲平台(GCP)(例如,存儲登錄穀歌雲存儲),不會與我們的AWS-based雲基礎設施Beplay体育安卓版本

1. Github的行為:當時不包括bring-your-own-infra,隻能工作在一個特定的類的微軟Azure vm 2 cpu / 7 gbmemory不會對我們來說足夠了
2. SAAS詹金斯:在理論與詹金斯解決穩定性問題,但它不會解決UI或複雜性問題
3. 詹金斯X:似乎更像一個CD比CI工具解決方案,重點部署CD管道和編排而不是CI驗證
4. Travis-CI:沒有bring-your-own-infra。也剛剛收購了當時他們的未來前景作為一個公司和項目都不清楚。
5. Infrabox:設置有困難做一個概念驗證部署

選擇的一個常見的線程在整個調查是缺乏“裸金屬”EC2支持或bring-your-own-infra在大多數“現代”CI係統。他們都認為你是運行在容器,經常他們的特定的容器內他們的特定的基礎設施。作為一個組織,已經有了大量的雲基礎設施,我們很滿意,運行在別人的容器內其他人的雲是行不通的。

還有其他選擇,我們沒有深入調查:廣場CI,CircleCI,Gitlab蔡先生,Buildkite,和許多其他人。這並不是由於任何價值判斷,而隻是現實的畫一條線。挖掘六個選擇之後,一些,我們覺得我們有一個良好的感覺是什麼,我們想要的。無論如何,我們希望是EC2實例上運行bash命令並告訴我們登錄瀏覽器;這有多難?

設計Runbot

這給我們帶來了Runbot;我們開發的CI係統的房子。在其核心,Runbot是“三層”的傳統web應用程序中,SQL數據庫,無狀態應用程序服務器(s),和一個網站的人可以看看:

除了後端係統管理CI工人來驗證PRs Github和掌握和報告提交狀態,大部分Runbot的價值在於它的Web UI。這讓用戶快速找到係統中發生了什麼,或與一個特定的工作,他們關心的事情。

寫在Scala中,Runbot約有~ 7000行代碼都包括:數據庫訪問Web / API服務器、雲相互作用,工作進程,HTML Web UI,等等。它已經增長到大約~ 10000行添加新功能和用例。

基本的係統架構

的技術設計Runbot可以概括為“不是詹金斯”。我們與詹金斯的所有問題,我們努力與Runbot難以避免。

詹金斯	Runbot
XML文件係統數據存儲	PostgreSQL數據庫
有狀態的服務器	無狀態應用程序服務器
需要持續連接到工人	容忍間歇性連接的工人
通過插件擴展	可擴展的隻是改變它的代碼
Groovy配置語言	Jsonnet配置語言
Groovy工作流語言	沒有工作流語言;它隻是運行你的可執行文件,你做你自己的事情

Runbot比詹金斯是一個更簡單的係統:如前所述,周圍開始~ 7000行Scala(小於java.util.regex此後!),適度增長。

在其核心,Runbot隻是一個傳統的三層的網站。HTTP請求來(從用戶的瀏覽器或JSON帖子從工人和API的客戶),我們打開一個數據庫事務,做一些查詢,提交事務並返回一個響應。不像別人可以學習網絡編程入門的課。

有趣的設計技術

在上述常見的係統架構之上,Runbot做一些引人注目的事情為了支持其featureset:

• 我們使用PostgreSQL的聽/通知功能來實現一個基本的發布-訂閱工作流;是否它是一個瀏覽器等待更新日誌,或者無所事事的工人等待新的工作要排隊,使用聽/通知讓我們立即通知他們沒有投票的性能/延遲開銷。結合SQL表存儲事件,這Postgres變成相當稱職的實時事件隊列,讓我們讓事情變得簡單,避免引入其他基礎設施組件就像卡夫卡或RabbitMQ

1. 大量的“計劃”工作運行管理邏輯定期跑步為了保持:生成新的工人EC2實例太多的工作排隊時,終止舊的/未使用EC2實例,等等。這些都是直接在Web上運行/ API服務器,再次和副本之間的協調通過Postgres數據庫,再一次讓我們的基礎設施簡單
2. 一個小代理進程運行在每個工人協調核心與應用程序服務器的交互:監聽/收購工作,工作是配置為運行必要的子流程命令運行,流日誌,等等。所有worker-server交互經曆相同的Web / API服務器作為JSON / HTTP / Websockets,就像Runbot其他API和Web ui。

盡管是一個分布式集群管理器實時pub / sub和即時更新網站,其核心Runbot工作類似於任何其他網站上,你可能見過。我們重用相同的數據庫支持的HTTP / JSON web服務器作為一個平台,覆蓋所有其他必要的領域特定的係統。Beplay体育安卓版本這種簡單的實現無疑是一個福音維護和易於操作和擴展係統。

工人管理

Runbot的一部分的設計值得特別討論職工生命周期。雖然Runbot管理幾個彈性集群的雲EC2實例,所涉及的實際邏輯比較幼稚。一個任務運行的生命周期和工人可以概括如下:

• 喬布斯通過config-as-code靜態配置:當Runbot部署,我們一起包配置它。配置更改需要重新部署,盡管Runbot服務器是無狀態的,這並不造成停機時間

• Github事件管道帖子Runbot的Web / API服務器排隊工作運行,與一些參數(如隻沙post-merge主的工作,或公關ID pre-merge公關工作)

• 如果有已經閑置勞動力,其中一個將收到的push-event排隊工作運行和立即聲稱它。否則預定工作運行幾次一分鍾會注意到有更多的比工人排隊的工作運行,並使用AWS SDK旋轉新工人EC2實例(一個maxWorkers限製)

• 新工人運行一組配置initCommands初始化本身(例如,首次克隆git回購),一旦做到了訂閱一個無人認領的工作從Runbot服務器運行。

• 一旦工人索賠工作運行,它運行一組配置runCommands實際執行工作的邏輯:查看有關沙/ PR-branch使用給定的參數與排隊的工作來看,巴澤爾建造或巴澤爾測試或sbt測試適當的。

• 一次runCommands完成時,它運行一些預配置嗎cleanupCommands嚐試把工作目錄準備拿起另一份工作運行(巴澤爾關閉,git清潔-xdf等等。),和re-subscribes Runbot服務器並接收或等待更多的工作。

• 如果一個工人空閑時間超過timeouts.waiting(通常配置為10分鍾),它調用sudo關閉- p現在和終止本身。我們還有一個計劃背景Runbot服務器上工作,定期清理工人,關閉失敗(這發生!)

上麵的描述是故意簡化和遺漏一些細節在短暫的利益。盡管如此,它給了一個好的Runbot如何管理員工的概述。

有些事情值得注意上麵的工作流程包括:

• 工人的行為集群的一種自然屬性係統配置:maxWorkers,運行spawn-instance背景的頻率工作,timeout.waiting。雖然不精確,它確實給我們大量的旋鈕可以長壽的一名員工工作或短暫的multi-worker工作。timeout.waitingcan be tweaked to tradeoff between idle workers and job-run queue times: longer worker idle times means there's more likely to be a waiting worker to pick up your job run immediately upon you queuing it.

1. 我們員工積極工作運行之間重用在一個工作。雖然這之間引入了潛在幹擾工作運行時,它大幅提高性能由於地方建立緩存,長壽守護程序進程等。每隔一段時間我們必須調查和處理一個工人進入一個糟糕的狀態。
2. 我們不重用的工人之間的工作。我們有這個特性在詹金斯的自動伸縮功能係統,理論上可以提高利用率之間工人通過分享他們的工作,但我們不認為增加了複雜性是值得的。我們在Runbot最終沒有實現它。
3. 我們不做任何聰明的CPU /內存/磁盤級別資源優化。這部分是因為這類係統通常需要運行容器內的一切,和我們的工作通常在“原始”EC2上運行。不同的工作被配置為使用不同的實例類型,和美國擴展我們的實例池的大小作為使用上下波動,我們有效地讓AWS代表我們執行一個粗粒度的優化資源配置。

Runbot的職工管理係統可以看作類似於麵向對象的編程:“對象”你“分配”一個工人通過調用EC2 API調用構造函數通過運行initCommands然後調用參數通過運行“方法”runCommands。像“對象”,Runbot工人使用內部可變性和數據位置的性能,但試圖保留一些不變量之間運行。

幾乎有點奇怪Runbot的工人的管理工作。“要求實例的工作,讓他們關閉自己在沒有“不會贏得任何獎項新奇。然而,有了很好的平衡效率、利用率、簡單性和可理解性。雖然我們確實遇到了問題使用已經在過去的兩年裏,天真的工人管理係統並不是其中之一。

麵向用戶的設計

可伸縮性和穩定沒有Runbot的唯一動機。的另一半圖片是提供更好的用戶體驗,基於知識的Jenkins-related microservices有機隨著時間的推移。

Runbot的目標的一部分信息密度:每一寸的屏幕應該是係統的用戶可能希望看到的。早些時候再次考慮主頁儀表板顯示:這是相對簡單的頁麵,每個工作都有許多工人(小廣場左邊)和一些工作運行(直方圖)的持續時間,工人和工作運行顏色來顯示他們的地位(黃色/灰色=初始化、綠色=空閑/成功,藍色=進步,紅/黑=失敗)。乍一看我們可以得出很多結論關於我們工作的性質看:

即使一切順利,我們已經注意到一些東西。為什麼是編譯Compile-MacOS-Master片狀?為什麼Compile-Master壞了一段時間,可以避免嗎?

但這種能力是更重要的問題。也許工作開始變得超級片狀,也許一個工人實例有損壞和處於糟糕的狀態,也許AWS實例的地區和新EC2工人不能開始。所有這些都可以經常看到乍一看,和頁麵上的每個元素工具提示和進一步的信息的鏈接:

值得對比Runbot與等效詹金斯的主要儀表板界麵:

雖然理論上詹金斯所有相同的數據如果你鑽,它通常需要更多的鑽探中找到你需要的信息。一些明顯的一瞥Runbot可能需要十幾個點擊和多個瀏覽器窗口並排在詹金斯通知。(以上我給傳統的UI,但新的“藍海”UI不是更好)。例如,而在於詹金斯可能隻顯示最基本的摘要信息,Runbot能夠向您展示整個工作的曆史和它的變化隨著時間的推移,給內髒感覺工作是如何表現的。

因此使用Runbot,有人調查一個問題能夠快速深入了解這份工作,對這份工作,工人,所有人幫助他們找出發生了什麼錯誤。前端UI設計構建這些內部後端係統時常常被忽視,但Runbot UI是一個核心部分的價值主張和磚的人喜歡用它的原因。

靜態HTML UI

總的來說,Runbot的UI是一個簡單的服務器端HTML / CSS UI。幾乎沒有任何交互性——任何配置是通過更新和部署Jsonnet配置文件,有什麼小交互性(開始、取消和重新啟動工作運行)實現通過簡單的HTML表單/按鈕和端點。我們有一些自定義邏輯允許即時更新儀表板和流日誌沒有刷新頁麵,但這是一個單純的漸進增強和UI沒有它是完全可用的。

一個有趣的結果靜態HTML UI就是性能。Github行動小組發表了博客如何巧妙地利用虛擬化技術,使大型日誌文件多達50 k線。Runbot,與靜態服務器端日誌呈現UI(包括服務器端語法高亮顯示),可以在瀏覽器中呈現50 k線沒有問題像Chrome,沒有任何客戶端Javascript !

也許是靜態HTML的更大的好處是多麼簡單對任何人作出貢獻。幾乎每一個程序員都知道一些HTML和CSS,可以爆炸了一些文本和鏈接和colored-rectangles如果必要的話。同樣不能說現代Javascript框架,雖然強大,是深刻和複雜的,需要前端專業知識正確地設置和使用。

雖然這些天許多項目使用某種形式的前端框架,Runbot,大多是靜態HTML,都有自己的好處。我們沒有任何前端專家維護Runbot,和任何軟件工程師能夠快速頁麵查詢數據爆炸,他們希望和呈現在一個像樣的格式。

推出Runbot

規模

自2019年推出以來,我們已經逐漸從詹金斯和移動他們Runbot卸載工作。使用Runbot有了顯著的增長,現在流程~ 15000左右的工作運行一天。

這種漸進遷移允許我們立即獲得好處。通過移動最高負載/從詹金斯Runbot高度重視工作,這些工作不僅得到Runbot提供的改善用戶體驗和穩定,但這些工作留下詹金斯也受益於降低負載和提高穩定性。現在我們在詹金斯約1/3和2/3 Runbot,雖然老詹金斯大師仍然有偶爾的問題,降低負載無疑給了它一個新生。我們希望逐漸將更多的工作崗位從詹金斯Runbot隨著時間的推移。

使用的增長Runbot並非沒有問題。50個並發原計劃的工人,我們現在接近500個並發工人15000 CPU核心高峰時段:

問題

當我們首次推出之前執行負載測試,以確保在預期的規模,我們做了最後觸及一些減速裝置的使用我們的係統過去兩年增長了10倍。鑒於Runbot應用服務器是無狀態的,容易更換,大部分的問題最終Postgres RDS數據庫是一個單點故障:

1. 有時候查詢計劃是善變和不合作的。沒有像Postgres自發決定但是查詢不再需要索引,而是應該開始做分鍾全表掃描,1點(當地時間),就像其他工程總部(在不同的時區)開始醒來,試著用你的CI係統!
2. Postgres讀副本可能有時會超載,在複製落後,降低主。原來的事務日誌主一直在等待副本趕上了足夠的消費上的所有磁盤空間的主人,不是我們期望能夠做複製品。
3. 默認情況下,RDS磁盤吞吐量壓製,因為是你的配置磁盤嗎大小。這意味著如果你有一個小型數據庫的磁盤流量,你可以配置一個更大的磁盤即使你不希望使用它。

盡管引起中斷的問題,這些問題是安慰常見問題基本上每個操作共享的數據庫支持的web服務。常見問題有共同的解決方案,確定節拍試圖理清之間的交互詹金斯threadpool爆炸、tb XML磁盤存儲,和我們的自定義周圍microservices動物園。

可擴展性

Runbot推銷的一部分是多少對我們的CI係統簡化開發。這在很大程度上已經被證實在過去兩年裏它已經運行。

我們有好幾個人貢獻的有用特性Runbot代碼庫,從較小的UI改進改進測試名截斷或更多信息提示更大的功能,如二進製構件存儲或工作運行曆史搜索。我們有經驗豐富的人加入該公司,並立即調整UI緩和一些粗糙的邊緣。我們實習生貢獻顯著特征作為他們的主要實習項目的一小部分。

沒有個人貢獻這些改進Runbot專家係統,但由於Runbot運行作為一個簡單的數據庫支持的web應用程序,他們可以找到自己的方式沒有問題,按自己的喜好修改Runbot。這種易於做出改進與舊詹金斯聞所未聞的基礎設施。

這驗證了我們最初的希望我們能夠Runbot足夠簡單,任何人都能貢獻隻要寫一些Scala / SQL / HTML / CSS。Runbot可能沒有插件,詹金斯的巨大的生態係統,但它很容易修補能力做任何我們想要超過彌補了它!

展望未來

到目前為止,我們已經談論我們所做的與Runbot過去;未來呢?有幾個主要的努力進入Runbot在現在和未來。

規模和穩定性

Runbot的使用已經大約10 x在過去的兩年裏,我們希望它在未來繼續快速增長。磚的工程團隊繼續增長,正如我們提到的,將繼續港口工作從我們的老詹金斯的主人。不僅如此,但隨著公司的發展,人們的期望繼續增長:2019年的可靠性水平是可以接受的磚2021年不再是可接受的。

這意味著我們將不得不繼續精簡流程,淬火係統,擴展了Runbot係統處理更多的能力。從目前的規模~ 500個並發的工人,我們可以預計,未來一年兩倍或三倍,Runbot需要能夠處理。擴展數據庫支持的web服務的坦途,我們隻需要執行在這繼續支持磚的工程。

支持新用例

Runbot的賣點之一就是fully-bespoke係統,我們可以做任何我們想要通過改變其相對較小的代碼庫。隨著CI工作流在磚的發展,新的集成測試工作流和前/ post-merge工作流和片狀測試管理,我們需要適應Runbot新的用戶界麵和新的代碼路徑來支持這些工作流。

一個有趣的例子是使用Runbot作為一個通用的跑步者在受限製的環境中工作。當我們熟悉詹金斯和Runbot Runbot是這樣一個小係統意味著它有一個最小的表麵積的攻擊。沒有複雜的權限係統,沒有用戶帳戶管理,沒有UI之工作在運行時,一個小代碼,很容易審計。使它更容易有信心你可以安全地部署沒有任何漏洞。

另一個用例可能是構建部署驗證管道管理的經驗。目前per-commit主測試,N-hourly集成測試,和其他的處理方式以一種特別的方式在決定是否提交安全促進分期和超越。這是Runbot的可擴展性真正閃光的地方,我們可以構建出任何工作流的Runbot的簡單web應用程序平台。Beplay体育安卓版本

自助服務

從其概念、Runbot是作為一個產品開發團隊開發管理和操作的。隨著時間的推移,其他球隊都開始采用這樣的方法越來越多,和係統正在從一個定製的基礎設施過渡到自助服務的商品,像Github的行為或特拉維斯CI。

在過去的兩年裏我們已經拋光在很多粗糙的邊緣回來當Runbot由開發團隊,但有很多工作要做,把它變成一個“電器”,人可以不需要的峰值引擎蓋下理解發生了什麼。這裏的目標是使Runbot使用簡單Travis-CI或Github行動,把它從“內部基礎設施”到“產品”或“設備”任何人都可以撿起並開始使用沒有幫助。

結論

在這篇文章中,我們討論了動機,磚的設計和推出Runbot CI係統。作為一個定製的CI係統根據磚的具體需求,Runbot有幾個優點在我們的老詹金斯基礎設施:穩定、簡單、改善用戶體驗,隨著時間的推移,更容易發展和演化。

Runbot是一個有趣的挑戰:雲基礎設施、分布式係統、完整的web前端UI,和開發人員的經驗都混合到一個項目。盡管常見的諺語對一切從頭開始,過去兩年Runbot已被證明值得投資,削減通過有機增長提供一個簡化的decade-and-half CI係統和經驗正是我們需要而已。Runbot證明關鍵支持磚已經過去兩年,我們預計它將發揮關鍵作用在支持數據磚在未來繼續增長。

如果你有興趣加入磚工程,作為用戶或開發人員是否我們的世界級的內部係統,我們正在招聘!