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

概述

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

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

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

在持續集成中使用容器

構建環境統一管理

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

在持續集成中使用docker

dockerrun--rm-vpwd:/workspace-v/tmp/.m2/repository:/root/.m2/repository--workdir/workspacemaven:3-jdk-8/bin/sh-c'mvncleanpackage'

如上所示，我們可以非常方便的通過容器來完成軟件包的構建，其中有幾個點需要注意的是：

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

-v 除了將當前源碼掛載到容器當中以外，我們還可以通過掛載磁盤來緩存一些構建所需的依賴，比如maven下載的jar包，從而提高編譯效率。

--workerdir 用以指定構建命令執行的工作路徑，當然需要和workspace保持一致。

如上，基于容器我們可以快速搭建適應多種構建需求的CI構建環境，所有需要的一起就是你的構建服務器上需要的只有Docker。

在持續集成中使用docker-compose

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

當然在理想情況下我們還是希望能夠使用與真實環境一直的真正的數據庫或者其他中間件服務?；赿ocker-compose我們可以非常方便的實現對于復雜構建環境的需求。

build:command:sh-c'mvn--help'image:maven:3-jdk8links:[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-composerun--rmbuildsh-c'mvncleanpackage'&&docker-composestop&&docker-composerm-f

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

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

建立持續交付解決方案

建立基于共同目標的具有跨職能協同的研發團隊，是DevOps運動的根本。而自動化則是提高效率的基石?；谝陨衔覀兪侨绾位谌萜鹘⑽覀兊某掷m交付解決方案?

基礎設施自動化

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