RDC容器构建和部署服务新功能上线

摘要: 通过RDC和容器服务的集成,很好的解决了从代码提交到发布上线,及多环境流水线部署等问题

容器服务

阿里云容器服务提供了从容器构建到部署的服务。再此基础之上还提供了一系列的阿里云其它服务的集成和扩展,比如监控、日志、负载均衡等。

Devops解决方案

先探讨一下我们期望的Devops研发流程是什么样子。

Devops需求

对于一个应用A(非容器服务中的应用,而是RDC中的应用的概念),会考虑下面的点:

  1. 在进行镜像构建时,我希望运行测试;对于Java之类的编译型语言,我还需要打包。但我不希望把运行测试和进行构建的依赖(比如maven),放入镜像中。目前容器服务提供的构建服务仅支持docker build命令,因此无法在镜像构建之外再做上述的工作。
  2. 多套环境的需求,比如testingstagingproduction三个环境。容器服务本身并没有环境的概念。一种可能的方式是创建三个集群,分别对应上述的三个环境。但是这个环境是集群级别的,而不是服务级别的(通常一次发布是更新一个服务)。
  3. 对于正常的开发流程(hot fix另说)而言,我希望某个镜像先上testing,验证通过之后上staging,再验证通过之后上production。需要有一个CD流水线来现实化这个过程。
  4. 如果发布出了问题,我也希望可以快速的把某个服务回滚到之前的版本。容器服务没有回滚的概念,只有变更应用配置的概念。也就是说,用户需要记得(或者通过操作日志查询)上一次发布的镜像版本是什么,然后通过变更应用配置的入口,进行操作。
  5. 我希望在不同环境使用同一个镜像,通过环境变量来区分不同的环境。容器服务是支持的,详见查看服务详情中的配置部分

可以看到对于上述的点,单用容器服务,有些无法很好的解决。下面看看结合了RDC之后是如何解决这些问题的:

基于RDC和容器服务的Devops模式

创建应用

创建或者加入到企业之后,可以创建应用

为了满足Devops需求中的第四点,目前需要选择自由模式Git Flow模式分支模式后续也会支持。关于这几种模式的区别,可以参看研发模式 。
RDC容器构建和部署服务新功能上线

发布流水线

创建好应用,进入发布页面后,可以看到RDC预置了三个环境(日常,预发,部署),并且在正常的开发流程中,每次代码变更需要依次经过这三个环境。在这个流水线中,可以在独立的环境中进行软件包构建及单元测试等。详见:构建配置容器构建配置 。

第一个stage(版本制作),将三个环境的包和镜像都打出来。目前还不支持多个环境打一个镜像,后续RDC会支持。不过可以通过配置让三个环境的打包方式一模一样,从而达到多个镜像,但内容相同的效果。
RDC容器构建和部署服务新功能上线

 

RDC和容器服务的概念映射

RDC中有应用和环境的概念,容器服务中有集群、应用和服务的概念。这里明确一下它们之间的对应关系。

容器服务中的集群和服务在RDC中没有对应概念。

RDC中的应用(后面均称为RDC应用),是一个可以独立提供服务的应用程序及其相关信息的结合。“独立提供服务的应用”这个概念与容器服务中的服务相对应,但又不是完全匹配,事实上和容器服务的一个服务对应的是RDC中的一个环境。在RDC中这种关联关系是通过环境的部署配置完成的。如图:

RDC容器构建和部署服务新功能上线
更多信息,详见容器构建和部署中的部署配置

回滚

在流水线的右上角有一个回滚按钮,点击之后,就可以针对特定的环境进行回滚。至于该环境具体对应到哪个集群的哪个应用的哪个服务,只需要一次性配置好,之后就不需要关心了,只关注container-test-rdc这个RDC应用的不同环境的发布即可。RDC会记住某个环境的某次发布所对应的镜像地址是什么,并在回滚时,自动替换掉模板中对应服务的镜像地址,进行一次重新部署。

基于RDC和容器服务的Devops模式的一些限制

可以看到,通过RDC和容器服务的集成,很好的解决了从代码提交到发布上线,及多环境流水线部署等问题。但目前还存在一些局限,这些局限会很快解决掉。

  1. 对于发布,只支持普通发布,不支持蓝绿发布。
  2. 对于应用,只支持通过模板创建的应用,不支持通过镜像创建的应用。
  3. 不支持多个环境打一个镜像。

其它Devops方案

基于容器 HUB 的持续交付基于 Jenkins 的持续交付

查看详细容器构建和部署详细操作,点此查看

作者:阿里云RDC的持续交付技术专家 崔力强(怀虎)

原文链接:http://click.aliyun.com/m/28452/

相关推荐