中小團隊基於Docker的Devops實踐

時間 2019-11-19

原文原文鏈接

筆者所在的技術團隊負責了數十個項目的開發和維護工做，每一個項目都至少有dev、qa、hidden、product四個環境，數百臺機器，在各個系統之間疲於奔命，解決各類瑣碎的問題，如何從這些瑣碎的事情中解放出來？devops成了咱們不二的選擇。python

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

實現方法

先來看下流程圖：
git

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

自動觸發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、releasesdocker

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

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

持續集成

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

關於持續集成更詳細的介紹能夠查看如下這篇文章tomcat

探祕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日誌部分，我寫有一個系列文章來介紹，這裏摘錄幾篇感興趣的點擊查看