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