咱们应该如何基于容器来进行软件的持续交付（一）?

概述

在过去的一段时间里容器已经大量的使用到了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∣   给你好看

长按，识别二维码，加关注