咱們應該如何基於容器來進行軟件的持續交付（一）?

概述

在過去的一段時間裏容器已經大量的使用到了IT軟件生產的各個環節當中：從軟件開發，持續集成，持續部署，測試環境到生產環境。

除了Docker官方的Docker Swarm, Docker Machine以及Docker Compose之外，開源軟件社區還涌現了一系列的與容器相關的工具，涵蓋了從容器編排，調度，監控，日誌等等各個方面的需求。

本文將從針對軟件研發流程，基於容器解決軟件的持續交付問題，以及團隊協做問題。

 

 

           在持續集成中使用容器      

 

 

構建環境統一管理

在傳統模式下使用持續集成工具諸如Jenkins，在部署企業持續持續集成平臺的第一個問題就是多樣化的構建構建環境需求，而一般的作法是將構建Agent（服務器或者虛擬機）分配給團隊由團隊本身管理構建服務器的環境配置信息，安裝相應的構建依賴等。

 

在持續集成中使用docker

docker run --rm -v `pwd`:/workspace -v /tmp/.m2/repository:/root/.m2/repository --workdir /workspace  maven:3-jdk-8 /bin/sh -c 'mvn clean package'

如上所示，咱們能夠很是方便的經過容器來完成軟件包的構建，其中有幾個點須要注意的是：

• --rm 命令能夠確保當命令執行完成後可以自動清理構建時產生的容器，我想你應該不太但願須要不按期清理構建服務器磁盤的問題吧。

•  -v 除了將當前源碼掛載到容器當中之外，咱們還能夠經過掛載磁盤來緩存一些構建所需的依賴，好比maven下載的jar包，從而提升編譯效率。

•  --workerdir 用以指定構建命令執行的工做路徑，固然須要和workspace保持一致。

如上，基於容器咱們能夠快速搭建適應多種構建需求的CI構建環境，全部須要的一塊兒就是你的構建服務器上須要的只有Docker。

 

在持續集成中使用docker-compose

在某些狀況下，在構建或者集成測試階段咱們可能須要使用到一些真正的第三方依賴，好比數據庫或者緩存服務器。在傳統的持續集成實踐中，一般要麼你直接使用已經部署的數據庫（記得清理測試數據，併發如何保證），直接使用內存數據庫來代替真實數據庫，要不使用mock或者stub來進行測試。

固然在理想狀況下咱們仍是但願可以使用與真實環境一直的真正的數據庫或者其餘中間件服務。基於docker-compose咱們能夠很是方便的實現對於複雜構建環境的需求。

build:  command: sh -c 'mvn --help'  image: maven:3-jdk8  links: [mysql]  volumes:
   - '.:/code'
   - '/tmp/.m2/repository:/root/.m2/repository'  working_dir: /codemysql:  environment: {MYSQL_DATABASE: test, MYSQL_PASSWORD: test, MYSQL_ROOT_PASSWORD: test, MYSQL_USER: test}  image: mysql:5.5

一樣咱們以maven爲例，假設咱們須要在構建中使用到mysql以支持集成測試的需求

docker-compose run --rm build sh -c 'mvn clean package' && docker-compose stop && docker-compose rm -f

• --rm 確保在構建命令執行完成後自動清理build所產生的容器。

• - docker-compose stop && docker-compose rm -f 確保依賴的其它服務如mysql可以正常的退出而且清理所產生的容器。

 

 

 

 

    創建持續交付解決方案   

 

 

創建基於共同目標的具備跨職能協同的研發團隊，是DevOps運動的根本。而自動化則是提升效率的基石。基於以上咱們是如何基於容器創建咱們的持續交付解決方案？

基礎設施自動化

使用Rancher理由很簡單，Rancher是目前市面上惟一一個能知足開箱即用的容器管理平臺，同時可以支持多種編排引擎，如Rancher本身的Cattle，Google的K8S,以及Docker官方的Swarm做爲容器編排引擎。同時Rancher提供的Catalog應用商店可以幫助研發團隊自主建立所須要的服務實例。

 

 

建立持續交付流水線

創建持續交付流水線的核心問題是如何定義企業的軟件交付價值流動。

以下圖所示，咱們總結了從開發，持續集成，持續交付各個階段所使用的一些典型工具的使用，以及在各個階段中的相關團隊的相關活動，典型的DevOps相關的活動。

 

 

在持續交付流水線下的團隊協做

正如上文所說，建立持續交付流水線的本質就是定義軟件的交付的價值流動，反應正式的軟件交付流程。價值的流動則涉及到團隊中各個職能的成員的高度協同。

 

 

基於容器的持續交付實踐當中以鏡像做爲在不一樣職能人員之間的價值傳遞物。

 

• 開發人員：頻繁提交持續集成，經過持續的編譯，打包，測試，鏡像構建，自動化驗收測試等環節產生可測試的候選鏡像列表(如：0.1-dev)。

• 測試人員：從候選測試鏡像列表中，選擇須要測試的目標鏡像，標記爲測試版本(將0.1-dev標記爲0.1-test)，而且將待測試鏡像自動部署到驗收測試環境，完成手動探索性測試，對於已測試完成的鏡像標記爲預發佈版本(0.1-test 標記爲 0.1-beta)。

• 運維人員：從預發佈鏡像列表中選擇鏡像部署到預發佈環境，而且在驗證經過後標記爲release版本（如將0.1-beta 標記爲 0.1-release）,而且發佈到生產環境。

在基於容器的持續交付實現方案當中，咱們以鏡像爲價值傳遞的單元，經過鏡像的持續測試以及驗證，完成鏡像從開發，測試到可發佈的狀態轉變，完成軟件的交付流程。

 

Wise2C∣   給你好看

長按，識別二維碼，加關注