運維思索：接地氣的運維自動化建設

簡述

《運維思索》介紹了一系列運維規範、運維管理及自動化的文章，主要分享的是運維自動化建設的部分想法與思路。站在讀者的角度，或許只有我本身明白，那麼它們在整個運維自動化建設中到底處於什麼位置、發揮着什麼做用呢？

先來分享一張比較初步且接地氣的圖：

圖中所用到的運維工具應該都是咱們比較熟悉的且經常使用的，從運維框架的層次來看：

• 基礎設施層，Vsphere虛擬化、物理機等；
• 數據層，數據庫、elk、緩存等；
• 應用層，各類基礎組件、業務應用，如java、python、php、nginx、中間件等；
• 平臺層，各類監控工具、管理工具，如Vsphere、jumpserver、Jenkins等；

咱們的運維工做基本都分佈在以上4個層次，所以如何高效、高質量的交付就成爲了咱們主要面對的問題。

技術棧

對於繁雜的運維工做，咱們首先想到的應該都是自動化，那麼自動化對技術棧要求高嗎？是否須要必定的開發能力？帶着這個問題來繼續往下看。

從上面的圖中能夠看出，我主要用到了如下幾個技術組件：

• Cobbler
• Ansible
• Jenkins
• 藍鯨
• Python
• Zabbix
• Vsphere
• JumpServer

以上幾個工具你們都不陌生，可是你們對工具的定位不一樣，也就決定了他們發揮做用的大小。尤爲是對Ansible、Jenkins、藍鯨的定位。

1.Ansible

Ansible做爲一個自動化運維工具，若是你只是把他看成批量執行命令的工具，那麼它的充其量就是一個腳本工具。可是若是把它做爲咱們運維過程的配置中心呢？

它能夠幫助咱們完成不少配置管理需求：

• 操做系統初始化
• 安全基線調整
• 環境初始化，如java、python
• 基礎組件安裝，如nginx、python
• 批量執行命令
• 中心化備份控制
• mysql同步

做爲配置中心，ansible的冪等性、免客戶端性能夠很友好的在操做系統交付後去實現咱們更多的個性化需求。

2.Jenkins

Jenkins做爲持續集成/交付工具，不僅是能夠在devops領域發揮重要做用，還能夠利用其強大的流水線，配合Ansible組件實現更多的參數化流程控制。

• 參數化操做系統初始化
• 參數化應用系統上線

理論上Ansible完成的終端操做，均可以利用Jenkins上線界面化的參數化構建，所以Jenkins + Ansible能夠組成一個簡易的運維平臺，實現一系列的場景化操做。

3.藍鯨

藍鯨做爲騰訊開源研發運維運維一體化平臺，它提供的CMDB、標準運維、做業平臺、故障自愈能夠豐富咱們的運維手段。可是最重要的是咱們能夠依託CMDB配置管理爲上層的服務提供可靠的數據支撐，再配合故障自愈+做業平臺接入不一樣的告警源，實現服務的故障自愈。站在巨人的肩膀上，處理問題都會事半功倍。

若是Jenkins+Ansible的功能還不夠個性化，那麼藍鯨就是咱們的備用方案，在此咱們藉助藍鯨實現瞭如下功能：

• 多環境（測試、準生產、生產）虛擬機上架，實現cmdb、zabbix、jumpserver等平臺的聯動；
• cmdb事件推送，配合python自行開發的事件推送網關，實現了以cmdb爲依據的，zabbix、cmdb資產同步；

藍鯨畢竟是一套比較重的平臺，爲此咱們並無全面接入，而是基於藍鯨的標準運維的開發框架，自行開發定義了

• Vsphere原子
• Jumpserver原子
• CMDB自動註冊原子

標準運維的原子開發要求咱們熟悉Django框架，按照開發規範，便可將咱們隔離的運維平臺進行打通。

技術棧方面除了藍鯨標準運維開發外，其餘並無什麼運維須要多高的開發能力，只須要咱們在日常使用中多總結就能輕鬆完成。若是你不信，能夠多看下個人部分專欄（公衆號最完整）：

• Ansible之路
• 藍鯨之路
• CI/CD之路
• Jenkins之路

這些專欄都是從平常中不斷總結完善的，抱着對本身負責的態度，這其實都不是難事。

運維規範

有了技術棧並不表明咱們就能夠前路暢通無阻了，相反你會發現因爲系統或配置的多樣性，你的自動化之路簡直就是步履維艱。

究其緣由就是運維沒有規範，團隊成員都有本身的習慣，沒有統一的標準規範，只會愈來愈亂。

所以咱們從基礎設施層、應用層、平臺層分別總結了不一樣的運維規範。

1.基礎設施層

• 操做系統安裝規範

  Cobbler無人值守安裝操做系統會遵循安裝規範、Vsphere虛擬機克隆等都會交付統一的操做系統；

• 操做系統配置規範

  Ansible操做系統初始化會根據此規範，完成內核參數、時間同步、安全基線、安裝源等一系列標準初始化；

• 目錄管理規範

  對基礎組件、應用組件、日誌等各個目錄進行定義，後續的一系列操做都將基於這些標準目錄；

2.應用層

應用配置管理規範，主要用於經過流水線交付應用系統時，對於依賴的一系列組件、參數進行規範化要求。在此應用管理規範只是一個統稱，在實際應用中能夠將其擴充到開發棧：

• java
• python
• php

對於每一個應用的數據目錄、日誌目錄、啓動參數、配置等各個方面進行規範。

3.平臺規範

平臺規範是咱們最後一步，由於咱們最終的操做是經過運維各個平臺去管理，若是此時沒有相關規範限制，這無疑會爲之後的某些操做留下隱患。

在此咱們建立了如下規範：

• Vsphere管理規範

  Vsphere虛擬機建立、分配、回收等生命週期的管理依據

• JumpServer管理規範

  JumpServer資產的分組、權限方面的管控

• Zabbix管理規範

  Zabbix主機羣組、主機、模板、監控間隔、告警等多方面進行管理

• CI/CD規範

  Jenkins 的job、流水線、slave節點等方面的管理

總結

在運維自動化建設過程當中，主要仍是基於運維規範、運維工具、流程控制等方面的結合，而不是分而治之。對於運維來講並無要求有很高的開發能力，所以我把此過程稱之爲接地氣的自動化建設。但願你們能夠借鑑這個初步的模型，給本身的實際工做帶來點實質性變化。

以上只是我在初步的運維自動化建設中的一些分享與看法，但願給你們可以帶來一些思路與啓發，不要兩眼一抹黑。隨着運維自動化建設的不斷深刻，就會對開發能力、平臺整理能力有了更高的要求，這時相信你的能力也會逐漸匹配，你們一塊兒加油！