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

簡述

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

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

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

• 基礎設施層，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節點等方面的管理

總結

在運維自動化建設過程中，主要還是基于運維規範、運維工具、流程控制等方面的結合，而不是分而治之。對于運維來說并沒有要求有很高的開發能力，是以我把此過程稱之為接地氣的自動化建設。希望大家可以借鑒這個初步的模型，給自己的實際工作帶來點實質性變化。

以上隻是我在初步的運維自動化建設中的一些分享與見解，希望給大家能夠帶來一些思路與啟發，不要兩眼一抹黑。随着運維自動化建設的不斷深入，就會對開發能力、平台整理能力有了更高的要求，這時相信你的能力也會逐漸比對，大家一起加油！