关于devops:GitLab-Jenkins-Harbor-工具链快速落地指南

7次阅读

共计 11530 个字符，预计需要花费 29 分钟才能阅读完成。

明天咱们来聊聊如何疾速落地“GitLab + Jenkins + Harbor 工具链”。

请留神这里的关键词：疾速（有多快呢？我心愿这个工夫是 5 分钟。）

我晓得你想要一条 闪闪亮 的工具链来撑持你的利用 CICD 流程，你想要“最佳实际”，你想要既灵便又简略还易保护，你有一肚子的既要，又要，还要……

行，明天我就给你一个“既有，又有，还有”的《GitLab + Jenkins + Harbor 落地计划》。

明天咱们要搭建一条怎么的工具链呢？且看效果图：

首先咱们须要实现 GitLab、Jenkins 和 Harbor 三个工具的部署；
接着咱们须要在 GitLab 上创立一个代码库，并且在 Jenkins 上创立相应的流水线，这个流程最好也自动化（的确能够自动化）；
而后适当地配置这三个工具，实现如下 CI 流程：
1. 当用户推送代码到 GitLab，也就是 GitLab 上相应代码库产生 push 或者 merge 事件的时候，这个事件可能主动触发 Jenkins 上的流水线执行；
2. Jenkins 上流水线执行的后果可能回显到 GitLab；
3. Jenkins 上实现了编译、构建等等流程后，最终制品是一个容器镜像，这个镜像能够被推送到 Harbor 上。

我筹备应用云原生的形式来部署这三个工具，起因不赘述。

当然我也晓得少数状况下你并不需要思考 GitLab 如何部署，因为 95% 的概率你们公司曾经有可用的 GitLab 了，或者你们思考应用 SaaS 版的 GitLab。外加 Kubernetes 上部署 GitLab 的复杂度不低，运维老本高，所以，GitLab 的“高可用部署”不是本文重点，咱们把重点放在如何部署和配置好 Jenkins + Harbor，而后对接 GitLab，走通一个 CI 流程。

综上，明天我筹备 sale 的部署模式是：

GitLab：Docker
Jenkins：Helm(Kubernetes)
Harbor：Helm(Kubernetes)

如果依照常理出牌，这时候咱们应该是翻阅三个工具的官网，学习部署流程和配置步骤，而后总结最佳实际，一步步试错，一步步改良……

听起来就简单。

这个流程不应该让所有人都重头体验一遍，被折磨一遍。如果有人曾经钻研了一遍这些工具的部署模式，并且将这个流程代码化，做一个工具进去，并且开源收费，让大家“开箱即用”，那该多好！

没错，你曾经猜到了，我不打算按常理出牌，我要找一个可能治理 DevOps 工具链的工具！

有这种工具？还真有！

DevStream 就干这事。DevStream 是啥？一句话：一个 DevOps 工具链管理器。

咱们看下 DevStream 如何实现这三个工具的落地：

DevStream 官网里有这么一个图。所以，这个花里胡哨的 DevStream 做了啥？

从下面的流程图，联合官网文档和源码，大抵我能够猜到它的工作流和原理：

DevStream 首先将 GitLab、Jenkins、Harbor 等工具的部署流程代码化，通过插件的模式反对这些工具的装置部署；
工具部署实现后，DevStream 会从 SCM（GitHub 或者 GitLab 都能够）下载一个我的项目脚手架模板，模板源码在这里；这个模板反对高度自定义，实质就是将一些须要自定义的内容抽离成变量，供用户自在渲染，而后批量生产我的项目脚手架；
接着 DevStream 依据用户给定的配置文件渲染模板库，而后将其上传到 SCM（GitHub 或者 GitLab 都能够）；
而后 DevStream 会配置 Jenkins，装置一些必要的插件等，用户反对最终的 Pipeline 顺利执行；
DevStream 冀望 Pipeline 配置通过 Jenkinsfile 来定义，这个 Jenkinsfile 也是通过模板的形式保留，能够灵便渲染。比方官网示例中 Jenkinsfile 模板保留在这里；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）。

