基于CODING CD+Nocalhost在大型應(yīng)用的ChatOps實踐

背景

ChatOps最早起源于GitHub，它以溝通平臺為中心，通過與機器人產(chǎn)生對話和交互，使開發(fā)人員只需在聊天窗口即可完成DevOps所承載的工作。

服務(wù)600+高校的IT實訓教學平臺“青椒課堂”，為何選擇ChatOps來承載業(yè)務(wù)，又如何將SaaS工具與開源工具結(jié)合形成完整的技術(shù)方案，本篇文章將為你揭曉答案。

為什么“復雜應(yīng)用”開發(fā)測試階段

需要ChatOps

·隨著部署工具及部署Pipeline流程引入到整個開發(fā)迭代流程中，使用發(fā)布單模式進行開發(fā)、測試環(huán)境的部署往往需要打開多個Web控制臺，對于日常開發(fā)迭代來說較為繁瑣。

·隨著項目的開發(fā)，項目會存在多個git repo，每個git repo又會產(chǎn)生多個制品用于部署，基于手動選擇的方式對于開發(fā)人員開發(fā)、測試非常不友好。

·在消息通知方面，雖然使用了Webhook將項目協(xié)同信息進行了群通知，但項目所有通知發(fā)送到一個群內(nèi)，造成信息爆炸，逐漸失去通知意義。

首先來看我們團隊當前的部署流程所需要的步驟，需要經(jīng)過“等待CI構(gòu)建成功”、“發(fā)布單選擇所需制品及環(huán)境”、“部署”這么幾個流程。其中制品的選擇，在每次發(fā)布時，都需要進行選擇，當組件較多時，尤為繁瑣。

并不是所有的場景都需要ChatOps，這里重點強調(diào)“復雜應(yīng)用”，是因為應(yīng)用復雜度提高后，會面臨配置復雜、制品復雜、流程復雜的局面，因此需要ChatOps工具來降低開發(fā)測試過程中的部署難度。而對于簡單的應(yīng)用，例如項目初始階段的單體應(yīng)用，則不必大費周折折騰復雜的工具流程，在CI中集成小部分自動更新測試環(huán)境的流程就很高效。

如何結(jié)合CI/CD體系和IM

開放平臺構(gòu)建ChatOps工具

當前CI/CD落地的現(xiàn)狀及選型思考

1.持續(xù)集成

持續(xù)集成是所有流程的基礎(chǔ)，目標也很明確，就是將構(gòu)建環(huán)境、制品類型進行統(tǒng)一，便于進行后續(xù)的部署使用。在當前容器化流程的背景下，我們也是選擇了容器鏡像作為最終制品，開發(fā)人員產(chǎn)出統(tǒng)一均為容器鏡像，方便進行部署。所有的代碼倉庫，無論復雜與否，都會創(chuàng)建Jenkinsfile進行構(gòu)建。

2.應(yīng)用定義選型

在應(yīng)用定義的選擇上，經(jīng)歷了最初的PaaS平臺自定義應(yīng)用模型、代碼倉庫存儲靜態(tài)Manifest文件后，最終選擇了Helm作為應(yīng)用定義的工具，主要基于一下幾個方面考慮：

·部署方式簡單，可以通過單條命令直接進行安裝，即使在工具較為匱乏的私有化環(huán)境中脫離部署工具也可使用一條命令進行部署和升級。

·使用模板進行定義，便于進行多個副本部署及差異化配置。

·通過制品庫來存儲Helm chart，dev環(huán)境使用構(gòu)建號進行版本推送，生產(chǎn)環(huán)境通過Helm倉庫打tag后進行版本推送，實現(xiàn)“應(yīng)用定義”的版本化。

3.應(yīng)用部署工具選型

在應(yīng)用部署工具上選擇使用了CODING CD，主要基于以下的內(nèi)容進行考慮：

·應(yīng)用定義及組件版本分離。

·基于環(huán)境加載公共配置。

·發(fā)布啟動參數(shù)定制。

將Helm chart及容器鏡像作為制品輸入，通過制品綁定，將Helm chart版本與image版本進行分離，實現(xiàn)應(yīng)用定義和應(yīng)用組件版本的獨立配置。

使用values文件引用，方便的對“某一類”環(huán)境進行統(tǒng)一配置，例如公用云不同廠商間的差異化配置。

構(gòu)建適合團隊的ChatOps體系

