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