- 面临的 DevOps 需求
- CI/CD 规划概览2.1 架构总览2.2 关键技术
2.3 总结
- CI/CD 工具及实践3.1 工具及流程概览3.2 实践说明
- CI/CD 流程总结
- 未来规划
01
“ 「面临的DevOps需求」 ”
随着客户要求迭代速度的加快,公司的项目管理、交付管理面临了来自公司内外部的巨大挑战。
公司目前需要管理很多客户项目和自身迭代产品项目,产品使用 Go、Java、NodeJS等多种技术栈的多个分支的代码项目。而且每周需要交付多个测试版本进行持续验证。同时,还要应对客户现场的紧急版本修复、客户定制版本交付等场景。
解决上述问题的核心就是要提升效率,加快交付速度。
02
“ 「CI/CD规划概览」 ”
2.1 架构总览
结合 Kubernetes 的一些基础理念和特性,综合考虑容器 PaaS 平台、微服务治理平台在 DevOps 的需求,并融合企业内部已有的 CI/CD 等工具,自主实现了一套更适合于云原生应用平台的 DevOps 服务体系。基本的技术架构及实现方式如下图所示:
上图中,代码仓库中的代码会被 Job 创建在构建节点上的 Pod 的容器拉取,并执行编译、单元测试、扫描、打包,制作镜像、 Push 镜像等操作后,这个 Pod 就会被销毁。容器日志会被节点的 Agent 发送到日志服务中心,可以提供容器被销毁后的日志查询。也可以使用 CronJob 执行定时任务。
该方案具备以下优势:
- 不需要单独部署复杂的高可用 CI/CD 服务,比如 Jenkins 集群等,简化了部署管理的复杂度。
- 构建任务均通过镜像进行封装,并在容器中进行,接口更加标准、透明。
- 对构建任务的资源、限额、日志、监控、告警、计费等诸多能力可以直接利用PaaS 平台,而无需重复开发,PaaS 未来的能力也可以直接为 DevOps 服务。
- 可以通过容器 PaaS,让构建任务具备更高级的调度能力。
- PaaS 层对底层资源的弹性伸缩也可以为 DevOps 服务,对构建资源进行伸缩策略的定义,实现构建资源的弹性。
- 对 DevOps 平台的管理运维可以同容器 PaaS 一致,没有额外的学习成本。
- 通过容器、镜像等标准概念,对构建任务进行封装,并快速实现 DevOps 的构建模版,使得 DevOps 平台通过自定义模版具备更好的扩展能力。
2.2 关键技术
2.2.1 技术要点
这种架构模式下,可以把每一个构建任务通过 Pod Spec 来进行描述,相关的构建任务能力可以通过以下方式映射到 Pod Spec 中。
同样道理,结合上层的 Job/CronJob,我们就可以控制构建的执行策略,比如构建任务期望的并⾏执⾏的最⼤ Pod 数量,期望的成功完成的 Pod 数量,从 Job 创建到活跃状态的超时时间(默认 12 ⼩时),标记 Job 为失败前的最⼤重试次数,默认 = 6;以及通过 Cron 格式的任务计划定义,Job 执⾏的并⾏策略,是否暂停后续执⾏,保留运⾏成功/失败的历史 Job 的数量。
2.2.2 实践举例
这里举两个例子,来说明时速云 DevOps 平台中每个构建任务的工作原理:
构建 Docker 镜像,也就是我们经常使用的从代码生成镜像的任务模版,其基本工作方式如下:
每个构建任务都是一个 Job,会按照用户传递的信息组装成 Job 的结构,并由 K8s 调度并执行,有 DevOps Manager 管理 Job的运行情况。其中使用了 InitContainer、Volume、Secret 等多种 K8s 资源。
服务持续部署,平台提供了镜像部署、应用模版部署、Spinnaker、时速云 DevOps 平台集成、应用包部署、服务状态检查等多种持续部署相关模版,通过灵活组合使用,可以满足几乎所有场景下的持续部署需求。如下图所示的基本工作流程,我们会把不同部署方式封装成对应的镜像,并提供可视化配置界面供用户使用。
同样,我们也提供了忽略某个构建任务的执行,某个构建任务失败时速云 DevOps 平台继续执行,指定构建节点,自定义构建任务所需资源,当然也支持构建任务使用 GPU 资源,进行机器学习相关的时速云 DevOps 平台处理能力。
2.3 总结
借助 Kubernetes 自动编排、自动回收资源的机制,减少了人工干预。结合 Kubernetes 提供的丰富的资源类型,CI/CD 解决方案也有了更多的选项和思路。仿佛 Kubernetes 是为 CI/CD 专门定做的。
03
“ 「CI/CD工具及实践」 ”
3.1 工具及流程概览
我们的 DevOps 工具链有 Jira, Gitlab, 时速云 DevOps 平台,Sonarqube, TestLink, Harbor
- Jira: 项目管理;
- Gitlab: 代码托管、在线 Review;
- 时速云 DevOps 平台:基于 Kubernetes 的代码拉取,编译,代码扫描,单元测试,打包,构建镜像、持续部署,审批,邮件;
- Sonarqube:代码静态扫描;
- TestLink: 测试管理;
- Harbor: 镜像托管,镜像安全扫描;
流程如下:
3.2 实践说明
3.2.1 需求/缺陷管理
需求和缺陷管理我们使用功能强大的 Jira 工具,以两周一迭代方式进行敏捷式开发。
3.2.2 代码 Review/Merge
聊天工具集成 gitlab,PR 提交后 Reviewer 及时看到提交信息,进行 Review 和Merge。
3.2.3 Gitlab触发自动化构建
时速云 DevOps 平台自动生成 Gitlab 项目的 webhook, 当 gitlab 有事件发生,把事件信息发送到时速云 DevOps 平台,时速云 DevOps 平台根据条件触发自动执行构建。
3.2.4 时速云 DevOps 平台
3.2.4.1 流程简介
时速云 DevOps 平台基于 Kubernetes 和 Docker 运行具体任务,由 Kubernetes 调度、执行完后销毁。每一个任务模板最终生成 Kubernetes 的 Job,Job 会生成 Pod 运行任务, 并管理生命周期。
每个任务模板镜像都有为自身任务的最小化工具。比如 maven 任务镜像只有 maven 客户端命令工具,容器被 job 生成时,会通过进入点运行 maven 命令,运行结束后将结束容器。代码扫描任务会有 sonar-scanner 客户端工具,Docker 构建任务可以运行Docker build 命令构建镜像和 Push 镜像到 Harbor。
镜像推送到 Harbor 后会使用平台持续部署任务模板更新服务。
持续部署成功后服务会被升级到最新版本。
3.2.4.2 任务模板
时速云 DevOps 平台的任务模板是为执行任务的镜像和数据集合。
sonar 扫描任务为例,sonar 扫描任务执行就是容器化运行 sonar-scanner。
下图为 sonar 扫描任务的 Dockerfile, 就是把代码和 sonar 扫描配置文件拷贝到指定目录,运行 sonar-scanner 命令。
执行结果以 Rest API 方式发送到平台,平台记录执行结果,并根据设置执行下一步任务或失败退出。
3.2.5 集成测试
测试有测试用例,测试用例有测试结果,如果测试结果与期待结果不符,同步到 Jira, 再执行编码的步骤,形成一个闭环。
测试用例和测试版本的测试结果使用TestLink工具管理。
集成测试是人工测试和基于 Selenium 的 python 脚本的自动化测试共同完成。
3.2.6 Harbor 同步
测试人员进行测试通过以后,使用 Harbor 镜像同步功能,同步到运维环境 Harbor。
3.2.7 Harbor 镜像更新后通过触发设置触发执行部署任务
harbor的common/config/registry/config.yml设置notification属性为时速云 DevOps 平台 webhook 地址和认证方式,时速云 DevOps 平台可以根据 payload 信息触发执行 CI/CD。
3.2.8 部署运维服务
时速云 DevOps 平台被触发执行后,与上面部署一样会根据新的镜像更新部署新的服务。
3.2.9 自动标记 Jira
集成测试结束以后,通过 Jira API , 把 gitlab 中的大括号里相应的 Jira issue 为关闭状态,添加部署版本说明。
3.2.10 保障代码和最终交付产物的源头一致性
如下图,在代码构建时把代码的版本信息一同写入镜像可以做到最终交付产物和代码源头的一致性比较。
git rev-parse –shortHEAD > .gitversion
git log–pretty=oneline HEAD…$PREVIOUS_COMMIT_ID > .gitdiff
04
“ 「CI/CD流程总结」 ”
- Jira, Gitlab, TestLink, Harbor 等工具的集成、 Kubernetes 特性和各组件的灵活使用、自动化构建流程使得 CI/CD 流程缩短了交付时间。而且从代码到最终交付产物的可验证性,需求到代码和 Bug 到代码的可追溯性,提高了效率。
- 对于公司服务器的计算资源也使得因 Kubernetes 的机制发挥到优先资源下灵活应用,让各个团队避免了因为计算资源不够等待资源的情况
- Kubernetes 的良好机制,使得公司有限服务器资源下灵活应用,让各个团队避免了因为计算资源不够等待资源的情况。
- 时速云 DevOps 平台任务模板容易扩张、可以快速集成其他第三方工具,也为管理、测试、研发团队快速提供需要的工具集成。
- 时速云 DevOps 平台任务模板的最小化,节省了资源,节省了费用。
- 对部分开源项目的修改和贡献也提高了工作的效率。比如修改 Harbor 的用户账户体系和验证方式与平台一致,减少了用户在交付中镜像账号的额外管理。修改 TestLink 源码,实现一键创建 Jira Bug ,自动使 Jira 项目管理与测试管理工具互相追踪,方便查看与管理。
当然我们的 CI/CD 流程还有很多不足,比如缺少 ChatOps 等更方便的功能、对已有流程复盘并优化、还需要集成更多 CI/CD 工具等。
05
“ 「未来规划」 ”
1) 随着 Kubernetes 的版本升级,提供了更多的功能,这些功能是否能让我们的 CI/CD 更灵活。比如 Node、Pod 的亲和性设置,部署容器启动先后顺序设置等。
2) 提供 ChatOps 功能,通过集成提供 API 的聊天工具。
3) 与更多的 DevOps 工具集成,包括 GitInspector 等。
4) 对开源工具的优化,以及对开源社区的贡献。比如 TestLink 等还有很多缺陷,集成时会遇到需要解决的问题等。
5) 持续增强 DevOps 前期项目管理、产品管理的功能模块,例如立项管理、路线图、需求管理、版本管理、发布物、产品运营、里程碑、迭代计划、测试管理等功能方向,有助于奠定项目/产品的基石。
6) 持续增强 DevOps 后期度量与优化功能模块,例如质量、效率、进度、APM、问题库、自愈等功能方向,帮助项目/产品后期更好的运营。
登录后评论
立即登录 注册