1. 程式人生 > >全開源方案實現基於Docker的CI/CD流水線

全開源方案實現基於Docker的CI/CD流水線

概要

       隨著DevOps理念不斷的傳播,大部分IT從業者對於DevOps本身也有了一定的瞭解和認識,然而企業內部想根據DevOps思想實踐,這並不是一件很簡單的事情。一方面由於企業內部的歷史環境以及組織結構問題,另外一方面因為業界並沒有一套標準的開源工具集可以借鑑(關於幾家基於Docker的服務提供商暫時除外啊)。

       那麼該篇內容主要講解如何藉助開源工具結合CI/CD的場景,將Docker融入到部署單元中去,進行持續整合、測試到最終的持續部署,開發人員最終只需要去關注業務的訪問入口就可以知道業務是否正常,並可以通過一系列的監控工具去及時發現業務異常。

       在整個DevOps部署流水線中需要以下幾個部分:CI部分、CD部分、服務治理部分、監控部分、日誌部分。本篇文章將通過一個簡單的go-web應用去進行基於Docker的CI/CD流水線的測試。

     

基於Docker的CI/CD的優勢

       一個完整的流程入上圖所示,使用者(也就是開發人員)將包含Dockerfile的原始碼從本地push到Git伺服器上,然後觸發Jenkins進行構建原始碼,原始碼構建完成後緊接著進行Docker image的構建,一切構建完成之後,順帶將構建成功的image上傳到企業內部的映象倉庫,到此刻為止,其實一個基本的CI(持續整合)已經算是結束,剩下的部分就是持續部署或者進行持續的交付開發產物了。在以前傳統的軟體釋出模式中,持續整合的產物是編譯打包好的程式碼,如果想要釋出程式,釋出系統需要在持續整合的製品庫中去獲得對應的程式碼,然後根據一系列的環境檢查來準備應用的執行時環境,而在此過程中往往會涉及到比較多的基本元件依賴,所以在整體的釋出週期內來看,還是有一些問題的。在Docker或者容器時代,我們將容器的映象構建部分融入到持續整合(CI)環節,最終持續整合的產出物是一些已經處理好依賴關係,基本不需要人工進行二次干預的Docker image,而在CD環節,釋出系統只需要設定和管理很少的資訊就能夠很快將image執行起來,快速地將業務釋出出去。

       在上面整個環節中,其實無非就是增加了Docker的那一層處理,但其實在整個軟體開發的生命週期中,它是產生了極大的影響的。首先,部署系統不需要為統一的部署框架去做更多邏輯抽象,業務研發在開發程式碼的過程中選擇自己依賴的base image即可,最終執行起來的業務也就是你當時提供的base image的模樣;其次,由於base image已經處理好了相關的依賴,所以當釋出系統拿到業務的image的時候,釋出操作將會變得異常迅速,這對於網際網路時代可謂是非常重要的;最後一點,也是我感受最深的,就是研發構建好的image可以在任何的Docker環境中run起來,研發人員不需要再關係環境一致性的問題,他們在自己本地的測試環境能夠執行起來的應用,那麼到生成環境也一定可以。

        為什麼第三點我感觸比較深呢?因為以前經常有研發兄弟跑過來跟我們講,我們程式碼在本地執行一切順利,程式碼給你們上到生產就各種問題。所以如果在整個流程中使用Docker image來講所有的環境固化,從此mm就再也不用擔心和研發兄弟扯皮環境不一致的問題啦。

基於Docker的CI/CD的開源方案實現

(1) 自助Git服務Gogs的構建國產自助式的git服務

(2) 持續整合工具Jenkins的構建

注意:使用jenkins構建image和執行docker container這塊當時是使用簡單的ssh進行build、push、和run的,但jenkins本身其實是有很多plugins可以支援docker的一系列操作的,plugins的基本操作也比較簡單,這裡不做過多介紹。

(3) 通過配置nginx反向代理來訪問Gogs、Jenkins、以及測試例項

訪問jenkins.biao.com的jenkins進行構建任務:

當研發在git上重新提交了程式碼之後進行下一次構建:

至此,整個基於Docker的CI/CD流水線的流程基本完成,其實可以看到對於研發兄弟來說,每次的提交程式碼都會觸發一次編譯構建,並且最終會run起來一個新的container,並且直接對外服務。當然在整個過程中對於整合、釋出部分演示的都比較粗淺,這裡只做一個引子,對於企業內部一整套的流程運轉體系來說,光有持續整合和持續部署也是遠遠不夠的,服務上線後的基礎監控以及業務的日誌監控還有整個業務排程都是需要進行協同考慮的,而在Docker理念大行其道的今天,我們需要更深層次的去考慮實際場景中它帶給我們的優勢和劣勢,並且要思考如何和當前整體系統架構進行銜接,如何去為業務研發做更好的支援。

本篇文章為前一個月實踐所得,今天重新編輯整理,過程中有些標識做了修改,如有部分章節讀者有疑問可以隨時勾搭作者。希望有共同愛好者一起交流關於Docker方面的東西。

原文來自微信公眾號:逼格運維說