今天我们要搭建一条怎样的工具链呢?且看效果图:
GitLab + Jenkins + Harbor Toolchain Workflow
-
首先我们需要完成 GitLab、Jenkins 和 Harbor 三个工具的部署;
-
接着我们需要在 GitLab 上创建一个代码库,并且在 Jenkins 上创建相应的流水线,这个流程最好也自动化(确实可以自动化);
-
然后适当地配置这三个工具,实现如下 CI 流程:
-
当用户推送代码到 GitLab,也就是 GitLab 上相应代码库产生 push 或者 merge 事件的时候,这个事件能够自动触发 Jenkins 上的流水线执行;
-
Jenkins 上流水线执行的结果能够回显到 GitLab;
-
Jenkins 上完成了编译、构建等等流程后,最终制品是一个容器镜像,这个镜像可以被推送到 Harbor 上。
-
三、今天怎么干?
我准备使用云原生的方式来部署这三个工具,原因不赘述。
当然我也知道多数情况下你并不需要考虑 GitLab 如何部署,因为95% 的概率你们公司已经有可用的 GitLab 了,或者你们考虑使用 SaaS 版的 GitLab。外加 Kubernetes 上部署 GitLab 的复杂度不低,运维成本高,所以,GitLab 的“高可用部署”不是本文重点,我们把重点放在如何部署和配置好 Jenkins + Harbor,然后对接 GitLab,走通一个 CI 流程。
综上,今天我准备 sale 的部署模式是:
-
GitLab:Docker
-
Jenkins:Helm(Kubernetes)
-
Harbor:Helm(Kubernetes)
3.1、常规打法
如果按照常理出牌,这时候我们应该是翻阅三个工具的官网,学习部署流程和配置步骤,然后总结最佳实践,一步步试错,一步步改进……
听起来就复杂。
这个流程不应该让所有人都重头体验一遍,被折磨一遍。假如有人已经研究了一遍这些工具的部署模式,并且将这个流程代码化,做一个工具出来,并且开源免费,让大家“开箱即用”,那该多好!
3.2、不走寻常路
没错,你已经猜到了,我不打算按常理出牌,我要找一个能够管理 DevOps 工具链的工具!
有这种工具?还真有!
DevStream[1] 就干这事。DevStream 是啥?一句话:一个 DevOps 工具链管理器。
我们看下 DevStream 如何完成这三个工具的落地:
GitLab+Jenkins+Harbor with DevStream
DevStream 官网里有这么一个图。所以,这个花里胡哨的 DevStream 做了啥?
从上面的流程图,结合官方文档和源码,大致我可以猜到它的工作流和原理:
-
DevStream 首先将 GitLab、Jenkins、Harbor 等工具的部署流程代码化,通过插件的形式支持这些工具的安装部署;
-
工具部署完成后,DevStream 会从 SCM(GitHub 或者 GitLab 都可以)下载一个项目脚手架模板,模板源码在这里[2];这个模板支持高度自定义,本质就是将一些需要自定义的内容抽离成变量,供用户自由渲染,然后批量生产项目脚手架;
-
接着 DevStream 根据用户给定的配置文件渲染模板库,然后将其上传到 SCM(GitHub 或者 GitLab 都可以);
-
然后 DevStream 会配置 Jenkins,安装一些必要的插件等,用户支持最终的 Pipeline 顺利执行;
-
DevStream 期望 Pipeline 配置通过 Jenkinsfile 来定义,这个 Jenkinsfile 也是通过模板的方式保存,可以灵活渲染。比如官网示例中 Jenkinsfile 模板保存在这里[3];DevStream 执行的时候会下载这个 Jenkinsfile 模板(当然,这个模板也支持自定义,支持放到 GitLab 或者其他任何 web 服务器上),下载后渲染用户自定义变量,然后将其写入刚才创建的项目脚手架对应的代码库里;
-
接着 DevStream 就可以调用 Jenkins api,完成 Pipeline 创建了。没错,创建 Pipeline 的时候,需要的 Jenkinsfile、项目地址等信息都有了,所以这里的 Pipeline 配置很轻量;
-
最后 DevStream 还需要调用 GitLab api 完成 webhook 的创建,这样 SCM(GitHub 或者 GitLab)上的事件(push、merge 等)才能顺利通知到 Jenkins,从而触发 Pipeline 执行。
到这里 DevStream 基本就打完收工了,这时候如果你往这个代码库里的主分支 push 了一个 commit,GitLab 就会直接触发 Jenkins 上流水线运行;进而 Jenkins 上的流水线执行状态也会直接回显到 GitLab 上;当然,Jenkins 里构建的产物,比如 Docker container image(s) 也会被 push 到 Harbor(每错,这个过程是定义在 Jenkinsfile 里的,你可以灵活修改;同时 Harbor 也不一定非得是 Harbor,你可以直接改成其他镜像仓库的地址,从而让 Jenkins 对接到云厂商提供的镜像仓库服务里也完全 OK)
如何在五分钟内快速构建一个 GitLab + Jenkins + Harbor 的云原生 DevOps 环境