Kubernetes上本地挂载jar包与将jar打进容器的比较

一，前言

先说说我这边大概的一个代码的更新过程
JAVA后端：dev > push Code > repository hooks > jenkins > git pull > mvn package  > kubernetes apply > 钉钉通知 > access success  = 90s - without an outage

为了加快更新速度，其中一些细节处理，如添加hook，减少mvn的编译包（增量编译），kubernetes滚动更新，Pod的检测保证不停机。

 

二，先说jar打进容器

这边使用的是jenkins，大概说一下之前的实现方式。

JAVA后端：dev > push Code > repository hooks > jenkins > git pull > mvn package(在mvn打包docker镜像，并上传仓库)  > kubernetes apply(更改镜像版本) > 钉钉通知 > access success  = xx秒(因时间太久没采用这种方式) - without an outage

1，可以不使用mvn插件进行打包也行，不过需要自己写命令脚本

2，在更改yaml文件镜像版本  使用sed进行替换（寻找某些变量进行标识，如jenkins内置变量，git版本号等等）

3，使用这种方式，有个问题就是需要清理旧的镜像，因为我这边，更新的次数太频繁，所以放弃这种了

4，采用这种方式会少了一些细节处理的问题，如脚本判断，只需要关注清理旧的镜像，耗费时间

 

三，本地挂载jar包

这里用的就是前言说的那种步骤

JAVA后端：dev > push Code > repository hooks > jenkins > git pull > mvn package  > kubernetes apply > 钉钉通知 > access success  = 90s - without an outage

1，这里需要注意的是 yaml文件的编写，（Deployment，imagePullPolicy，command，hostPath，一些健康检测，就绪检测等等）

2，上面说的就是拉取镜像方式，使用java -jar去启动，挂载jar包进去，滚动更新，并检测是否就绪，之后在替换

3，这种挂载方式，需要有一个共享存储，这里使用的nfs。如果没有共享存储，jar包是没办法同步的，因为用的hostPath

4，只所以采用这种方式，是因为不想在dev环境上浪费太多docker build，docker push时间（虽然是内网，但是也需要浪费30-40秒）

5，如何进行apply呢（因为不改动yaml的情况下是没办法进行替换的）解决方法，写了个替换版本的脚本，有2个镜像，每次更新去执行，如果yaml的版本是A，就替换成B，如果yaml版本是B，就替换成A

 

四，本地挂载jar包与将jar打进容器的比较

其实选择两种都会有些不好的地方，只能选更为合适自己的，因我这边需要加快这种流程的速度，所以选择挂载方式

说说他们不好的地方

本地挂载jar包：

1，需要nfs存储，

2，需要将挂载的路径不能与jenkins 编译后的java里的target一致(如果一直会出现在mvn打包过程中，会将旧的jar包替换，这个过程会出现某些noclass，服务会报错)，
解决方法：使用rsync ，如果mvn编译后是 /JAVA/target/java.jar    那就把挂载目录设置为/新的jar包路径/java.jar

rsync -av /JAVA/target/java.jar /新的jar包路径/java.jar   

报错截图：

 

将jar打进容器

1，清理旧的镜像，而且每个镜像在200M左右（使用的oracleJDK=130M,jar包几十M）

2，耗费时间（在docker build  docker push）

 

五，本地挂载jar包与将jar打进容器的比较

他们好的地方就是。

本地挂载jar包：

1，快速，不需要等待打包镜像的时间

 

将jar打进容器

1，方便，不需要执行太多花里胡哨的操作

 

整个过程为自己的操作过程，如果有更好的方式，麻烦告知下，也想更好的接触更多技术