思考到插件的依赖程序，外加 Jenkins、GitLab、Harbor 等工具的部署属于 ” 基础设施 ”，简直只须要执行一次，而 Repo Scaffolding 和 Jenkins Pipeline 的创立属于 ” 配置 ” 过程，可能要执行屡次（比方一直新增 Repo 和 Pipeline 等），所以咱们分 2 步来实现这条工具链的搭建过程。

先下载一个 DevStream 的 CLI，参考这个文档。有了 dtm 之后，咱们就该着手筹备配置文件了（上面配置保留到 config.yaml 里）：

---
varFile: "" # If not empty, use the specified external variables config file
toolFile: "" # If not empty, use the specified external tools config file
pluginDir: "" # If empty, use the default value: ~/.devstream/plugins, or use -d flag to specify a directory
state: # state config, backend can be local, s3 or k8s
  backend: local
  options:
    stateFile: devstream-1.state
---
tools:
- name: gitlab-ce-docker
  instanceID: default
  dependsOn: [ ]
  options:
    hostname: gitlab.example.com
    gitlabHome: /srv/gitlab
    sshPort: 30022
    httpPort: 30080
    httpsPort: 30443
    rmDataAfterDelete: false
    imageTag: "rc"
- name: jenkins
  instanceID: default
  dependsOn: [ ]
  options:
    repo:
      name: jenkins
      url: https://charts.jenkins.io
    chart:
      chartPath: ""
      chartName: jenkins/jenkins
      namespace: jenkins
      wait: true
      timeout: 5m
      upgradeCRDs: true
      valuesYaml: |
        serviceAccount:
          create: true
          name: jenkins
        controller:
          adminUser: "admin"
          adminPassword: "changeme"
          ingress:
            enabled: true
            hostName: jenkins.example.com
          installPlugins:
            - kubernetes:3600.v144b_cd192ca_a_
            - workflow-aggregator:581.v0c46fa_697ffd
            - git:4.11.3
            - configuration-as-code:1512.vb_79d418d5fc8
          additionalPlugins:
            # install "GitHub Pull Request Builder" plugin, see https://plugins.jenkins.io/ghprb/ for more details
            - ghprb
            # install "OWASP Markup Formatter" plugin, see https://plugins.jenkins.io/antisamy-markup-formatter/ for more details
            - antisamy-markup-formatter
        # Enable HTML parsing using OWASP Markup Formatter Plugin (antisamy-markup-formatter), useful with ghprb plugin.
        enableRawHtmlMarkupFormatter: true
        # Jenkins Configuraction as Code, refer to https://plugins.jenkins.io/configuration-as-code/ for more details
        # notice: All configuration files that are discovered MUST be supplementary. They cannot overwrite each other's configuration values. This creates a conflict and raises a ConfiguratorException.
        JCasC:
          defaultConfig: true
- name: harbor
  instanceID: default
  dependsOn: [ ]
  options:
    chart:
      valuesYaml: |
        externalURL: http://harbor.example.com
        expose:
          type: ingress
          tls:
            enabled: false
          ingress:
            hosts:
              core: harbor.example.com
        chartmuseum:
          enabled: false
        notary:
          enabled: false
        trivy:
          enabled: false
        persistence:
          persistentVolumeClaim:
            registry:
              storageClass: ""
              accessMode: ReadWriteOnce
              size: 5Gi
            jobservice:
              storageClass: ""
              accessMode: ReadWriteOnce
              size: 1Gi
            database:
              storageClass: ""
              accessMode: ReadWriteOnce
              size: 1Gi
            redis:
              storageClass: ""
              accessMode: ReadWriteOnce
              size: 1Gi

这里的配置项并不难看懂，举荐大伙执行前面的命令前先认真看一遍这个配置文件，按需调整。比方外面配置了几个工具的域名啥的，这些都能够改。

而后就能够开始初始化了（次要是插件下载）：

dtm init -f config.yaml

而后执行 apply 开始部署：

dtm apply -f config.yaml -y

这时候你会看到谐和的日志：

