基於 CODING CD + Nocalhost 在大型應用的 ChatOps 實踐
本文作者：紅亞科技 CTO——盧興民
紅亞科技聚焦信息技術發展，為信息技術相關專業提供優質教學服務
背景
ChatOps 最早起源於 GitHub，它以溝通平台為中心，通過與機械人產生對話和交互，使開發人員只需在聊天窗口即可完成 DevOps 所承載的工作。
服務 600+ 高校的 IT 實訓教學平台「青椒課堂」，為何選擇 ChatOps 來承載業務，又如何將 SaaS 工具與開源工具結合形成完整的技術方案，本篇文章將為你揭曉答案。
為什麼「複雜應用」開發測試階段需要 ChatOps
- 隨着部署工具及部署 Pipeline 流程引入到整個開發迭代流程中，使用發佈單模式進行開發、測試環境的部署往往需要打開多個 Web 控制台，對於日常開發迭代來說較為繁瑣。
- 隨着項目的開發，項目會存在多個 git repo，每個 git repo 又會產生多個製品用於部署，基於手動選擇的方式對於開發人員開發、測試非常不友好。
- 在消息通知方面，雖然使用了 Webhook 將項目協同信息進行了群通知，但項目所有通知發送到一個群內，造成信息爆炸，逐漸失去通知意義。
首先來看我們團隊當前的部署流程所需要的步驟，需要經過「等待 CI 構建成功」、「發佈單選擇所需製品及環境」、「部署」這麼幾個流程。其中製品的選擇，在每次發佈時，都需要進行選擇，當組件較多時，尤為繁瑣。
並不是所有的場景都需要 ChatOps，這裡重點強調「複雜應用」，是因為應用複雜度提高後，會面臨配置複雜、製品複雜、流程複雜的局面，因此需要 ChatOps 工具來降低開發測試過程中的部署難度。而對於簡單的應用，例如項目初始階段的單體應用，則不必大費周折折騰複雜的工具流程，在 CI 中集成小部分自動更新測試環境的流程就很高效。
如何結合 CI/CD 體系和 IM 開放平台構建 ChatOps 工具
當前 CI/CD 落地的現狀及選型思考
持續集成
持續集成是所有流程的基礎，目標也很明確，就是將構建環境、製品類型進行統一，便於進行後續的部署使用。在當前容器化流程的背景下，我們也是選擇了容器鏡像作為最終製品，開發人員產出統一均為容器鏡像，方便進行部署。所有的代碼倉庫，無論複雜與否，都會創建 Jenkinsfile 進行構建。
應用定義選型
在應用定義的選擇上，經歷了最初的 PaaS 平台自定義應用模型、代碼倉庫存儲靜態 Manifest 文件後，最終選擇了 Helm 作為應用定義的工具，主要基於一下幾個方面考慮：
- 部署方式簡單，可以通過單條命令直接進行安裝，即使在工具較為匱乏的私有化環境中脫離部署工具也可使用一條命令進行部署和升級。
- 使用模板進行定義， 便於進行多個副本部署及差異化配置。
- 通過製品庫來存儲 Helm chart，dev 環境使用構建號進行版本推送，生產環境通過 Helm 倉庫打 tag 後進行版本推送，實現「應用定義」的版本化。
應用部署工具選型
在應用部署工具上選擇上使用了 CODING CD，主要基於以下的內容進行考慮：
- 應用定義及組件版本分離。
- 基於環境加載公共配置。
- 發佈啟動參數定製。
將 Helm chart 及容器鏡像作為製品輸入，通過製品綁定，將 Helm chart 版本與 image 版本進行分離，實現應用定義和應用組件版本的獨立配置。
使用 values 文件引用，方便的對「某一類」環境進行統一配置，例如公用雲不同廠商間的差異化配置。
構建適合團隊的 ChatOps 體系
ChatOps 工具構建的目標
- 解決消息雜而亂的問題，以項目迭代為粒度進行消息的分類、創建 IM 群組。
- 解決開發測試環境創建繁瑣、需要口頭約定的問題，以項目迭代為粒度，創建獨立的測試環境。
- 盡量避免 Web 控制台操作。
- 迭代結束後自動清理環境、群。
開發測試過程流程梳理
如下圖所示，我們對開發測試的整個部署流程進行梳理。其中最為繁瑣的、需要多次人工操作的部分就是「部署配置」 + 「版本選擇」這個過程，如何將製品按照一定的規則更新到對應的環境中，並且能夠記住當前的選擇便是這個流程的關鍵。
首先，我們需要將整個部署流程進行模板化，這裡我們使用 Namespace 作環境間的隔離，將環境中最關鍵的兩個因素，Namespace、訪問域名作為啟動參數，將單一的部署流水線模板化。
通知隔離
通過接管 Webhook 事件，將原有的項目協同通知進行重新分發。當項目協同工具中產生迭代創建時，自動觸發創建一個預製好 DevOps 機械人的群，並利用 IM 提供的卡片能力對消息進行優化，增加便捷的入口。項目協同事項變更時，自動對群內成員進行增刪。同時，環境也與當前的迭代關聯，在需要時通過聊天指令進行快速創建。在迭代結束時，回收群、測試環境等，進行清理工作。
當前 ChatOps 主要實現以下指令：
- deploy —— 喚出部署設置卡片。
- branch —— 設置某個倉庫對應的分支、查找對應製品並喚出部署卡片。
當環境創建成功後，ChatOps 控制器會記錄當前環境的製品選擇，當對應的製品有更新時，會自動更新當前的環境，實現測試環境一次配置，整個迭代內自動更新。
開發測試階段如何快速調試應用
在日常的開發過程中，基於上述的 ChatOps 流程進行環境的部署和更新已經能滿足大部分的需求，代碼推送後，也可以在分鐘級做到環境的更新。
單對於聯調和測試時遇到的問題需要修改時，等待一個 CI/CD 的流程顯得非常漫長，另外開發新的功能和新組件時，想快速放入測試環境中也較為繁瑣。因此我們在尋求一個工具，用於快速調試開發環境。
在早年的服務端開發時，我們時常使用 sftp 插件，將本地代碼同步到服務器上進行執行，那麼 Nocalhost 就是容器化的 rsync 工具。Nocalhost 在進入調試模式時，把對應的 Container 鏡像替換為指定的開發鏡像，並增加一個文件同步的 Sidecar，可以將本地的代碼同步至容器中，對於腳本類型的語言可以直接進行調試，像 Golang 需要編譯的類型，可以在本地構建進行同步，也可以直接在容器中進行構建。
整個使用的過程中需要留意的關鍵步驟是製作適合開發調試使用的鏡像，Nocalhost 提供了常見環境的開發鏡像，但應用於自己團隊內部時，鏡像所包含的內容往往與組件相關，此時就需要定製一個適用於當前業務的開發鏡像。主要基於以下幾點考慮：
- 盡量包含實際環境中使用鏡像中的工具和常用的調試工具。
- 去除掉影響調試的緩存組件，例如 PHP 中的 OPcache。
總結
隨着業務的複雜程度提高，開發測試流程中重複繁瑣的操作會變得越來越多，基於已有的 CI/CD 體系構建 ChatOps 工具是解決這種問題的一個思路，選擇適合自己團隊的方案才是最為重要。
