摘要： 通过RDC和容器服务的集成，很好的解决了从代码提交到发布上线，及多环境流水线部署等问题
容器服务
阿里云容器服务提供了从容器构建到部署的服务。再此基础之上还提供了一系列的阿里云其它服务的集成和扩展，比如监控、日志、负载均衡等。
Devops解决方案
先探讨一下我们期望的Devops研发流程是什么样子。
Devops需求
对于一个应用A（非容器服务中的应用，而是RDC中的应用的概念），会考虑下面的点：
- 在进行镜像构建时，我希望运行测试；对于Java之类的编译型语言，我还需要打包。但我不希望把运行测试和进行构建的依赖（比如maven），放入镜像中。目前容器服务提供的构建服务仅支持
docker build命令，因此无法在镜像构建之外再做上述的工作。 - 多套环境的需求，比如
testing，staging，production三个环境。容器服务本身并没有环境的概念。一种可能的方式是创建三个集群，分别对应上述的三个环境。但是这个环境是集群级别的，而不是服务级别的（通常一次发布是更新一个服务）。 - 对于正常的开发流程（hot fix另说）而言，我希望某个镜像先上
testing，验证通过之后上staging，再验证通过之后上production。需要有一个CD流水线来现实化这个过程。 - 如果发布出了问题，我也希望可以快速的把某个服务回滚到之前的版本。容器服务没有回滚的概念，只有变更应用配置的概念。也就是说，用户需要记得（或者通过操作日志查询）上一次发布的镜像版本是什么，然后通过变更应用配置的入口，进行操作。
- 我希望在不同环境使用同一个镜像，通过环境变量来区分不同的环境。容器服务是支持的，详见查看服务详情中的配置部分
可以看到对于上述的点，单用容器服务，有些无法很好的解决。下面看看结合了RDC之后是如何解决这些问题的：
基于RDC和容器服务的Devops模式
创建应用
为了满足Devops需求中的第四点，目前需要选择自由模式和Git Flow模式。分支模式后续也会支持。关于这几种模式的区别，可以参看研发模式 。
发布流水线
创建好应用，进入发布页面后，可以看到RDC预置了三个环境（日常，预发，部署），并且在正常的开发流程中，每次代码变更需要依次经过这三个环境。在这个流水线中，可以在独立的环境中进行软件包构建及单元测试等。详见：构建配置和容器构建配置 。
第一个stage（版本制作），将三个环境的包和镜像都打出来。目前还不支持多个环境打一个镜像，后续RDC会支持。不过可以通过配置让三个环境的打包方式一模一样，从而达到多个镜像，但内容相同的效果。
RDC和容器服务的概念映射
RDC中有应用和环境的概念，容器服务中有集群、应用和服务的概念。这里明确一下它们之间的对应关系。
容器服务中的集群和服务在RDC中没有对应概念。
RDC中的应用（后面均称为RDC应用），是一个可以独立提供服务的应用程序及其相关信息的结合。“独立提供服务的应用”这个概念与容器服务中的服务相对应，但又不是完全匹配，事实上和容器服务的一个服务对应的是RDC中的一个环境。在RDC中这种关联关系是通过环境的部署配置完成的。如图：
更多信息，详见容器构建和部署中的部署配置。
回滚
在流水线的右上角有一个回滚按钮，点击之后，就可以针对特定的环境进行回滚。至于该环境具体对应到哪个集群的哪个应用的哪个服务，只需要一次性配置好，之后就不需要关心了，只关注container-test-rdc这个RDC应用的不同环境的发布即可。RDC会记住某个环境的某次发布所对应的镜像地址是什么，并在回滚时，自动替换掉模板中对应服务的镜像地址，进行一次重新部署。
基于RDC和容器服务的Devops模式的一些限制
可以看到，通过RDC和容器服务的集成，很好的解决了从代码提交到发布上线，及多环境流水线部署等问题。但目前还存在一些局限，这些局限会很快解决掉。
- 对于发布，只支持普通发布，不支持蓝绿发布。
- 对于应用，只支持通过模板创建的应用，不支持通过镜像创建的应用。
- 不支持多个环境打一个镜像。
其它Devops方案
基于容器 HUB 的持续交付和基于 Jenkins 的持续交付。
查看详细容器构建和部署详细操作，点此查看
作者：阿里云RDC的持续交付技术专家 崔力强（怀虎