利用容器技术构建持续交付/持续发布系统

原文连接：https://github.com/billycyzhang/containerization/blob/master/activity-sharing/ci-cd/ci-cd.md

各位好，我是希云cSphere技术总监张春源；今天和你们分享一下为什么会选择容器技术来构建持续交付/持续发布系统。

利用容器技术构建持续交付/持续发布系统

概述

提到软件发布确实是很使人头疼的一个过程，且仍是高风险动做。借用一句话：“99%的故障是因为变动引发的”。本次分享内容着重介绍使用容器技术实现自动化构建、部署和测试过程，并使得开发、测试、运维之间能更好的协做，最终能够在几个小时甚至几分钟的时间，实现可重复，且可靠的软件发布系统。

常见场景

• 在开发测试环境中测试均没有问题，但上生产环境的时候会有问题。即便咱们在开发测试环境中部署上万遍没问题，但历来没有在生产环境中部署过一次，每到在新版本发布时，你们不只要加班，并且都还很紧张。若是没有很好的回滚策略，即便发布成功了心仍是悬着。

• 移动互联网飞速发展，业务要求敏捷，要在很短的时间完成从开发到上线的任务。不少企业从开发到上生产的周期都要花好几个月的时间完成，现有IT架构跟不上业务发展。

• 软件项目开发完成后，要将开发好的版本交付到客户的环境中。目前常见的作法是按照长长的安装文档，且是经过手动安装完成，此种模式不只对安装实施人员的要求高，且出错概率很高。

构建持续交付/持续发布系统须要考虑

• 环境管理

环境包括硬件和软件，对于软件环境必定要能对硬件解耦，这样即便在硬件坏的状况下能够在很短的时间内将软件环境部署到新的硬件上。除此以外，好的环境管理方式能有效下降在生产环境中部署的风险。

实践推荐：环境的管理在项目开始的时候，开发团队和运维团队就应该全面合做，后面的事情就会变的很容易。

• 组件和依赖管理

不少系统都是由多个组件组合起来对外提供服务。组件内部要依赖库文件，组件之间也有复杂的依赖关系。一套复杂的系统部署起来依赖的处理是很是重要的。组件以及依赖关系的更新，要能以增量的形式进行，并造成不一样的版本。

• 配置管理

配置管理记录了项目演进的过程。好的配置管理系统在很是短的时间内能建立出任何的环境；批量更新线上系统的配置信息且能保证更新失败回退到能正常运行的版本；不只能知足本部门的需求一样也能知足其余部门的需求，以及不一样环境之间的需求。

• 版本管理

在持续交付和持续发布的过程当中，任何一个细节都应被记录（操做系统，中间件，代码，配置文件，依赖信息等），而且造成版本。

小提示：程序中不要把在不一样环境部署时变化的参数写死，推荐使用名称。如：链接外部数据库地址、用户、密码等信息。

• 持续交付管理

在交付的过程当中，任何缘由都有可能致使部署失败。失败不可怕，可怕的是不知道怎么失败的。明枪易躲暗箭难防道理让咱们明白，软件项目的交付要复杂的多，因此建设持续交付系统必定要创建可重复且可靠的部署流水线，较完善的配置管理系统，以及操做审计系统。问题越早发现修复起来的成本越低，且更好地保证成功的发布上线。

为什么选择使用容器

以Docker为表明的容器技术，在短短的时间内发展迅速。容器技术早在2008年已经出现，Docker公司厉害的是提供了将软件运行环境总体打包的技术-镜像。

现实中不少不标准化的交付，使用镜像均可以实现标准化。标准化之后能够更好的实现自动化，而且能更好的促进上游和下游的发展。如：开发、测试、运维之间能更好的协助，践行DevOps文化。

持续交付

原则：可重复、可靠；自动化；版本控制；团队责任；

• 可重复、可靠

镜像将软件的运行环境以及软件代码打包起来，咱们能够基于同一个镜像在不一样的环境中生成如出一辙的环境。由于容器就是进程，因此一个容器中推荐只运行一个服务。对于企业而言单容器是干不成事的，须要利用编排系统将多个镜像编排起来（镜像/版本、应用配置文件、启动优先级设置、日志处理、数据处理等）造成应用模板。经过应用模板能够重复，且可靠的将应用部署到不一样的环境中，实现持续交付第一步。

• 自动化

容器技术在持续集成方面不只仅解决了CI的问题，而且很好的解决了CD。利用容器实现持续交付区别于传统的作法是，原来开发交付出来的都是软件包和安装部署文档；利用容器技术开发人员交付的是应用模板+镜像，应用模板替代了安装部署文档，镜像技术更可靠的完成了软件包和软件运行环境的交付。并利用CI工具实现了，开发人员提交代码到代码库中，经过钩子可自动触发构建镜像。并能够对镜像以及应用作测试。

• 版本控制

容器要比虚拟机更接近应用层，从叫法上来讲虚拟机通常都叫虚拟机，但容器你们都会说是MySQL容器，Tomcat容器。容器更加细化到了应用层。上面咱们也都说到了，环境的变动，应用的版本或者是底层操做系统以及库的变动都能作到增量式的版本管理。镜像能够经过Tag来实现版本的管理，应用模板、配置文件、依赖关系等信息一样在企业实际应用中应严格要求经过版原本进行管理。

• 团队责任

DevOps不是一种工具，是一种文化。整个持续交付流程能顺利的创建起来，仅依靠一我的或一个部门基本上创建不起来。在咱们给中英人寿保险有限公司利用容器创建持续交付系统的过程深入的感觉到，须要让实际业务团队共同的参与，才真正能最大化容器的优点。容器技术是比较先进，但业务不关心先进性，重点看实际效果。因此DevOps不是我的运维或者开发人员的责任，必须是团队的责任。

利用容器实现的交付流水线：

持续发布

一切皆模板，服务于应用!

基于容器实现持续发布系统以下：

*注解：

1.开发人员将代码提交至代码仓库

2.经过钩子自动触发构建镜像流程

3.镜像构建完成后，push到镜像仓库Registry

4.有新版本进行生成，自动触发部署流程，部署至测试环境

5.测试工做完成后，标记镜像状态为成功，自动触发部署至准生产环境

6.准生产环境测试完成后，可自动或半自动部署业务