CentOS7中自带的python版本是python-2.7.5，由于新开的虚拟机需要使用python3，于是便升级一下版本。

官网下载地址：https://www.python.org/downlo…

这里选择下载python 3.7.3。

# 下载 wget https://www.python.org/ftp/python/3.7.3/Python-3.7.3.tgz # 解压 tar -zxf Python-3.7.3.tgz # 安装依赖包 yum install zlib-devel bzip2-devel openssl-devel ncurses-devel sqlite-devel readline-devel tk-devel gcc  libffi-devel # 进入python目录 cd Python-3.7.3 # 编译 ./configure --prefix=/usr/local/python3.7 #安装 make && make install 

关于Python3.7以上的版本，需要多安装一个依赖包:

 yum install -y libffi-devel 

否则会出现ModuleNotFoundError: No module named '_ctypes'的报错。

在make install后执行echo $?，为0表示没有出错。如果没有报错，在/usr/local会生成python3.7目录。

然后将系统默认的python2备份

mv /usr/bin/python /usr/bin/python.bak 

创建新的软连接

ln -s /usr/local/python/bin/python3.7 /usr/bin/python 

查看版本

[root@moli-linux03 src]# python -V
Python 3.7.3 

升级完成了。

更改yum配置

因为yum需要使用python2，将/usr/bin/python改为python3后，yum就不能正常运行了，因此需要更改一下yum的配置。

vim /usr/bin/yum vim /usr/libexec/urlgrabber-ext-down 

编辑这两个文件，将文件头的#!/usr/bin/python改为#!/usr/bin/python2即可。

注意事项

本文的环境都是系统自带的openssh，若是手动编译安装的，不保证成功。若是自带的，则升级过程中不需要卸载旧版本openssh。

安装之前可以先试试yum更新,若是可以更新，就不需要往下看了

# centos8 $ yum update openssh -y # 重启sshd $ systemctl restart sshd 

准备工作

系统说明

• 系统版本：CentOS Linux release 7.7.1908 (Core)
• openssh：OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
• openssl: OpenSSL 1.0.2k-fips 26 Jan 2017

下载最新包

• openssh
• openssl

本文选择的是: openssh-8.2p1.tar.gz openssl-1.1.1g.tar.gz

$ wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-8.2p1.tar.gz   $ wget https://ftp.openssl.org/source/openssl-1.1.1g.tar.gz 

安装telnet备用（可选）

安装新的ssh之后，只要配置好启动，就可以做到无缝切换，但是中途断开就不能连接了，为了防止这种情况，我们可以安装telnet当作备用，若是你能保证中途不会断开，此步骤可以忽略

1.安装

$ yum install telnet telnet-server -y 

2.启动

$ systemctl enable telnet.socket $ systemctl start telnet.socket 

3.连接

# telnet 默认禁止root用户连接，我们先生成一个普通用户 $ useradd testuser $ passwd testuser   # 本地测试 $ telnet 127.0.0.1 VM_0_6_centos login: testuser Password: [testuser@VM_0_6_centos ~]$ # 切换root [testuser@VM_0_6_centos ~]$ su 

升级openssl

备份

$ mv /usr/bin/openssl /usr/bin/openssl_old 

安装

$ tar xzvf openssl-1.1.1g.tar.gz $ cd openssl-1.1.1g/ $ ./config shared && make && make install 

配置软连接

$ ln -s /usr/local/bin/openssl /usr/bin/openssl 

如果执行openssl version报下面的错误

openssl: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory 

则执行下面命令解决：

$ ln -s /usr/local/lib64/libssl.so.1.1 /usr/lib64/ $ ln -s /usr/local/lib64/libcrypto.so.1.1 /usr/lib64/ 

旧版本:

$ openssl_old version OpenSSL 1.0.2k-fips  26 Jan 2017 

升级openssh

安装所需依赖

$ yum install zlib-devel  openssl-devel  pam-devel -y 

备份

$ mkdir /etc/ssh_old $ mv /etc/ssh/* /etc/ssh_old/ 

解压、编译安装

$ tar xzvf openssh-8.2p1.tar.gz $ cd openssh-8.2p1/   $ ./configure --prefix=/usr/ --sysconfdir=/etc/ssh --with-ssl-dir=/usr/local/lib64/ --with-zlib --with-pam --with-md5-password --with-ssl-engine --with-selinux   # 安装 $ make && make install   # 验证 $ ssh -V OpenSSH_8.2p1, OpenSSL 1.1.1g  21 Apr 2020   $ ls /etc/ssh moduli  ssh_config  sshd_config  ssh_host_dsa_key  ssh_host_dsa_key.pub  ssh_host_ecdsa_key  ssh_host_ecdsa_key.pub  ssh_host_ed25519_key  ssh_host_ed25519_key.pub  ssh_host_rsa_key  ssh_host_rsa_key.pub 

配置

1.修改sshd_config

$ vim /etc/ssh/sshd_config   # 例子：配置root登录,   根据你以前的配置来 PermitRootLogin yes 

2.启动

# 移走以前的ssh服务, 防止与新的冲突 $ mv /usr/lib/systemd/system/sshd.service /etc/ssh_old/sshd.service $ mv /usr/lib/systemd/system/sshd.socket /etc/ssh_old/sshd.socket   # 在解压包中拷贝一些文件 $ cp -a contrib/redhat/sshd.init /etc/init.d/sshd       # 重新启动 $ /etc/init.d/sshd restart $ systemctl daemon-reload   # 添加自启动 $ chkconfig --add sshd $ chkconfig sshd on 

可能碰到的问题：

1. /etc/init.d/sshd restart之后报错

Reloading systemd:                                         [  确定  ] Restarting sshd (via systemctl):  Job for sshd.service failed because the control process exited with error code. See "systemctl status sshd.service" and "journalctl -xe" for details.  [失败] 

是selinux导致，需要关闭

# 临时修改 setenforce 0 # 永久修改 sed -i 's/SELINUX=.*/SELINUX=disabled/g' /etc/selinux/config # 重启 /etc/init.d/sshd restart 

