今天我们要搭建一条怎样的工具链呢?且看效果图: GitLab + Jenkins + Harbor Toolchain Workflow
三、今天怎么干?我准备使用云原生的方式来部署这三个工具,原因不赘述。 当然我也知道多数情况下你并不需要考虑 GitLab 如何部署,因为95% 的概率你们公司已经有可用的 GitLab 了,或者你们考虑使用 SaaS 版的 GitLab。外加 Kubernetes 上部署 GitLab 的复杂度不低,运维成本高,所以,GitLab 的“高可用部署”不是本文重点,我们把重点放在如何部署和配置好 Jenkins + Harbor,然后对接 GitLab,走通一个 CI 流程。 综上,今天我准备 sale 的部署模式是:
3.1、常规打法如果按照常理出牌,这时候我们应该是翻阅三个工具的官网,学习部署流程和配置步骤,然后总结最佳实践,一步步试错,一步步改进…… 听起来就复杂。 这个流程不应该让所有人都重头体验一遍,被折磨一遍。假如有人已经研究了一遍这些工具的部署模式,并且将这个流程代码化,做一个工具出来,并且开源免费,让大家“开箱即用”,那该多好! 3.2、不走寻常路没错,你已经猜到了,我不打算按常理出牌,我要找一个能够管理 DevOps 工具链的工具! 有这种工具?还真有! DevStream[1] 就干这事。DevStream 是啥?一句话:一个 DevOps 工具链管理器。 我们看下 DevStream 如何完成这三个工具的落地: GitLab+Jenkins+Harbor with DevStream DevStream 官网里有这么一个图。所以,这个花里胡哨的 DevStream 做了啥? 从上面的流程图,结合官方文档和源码,大致我可以猜到它的工作流和原理:
到这里 DevStream 基本就打完收工了,这时候如果你往这个代码库里的主分支 push 了一个 commit,GitLab 就会直接触发 Jenkins 上流水线运行;进而 Jenkins 上的流水线执行状态也会直接回显到 GitLab 上;当然,Jenkins 里构建的产物,比如 Docker container image(s) 也会被 push 到 Harbor(每错,这个过程是定义在 Jenkinsfile 里的,你可以灵活修改;同时 Harbor 也不一定非得是 Harbor,你可以直接改成其他镜像仓库的地址,从而让 Jenkins 对接到云厂商提供的镜像仓库服务里也完全 OK) |
原文地址:https://blog.csdn.net/qq_42672770/article/details/131674375
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:https://www.msipo.com/article-232.html 如若内容造成侵权/违法违规/事实不符,请联系MSIPO邮箱:3448751423@qq.com进行投诉反馈,一经查实,立即删除!
Copyright © 2024, msipo.com