筆者所在的技術(shù)團隊負責了數(shù)十個項目的開發(fā)和維護工作，每個項目都至少有dev、qa、hidden、product四個環(huán)境，數(shù)百臺機器，在各個系統(tǒng)之間疲于奔命，解決各種瑣碎的問題，如何從這些瑣碎的事情中解放出來?devops成了我們不二的選擇。

文章是基于目前的環(huán)境和團隊規(guī)模做的devops實踐總結(jié)，方案簡單易懂，容易落地且效果顯著。

實現(xiàn)方法

先來看下流程圖：

工程師本地開發(fā)，開發(fā)完成后提交代碼到代碼倉庫，[自動]觸發(fā)jenkins進行持續(xù)集成與部署，部署完成會收到結(jié)果郵件。項目運行過程中可通過日志系統(tǒng)查看程序日志，有異常會觸發(fā)監(jiān)控系統(tǒng)發(fā)送報警。從編碼到上線后結(jié)果反饋都可以工程師自主完成，形成完整閉環(huán)，運維則負責提供完整流程的工具鏈及協(xié)助異常情況的處理，工作量減少了，效率卻高了。

自動觸發(fā)jenkins部署通過svn和git的hooks來實現(xiàn)，是否自動觸發(fā)根據(jù)項目內(nèi)部溝通決定，我們目前沒有自動觸發(fā)，原因是QA在測試的過程中不希望被自動觸發(fā)的部署打斷，不過也可以方便的在jenkins上手動觸發(fā)執(zhí)行

jenkins從svn拉代碼 --> 編譯 --> JS/CSS合并壓縮 --> 其他初始化操作 --> 生成最終線上運行的代碼包，通過Dockerfile打包成鏡像上傳到docker hub，然后觸發(fā)kubernetes滾動更新

鏡像包含了基礎(chǔ)鏡像+項目代碼，基礎(chǔ)鏡像就是根據(jù)項目運營環(huán)境打包的一個最小化的運行環(huán)境(不包含項目代碼)，根據(jù)項目依賴的技術(shù)棧不同我們打包了很多不通類型的基礎(chǔ)鏡像，例如包含nginx服務(wù)的基礎(chǔ)鏡像，包含jdk+tomcat的基礎(chǔ)鏡像

如果發(fā)現(xiàn)程序上線出錯或有bug短時間內(nèi)無法解決，可通過jenkins快速回滾到上一鏡像版本，十分方便

如果發(fā)現(xiàn)流量突然增高，可以通過kubernetes快速調(diào)整容器副本數(shù)量

軟件和工具

代碼管理：svn，git

持續(xù)集成：jenkins，shell，python

Docker化：docker，harbor，kubernetes

監(jiān)控報警：zabbix，prometheus

日志系統(tǒng)：filebeat，kafka，logstash，elasticsearch，kibana

代碼管理

大部分項目還是通過svn來管理的，這里以svn為例說明，每個項目有3條代碼線，dev、trunk、releases

dev： 本地開發(fā)，開發(fā)好一個功能或task就可以提交到dev分支，同時可部署到dev環(huán)境進行自測

trunk：當一個大的功能開發(fā)完成計劃上線前合并代碼到trunk分支，QA部署到trunk環(huán)境進行詳細測試

releases：QA測試通過，項目即將上線，則將代碼合并到releases分支，部署hidden環(huán)境(仿真環(huán)境，所有配置、代碼等與線上保持一致)再次回歸，回歸通過，則上線product正式環(huán)境

有些項目是基于版本發(fā)布的，那么在代碼合并到releases之后會通過branch/tag打個tag部署到hidden測試

持續(xù)集成

這一步主要工作是按照需求把源代碼打包為最終線上跑的項目工程，大部分工作都有shell、python編寫的腳本來完成，例如去svn拉代碼、編譯源代碼、對靜態(tài)資源文件合并壓縮等等操作。利用jenkins將我們這么多分散的步驟串成一個完整的流程，運維對這一部分應(yīng)該很熟悉了，不過多介紹

Docker化

Docker是我們整個方案中很重要的一塊，可以方便的進行部署，所有環(huán)境使用同一Docker鏡像也保證了環(huán)境的統(tǒng)一，大大減少了開發(fā)環(huán)境運行正常，線上運行報錯的情況出現(xiàn)，同時可根據(jù)項目負載情況實時調(diào)整資源占用，節(jié)約成本。

Dockerfile：通過編寫dockerfile來打包鏡像

harbor：充當docker hub鏡像倉庫的作用，有web界面和api接口，方便集成

kubernetes：kubernetes(k8s)將一個一個的Docker實例給整合成了集群，方便鏡像下發(fā)、升級、回滾、增加或刪除副本數(shù)量，同時也提供了ingress外網(wǎng)訪問方式，這一塊比較重，不過我們也沒有用到太高級的功能，只是上邊提到的一些基礎(chǔ)功能，無需對k8s進行二次開發(fā)或定制，只是部署好了使用，對運維來說技術(shù)難度不大。

監(jiān)控報警

監(jiān)控報警在整個運維過程中非常重要，能未雨綢繆，減少故障的發(fā)生，加快故障的解決。這一塊也是運維的基礎(chǔ)不過多介紹了

zabbix：宿主機統(tǒng)一通過zabbix進行監(jiān)控報警

prometheus：Docker容器的運行情況通過prometheus進行監(jiān)控報警(目前還未完成)

日志系統(tǒng)

elk日志系統(tǒng)真是運維的福音，用了都說好，從此再也不用聽開發(fā)給你說“xx，幫我拉下線上的日志”。我們使用的架構(gòu)為filebeat/rsyslog --> kafka --> logstash --> elasticsearch --> kibana

filebeat/rsyslog：client端通過filebeat或者rsyslog來收集日志，filebeat是一個go開發(fā)的程序，部署起來非常方便，跟Docker簡直絕配，我們Docker基礎(chǔ)鏡像里都默認起了一個filebeat服務(wù)初始化了配置文件，后邊整合項目代碼的時候不需要額外配置;使用rsyslog的好處是大部分系統(tǒng)自帶了rsyslog服務(wù)，不需要額外安裝一個程序來收集日志，但是rsyslog要傳數(shù)據(jù)到kafka需要用到omkafka模塊，omkafka對rsyslog版本有要求，大部分系統(tǒng)需要升級rsyslog版本很麻煩，就放棄了

kafka：kafka就是為處理日志類數(shù)據(jù)而生，我們采用3臺機器做kafka集群，同時1個topic對應(yīng)多個group，避免單點

logstash：作為為從kafka取數(shù)據(jù)，過濾之后寫入elasticsearch。還在想為啥介紹kafka的時候說明1個topic對應(yīng)多個group?主要是為了一個group對應(yīng)一個logstash index，解決掉logstash這里的單點

elasticsearch：存儲過濾之后的數(shù)據(jù)，同樣采用了3個節(jié)點的集群，避免單點

kibana：可視化工具，方便的來搜索想要的數(shù)據(jù)，同事也做各種報表，一目了然

總結(jié)

1. 支持：要獲得各方的支持，項目已經(jīng)成功了一半，沒有啥事一頓燒烤解決不了的，如果有就兩頓
2. 規(guī)范：眾多的項目，龐大的系統(tǒng)，必須要有規(guī)范，規(guī)范是自動化的基礎(chǔ)
3. 文檔：實施的詳細過程、如何使用、怎么維護要保留有詳細文檔
4. 培訓：對于jenkins、elk非運維使用的工具要對使用者有相應(yīng)的培訓分享，當然運維內(nèi)部也要分享項目的種種細節(jié)