一、今天想干啥？

今天我们来聊聊如何快速落地“GitLab + Jenkins + Harbor 工具链”。

请注意这里的关键词：快速（有多快呢？我希望这个时间是5分钟。）

我知道你想要一条闪闪亮的工具链来支撑你的应用 CICD 流程，你想要“最佳实践”，你想要既灵活又简单还易维护，你有一肚子的既要，又要，还要……

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

二、今天干点啥？

今天我们要搭建一条怎样的工具链呢？且看效果图：

1. 首先我们需要完成 GitLab、Jenkins 和 Harbor 三个工具的部署；
2. 接着我们需要在 GitLab 上创建一个代码库，并且在 Jenkins 上创建相应的流水线，这个流程最好也自动化（确实可以自动化）；
3. 然后适当地配置这三个工具，实现如下 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)

3.1、常规打法

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

听起来就复杂。

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

3.2、不走寻常路

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

有这种工具？还真有！

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

我们看下 DevStream 如何完成这三个工具的落地：

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

从上面的流程图，结合官方文档和源码，大致我可以猜到它的工作流和原理：

1. DevStream 首先将 GitLab、Jenkins、Harbor 等工具的部署流程代码化，通过插件的形式支持这些工具的安装部署；
2. 工具部署完成后，DevStream 会从 SCM（GitHub 或者 GitLab 都可以）下载一个项目脚手架模板，模板源码在这里；这个模板支持高度自定义，本质就是将一些需要自定义的内容抽离成变量，供用户自由渲染，然后批量生产项目脚手架；
3. 接着 DevStream 根据用户给定的配置文件渲染模板库，然后将其上传到 SCM（GitHub 或者 GitLab 都可以）；
4. 然后 DevStream 会配置 Jenkins，安装一些必要的插件等，用户支持最终的 Pipeline 顺利执行；
5. DevStream 期望 Pipeline 配置通过 Jenkinsfile 来定义，这个 Jenkinsfile 也是通过模板的方式保存，可以灵活渲染。比如官网示例中 Jenkinsfile 模板保存在这里；DevStream 执行的时候会下载这个 Jenkinsfile 模板（当然，这个模板也支持自定义，支持放到 GitLab 或者其他任何 web 服务器上），下载后渲染用户自定义变量，然后将其写入刚才创建的项目脚手架对应的代码库里；
6. 接着 DevStream 就可以调用 Jenkins api，完成 Pipeline 创建了。没错，创建 Pipeline 的时候，需要的 Jenkinsfile、项目地址等信息都有了，所以这里的 Pipeline 配置很轻量；
7. 最后 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步来完成这条工具链的搭建过程。

4.1、工具链部署

先下载一个 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 吧。

4.2、网络配置

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

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

1. 修改 /etc/hosts 文件，添加这条记录（记得替换成你自己的 IP）：

   44.33.22.11 gitlab.example.com jenkins.example.com harbor.example.com 
   

2. 修改 CoreDNS 的配置，在 ConfigMap kube-system/coredns 中添加静态解析记录：

   1. 执行命令：kubectl edit cm coredns -n kube-system；
   2. 在 hosts(第20行左右) 部分添加和 /etc/hosts 一样的记录。

这样 Jenkins 才能通过域名访问到 GitLab。

4.3、验证工具链部署结果

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

4.3.1、GitLab

不出意外的话，你可以在自己的 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：

4.3.2、Jenkins

在浏览器里通过 http://jenkins.example.com:32000 就可以访问到 Jenkins 了：

Jenkins 的 admin 用户初始登录密码是 changeme，如果你仔细看了前面 dtm 使用的配置文件，可以发现这是在配置文件里指定的。我们尝试用 admin/changeme 登录 Jenkins 检查功能是否正常，不过这时不需要在 Jenkins 上进行任何额外的操作。

4.3.3、Harbor

我们可以通过 docker login harbor.example.com:80 命令来尝试登录 Harbor，也可以直接通过 http://harbor.example.com:30180 访问 Dashboard：

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

4.4、流水线配置

工具有了，下一步就是配置流水线了，咱继续准备第二个配置文件（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. 

4.5、验证流水线配置结果

我们上 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, gitlab, jenkins, harbor, cicd, 中文文章, 开源

Back | Home

DevStream v0.9.0 Release 10 Best DevOps Tools for Start-ups

Merico Inc. and the DevStream Contributors

2022