兩年前我寫了篇文章『我們自研的那些Devops工具』介紹了我們自研的一些DevOps工具系統，兩年過去了這些工具究竟還有沒有在發光發熱，又有哪些新的變化呢，我將通過這篇文章來回顧一下這兩年的發展與變化
CMDB
CMDB配置管理資料庫，作為整個運維體系構建的基礎，幾乎其他所有的運維工具系統都要依賴他提供的基礎資料，所以保證穩定非常重要，這裡的穩定不僅指的是系統執行狀態的穩定，還有資料結構、功能的穩定，其資料結構一旦改變上游系統可能都要跟著修改，所以在規劃CMDB的迭代更新時，首先要考慮相容性，已有功能不做過多修改，僅進行新功能的新增
基於以上考量，CMDB在這兩年來整體功能沒有太大變化，功能上僅是將主機監控給整合進來，可以在cmdb裡直接搜尋對應主機檢視監控，而無需再去監控系統檢索，同時在易用性上有了提升，例如去掉了目錄樹，豐富了展示資訊，優化了檢索功能
nova
nova系統主要用來做生產環境的持續部署，之前的文章裡也有介紹，由於我們的環境比較複雜，公有云、私有云、雲主機、物理機、Kubernetes等都有使用，並且分佈在不同地區的機房，為了方便維護，我們專門抽離了生產環境的部署功能做了nova系統
持續整合原本是通過varian系統來實現的，但現在我們已經徹底廢棄了varian，用更為強大的自定義任務引擎Probius來代替了，Probius下邊介紹
現在將回滾功能也整合進了nova，回滾基於Docker映象來實現，選擇要回滾環境，會根據環境拉對應專案和環境去Dockerhub拉取相應的映象列表，選擇映象進行回滾，可以快速回滾到之前的任何一個版本
還為nova增加了批量任務執行的功能，主要基於Ansible來實現，詳細介紹可以看之前的文章：Django+Ansible構建任務中心思路，藉助於批量任務可以方便的進行多節點異常排查，以及非部署類的任務處理
kerrigan
作為對運維非常友好的配置管理工具，Kerrigan在整個專案執行中起著至關重要的作用，目前已經管理了數百個不同型別的配置檔案，保障了上萬次的配置修改得以正常執行，近兩年來也對其進行了優化升級，主要有2個方面
confd該為watch模式，配置修改立即生效。這個主要是針對nginx配置檔案的管理，在之前的模式中，配置修改之後需要重新部署專案或者重啟confd服務配置才能生效，這個過程較為繁瑣，於是我們將confd改為了watch模式，配置一旦修改就會立即更新，這個模式有一個風險在於如果配置改錯了怎麼辦？配置改錯分兩種情況，語法錯誤與規則錯誤，首先confd在更新配置檔案前會檢查配置檔案是否有語法錯誤，如果沒有才會更新，這樣就避免了因為語法錯誤導致的更新失敗，其次對於規則本身寫錯的問題，這個只能在更新前認真檢查了，即便不是watch模式自動更新也會有這種問題存在，為此kerrigan做了幾個方面的優化來儘量保證不改錯以及改錯後能快速修正，具體的可以看這篇文章：Kerrigan：配置中心管理UI的實現思路和技術細節，包括配置對比、快速回滾等
提供了完善的API。kerrigan除了管理了nginx之類的服務配置外，同時還管理了Dockerfile之類的檔案，在持續整合的過程中需要用到Dockerfile，所以為Kerrigan提供了API來支援通過http的方式來獲取配置檔案，以便在Probius系統中使用配置檔案，為此還用Python專門寫了個獲取配置檔案的系統命令，只需要一個命令即可獲取kerrigan裡的配置檔案，具體的實現方式可以看這裡：用Python寫個Linux系統命令
overmind
最開始寫overmind系統僅僅是一個SQL稽核平臺，做到現在已經成了一站式DB管理系統，從工單開始，到DB資訊新增，密碼管理、許可權管理，DB查詢與審計，DB執行稽核等一系列資料庫相關的操作均可藉助於overmind系統來完成
proxy
proxy代理系統在易用性上有了不小的提升，首先是建立例項時選擇協議，如果想要一個例項同時支援http和https兩種協議，則在之前的版本需要建立兩個例項，而現在則可以選擇HTTP和HTTPS都支援，建立的例項將同時支援http和https協議訪問，同時還可以配置是兩個協議都可以同時訪問還是http強制跳轉至https，操作簡單了許多
另一個修改是，可以編輯是否開啟日誌，如果開啟的話還能在頁面上實時監聽日誌，這對於某些排錯的場景非常好用，實時監聽日誌就是模擬了tailf的功能，感興趣的可以檢視這篇文章：Django使用Channels實現WebSocket
關於proxy的詳細介紹可以檢視這篇文章：Proxy：簡單小巧又強大好用的代理系統
wiki
wiki整體功能沒有太大的變化，只是強化了搜尋功能，首頁依然是個目錄樹，內頁則只有內容，聚焦重點，沒有花裡胡哨的功能，不過隨著目錄的越來越多，後邊若是重構則會考慮增加空間的概念，團隊與團隊，板塊與板塊之間做個區分還是很有必要的
我們自研的那些Devops工具這篇文章裡介紹過的工具除了varian已經完全廢棄了之外，其他的各個系統都有在正常使用和迭代更新，生命力依然頑強。除了以上這些系統外，近兩年還開發了一些新的工具系統
alodi
alodi系統主要用來快速生成臨時環境，並實現對臨時環境整個生命週期的一站式管理，主要應用在同一專案多版本同時開發測試或是保密專案不能通過常規測試環境測試的情況下使用，通過alodi可以快速的建立一個專案執行環境，通過生成的隨機臨時域名訪問
alodi基於Kubernetes實現，部署過程日誌、容器終端日誌、進入容器終端檢視都可以在alodi系統中實現，無需跳轉到其他系統，同時為了應對某些特殊的測試環境，還允許繫結自定義域名，使用完成之後一個按鈕即可銷燬所有建立的資源
更多alodi的介紹可以檢視這篇文章：Alodi：環境建立從未如此簡單
webssh
通過webssh實現堡壘機功能，通過webssh連線遠端主機，可以記錄會話資訊，對操作進行錄影，後續還可進行審計，同時也可以實時檢視其他使用者的操作過程，提取操作命令等，為了方便使用，還通過目錄樹增加了分組功能
probius
自定義任務引擎probius是這兩年實現的最重要的一個系統，具有強大且靈活的任務編排能力，最初只是想取代varian，但現在不僅做到了完美的取代，而且在易用性功能性上有了很大的提升，現在每天都有數十上百個持續整合任務通過probius來完成，同時還把kubernetes以及prometheus都整合了probius系統
probius的三個核心概念是命令、模板和任務，命令是系統中的最小粒度，可以是一個具體的linux命令或是一個可以執行的指令碼，模板是一組命令的組合，任務包含了模板和引數，同一個模板對應不同的引數就會是多個不同的任務，基於這種思想probius可以實現任何的功能，無論是日常巡檢還是釋出上線，都可輕鬆應對
probius跑了所有開發測試環境的部署任務，而開發測試環境依賴的底層資源是Kubernetes，所以為了方便使用，Probius也整合進了Kubernetes和Prometheus，Kubernetes和Prometheus是作為外掛的形式整合進來的，可以不用，對probius本身影響不大
sadmin
Sadmin是一個Django的基礎公共庫，這個公共庫整合了許多基礎的功能，例如後臺配置網站標題、Title以及主題，動態配置選單，自動的審計日誌記錄，多種認方式等等，同時也對最常用到的CRUD進行了封裝，使用起來得心應手
目前以上這些系統幾乎全都使用了Sadmin公共庫進行了重構，保證了統一，也方便後續維護，sadmin公共庫的更多介紹看這裡：Sadmin：打造私有Django公共庫實現程式碼複用
最後
我們自研的那些Devops工具的文章裡寫未來一年的計劃，將那些相對分散的系統給串聯起來，現在未來已成過去，我們藉助於probius實現了對多個系統的串聯，實現了更高程度的自動化，那下一階段要怎麼發展？真的需要再停下來認真思考一下了
除了以上這些DevOps相關工具系統外，我還協助開發了一些業務相關的系統，例如前兩天介紹的需求管理系統，關於以上這些工具系統，我寫過很多相關文章來介紹，感興趣的可以前往運維咖啡吧同名公眾號或是部落格檢視，如有想法可以一起交流