2022-10-08 09:43:13 ℹ [INFO]  Apply started.
2022-10-08 09:43:13 ℹ [INFO]  Using dir </root/.devstream/plugins> to store plugins.
2022-10-08 09:43:13 ℹ [INFO]  Using local backend. State file: devstream-1.state.
2022-10-08 09:43:13 ℹ [INFO]  Tool (gitlab-ce-docker/default) found in config but doesn't exist in the state, will be created.
2022-10-08 09:43:13 ℹ [INFO]  Tool (jenkins/default) found in config but doesn't exist in the state, will be created.
2022-10-08 09:43:13 ℹ [INFO]  Tool (harbor/default) found in config but doesn't exist in the state, will be created.
2022-10-08 09:43:13 ℹ [INFO]  Start executing the plan.
2022-10-08 09:43:13 ℹ [INFO]  Changes count: 3.
2022-10-08 09:43:13 ℹ [INFO]  -------------------- [Processing progress: 1/3.] --------------------
2022-10-08 09:43:13 ℹ [INFO]  Processing: (gitlab-ce-docker/default) -> Create ...
2022-10-08 09:43:13 ℹ [INFO]  Cmd: docker image ls gitlab/gitlab-ce:rc -q.
2022-10-08 09:43:13 ℹ [INFO]  Running container as the name <gitlab>
2022-10-08 09:43:13 ℹ [INFO]  Cmd: docker run --detach --hostname gitlab.example.com --publish 30022:22 --publish 30080:80 --publish 30443:443 --name gitlab --restart always --volume /srv/gitlab/config:/etc/gitlab --volume /srv/gitlab/data:/var/opt/gitlab --volume /srv/gitlab/logs:/var/log/gitlab gitlab/gitlab-ce:rc.
Stdout: 53e30ad85faf7e9d6d18764450bb8458db46b388b690b7c8b7a7cc6d0deb283a
2022-10-08 09:43:14 ℹ [INFO]  Cmd: docker inspect --format='{{json .Mounts}}' gitlab.
2022-10-08 09:43:14 ℹ [INFO]  GitLab access URL: http://gitlab.example.com:30080
2022-10-08 09:43:14 ℹ [INFO]  GitLab initial root password: execute the command -> docker exec -it gitlab grep 'Password:' /etc/gitlab/initial_root_password
2022-10-08 09:43:14 ✔ [SUCCESS]  Tool (gitlab-ce-docker/default) Create done.
2022-10-08 09:43:14 ℹ [INFO]  -------------------- [Processing progress: 2/3.] --------------------
2022-10-08 09:43:14 ℹ [INFO]  Processing: (jenkins/default) -> Create ...
2022-10-08 09:43:15 ℹ [INFO]  Creating or updating helm chart ...
2022/10/08 09:43:16 creating 13 resource(s)
2022/10/08 09:43:16 beginning wait for 13 resources with timeout of 5m0s
2022/10/08 09:43:16 StatefulSet is not ready: jenkins/jenkins. 0 out of 1 expected pods are ready
...
2022/10/08 09:44:18 StatefulSet is not ready: jenkins/jenkins. 0 out of 1 expected pods are ready
2022/10/08 09:44:20 release installed successfully: jenkins/jenkins-4.1.17
2022-10-08 09:44:20 ✔ [SUCCESS]  Tool (jenkins/default) Create done.
2022-10-08 09:44:20 ℹ [INFO]  -------------------- [Processing progress: 3/3.] --------------------
2022-10-08 09:44:20 ℹ [INFO]  Processing: (harbor/default) -> Create ...
2022-10-08 09:44:21 ℹ [INFO]  Creating or updating helm chart ...
2022/10/08 09:44:23 creating 28 resource(s)
2022/10/08 09:44:23 beginning wait for 28 resources with timeout of 10m0s
2022/10/08 09:44:24 Deployment is not ready: harbor/harbor-core. 0 out of 1 expected pods are ready
...
2022/10/08 09:46:16 Deployment is not ready: harbor/harbor-jobservice. 0 out of 1 expected pods are ready
2022/10/08 09:46:18 release installed successfully: harbor/harbor-1.10.0
2022-10-08 09:46:19 ✔ [SUCCESS]  Tool (harbor/default) Create done.
2022-10-08 09:46:19 ℹ [INFO]  -------------------- [Processing done.] --------------------
2022-10-08 09:46:19 ✔ [SUCCESS]  All plugins applied successfully.
2022-10-08 09:46:19 ✔ [SUCCESS]  Apply finished.

