本来生活网基于KubeSphere的DevOps升级之路( 二 ) 我叫杨杨

----本来生活网基于KubeSphere的DevOps升级之路//----

　　积累经验值在 KubeSphere 初步完成 CI/CD 流程后，我们继续研究和完善流水线。比如，在研究 Jenkins Pipeline 的自定义方法后，我们实现了动态生成应用相关信息。 Jenkins 成为企业级的主流 CI/CD 软件很大一部原因是其拥有丰富的插件生态，因此我们继续研究 Jenkins 插件，并在流水线中实现了上传 FTP、通过命令动态部署 ConfigMap、部署存储等流程。

----本来生活网基于KubeSphere的DevOps升级之路//----

　　Level 2：完善流水线经过不停的努力学习 Jenkinsfile 语法及插件后，我们的 CI/CD 流程升级到 Level 2 。我们在流水线中，加入了部署配置、部署存储、上传CDN等，如下图：

----本来生活网基于KubeSphere的DevOps升级之路//----

　　小坑-动态参数因为业务需要，我们的 CI/CD 流程需要分为几种类型的发布，而每种类型的发布都需要不同的参数;于是我们按照之前学习到的 Jenkins Pipeline 语法，想当然的使用 When 条件语句去判断传入的发布类型跳转到不同 Stage ，然后在通过 Input 输入参数语句实现不同参数的输入。但是发现 Input 参数语句的优先级高于 When 条件语句，也就是说不管我选择哪个发布类型都要先输入参数，然后系统才会去判断是否跳过该 Stage ，这与我们想的完全不一样。于是我们各种 Google 和查官方文档，最后找到另外一种 input 语法，可以把 input 的优先级降低，使得 When 条件语句先判断，这样就满足了我们的需求。

----本来生活网基于KubeSphere的DevOps升级之路//----

　　Level 3：经过采坑动态参数，我们将 CI/CD 流程升级到 Level 3 ，即新增了根据不同发布类型的任务，满足动态生成所需的参数，具体流程如下图：

----本来生活网基于KubeSphere的DevOps升级之路//----

　　小坑-ConfigMap在实际生成环境中我们回滚肯定是要将应用的程序和 ConfigMap 一起回滚的，但是 Kubernetes 的 ConfigMap 是没有版本控制的，这对于管理就会非常麻烦。于是，我们只能使用笨办法，在每次发布应用时，去配置中心抓取当前应用的配置生成 ConfigMap 。并且，在 ConfigMap 名称后面跟上当前应用的发布版本，然后，在部署到 Kubernetes 时，会将该版本的 ConfigMap 挂载到当前发布的 Deployment 中，这样我们在回滚或发布时，就能直接将应用的镜像和 ConfigMap 一起回滚到指定版本。唯一美中不足的就是 ConfigMap 会越来越多，后期只要定时清理就好，后续也将调研相关的配置管理工具。