基于kubernetes CI/CD实践

基于K8s创建静态节点

---

 env部分是Jenkins的地址和secret。

这个Jenkins agent其实有一个服务启动脚本，然后去读这些参数。在这个pod里面默认是没有mvn构建工具的，这就需要我们去构建镜像，将常用的工具添加到镜像当中，然后agent使用这个镜像就可以了。

动态创建节点

---

实现的思路就是先去k8s里面创建一个pod， 然后我再运行pipeline，运行完之后调用k8s的api去delete将这个pod删除掉。

实现这个功能可以使用上面的插件，主要依赖于几个插件，一个是kubernetes插件，还有一个是凭据的插件，还有一个依赖于kubernetes的api其实也包含在Kubernetes插件里面的。

不要去过度的依赖插件，你只顾着安装，在升级Jenkins的时候就痛苦，导致升级之后Jenkins起不来了。

如何避免这样的问题，在使用groovy写的时候可以通过共享库来减少对插件的依赖。

所以避免使用插件，只需要安装核心插件就行了，其他的都是写groovy的共享库来实现，比如调用原生的api来实现。

这个名称可以随便定义，这个后面会用到。凭据这里是kube-config文件加到了这里

这个类型是文件的类型，文件就是kube-config这个文件，上传完之后连接测试就行了。

可以看到agent这里发生了变化，这里添加了kubernetes

cloud字段要和我们在插件里面配置的字段保持一致，现在镜像里面是没有mvn工具的，要进行代码扫描和docker镜像的构建，这个时候就需要我们自己去构建镜像了，或者多个container。

ci这块，我们输入版本分支，帮我们去下载代码，然后运行我们的构建，然后单元测试和代码扫描，因为是基于kubernetes做交付的，所以这里会有构建镜像的步骤，镜像是分支名称加commit-id来命名的。

cd使用的helm来部署的，在企业里面都是会自己去开放chart，这个仓库里面存放的就是chart，ci之后更新chart里面values.yaml文件，然后通过helm去部署，如果出现了问题立刻去回滚。

上面是自动的更新yaml文件，gitops里面推崇的是将环境的配置信息都纳入到版本控制系统里面来进行管理，这样对环境的变更都会留下历史记录，很方便去回顾。

我们代码库里面存放的是业务的代码还有我们的chart。

先加载共享库，第一个容器是jnlp容器，也即是agent，其次就是mvn构建的容器，还有docker构建，因为很多版本都是使用了containerd去作为容器运行时，所以里面是没法使用docker的，所以需要使用dind去构建镜像，然后使用docker，还有curl容器和helm部署的容器。

下载代码

 这里做了优化，将项目的信息改为commit-id，这里也会加一些描述信息。

这里面就是下面的代码部分。 

 build部分是在jnlp容器里面运行的，就是jenkins agent容器里面运行的，下面是在container里面去运行的，

mvn的配置文件已经放在共享库里面了，那么就可以去共享库里面拿到文件的内容，然后写到本地， 也就是将文件从共享库里面拿下来了，然后通过mvn命令指定配置文件。（这里还涉及到m2的缓存）

上传制品其实就是将包名称做了重命名mv，然后将其上传到了制品库， 上传制品其实也就是调用了nexus的api。

docker构建镜像的命令，同时切换容器。涉及到登入信息都放在凭据里面，然后通过变量的方式引用这些凭据信息。

最后就是调用gitlab的api去更新文件。你构建了镜像后面需要去部署，需要找到chart仓库里面，需要去更新values里面的镜像信息，还有tag信息。

这个步骤是自动去做的。

cd部分就是下载仓库，并且helm部署和回滚。

这个下载代码其实就是下载我们的chart仓库。部署的时候就是切换到helm里面去，然后将k8s信息存入到本地，然后放到root下面去。

 这里回滚是通过input的。