钛动利用 Zadig 完成云原生转型之路
钛动科技 (Tec-Do) 成立于 2017 年，是全球领先的基于大数据和 BI 的商业增长赋能公司。 公司秉承以服务客户为中心的核心价值观，旨在通过技术能力抽样提高全球商业运营效率，打造帮助中国企业出海的一站式服务平台。
是时候改变了
我们公司的业务主要跑在两种基础资源上，一种是传统的虚拟机，一种则是公有云的 K8s 集群。
构建部署方式是通过 Jenkins 进行打包上传到对象存储，通过 ssh 触发自定义脚本发布服务。K8s 环境则需要单独构建镜像，然后手动 apply 的方式更新服务。没有统一的开发环境，测试环境也残缺不齐。
当我们的研发人员和微服务都扩张的时候，大量痛点相继爆发：
- 开发环境的缺失让 开发联调异常艰难
- 测试环境没有统一管理且残缺不全，对新加入小伙伴非常不友好
- 开发，测试，生产的 运行环境不一致。
- 构建部署通知 流程割裂，花费时间较长
- 因为测试环境部署在虚拟机上，端口管理问题需要单独维护文档
- 实时日志查看不方便
基于以上种种原因，且刚好公司在推行服务容器化，我们对 CI/CD 的方案开始了选型。
没有最好只有最合适
对于 CI/CD 首先让大家想到的就是 Jenkins，包括我之前使用的也是 Jenkins。它的确是一个很强大的工具，有繁多的插件支持你想要做的功能。但是 对于云原生的支持就相对没有那么完善。GitLab 的 CI/CD 也是业界比较流行的方案，但是考虑到 每个项目维护的 gitlab-ci.yml 对于运维的维护不是很方便，还是没有考虑。后来有小伙伴推荐了 Zadig 这个国内云原生新平台，看别人用得不错也研究起来。
Zadig 初体验
首先说部署，官方比较推荐的方式之一是 Helm 部署的，正好我们也在推 K8s 容器化， 使用 Helm 部署极其方便。刚上手的时候使用的是 YAML 的方式来部署服务，将定义好的 K8s yaml 直接贴入或者导入到 Zadig 里面，即可在 K8s 里面启动服务。当然， Zadig 还提供了各种方便的集成，GitLab，LDAP，镜像仓库，Helm 仓库，集群管理等等，需要且必要的东西都已经集成，直接对接即可。
这是 VIP 服务？
在我们跑通 YAML 部署方式之后，我们发现还有 Helm 的服务部署方式，鉴于 Helm 中可以支持各类判断，统一修改等，所以我们决定尝试使用 Helm 作为服务发布方式。由于开始不是很理解 Zadig 上使用Helm 的逻辑，我们遇到了问题。在尝试解决未果的情况下，我们选择了向 Zadig 官方求助，我们加到Zadig 的技术交流微信群，抛出了我们的问题，没想到官方回复速度非常快，在得知我们公司在准备全面落地 Zadig 时，官方直接拉了专门群来帮助我们解决期间遇到的落地问题。
具体实施过程
第一步：基础准备和配置
- 根据语言栈创建编译构建镜像，如 Node、Gradle，Maven，Python，Go 等构建环境，并配置对接私仓，开启 Zadig PVC 缓存。
- 创建基础环境运行镜像。
- 根据项目类型创建 Helm Chart 模版托管至 Zadig
- 托管业务运行 Dockerfile 至 Zadig
- 托管每个环境的 Helm value 文件到 GitLab
第二步：对团队进行培训
通过文档，和培训会议的方式对开发和测试同事进行 Zadig 使用培训。
第三步：迁移新流程
在不影响现有流程的情况下同时在 Zadig 创建新的 CI/CD 流程，启动服务然后切换 DNS，接入新流程。 目前我们已经有 10 条业务线接入，稳定运行，满足工程师同学们的日常使用。
- 第三方集成完善，配置简单，如 LDAP ，GitLab，Harbor，Jira，Helm 等
- 强大的 数据统计功能，看清每个环节的效率和质量
- 强大的 环境复制能力，随时可以拉起新环境
- 社区活跃，问题反馈和处理的速度快
- 统一的模版管理， 降低运维管理负担
- 方便的日志查看和服务调试功能