如果日志不够谐和，那就，那就，，，debug 吧。

后面 GitLab + Jenkins + Harbor 三个工具的配置文件里咱们都设置了域名，如果是 kubeadm 间接部署的 k8s 集群，你能够间接将这些域名与 IP 的映射关系配置到 DNS 服务器里。

如果没有 DNS 服务器，你也能够间接将域名与 IP 的映射关系配置到 /etc/hosts 以及 CoreDNS 的 ConfigMap kube-system/coredns 里让域名失效。比方：

批改 /etc/hosts 文件，增加这条记录（记得替换成你本人的 IP）：
```
44.33.22.11 gitlab.example.com jenkins.example.com harbor.example.com
```
批改 CoreDNS 的配置，在 ConfigMap kube-system/coredns 中增加动态解析记录：
1. 执行命令：kubectl edit cm coredns -n kube-system；
2. 在 hosts(第 20 行左右) 局部增加和 /etc/hosts 一样的记录。

这样 Jenkins 能力通过域名拜访到 GitLab。

来，看下新部署的 GitLab、Jenkins、Harbor 是不是都能拜访到。

不出意外的话，你能够在本人的 PC 里配置 44.33.22.11 gitlab.example.com 动态域名解析记录，而后在浏览器里通过 http://gitlab.example.com:30080 拜访到 GitLab：

而后通过执行如下命令，你就能取得 GitLab 的初始 root 明码了：

docker exec gitlab cat /etc/gitlab/initial_root_password | grep Password:

拿到 root 明码后，你能够尝试用 root/YOUR_PASSWORD 来登录 GitLab。因为前面咱们须要用到 GitLab 的 token，所以这时候能够棘手创立一个 token：

在浏览器里通过 http://jenkins.example.com:32000 就能够拜访到 Jenkins 了：

Jenkins 的 admin 用户初始登录明码是 changeme，如果你认真看了后面 dtm 应用的配置文件，能够发现这是在配置文件里指定的。咱们尝试用 admin/changeme 登录 Jenkins 查看性能是否失常，不过这时不须要在 Jenkins 上进行任何额定的操作。

咱们能够通过 docker login harbor.example.com:80 命令来尝试登录 Harbor，也能够间接通过 http://harbor.example.com:30180 拜访 Dashboard：

Harbor 的 admin 用户初始登录明码是 Harbor12345，咱们尝试用 admin/Harbor12345 登录 Harbor：

工具有了，下一步就是配置流水线了，咱持续筹备第二个配置文件（config-pipeline.yaml）：

---
varFile: "" # If not empty, use the specified external variables config file
toolFile: "" # If not empty, use the specified external tools config file
pluginDir: "" # If empty, use the default value: ~/.devstream/plugins, or use -d flag to specify a directory
state: # state config, backend can be local, s3 or k8s
  backend: local
  options:
    stateFile: devstream-2.state
---
tools:
- name: repo-scaffolding
  instanceID: springboot
  dependsOn: [ ]
  options:
    destinationRepo:
      owner: root
      repo: spring-demo
      branch: master
      repoType: gitlab
      baseURL: http://gitlab.example.com:30080
    sourceRepo:
      owner:  devstream-io
      repo: dtm-repo-scaffolding-java-springboot
      repoType: github
- name: jenkins-pipeline
  instanceID: default
  dependsOn: [repo-scaffolding.springboot]
  options:
    jenkins:
      url: http://44.33.22.11:32000
      user: admin
      enableRestart: true
    scm:
      cloneURL: http://gitlab.example.com:30080/root/spring-demo
      branch: master
    pipeline:
      jobName: test-job
      jenkinsfilePath: https://raw.githubusercontent.com/devstream-io/dtm-jenkins-pipeline-example/main/springboot/Jenkinsfile
      imageRepo:
        url: http://harbor.example.com:80
        user: admin

