中小團隊基於Docker的devops實踐

2021-08-21 05:11:00 字數 2365 閱讀 8540

筆者所在的技術團隊負責了數十個專案的開發和維護工作,每個專案都至少有dev、qa、hidden、product四個環境,數百台機器,在各個系統之間疲於奔命,解決各種瑣碎的問題,如何從這些瑣碎的事情中解放出來?devops成了我們不二的選擇。

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

先來看下流程圖:

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

大部分專案還是通過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將我們這麼多分散的步驟串成乙個完整的流程,運維對這一部分應該很熟悉了,不過多介紹

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:視覺化工具,方便的來搜尋想要的資料,同事也做各種報表,一目了然

支援:要獲得各方的支援,專案已經成功了一半,沒有啥事一頓燒烤解決不了的,如果有就兩頓

規範:眾多的專案,龐大的系統,必須要有規範,規範是自動化的基礎

文件:實施的詳細過程、如何使用、怎麼維護要保留有詳細文件

培訓:對於jenkins、elk非運維使用的工具要對使用者有相應的培訓分享,當然運維內部也要分享專案的種種細節

基於Transformer的目標檢測DETR

transformer之前在nlp領域大放異彩,但是在cv界平平無奇。自從eccv20這篇基於transformer的目標檢測模型detr發表以後,transformer在cv中應用的探索越來越廣泛,今天先粗淺的解讀一下這篇 剩下的慢慢學習。在目標檢測領域,faster rcnn無疑是最經典的模型之...

基於3DE平台的焊縫管理系統

一 專案背景簡介 焊縫管理在汽車 船舶 鍋爐等行業設計和生產過程中都有重要作用。尤其對於有大量焊縫的產品,應用焊縫管理系統,在設計階段,進行焊縫的型別 引數的設定,自動校對等功能,可以提高設計效率。在生產環節,利用焊縫管理系統,可以對焊縫進行分門別類的統計,完成焊材的統計計算,預先完成採購工作,縮短...

基於docker的環境搭建

docker 是乙個開源的應用容器引擎,讓開發者可以打包他們的應用以及依賴包到乙個可移植的容器中,然後發布到任何流行的 linux 機器上,也可以實現虛擬化。容器是完全使用沙箱機制,相互之間不會有任何介面。docker這種技術跟平常用的虛擬機器很相似,但相比之下更加輕量。在工程化部署專案的時候非常好...