運維思索

運維工作中的重複性工作有哪些？

新伺服器上架，與CMDB、監控、堡壘機聯動同步；
作業系統初始化，包括使用者、核心、安裝源、規範目錄、安全基線等；
基礎元件初始化，包括Java環境、Pyhon環境、Nginx等各種元件；
應用版本釋出、回滾，此過程與監控聯動；
應用管理操作，如啟動、停止、重啟等；
監控系統與應用相關監控項的建立、禁用、啟用等；
……
上述這些重複性的工作會零碎的分散在我們日常的運維過程中，我們有什麼辦法能夠通過自動化的方式來處理這些瑣碎的事情呢？

我的解決方案就是藉助Jenkins 通過CI/CD的方式來實現運維自動化。之所以選擇Jenkins，不只是因為其能夠通過各種外掛實現各種工具的整合，更重要有以下幾點：

BlueOcean

Jenkins官方從使用者角度出發，可使複雜的pipeline視覺化，快速直觀地理解管道狀態。

擴充套件共享庫

通過共享庫可以實現多個專案之間共享流水線，有助於減少冗餘並保持程式碼乾淨整潔。

Pipeline

流水線既可以作為job獨立執行，也可以作為一項任務被其他流水線呼叫。

總結以上兩點：

BlueOcean滿足了我對視覺化管理介面的需求，降低了運維開發前端管理介面的負擔，讓我們把精力更多的集中在我們擅長的領域；
擴充套件共享庫更大程度上滿足了我對運維崗位的理解：二線運維通過共享庫管理提供運維的原子化模組；一線運維通過pipeline自由組合共享庫中的原子模組，形成最終的解決方案；
隨著原子化的模組不斷增多，那麼我們的自動化運維就可以覆蓋更多的場景，後續通過故障自愈的方式接入，那麼就可以給我們釋放更多時間，屆時真正的SRE將不再是夢！

確保長期關注研發工作：Google 將 SRE 團隊的運維工作限制在 50% 以內，剩餘的時間花在研發專案上.
----《SRE: Google運維解密》

擴充套件共享庫和流水線

如圖，我們通過pipline編排出以下運維場景：

伺服器自動上架
基礎元件定製化安裝
Java應用自動上線
Java應用版本釋出
這些場景執行構建時會呼叫擴充套件共享庫中多個原子化模組，為方便區分我們將各個原子模組針對其功能劃分為以下幾個級別：

作業系統級
Java應用級
Apollo配置中心級
監控系統級
CMDB級
後續我們可根據實際情況自行新增相關原子模組至擴充套件共享庫中。

場景自動化實現

1.伺服器自動上架

伺服器的自動上架更多的是藉助於藍鯨標準運維，但因為伺服器自動上架也是運維工作中的常見場景，所有在此進行簡單說明，具體實現請見《藍鯨智雲實現虛擬機器交付》、《運維思索：cmdb打通zabbix、jumpserver探索》。

2.作業系統初始化與基礎元件安裝

作業系統初始化與基礎元件安裝藉助於Jenkins + Ansible Playbook實現，同時也可以作為一個job由其他場景進行整合呼叫。其具體功能實現請見《Jenkins+Ansible：助力基礎設施建設》。

3.Java應用自動上線

Java應用自動上線一般在應用第一次上線時使用，目的是在明確的運維規範前提下，能夠快速上線應用。此過程我們主要使用的時pipeline job 及擴充套件共享庫中的原子模組：

CMDB級模組：根據應用名獲取應用IP；
pipeline job：基礎元件初始化；
apollo配置中心級模組：配置釋出；
Java應用級模組：應用版本釋出、健康檢查及應用啟停等；
監控系統級模組：監控項新增；
通過這一些列的搭配，我們實現了Java應用自動上線的運維場景。

4.Java應用版本釋出

Java應用版本釋出包含釋出、回滾兩部分，在此我們統一以釋出為準。此過程主要使用的是擴充套件共享庫中的原子模組：

CMDB級模組：根據應用名獲取應用IP；
apollo配置中心級模組：配置釋出；
監控系統級模組：遮蔽監控；
Java應用級模組：應用版本釋出、健康檢查及應用啟停等；
監控系統級模組：恢復監控；
由於版本釋出在各公司的具體流程有所不同，在此我們需要根據實際情況自行調整，將流程中缺失的環節可以做成原子模組增加到擴充套件共享庫。

總結

CI/CD不僅能夠在企業DevOps程序中發揮重要作用，其實在運維自動化過程中也能做到足夠有效的支撐。因此如果我們只將其當作成一個打包工具就大錯特錯了，其帶給我們思想上的轉變則更加有意義。
————————————————

 

文章來自網路，如有侵權，將第一時間刪除內容。
文章作者：CSDN博主「木訥大叔愛運維」
原文連結：https://blog.csdn.net/yanggd1987/article/details/121750197