云效(原RDC)+ 容器服务完成持续集成

最近在将公司的持续集成架构做一个系统的调整,调整过程中受到了RDC团队大量的帮助,所以利用国庆时间写了几篇RDC的分享,希望能让更多的人了解和用好RDC这个产品。

我会把我最近3个月的使用体会分成5个部分:使用RDC的动机、PHP项目集成、JS项目集成、JAVA项目集成、Docker类项目集成这5个分支来写

因为近期RDC的迭代比较频繁,所以我的分享会比较的浅,点到为止,仅供参考,目录:

1、RDC如何耦合进我们的业务

2、如何构建一个基于Composer的PHP项目

3、如何构建一个基于NodeJS的前后端项目

4、如何构建一个基于Maven的Java项目

5、RDC + 容器服务完成持续集成


一、现状

在没有切入RDC之前,我们公司的持续集成主要是通过Jenkins完成,定时构建、打包、制作docker镜像,然后通过API发布到docker集群。

这套方案的优点在于:

1.只要技术能力过硬,几乎可以通过jenkins的自定义脚本实现99%的功能。相对更自由一些。

2.可以通过分布式的构建节点来降低构建压力和提高稳定性,适合大并发的构建场景。

缺点也很明显:

1.没有过多技术精力的团队,只能使用jenkins自带的功能、扩展插件来实现相关功能,较为繁琐且jenkins的界面和操作有时候确实有点反人类的,属于用起来很简单,要用好很难。

2.需要投入额外的部署、构建节点,成本,成本~

3.因为公司的服务基于docker部署,而jenkins+docker的构建和部署并非特别的好用。更关键的问题是安全,需要将相关集群的证书打入构建和部署节点,一旦被攻击,可能公司/团队就没了~


二、RDC结合阿里云容器服务实现自动迭代

阿里云目前提供了Docker的集群服务,分为3种类型,一种是阿里云自己基于原生集群改造的版本、Swarm Mode、K8S,后两个是新支持的,目前来说体验体验就好,不太建议在生产环境用。

具体的阿里云容器服务我就不介绍了,感兴趣的朋友可以去cs.console.aliyun.com开通并使用。

那么让RDC自动部署到容器服务需要如下的步骤:

1.先修改应用的流程,进入项目—-流水线,找到下图界面,点击某个流水线的修改按钮:

2.调整部署规则,可以按需要删除或添加新的部署点,环境选择已有环境,如果此处没有可用的环境,请进入 应用—–环境—-配置,进行设置,可以指定每个环境对应的docker集群、应用、服务、蓝绿发布规则等。

3.调整完成后,保存即可,然后重新运行一次流水线,就OK啦。其实还有一些更高级的用法,比如加开关,日常部署全自动,正式部署由特定权限者手动点确认才能部署等。

是不是超级简单!

部署到Docker集群的几个小坑:

1.比如你的容器应用由(nginx+code)组成,而你在RDC中部署目标设置为code,更新后可能出现nginx的link目标还是上一次的集群IP,导致fpm转发失败。这个问题,小概率出现,不知是容器的问题还是RDC的问题,大概1000次部署,遇到1次。

2.如果你的应用名称为中文,比如:门户网站前端应用,通过RDC自动部署后,容器应用名会变成?????,对使用没影响,就是看上去怪怪的,应该是2个产品的编码没协调好。


三、后记

几个分享就说到这里了,在写分享的过程中发现一些功能经常在迭代,导致反反复复修改文章,如果你在看的时候发现文章和配套搭配不了,请重新按官方文档进行理解吧~

5篇分享写的比较浅,主要用作入门,后面有时间会再写3篇进阶分享,主要聊聊如何用RDC等工具链完成一整套的持续集成工作。

文章原文出处:qipangzi.com (个人博客)

时间: 2024-12-24 11:40:30

云效(原RDC)+ 容器服务完成持续集成的相关文章

基于容器服务的持续集成与云端交付(五)- 探究持续交付系统的本质

换个角度看持续交付 在<基于容器服务的持续集成与云端交付>系列中,我们已经讨论了持续集成与持续交付给软件开发带来的变革,介绍了如何从零搭建一个持续交付系统以及在阿里云上面如何实现持续交付. 不过,在这篇文章中,我们会用一个不一样的角度来思考持续交付,到底持续交付给我们带来了什么,在容器的持续交付的场景中还缺少什么.回到本系列第一篇文章中的容器持续交付的流程图: 这张图中描述了一个基于容器的持续交付的流程,它定义了几个阶段,本地开发阶段.持续集成阶段.持续交付阶段等等,规定了在每个阶段中该做什么

基于容器服务的持续集成与云端交付(二)- 多维度打磨交付能力

