Dev Talks

小團隊使用 GitLab AutoDevOps 除了 Kubernetes 之外的選擇(ㄧ)

5xRuby Technolgy Director QiuZhengXian
蒼時弦也 / 邱政憲, 技術總監 Apr 7, 2021

隨著雲端技術的發展,我們可以很容易取得伺服器的資源來使用。同時,在軟體開發上我們也越來越重視 Continuous Integration(持續整合)與 Continuous Delivery(持續交付)的實踐,這也是讓我們的開發團隊能夠進入 DevOps 的重要基礎。

不過,要管理 Kuberentes 對小規模的團隊並不一定是一件容易的事情。在這樣的情境之下,我們是否還能夠有其他的選擇呢?

容器的調度

在過去網路還沒有這麼普及的時代,架設網路服務大多只需要一台或者數台的伺服器。同時軟體也非常單純,只需要以 Monolithic(單體)的方式來設計跟開發,只需要將開發完畢的軟體放到伺服器上面執行就算是完成部署。

隨著網路普及以及使用者增加,我們開始出現需要根據不同類型的功能、使用頻率,去切分成單獨的服務,並且分配不同的資源到這些伺服器上面,來達到最有效率的使用伺服器。

直到今日,單一個產品可能會有上百台伺服器需要管理,並且要能合理的將不同類型的服務分配到這些伺服器上,並合理的使用這些伺服器資源。這就是「調度」,也是 Kubernetes 主要解決的問題。

只是 Kubernetes 整合了非常多功能,以及為了能夠適應各種類型的應用情境,加入了非常多抽象化的概念,這對只有數十人的小團隊來說實在太過複雜。

另一個選擇 - Nomad

在五倍紅寶石軟體開發,我們選擇 Nomad 作為調度管理工具。跟 Kubernetes 不同的是,他只需要將執行檔複製到伺服器,基本上就能夠直接運行起來,同時也沒有太多複雜的選項,我們只需要專注在定義如何「啟動服務」這件事情上即可。

對應我們的業務類型,如果要幫每一個客戶搭建 Kuberenetes 用於 DevOps ,會是一件非常耗費精力的事情,也因此使用 Nomad 來建構工程師在開發、測試的環境,搭配 GitLab 設計給 AutoDevOps 的各項功能,我們可以很簡單的用一台伺服器搭配 ProxmoxVE 或者類似的虛擬化技術,來建構一個以專案為基礎的測試環境。

當工程師建立新的 Pull Request(合併請求)時,我們可以自動部署測試環境,讓 Code Reviewer 和 PM(或者 PO)能夠直接去檢查實際的成果,而不需要再另外部署或者抓到自己的電腦內。

使用 Nomad 的優點

透過簡單和部署、設定,搭配容器化的技術,我們可以很輕鬆的針對不同的客戶建置開發環境。而這樣的流程也大大加速了我們在開發時的速度,工程師只需要更專注在功能和測試的撰寫,當程式碼上傳之後馬上就能透過部署後的結果來驗證是否符合規格。同時我們還能夠加入像是 LightHouse 這類針對實際網站的效能測試,而不是只有針對程式碼進行檢驗。

相比使用 Kuberentes 要付出的學習時間,對小團隊來說, Nomad 可能會是一個適合在初期使用的選項。

下一章我們會說明 GitLab CI 所提供的機制如何讓我們實現使用 Nomad 來替代 Kuberentes 實現自動化的測試環境搭建。




分享