一、背景
在开发发布系统之前我们的CICD用的是某开源持续发布平台。整个流程大概是这样的&＃xff0c;新项目首先要在流程系统录入应用、角色、构建参数、部署参数等基本信息&＃xff1b;代码更新后&＃xff0c;开发/测试会通过公司的流程系统或者jenkins进行线下环境的打包构建和发布(本质都是调用发布系统的api)&＃xff0c;然后生产环境由SRE到发布系统上操作。但是这种方式其实存在很多问题&＃xff0c;主要概括为以下几点&＃xff1a;
没有权限管理&＃xff1a;只要知道发布系统地址&＃xff0c;就可以操作任何环境的发布&＃xff1b;
发布入口多&＃xff0c;存在多套CICD方案&＃xff1a;流程系统、jenkins、开源发布系统都可以操作&＃xff1b;
由于镜像版本名称设计问题&＃xff0c;没有办法支持真正意义上的回滚&＃xff0c;这样的回滚可能带来的是一次新的发布&＃xff1b;
配置不够透明和清晰、入口很多&＃xff0c;出现问题SRE排查困难&＃xff1b;
开源发布系统的功能很少而且二次开发成本高&＃xff0c;很难根据具体使用情况定制相应功能&＃xff1b;
为了解决以上问题&＃xff0c;我们重新设计了一套基于K8S的发布系统。
二、发布系统流程介绍
1、发布前配置
对于一个新的应用接入发布系统&＃xff0c;SRE需要提前进行一些配置&＃xff0c;这些配置只需要在应用接入的时候配置一次&＃xff0c;后面可以进行修改。
绑定或者自定义pipeline&＃xff0c;并配置CI参数
我们的CI过程是通过调用Jenkins完成的。Jenkins pipeline的配置在发布系统统一维护&＃xff0c;由CI-admin进行管理&＃xff0c;可以为每个应用制定个性化的Pipeline也可以使用通用Pipeline。
绑定Pipeline后&＃xff0c;就可以执行构建操作了&＃xff0c;一些经常修改的构建参数可以暴露给开发&＃xff0c;例如分支、构建命令、sonarqube构建命令等。
配置CD参数&＃xff1a;例如各个环境的存储、探针、资源限制、环境变量、副本数、边车版本等。
CD配置之后就可以交给开发进行部署
2、构建和发布
我们的CICD过程是解绑的&＃xff0c;两者互不影响。因此可以更好的支持‘一次构建、多次发布’&＃xff0c;也就是说每次的发布开发只要构建一次生成镜像&＃xff0c;在部署各个环境的时候&＃xff0c;都可以选择相应的版本。对于不同环境的一些差异化的配置&＃xff0c;可以通过CD配置的环境变量传入。我们的发布系统还支持同一环境部署多个子环境&＃xff0c;方便应用的多版本测试&＃xff0c;并且支持滚动发布和蓝绿发布两种发布方式。
发布&＃xff1a;
对于生产环境&＃xff0c;我们给开发配置应用的发布权限&＃xff0c;支持开发自助发布。但是要申请工单&＃xff0c;在申请工单时候要填写镜像版本等信息&＃xff0c;之后由测试、owner、sre层层确认审批完成后&＃xff0c;就可以简单的通过点击工单部署了。
此外&＃xff0c;发布到生产环境是有限制的&＃xff0c;我们要求发布到生产的版本需要在test以及stage环境部署成功&＃xff0c;否则在申请工单的时候根本不会显示该镜像版本&＃xff0c;这样可以最大限度的减少生产发布出现问题。
每个应用都会拉一个企业微信群组&＃xff0c;工单审批信息和部署结果等信息都会发到群组中&＃xff0c;SRE可以通过群组中的消息跟踪发布过程&＃xff0c;以便有问题时可以及时介入处理。
3、问题处理
发布出现问题怎么办&＃xff1f;我们支持回滚策略&＃xff0c;可以快速回滚到稳定版本&＃xff1b;对于问题的排查我们也提供一些功能来支持&＃xff0c;可以通过部署日志查定位出现问题的阶段&＃xff0c;如果是应用报错可以通过应用日志和远程终端查看具体原因。
部署日志&＃xff1a;
应用日志&＃xff1a;
远程终端&＃xff1a;
三、其他功能
除了持续发布的功能&＃xff0c;还支持K8S管理功能&＃xff1a;
volume模版管理&＃xff0c;可以设置glusterfs、pvc、nfs、emptydir多种类型。
证书管理&＃xff0c;为发布系统添加多个集群以及集群证书。
域名管理功能&＃xff0c;可以配置和修改ingress信息&＃xff0c;避免在服务器上随意手动创建和修改&＃xff0c;此功能也解决了之前域名配置混乱的问题&＃xff0c;开发和SRE都可以一目了然的看到应用域名。
隔离配置功能&＃xff0c;可以为重点应用和产线单独配置资源&＃xff0c;与其他应用隔离&＃xff0c;页面修改方便。
代码质量管理&＃xff1a;增加了代码质量管理功能&＃xff0c;配置和测试命令由发布系统维护&＃xff0c;在CI构建过程中自动触发代码质量扫描&＃xff0c;并回调扫描结果显示在每个应用界面&＃xff0c;方便开发人员查看代码质量指标的具体数值和变化趋势&＃xff0c;以便提升代码质量。
四、总结
我们的发布系统不仅解决了之前的CICD系统遇到的问题&＃xff0c;还增加了很多便利的功能。尤其是自助发布和终端等功能解放了SRE&＃xff0c;减少了琐事的处理&＃xff0c;可以让SRE把更多精力放到项目建设上。总结起来特点如下&＃xff1a;
CICD解绑&＃xff1a;区分CI和CD&＃xff0c;例如&＃xff1a;如果仅仅是K8S问题影响部署失败不必重新构建镜像&＃xff1b;支持“一镜像多环境部署”&＃xff0c;节省时间和资源&＃xff1b;
阶段化和自定义CI&＃xff1a;Jenkins pipeline通过发布系统来管理&＃xff0c;分为检查参数、编译、构建镜像等阶段&＃xff0c;方便定位问题&＃xff1b;支持个性化CI配置&＃xff0c;不只是每个语言绑定一个pipeline&＃xff0c;而是可以为每个应用设计不同的个性化pipeline。
权限管理&＃xff1a;分为dev、qa、SRE、ci_admin、admin、k8s_admin、deployer等角色对应相应的权限&＃xff1b;
发布记录和构建记录&＃xff1a;每一次构建、发布和镜像的详细参数都有记录&＃xff0c;出现问题容易回溯&＃xff1b;
版本控制&＃xff1a;镜像版本管理&＃xff0c;每一次生成镜像的版本都是独一无二的&＃xff1b;配置版本管理&＃xff1a;资源配置、探针、环境变量、存储的每一次变更都有对应的版本记录&＃xff1b;更好的支持回滚&＃xff1b;
发布入口收口&＃xff1a;所有CI、CD参数包括Jenkins Pipeline都是通过发布系统来配置&＃xff0c;所有人员的发布相关操作也都通过发布系统完成&＃xff1b;
自助发布&＃xff1a;开发能够自助发布生产&＃xff0c;解放SRE&＃xff1b;
多种发布方式&＃xff1a;支持滚动发布、蓝绿发布&＃xff1b;
线下环境多版本管理&＃xff1a;支持同一环境部署多个子环境&＃xff0c;方便应用的多版本测试&＃xff1b;
远程终端&＃xff1a;进入容器排查问题&＃xff1b;
K8S管理
代码质量管理&＃xff1a;构建过程触发代码质量检查&＃xff0c;支持查看代码质量基本指标的数值和趋势&＃xff1b;
注&＃xff1a;本来是之前要写的【基于K8S的发布系统设计】&＃xff0c;但是同事说我这不是设计思想是使用方法&＃xff0c;所以我改标题了&＃xff0c;来凑一下本周自己给自己定的任务。额.......我觉得从这个“使用方法上”还是可以看出来一丢丢的设计思想的。
京公网安备 11010802041100号