1.ChatOps工具構(gòu)建的目標

·解決消息雜而亂的問題，以項目迭代為粒度進行消息的分類、創(chuàng)建IM群組。

·解決開發(fā)測試環(huán)境創(chuàng)建繁瑣、需要口頭約定的問題，以項目迭代為粒度，創(chuàng)建獨立的測試環(huán)境。

·盡量避免Web控制臺操作。

·迭代結(jié)束后自動清理環(huán)境、群。

2.開發(fā)測試過程流程梳理

如下圖所示，我們對開發(fā)測試的整個部署流程進行梳理。其中最為繁瑣的、需要多次人工操作的部分就是“部署配置”+“版本選擇”這個過程，如何將制品按照一定的規(guī)則更新到對應(yīng)的環(huán)境中，并且能夠記住當前的選擇便是這個流程的關(guān)鍵。

首先，我們需要將整個部署流程進行模板化，這里我們使用Namespace作環(huán)境間的隔離，將環(huán)境中最關(guān)鍵的兩個因素，Namespace、訪問域名作為啟動參數(shù)，將單一的部署流水線模板化。

3.通知隔離

通過接管Webhook事件，將原有的項目協(xié)同通知進行重新分發(fā)。當項目協(xié)同工具中產(chǎn)生迭代創(chuàng)建時，自動觸發(fā)創(chuàng)建一個預制好DevOps機器人的群，并利用IM提供的卡片能力對消息進行優(yōu)化，增加便捷的入口。項目協(xié)同事項變更時，自動對群內(nèi)成員進行增刪。同時，環(huán)境也與當前的迭代關(guān)聯(lián)，在需要時通過聊天指令進行快速創(chuàng)建。在迭代結(jié)束時，回收群、測試環(huán)境等，進行清理工作。

當前ChatOps主要實現(xiàn)以下指令：

·deploy——喚出部署設(shè)置卡片。

·branch——設(shè)置某個倉庫對應(yīng)的分支、查找對應(yīng)制品并喚出部署卡片。

當環(huán)境創(chuàng)建成功后，ChatOps控制器會記錄當前環(huán)境的制品選擇，當對應(yīng)的制品有更新時，會自動更新當前的環(huán)境，實現(xiàn)測試環(huán)境一次配置，整個迭代內(nèi)自動更新。

開發(fā)測試階段如何快速調(diào)試應(yīng)用

在日常的開發(fā)過程中，基于上述的ChatOps流程進行環(huán)境的部署和更新已經(jīng)能滿足大部分的需求，代碼推送后，也可以在分鐘級做到環(huán)境的更新。

單對于聯(lián)調(diào)和測試時遇到的問題需要修改時，等待一個CI/CD的流程顯得非常漫長，另外開發(fā)新的功能和新組件時，想快速放入測試環(huán)境中也較為繁瑣。因此我們在尋求一個工具，用于快速調(diào)試開發(fā)環(huán)境。

在早年的服務(wù)端開發(fā)時，我們時常使用sftp插件，將本地代碼同步到服務(wù)器上進行執(zhí)行，那么Nocalhost就是容器化的rsync工具。Nocalhost在進入調(diào)試模式時，把對應(yīng)的Container鏡像替換為指定的開發(fā)鏡像，并增加一個文件同步的Sidecar，可以將本地的代碼同步至容器中，對于腳本類型的語言可以直接進行調(diào)試，像Golang需要編譯的類型，可以在本地構(gòu)建進行同步，也可以直接在容器中進行構(gòu)建。

整個使用的過程中需要留意的關(guān)鍵步驟是制作適合開發(fā)調(diào)試使用的鏡像，Nocalhost提供了常見環(huán)境的開發(fā)鏡像，但應(yīng)用于自己團隊內(nèi)部時，鏡像所包含的內(nèi)容往往與組件相關(guān)，此時就需要定制一個適用于當前業(yè)務(wù)的開發(fā)鏡像。主要基于以下幾點考慮：

·盡量包含實際環(huán)境中使用鏡像中的工具和常用的調(diào)試工具。

·去除掉影響調(diào)試的緩存組件，例如PHP中的OPcache。

總結(jié)

隨著業(yè)務(wù)的復雜程度提高，開發(fā)測試流程中重復繁瑣的操作會變得越來越多，基于已有的CI/CD體系構(gòu)建ChatOps工具是解決這種問題的一個思路，選擇適合自己團隊的方案才是最為重要。