咱們自研的那些Devops工具

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

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

系統介紹

CMDB

CMDB配置管理數據庫，主要用來記錄咱們管理維護的軟硬件信息，包含實體的服務器，交換機以及虛擬的項目、服務、環境等全部須要管理維護的信息，通俗一點理解就是以前咱們可能一個excel表格記錄了咱們維護的全部項目，項目所用的服務器資源，服務器的配置等等信息，均可以錄入到CMDB系統裏統一維護管理

CMDB系統是其餘不少系統的基石，要給全部用到基礎信息的第三方系統提供API以查詢或修改數據，例如提供項目對應的服務器信息給持續部署工具推送代碼到項目服務器上，因此CMDB系統的數據準確性很是重要，同時只在一個地方維護基礎信息可以讓整個運維繫統更可控，更高效，減小出錯

咱們CMDB系統上線時間比較久，以前僅是用來替代Excel表格維護信息用，今年爲他增長了API，提供給第三方系統獲取基礎數據，API認證採用了JWT，關於API認證這篇文章有更多的介紹：Django+JWT實現Token認證

varian

varian是咱們內部開發的一個模塊化的持續集成工具，主要負責項目從源代碼到最終可部署程序的這個過程，如今有大部分項目已是Docker部署了，那麼varian會負責從源代碼到最終打包好的項目鏡像並上傳到鏡像倉庫這個過程，其中會涉及到編譯、合併、壓縮等等操做，這篇文章有詳細介紹咱們varian的工做過程：探祕varian：優雅的發佈部署程序

varian的核心邏輯是把持續集成中的每個小步驟拆分紅獨立的類或方法，最終根據項目類型的不一樣組裝不一樣的類或方法，實現不一樣類型不一樣技術棧項目可以共用同一套持續集成程序，減小代碼冗餘，提升可用性

nova

nova持續部署，配合varian作整個上線流程，nova主要負責的是將最終的可部署程序或者Docker鏡像推送到線上各個節點更新的過程，由於線上環境比較複雜，有云主機、Docker容器、私有云、公有云k8s等，因此在nova這一層作了兼容

nova只接受三個參數，1.項目名稱，2.部署環境，3.部署版本號，根據項目名稱和部署環境調用CMDB提供的API肯定最終推送項目到哪些節點，根據版本號去拉取代碼倉庫代碼或者鏡像倉庫鏡像

擴容、回滾、重啓等操做均可以經過nova系統自動完成，這篇文章介紹了持續部署的更多細節：Docker環境的持續部署優化實踐

kerrigan

在整個發佈上線的過程當中除了代碼的變動以外，一般還會涉及到配置文件、數據庫的變動，爲了解決配置文件自動更新的問題咱們開發了kerrigan系統，這篇文章有關於配置中心實現細節的介紹：中小團隊落地配置中心詳解

kerrigan底層基於etcd+confd實現，主要實如今web端修改，服務器上自動更新生效的功能，kerrigan還可以管理多環境不一樣類型的配置，尤爲擅長文件型的配置（區別於一般看到的基於KV的配置中心，對運維更友好），例如管理nginx，tomcat等配置，同時可以記錄配置文件的修改歷史，快速回滾配置，還支持配置文件對比，只修改保存延後發佈等功能

由於咱們項目比較多，每一個項目的nginx裏邊有一堆的規則，基於Docker的話每一個rewrite的更新都須要從新打包發佈比較繁瑣，使用kerrigan以後有效解決了這個問題

overmind

數據庫運維繫統overmind，除了可以解決發佈上線過程當中的最後一環數據庫變動外，咱們還集成了其餘一些實用的功能，例如SQL審覈、SQL查詢、自動導數據的工單系統，密碼錶等

overmind的第一個版本主要是集成了inception作SQL的審覈和執行，幫助咱們自動化的處理線上數據庫的變動，這篇文章有介紹：中小團隊快速構建SQL自動審覈系統

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

後邊拋棄了Excel維護密碼的方式，開發了密碼錶功能，見這篇文章介紹：Django開發密碼管理表實例【附源碼】

overmind在慢慢完善，後續還會基於需求和實用性添加更多的功能來提升效率

proxy

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

咱們維護項目較多，每一個項目有多套不一樣的環境，每一個環境都有不一樣的域名，對應不一樣的後端服務，爲了模擬真實請求過SLB代理的環境以及集中的管理這些項目入口，以前的作法是把全部的域名都指向到一個nginx服務器，nginx服務器經過基於域名的vhost代理到後端服務，每次添加或修改都經過手動變動nginx配置文件來完成，如今開發了proxy系統，能夠經過頁面來快速方便的完成

wiki

wiki系統在18年以前已上線，當年提出來規範化、文檔化、自動化、智能化的運維目標，文檔是整個運維過程當中很是重要的一環，其好處不用多說，持續推動文檔的輸出也是咱們很是重要的一環

固然除了以上這些系統外還開發了一些小工具來規範管理，提升效率，這裏很少介紹。另外咱們還用到了大量的開源軟件系統，例如Jenkins、ELK套件、Kubernetes等

2019年計劃

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

---

若是你以爲文章不錯，請點右下角【好看】。若是你以爲讀的不盡興，推薦閱讀如下文章：

• 中小團隊基於Docker的devops實踐
• 代碼中的敏感信息加密方案