前言 在上一篇中,和大家一起讨论了传统软件交付的问题.持续交付的难点.以及为什么云端的容器交付可以协助大家快速的持续交付. 但是当真正的将一个系统通过云端容器交付的时候会发现不能单纯的将Docker作为一种交付工具来对待,更多的时候是作为一个交付平台的基础设施来看待,还需要关心的是使用Docker后网络.存储.安全.性能.监控等等不同方面带来的变革. 因为交付的本质是将一套复杂的软件系统从零到一完成开发.测试.部署.上线的过程,软件的复杂度直接关系到了交付的难度,特别是现在微服务的架构方式越来越

基于容器服务的持续集成与云端交付(一)- 交付之禅

前言 随着微服务架构与容器虚拟化技术的发展,持续集成与持续交付的概念又重新回到了大家的视野,越来越多的公司开始使用持续集成的系统来解决频繁发布带来的质量问题:使用持续交付的工具来实现代码在不同环境上的自动部署.原本有些学院派乌托邦式的思想正被千千万万次的集成与部署证明着它应有的价值.那么究竟是因为什么让持续集成与持续交付这个已经不再年轻的软件开发与交付的思想重新焕发绽放迷人的光彩呢? 传统软件交付之殇 传统软件的开发与交付的周期都很漫长,一款普通的企业软件通常需要十几个开发人员,几个月的时间来完

基于容器服务的持续集成与云端交付(四)- 多种发布方式

前言 哲学有各种各样的流派,百家争鸣,但是只有一个哲学问题是严肃的,那就是生与死.而云端交付过程中也只有三个问题是严肃的. 如何重建你的系统 How to recreate your system? 如何安全地部署你的系统 How to safely change your system? 部署后的问题监控与解决 When something has gone wrong? 在前面的文章中,我们讲述了什么是云端交付,如何搭建从零搭建一个持续交付系统,而今天我们要谈的是如何安全的部署你的系统,部署

基于容器服务的持续集成与云端交付(三)- 从零搭建持续交付系统

前言 在上一篇文章中讨论了容器服务提供的交付能力,在本文中我们将讨论如何从零搭建一个持续交付系统. 对于大多数公司而言,选择一个合适自己的持续交付系统是尤为重要的一件事情,不同的公司.不同的业务使用的场景也各不相同,因此要根据自己的业务场景与发展方向来选择合适的方案.根据不同的业务场景与交付方式,阿里云容器服务提供了三种不同的持续交付方案. 基于Jenkins的持续交付方案 基于Jenkins的持续集成和持续交付方案是所有方案中最灵活.能力最强的方式,但也是需要客户自主运维的方案.对于现有提供持

在阿里云HPC上用容器服务一键部署和运行WRF解决方案

背景 众所周知,容器技术的出现深刻改变了软件交付的方式: 敏捷: 秒级应用启动.轻量级隔离.细粒度资源控制.低性能损耗 标准化:版本管理可追溯. 可移植性: 环境无关的交付.部署方式:可用于软件生命周期中不同运行环境.这些能力不但影响了企业软件的开发.构建和交付模式,提高了交付效率和可靠性,也对于像WRF(Weather Research Forecast)这类大型开源气象科学预报软件产生了潜移默化的影响.美国国家大气研究中心(NCAR,也是WRF的开发方)于2016年开源了自己的容器化解决方案

大叔公开课~微服务与持续集成

闲话多说 免费报名:http://www.genshuixue.com/teacher/classCourseDetail/171117794648 .Net Core来了,带给我们的是什么?跨平台,无疑是最大的亮点! Docker横空出世,让开发者和运维者都尝到了甜头! Jenkins持续集成,功能包括了持续的软件版本发布与测试,让开发人员专心关注自己的代码开发,让运维人员专心写部署代码,一次性工作,从来不要反复的做一件事! 云时代来了,容器时代了,面向应用的微服务也来了,麻烦也就跟着来了,我

微服务的持续集成,四步“构建”一个代码世界

本文讲的是微服务的持续集成,四步"构建"一个代码世界,大师Martin Fowler对持续集成是这样定义的:持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成.每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽快地发现集成错误. 今天我们就来聊一聊微服务的持续集成. 目录 一.持续集成之构建 二.持续集成之部署 三.持续集成之测试 四.持续集成之发布 五.总结 一.持续集成之构建 当微服务产生

【狂云歌之unity_vr】unity项目持续集成dailybuild以及多平台打包管理

[狂云歌之unity_vr]unity项目持续集成dailybuild以及多平台打包管理 前言  持续集成的意义就不多说了.unity通常打包一般就直接build&run,但是在实际项目中,往往直接在服务器build包,所以命令行打包必不可少,这里一方面分享unity打包做持续集成,一方面分享使用unity管理多平台打包,例如一个vrapp需要支持gear版本,支持小米版本,支持cardboard版本等等~懂的人就知道这里具有一定的管理维护成本.  我们做vr相关的app,需要支持gear.ca