文章是基於目前的環境和團隊規模做的devops實踐總結，方案簡單易懂，容易落地且效果顯著。

實現方法

先來看下流程圖：

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

• 自動觸發jenkins部署通過svn和git的hooks來實現，是否自動觸發根據項目內部溝通決定，我們目前沒有自動觸發，原因是QA在測試的過程中不希望被自動觸發的部署打斷，不過也可以方便的在jenkins上手動觸發執行
• jenkins從svn拉代碼 --> 編譯 --> JS/CSS合併壓縮 --> 其他初始化操作 --> 生成最終線上運行的代碼包，通過Dockerfile打包成鏡像上傳到docker hub，然後觸發kubernetes滾動更新
• 鏡像包含了基礎鏡像+項目代碼，基礎鏡像就是根據項目運營環境打包的一個最小化的運行環境（不包含項目代碼），根據項目依賴的技術棧不同我們打包了很多不通類型的基礎鏡像，例如包含nginx服務的基礎鏡像，包含jdk+tomcat的基礎鏡像
• 如果發現程序上線出錯或有bug短時間內無法解決，可通過jenkins快速回滾到上一鏡像版本，十分方便
• 如果發現流量突然增高，可以通過kubernetes快速調整容器副本數量

軟件和工具

• 代碼管理：svn，git
• 持續集成：jenkins，shell，python
• Docker化：docker，harbor，kubernetes
• 監控報警：zabbix，prometheus
• 日誌系統：filebeat，kafka，logstash，elasticsearch，kibana

代碼管理

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

• dev： 本地開發，開發好一個功能或task就可以提交到dev分支，同時可部署到dev環境進行自測
• trunk：當一個大的功能開發完成計劃上線前合併代碼到trunk分支，QA部署到trunk環境進行詳細測試
• releases：QA測試通過，項目即將上線，則將代碼合併到releases分支，部署hidden環境（仿真環境，所有配置、代碼等與線上保持一致）再次迴歸，迴歸通過，則上線product正式環境

有些項目是基於版本發佈的，那麼在代碼合併到releases之後會通過branch/tag打個tag部署到hidden測試

持續集成

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

關於持續集成更詳細的介紹可以查看以下這篇文章

• 探祕varian：優雅的發佈部署程序

Docker化

Docker是我們整個方案中很重要的一塊，可以方便的進行部署，所有環境使用同一Docker鏡像也保證了環境的統一，大大減少了開發環境運行正常，線上運行報錯的情況出現，同時可根據項目負載情況實時調整資源佔用，節約成本。

• Dockerfile：通過編寫dockerfile來打包鏡像
• harbor：充當docker hub鏡像倉庫的作用，有web界面和api接口，方便集成
• kubernetes：kubernetes(k8s)將一個一個的Docker實例給整合成了集群，方便鏡像下發、升級、回滾、增加或刪除副本數量，同時也提供了ingress外網訪問方式，這一塊比較重，不過我們也沒有用到太高級的功能，只是上邊提到的一些基礎功能，無需對k8s進行二次開發或定製，只是部署好了使用，對運維來說技術難度不大。

監控報警

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

• zabbix：宿主機統一通過zabbix進行監控報警
• prometheus：Docker容器的運行情況通過prometheus進行監控報警(目前還未完成)

日誌系統

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

• filebeat/rsyslog：client端通過filebeat或者rsyslog來收集日誌，filebeat是一個go開發的程序，部署起來非常方便，跟Docker簡直絕配，我們Docker基礎鏡像裡都默認起了一個filebeat服務初始化了配置文件，後邊整合項目代碼的時候不需要額外配置；使用rsyslog的好處是大部分系統自帶了rsyslog服務，不需要額外安裝一個程序來收集日誌，但是rsyslog要傳數據到kafka需要用到omkafka模塊，omkafka對rsyslog版本有要求，大部分系統需要升級rsyslog版本很麻煩，就放棄了
• kafka：kafka就是為處理日誌類數據而生，我們採用3臺機器做kafka集群，同時1個topic對應多個group，避免單點
• logstash：作為為從kafka取數據，過濾之後寫入elasticsearch。還在想為啥介紹kafka的時候說明1個topic對應多個group？主要是為了一個group對應一個logstash index，解決掉logstash這裡的單點
• elasticsearch：存儲過濾之後的數據，同樣採用了3個節點的集群，避免單點
• kibana：可視化工具，方便的來搜索想要的數據，同事也做各種報表，一目瞭然

關於elk日誌部分，我寫有一個系列文章來介紹，這裡摘錄幾篇感興趣的點擊查看

• ELK日誌系統之通用應用程序日誌接入方案
• Logstash讀取Kafka數據寫入HDFS詳解
• ELK架構下利用Kafka Group實現Logstash的高可用

總結

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

原文：https://www.cnblogs.com/37Y37/p/11216915.html