16 | 构建资源的弹性伸缩
王潇俊
该思维导图由 AI 生成，仅供参考
在前面的文章中，我已经介绍了构建在整个持续交付过程中扮演的重要角色，并且详细讨论了依赖管理和构建检测等方面的内容。在这篇文章中，我将带你搭建一套高可用、高性能的构建系统。
持续集成工具
目前市面上已经有很多持续集成工具了，它们已经替我们解决了很多实际问题，所以我们也就没有必要去再重复造轮子了。这些持续集成工具，最流行的应属 Travis CI、Circle CI、Jenkins CI 这三种。
第一，Travis CI
Travis CI 是基于 GitHub 的 CI 托管解决方案之一，由于和 GitHub 的紧密集成，在开源项目中被广泛使用。
Travis CI 的构建，主要通过 .travis.yml 文件进行配置。这个 .travis.yml 文件描述了构建时所要执行的所有步骤。
另外，Travis CI 可以支持市面上绝大多数的编程语言。但是，因为 Travis 只支持 GitHub，而不支持其他代码托管服务，所以官方建议在使用前需要先具备以下几个条件：
能登录到 GitHub；
对托管在 GitHub 上的项目有管理员权限；
项目中有可运行的代码；
有可以工作的编译和测试脚本。
Travis CI 的收费策略是，对公共仓库免费，对私有仓库收费。
第二，CircleCI
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了构建高可用、高性能的持续集成系统的重要性，并介绍了三种流行的持续集成工具：Travis CI、CircleCI和Jenkins CI。重点关注了Jenkins CI的特点和优势，并分享了携程公司在构建系统方面的实践经验。 文章着重讨论了Jenkins Master高可用架构，并指出单个Jenkins Master可能成为系统瓶颈。为解决这一问题，携程公司采取了自己的解决方案，即在Jenkins上再封装两层：Build Service和Build Worker。这种架构使得构建任务分发的策略非常灵活，保证高可用性，并便于管理和维护。 此外，文章还介绍了携程公司在解决Slave资源管理和利用率问题上的实践经验。通过使用容器技术，他们成功实现了Slave节点的弹性伸缩，提高了资源利用率。 总的来说，本文通过介绍持续集成工具和携程公司的实践经验，强调了构建高可用、高性能的持续集成系统的重要性，并分享了一种解决Jenkins Master高可用架构的实用方案。对于需要构建高效、稳定的持续集成系统的技术人员具有一定的参考价值。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《持续交付 36 讲》，新⼈⾸单¥59
《持续交付 36 讲》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(12)
- 最新
- 精选
九脉一谷我们现在个别的项目在使用jenkins的流水线，为了实现持续部署，开发了一套内部管理平台依靠jenkins提供的接口，实现了流水线的执行过程的监控，自行开发了环境资源管理模块，自动化测试模块，最终通过docker发布。将整个过程都在管理平台统一跟踪监控。我想问一下作者，我们现在的产品线项目非常多，只有个别的项目加入了jenkins,那现在除了让各个项目组都加入pipeline，还有没有其他比较好的方式能实现对整个从开发人员提交代码后，接下来的走查，单元测试，环境部署，自动化测试等等这些全周期部署过程都能依靠平台统一监控各个过程。谢谢！！作者回复: 监控肯定不是最终的目的，提高研发效率才是，所以，不管是标准化，还是自动化，以提高效率为目标，解决实际问题，就比较容易被项目组所接受
2018-08-104
小雨使用了GitLab runner ，编译部分已经完成，正在进行线上docker，目前无法大批量转入k8s，只能使用docker swarm，资源调度还有些距离，毕竟现在只有两台机器，推动难度很大，只能将新的推荐和ai业务进行容器化。原先的php业务耦合太严重。作者回复: 一步步走稳，解耦是架构永远追求的目标
2018-08-111
吃饱了晒太阳jenkins ci和现在最新版本的gitlab自带的ci功能有何区别呢，哪一个更适合使用呢，最近在公司用的是用的自带的，想了解下是否需要切换，还望给点意见作者回复: 本质上都是任务驱动管理，如果已经很熟悉gitlab那就用它的ci，Jenkins更多了不同插件的支持，如果你有更丰富的需求，不如自动化测试，部署等等，Jenkins就更适合
2018-08-091
刘京城老师，请问你有研究过teamcity吗？我大致在网上查了下，说它开箱即用更容易些，但高可用和弹性伸缩不知道是否支持作者回复: 没有特别去研究这个，但是我写的那个ha方案是通用的，无论构建引擎用的是什么，甚至混用都可以的
2018-08-091
戴斌当下我们尝试了jenkins的kubernetes插件，让slave节点根据pipeline的执行生命后期一致，大大的提高效率，资源也利用更合理2020-03-225
技术修行者
不是很理解构建环境容器化的含义。 从持续交付的角度来说，我们有Jenkins来从GitHub获取代码，有Maven或者其他工具来打包，有Dockerfile来构建镜像，有私有docker registry来管理镜像，有Kubernetes来管理容器实例。我理解这就是一个闭环了。2019-09-1533
董永刚请问如何能够实时获取到jenkins的构建数量呢，2019-01-232
禾子先生jenkins的slave扩展问题，我也是通过容器的方式，master使用swarm插件，每个开发者可以在自己的机器上启动slave镜像，避免资源不足和自己构建的需求。看到作者提供思路和方案，很受启发，谢谢。2018-08-092- 技术修行者请教几个和组织结构相关的问题，可能和技术关系不大。 1. DevOps需要作为一个横跨多个部门的独立部门存在吗？如何统一不同部门之间不同的开发规范？ 2. DevOps需要在公司层面针对所有项目进行统一管理吗？ 3. DevOps有价值，持续交付也有价值，但是涉及到不同的部门时，不同的部门可能有不同的诉求，如何平衡所有的利益？2019-09-151
丫头pipeline是jenkins特有的嘛？我们用的gitlab托管代码，但是部署的时候有pipeline，然后还有项目里还有dockerfile文件… 作为一枚前端，就是好奇自己写的代码提交到gitlab后，集成到指定分支（如：develop），部署到指定环境（如：dev开发环境）交付给协作方（如：接口联调的后端同学，负责验收的测试同学）。这个过程，运维平台都做了什么…前端需要配合输出什么？或者有哪些内容是需要前端提供的？2023-02-10归属地：广东
收起评论