同样我倡议你认真看一下这个配置文件，外面的一些拜访地址，比方 IP 和域名啥的，按需调整。

后面咱们增加了一个 GitLab 的 token，这个 token 须要被设置到环境变量里：

export GITLAB_TOKEN=YOUR_GITLAB_TOKEN

同时咱们须要将 Harbor 明码配置到环境变量里，如果你的 Harbor 没有去批改明码，这时候默认明码应该是 Harbor12345：

export IMAGE_REPO_PASSWORD=Harbor12345

接着就是相熟的 init 和 apply 命令了：

dtm init -f config-pipeline.yaml
dtm apply -f config-pipeline.yaml -y

后果日志仍旧应该谐和：

2022-10-08 13:19:27 ℹ [INFO]  Apply started.
2022-10-08 13:19:27 ℹ [INFO]  Using dir </root/.devstream/plugins> to store plugins.
2022-10-08 13:19:28 ℹ [INFO]  Using local backend. State file: devstream-2.state.
2022-10-08 13:19:28 ℹ [INFO]  Tool (jenkins-pipeline/default) found in config but doesn't exist in the state, will be created.
2022-10-08 13:19:28 ℹ [INFO]  Start executing the plan.
2022-10-08 13:19:28 ℹ [INFO]  Changes count: 1.
2022-10-08 13:19:28 ℹ [INFO]  -------------------- [Processing progress: 1/1.] --------------------
2022-10-08 13:19:28 ℹ [INFO]  Processing: (jenkins-pipeline/default) -> Create ...
2022-10-08 13:19:28 ℹ [INFO]  Secret jenkins/docker-config has been created.
2022-10-08 13:19:32 ✔ [SUCCESS]  Tool (jenkins-pipeline/default) Create done.
2022-10-08 13:19:32 ℹ [INFO]  -------------------- [Processing done.] --------------------
2022-10-08 13:19:32 ✔ [SUCCESS]  All plugins applied successfully.
2022-10-08 13:19:32 ✔ [SUCCESS]  Apply finished.

咱们上 GitLab 看下 dtm 筹备的 Java Spring Boot 我的项目脚手架：

接着登录 Jenkins，能够看到 dtm 创立的 Pipeline：

Pipeline 胜利执行实现后：

再回到 GitLab 看下回显的状态：

歌舞升平，一片祥和！

此处应该有个总结，然而到饭点了。

不总结了吧。

就留一个问题：DevStream 部署 DevOps 工具链是不是最佳实际？

兴许是，兴许不是。不过我置信 DevStream 会逐渐会集业内最佳实际，最终变成一个规范。

再留个问题：DevStream 足够成熟稳固了不？

应该不够。不过 DevStream 在逐步走向成熟。如果大家违心应用 DevStream，多提 bug，甚至参加社区开发，DevStream 就会更快走向成熟稳固。

参考：

DevStream 我的项目仓库

DevStream 文档：本地部署 GitLab + Jenkins + Harbor 工具链

DevStream 文档：离线部署

完结。催吃饭了。

正文完

devops

发表至： devops

2022-10-09

0

关于devops:Artifactory制品库的密码管理及策略配置

关于devops:大型前端项目-DevOps-沉思录-CI-篇

关于devops:什么是-DevOps看这一篇就够了

关于devops:研发效能｜DevOps-是运维还是开发

关于kubernetes:K8S-笔记-修改-kubelet-10250-端口运行的协议和地址

关于devops:GitLab-Jenkins-Harbor-工具链快速落地指南

一、明天想干啥？

二、明天干点啥？

三、明天怎么干？

3.1、惯例打法

3.2、不走寻常路

四、开干吧！

4.1、工具链部署

4.2、网络配置

4.3、验证工具链部署后果

4.3.1、GitLab

4.3.2、Jenkins

4.3.3、Harbor

4.4、流水线配置

4.5、验证流水线配置后果

五、总结

站内搜索