说明：本实验使用的Jenkins X版本为V3.2.140
1 安装
（1）从官方github下载离线安装包
https://github.com/jenkins-x/jx/releases/download/v3.2.140/jx-linux-amd64.tar.gz
（2）使用如下命令解压tar文件
tar -zxvf jx-linux-amd64.tar.gz（3）将解压出来的jx文件使用下面命令移动到 /usr/local/bin
mv jx /usr/local/bin（4）输入jx命令验证安装是否成功
出现下面的命令说明则安装成功
2 使用
2.1 Jenkins X UI（octant）
（1）执行下述命令，会自动从对应的github仓库下载tar包
jx ui
由于服务器无法连接github导致下载失败，我们可以手动从https://github.com/vmware-tanzu/octant/releases/download/v0.20.0/octant_0.20.0_Linux-64bit.tar.gz下载tar包，并上传到服
（2）使用下述命令解压tar包，将解压出来的文件移动到 /usr/local/bin/目录下
tar -zxvf octant_0.20.0_Linux-64bit.tar.gz
mv octant_0.20.0_Linux-64bit/octant /usr/local/bin/（3）执行octant命令，验证安装是否成功
可以看到octant已经运行在7777端口
（4）设置外部访问octant
由于使用ubuntu server版，无法访问127.0.0.1:7777，因需要端口映射，执行下述命令
octant --listener-addr=0.0.0.0:7777
打开浏览器即可看到octant界面
2.2 Jenkins X Dashboard
Octant 是一个应用程序，目的是作为一个单独的客户端工具，Jenkins X计划不去支持Octant的其他托管版本，所以Jenkins X做了一个新的UI（Jenkins X Dashboard）
生成git token：
kubectl create -f git-token.yaml生成Dashboard后端服务
helm --debug install jx jx-pipelines-visualizer -f values.yamlvalues.yaml文件：
jx:
# whether to create a Release CRD when installing charts with Release CRDs included
releaseCRD: true
serviceAccount:
# allow additional annotations to be added to the ServiceAccount
# such as for workload identity on clouds
annotations: {}
role:
rules:
- apiGroups:
- jenkins.io
resources:
- pipelineactivities
- pipelinestructures
verbs:
- list
- watch
- get
- apiGroups:
- tekton.dev
resources:
- pipelineruns
- pipelines
verbs:
- list
- watch
- get
- apiGroups:
- ""
resources:
- pods
verbs:
- list
- watch
- get
- apiGroups:
- ""
resources:
- pods/log
verbs:
- get
extraVolumes: []
# - name: config
# configMap:
# name: minio-certificate
extraVolumeMounts: []
# - name: config
# mountPath: /config
# readOnly: true界面：
Jenkins x使用较少，目前看只有阿里和aws在使用，用于代替kubectl helm等操作，以及在公有云上生成集群，和我们的需求不太贴合。另外在 Jenkins X 看来，Jenkins 只不过是 Jenkins X 中的一个应用，是一个黑盒子，编排通过 Tekton 来实现（可以把jenkins去掉），但是这种插件理念也让jenkins X变得异常复杂，不符合现阶段流行的开箱即用的理念。
我想到之前用过的一个专为云原生而存在的平台——Drone，这个表格是对比。
对于 Drone 来说，最大的特征就是容器优先。表格里的其他工具并没有把容器作为默认支持的第一选项。而在 Drone 中，容器则是标配，这也是典型的云原生 CI 工具的特征：一切都在容器中运行。也正因为如此，非容器化开发部署的项目如果采用 Drone 就不太合适了。另外，除了容器方式之外，Drone 也支持本地执行，这为一些特殊的场景提供了可能性（比如绑定设备的自动化测试等）。
2.3 Drone安装
获取gitlab权限
获取gitlab ID与secret
启动drone
docker run \
--volume=/var/lib/drone:/data \
--env=DRONE_GITLAB_SERVER=http://10.8.59.16 \
--env=DRONE_GITLAB_CLIENT_ID=a8c54a8695ec824009856a7e9dff698d05529d1e12b850a04f2266e9fb46beaf \
--env=DRONE_GITLAB_CLIENT_SECRET=c7665e5ef427120a3d4cf05937e197d0fa63df57647b15de6e2ef7aa2e9629b5 \
--env=DRONE_RPC_SECRET=863b4d9d38f3408d78390fb012e4ee4b \
--env=DRONE_SERVER_HOST=10.8.59.174 \
--env=DRONE_SERVER_PROTO=http \
--publish=80:80 \
--publish=443:443 \
--restart=always \
--detach=true \
--name=drone \
drone/drone:1安装runner
docker run -d \
-v /var/run/docker.sock:/var/run/docker.sock \
-e DRONE_RPC_PROTO=http \
-e DRONE_RPC_HOST=http://10.8.59.16 \
-e DRONE_RPC_SECRET=863b4d9d38f3408d78390fb012e4ee4b \
-e DRONE_RUNNER_CAPACITY=2 \
-e DRONE_RUNNER_NAME=${HOSTNAME} \
-p 3000:3000 \
--restart always \
--name runner \
drone/drone-runner-docker:latest界面访问
可以看到我们gitlab上的项目已经加到drone上了，后面就可以愉快的提交代码触发cicd了。
