前面的章节，手动去执行maven package，手动创建镜像、push、调用kube-controller去控制K8S完成一个新的调度，在实际过程中，开发、部署和测试是一个不断重复、不断迭代的过程，这个过程肯定是要自动化的。

CI 持续集成

CD持续部署

本章熟悉常见的CICD相关工具，以及在没有K8S之前，有了K8S之后，CICD的流程是啥样的，啥变化，借助之前的代码实现CICD的流程。由于每家公司都有自己的组织架构，都有自己的业务特征，所以在CICI落地过程中，肯定有个性化的东西。

这里只提供一些思路。

K8S之前已经有了很久的历史，发展到今天，催生了周边成熟的工具，

代码仓库Gitlab、构建工具maven、持续集成工具Jenkins、结合脚本scripts完成持续集成的工作，代码预编译、构建代码的健康检查、单元测试、发布到指定的服务器等都可以完成。

8-1 kubernetes与cicd

一、没有K8S之前的CI和CD的流程:

传统WEB:git、maven、构建结果到指定的服务器、调用脚本(停止老服务、启动新服务)

发布服务:事先知道发布到哪台机器上，并且事先在这台机器搭建好WEB服务器，比如tomcat，一般来说，每个服务都要有一个固定的节点。

调用脚本:停止旧的服务，启动新的服务。

这个流程隐含的问题:

问题1:服务先停止再启动。问题:服务的间断、停止并不能保证马上起来，一段时间的不可用。

问题2:再关注下服务器，服务器一般是实体机或虚拟机，服务器一般不止部署一个服务，大家共同使用一台机器，内网资源不宽松。

另外，大家共同使用一台机器，环境问题，环境不可控。比如有人改了这个主机的DNS，配置了hostname，配置了ETC的host绑定了某个域名等，都可能影响到服务。

问题3:启动脚本问题，启动脚本执行完了，程序是否能正常对外提供服务呢？没法确定的，很难确定(很难用一个脚本判断)服务的状态，项目启动成功之后，还得回过头检查是否可能出了什么问题，导致服务间断的时间延长，直到解决了BUG服务才可用，如果有人在做测试，那么就很严重了。

问题4:可能要多次构建。公司的环境不止一套。开发环境dev，测试环境test，预发布环境release、准生产环境preroduct、生产环境product。这么多套环境，每个环境的服务都要重新构建，非常耗时。

二、有了docker和K8S之后的CI和CD的流程:

提交代码Git、构建代码、构建镜像、镜像推到仓库、K8S部署、K8S自身的健康机制(每个应用都可以设置自己的健康检查方式，调用K8S的API做HealthCheck可以每个应用的状态，健康检查过了就成功，否则就失败)。

有了Docker和K8S的好处:

好处1:环境稳定(每个进程运行在一个稳定、独立的操作系统中，所有的东西都跟镜像相关，一成不变)。

好处2:针对前面的问题，解决了服务不间断问题(K8S本身就保证了服务的高可用，在滚动部署的时候，哪怕只有一个实例，先启动一个，成功之后再停掉原实例，保证后端的请求一直是可以请求到健康的服务的)。

好处3:针对每个环境都构建，用了K8S和docker之后呢，就可以一次构建、多环境运行，对应用也有要求，代码中不能用写死的环境相关的东西，环境相关的配置都抽离出来，比如可以放到配置中心、K8S的consumerMap里面、公共的存放空间，这样的话，就可以从

开发环境dev、测试环境test、预发布环境release、准生产环境preroduct到生产环境product，

镜像就只有一个，最开始的打出来的K8S的镜像，可以一步步的走到线上去，也进一步提高了服务的稳定性，也就是每个环境都是测试的同一个镜像，如果每个环境都构建了一次，可能测试的结果就不相同。