我们为什么选择使用分布式持续交付新星 Zadig ?
编者荐语: 惊喜地看到社区小伙伴向 “Github 爱好者 " 投稿一篇,来瞅瞅他看上 Zadig 啥了。
以下文章来源于 Github 爱好者 ,作者 Alan Wang
简介:
Zadig 是一款分布式持续交付产品,由 KodeRover 公司基于 Kubernetes 自主设计研发,具有产品持续交付、持续测试、持续追踪的全流程能力,业务架构图:
为什么选择 Zadig ?
原来是使用 Jenkins 做的交付,结合 kustomize 也能实现基于 k8s 编排应用的丝滑交付。我们考虑其他工具的出发点一方面是:新增一个环境的话配置对应的交付任务也比较复杂;另一方面是:为了方便测试和开发同学,作为一个交付系统来说,Jenkins 是足够胜任的,但是并不能很好的展示被交付应用的运行状态、日志等,还需要其他工具或者系统去看应用运行是不是正常、查看日志等,所以考虑是否有开源的产品可以满足需求,经过一顿找找找,Zadig 凭借着出色的能力,在一众选手中杀出重围,另一个有力的竞争者是云效,云效是阿里云的 PaaS 应用,基于阿里云能力栈可完整覆盖整个应用的生命周期,简单说明如下:
Zadig 核心优势:并发工作流(云效并发任务大于 6 的话需额外购买)、更灵活 & 维护成本更低(构建与部署过程可高度个性化定制,公共配置可复用)、100% 开源(私有化部署,不强耦合指定云厂商);
云效核心优势:产品线更全(覆盖应用全生命周期)、功能开箱即用、更完善的发布策略(分批发布、灰度发布、蓝绿发布,且发布过程可控);
Zadig 产品团队 KodeRover 官方公众号
结合需求和当前运维现状,权衡后选择了 Zadig,可用的核心功能:
高并发的工作流:基于云原生实现多环境、多服务的高效并发交付;
灵活的集成环境:跨环境共享服务配置,通过参数化实现隔离业务数据和访问入口区分,可以在数分钟内创建一套隔离的全新测试环境;
兼容性好:无缝集成 GitHub/GitLab、Jenkins、多家云厂商等;
无侵入的自动化测试:支持对接已有的自动化测试框架,通过 GitHub/GitLab WebHook 自动触发测试任务;
开发本地联调 CLI:支持通过 IDE 插件远程调试本地代码、日志查看等功能;
落地过程
安装
Zadig 提供云上测试环境(非常 Nice):https://os.koderover.com/
官方提供完善的安装文档,并且有微信群进行全方位技术支持 👍👍👍,这里只提一下推荐使用外部高可用的数据库、存储来提高部署安全性。
使用
集成外部系统:ldap(用户管理)、gitlab(代码管理)、oss(保存缓存文件)、镜像仓库(保存镜像制品);
将业务线的各个环境拆成不同的项目隔离管理;
项目初始化流程:项目 >> 服务 >> 环境 >> 构建 >> 工作流交付。
价值
并发工作流显著提高了发布效率;
很好的满足了落盘和 Stdout 日志查看的需求;
使拉起一个新环境的成本大幅度降低;
自测模式使低成本高效率的开发联调成为可能。
不足
在 v1.11.0 版本中,存在以下略影响使用体验的点:
zadig 暂不兼容 kustomize,提供了模板库功能实现公共配置抽离和复用,缺点是只适合服务初始化使用,更新模板后需要逐个手动应用到服务(批量更新功能预计 v1.12.0 上线);
构建配置目前不支持复用(服务和代码仓库强关联),每个服务就需要单独创建一个构建,同类服务的构建过程其实就一个代码仓库不同其他完全一致,也就是说 90% 的配置工作都是多余的;相关优化功能 zadig 开发团队已经在计划中,后续版本会解决这个问题;
服务编排里任何改动都会重建 deployment 的 rs、重建 pod,一些资源对象比如 pdb、hpa 这种仍倾向于手动维护。
展望
我们目前已经接入了多个环境的数百个前后端微服务的交付,顺利进行了数千次部署交付,Zadig 漂亮的界面(可强 Jenkins 太多了~)和易用性也得到了测试和研发同学的肯定。作为一个懒人,希望 Zadig 在配置复用上再改善一些,虽然可以自己开发脚本通过 API 实现很多重复配置的自动化,我们落地过程中就开发了脚本实现:服务、构建、用户权限分配等功能的批量管理,极大降低了配置成本;但还是希望 Zadig 能提供原生功能实现,降低大家的使用成本。服务编排里面的改动会造成不必要的 pod 重启的问题,也希望 Zadig 后面能有解决方案。
Zadig 已经很出色了,未来可期,共勉。
版权声明: 本文为 InfoQ 作者【KodeRover】的原创文章。
原文链接:【http://xie.infoq.cn/article/c404e38bc99d6d25cf505637d】。文章转载请联系作者。
评论