我們自研的那些Devops工具

運維咖啡吧發表於2019-02-13

隨著雲技術以及容器技術的崛起,人肉運維的時代結束了

2018年為了解決日常運維中的痛點以及更高效的推進運維工作,我們自研並完善了幾個工具系統,這些系統無一例外的幫我們節約了時間,提高了效率,這篇文章將分享介紹一下這些工具系統

系統介紹

我們自研的那些Devops工具

CMDB

CMDB配置管理資料庫,主要用來記錄我們管理維護的軟硬體資訊,包含實體的伺服器,交換機以及虛擬的專案、服務、環境等所有需要管理維護的資訊,通俗一點理解就是之前我們可能一個excel表格記錄了我們維護的所有專案,專案所用的伺服器資源,伺服器的配置等等資訊,都可以錄入到CMDB系統裡統一維護管理

CMDB系統是其他很多系統的基石,要給所有用到基礎資訊的第三方系統提供API以查詢或修改資料,例如提供專案對應的伺服器資訊給持續部署工具推送程式碼到專案伺服器上,所以CMDB系統的資料準確性非常重要,同時只在一個地方維護基礎資訊能夠讓整個運維繫統更可控,更高效,減少出錯

我們CMDB系統上線時間比較久,之前僅是用來替代Excel表格維護資訊用,今年為他增加了API,提供給第三方系統獲取基礎資料,API認證採用了JWT,關於API認證這篇文章有更多的介紹:Django+JWT實現Token認證

我們自研的那些Devops工具

varian

varian是我們內部開發的一個模組化的持續整合工具,主要負責專案從原始碼到最終可部署程式的這個過程,現在有大部分專案已經是Docker部署了,那麼varian會負責從原始碼到最終打包好的專案映象並上傳到映象倉庫這個過程,其中會涉及到編譯、合併、壓縮等等操作,這篇文章有詳細介紹我們varian的工作過程:探祕varian:優雅的釋出部署程式

varian的核心邏輯是把持續整合中的每一個小步驟拆分成獨立的類或方法,最終根據專案型別的不同組裝不同的類或方法,實現不同型別不同技術棧專案能夠共用同一套持續整合程式,減少程式碼冗餘,提高可用性

nova

nova持續部署,配合varian做整個上線流程,nova主要負責的是將最終的可部署程式或者Docker映象推送到線上各個節點更新的過程,因為線上環境比較複雜,有云主機、Docker容器、私有云、公有云k8s等,所以在nova這一層做了相容

nova只接受三個引數,1.專案名稱,2.部署環境,3.部署版本號,根據專案名稱和部署環境呼叫CMDB提供的API確定最終推送專案到哪些節點,根據版本號去拉取程式碼倉庫程式碼或者映象倉庫映象

擴容、回滾、重啟等操作都可以通過nova系統自動完成,這篇文章介紹了持續部署的更多細節:Docker環境的持續部署優化實踐

我們自研的那些Devops工具

kerrigan

在整個釋出上線的過程中除了程式碼的變更之外,通常還會涉及到配置檔案、資料庫的變更,為了解決配置檔案自動更新的問題我們開發了kerrigan系統,這篇文章有關於配置中心實現細節的介紹:中小團隊落地配置中心詳解

kerrigan底層基於etcd+confd實現,主要實現在web端修改,伺服器上自動更新生效的功能,kerrigan還能夠管理多環境不同型別的配置,尤其擅長檔案型的配置(區別於通常看到的基於KV的配置中心,對運維更友好),例如管理nginx,tomcat等配置,同時能夠記錄配置檔案的修改歷史,快速回滾配置,還支援配置檔案對比,只修改儲存延後釋出等功能

因為我們專案比較多,每個專案的nginx裡邊有一堆的規則,基於Docker的話每個rewrite的更新都需要重新打包釋出比較繁瑣,使用kerrigan之後有效解決了這個問題

我們自研的那些Devops工具

overmind

資料庫運維繫統overmind,除了能夠解決釋出上線過程中的最後一環資料庫變更外,我們還整合了其他一些實用的功能,例如SQL稽核、SQL查詢、自動導資料的工單系統,密碼錶等

overmind的第一個版本主要是整合了inception做SQL的稽核和執行,幫助我們自動化的處理線上資料庫的變更,這篇文章有介紹:中小團隊快速構建SQL自動稽核系統

完成第一個版本之後內部推動開發測試使用,收集到反饋,在第一個版本的基礎上新增了SQL查詢、Explain執行計劃展示等功能,後續發現DBA經常接到各個不通環境之間導資料的需求,又開發了工單功能來實現資料自動遷移,這篇文章有介紹遷移:運維效率之資料遷移自動化

後邊拋棄了Excel維護密碼的方式,開發了密碼錶功能,見這篇文章介紹:Django開發密碼管理表例項【附原始碼】

overmind在慢慢完善,後續還會基於需求和實用性新增更多的功能來提高效率

我們自研的那些Devops工具

proxy

proxy是一個代理系統,類似於阿里雲的SLB,kubernetes的ingress,主要給開發測試環境使用

我們維護專案較多,每個專案有多套不同的環境,每個環境都有不同的域名,對應不同的後端服務,為了模擬真實請求過SLB代理的環境以及集中的管理這些專案入口,之前的做法是把所有的域名都指向到一個nginx伺服器,nginx伺服器通過基於域名的vhost代理到後端服務,每次新增或修改都通過手動變更nginx配置檔案來完成,現在開發了proxy系統,可以通過頁面來快速方便的完成

我們自研的那些Devops工具

wiki

wiki系統在18年之前已上線,當年提出來規範化、文件化、自動化、智慧化的運維目標,文件是整個運維過程中非常重要的一環,其好處不用多說,持續推進文件的輸出也是我們非常重要的一環

我們自研的那些Devops工具

當然除了以上這些系統外還開發了一些小工具來規範管理,提高效率,這裡不多介紹。另外我們還用到了大量的開源軟體系統,例如Jenkins、ELK套件、Kubernetes等

2019年計劃

我們知道devops是從研發到上線整個過程自動化的一種思想,並不是某個工具或者某幾個工具的集合,我一直在想如何才能將devops落到實處,18年基於當前的環境我們開發了以上的各種工具來幫助我們高效的工作,但這些工具系統相對分散,不能形成體系流程,19年會實踐一些方式方法將這些工具系統串聯,實現更高程度的自動化,同時也會持續推進Kubernetes更大範圍的落地,為真正的實現Devops思想,從開發到上線的全流程自動化打基礎


我們自研的那些Devops工具

如果你覺得文章不錯,請點右下角【好看】。如果你覺得讀的不盡興,推薦閱讀以下文章:

相關文章