k8s与CICD--利用helm部署应用到kubernetes

前言

本小节应该是这个系列剩下的两个小节之一了。剩下一个是以前承诺好的drone-wechart插件。本节主要介绍利用helm部署应用到kubernetes中。
至于helm，详细能够参考FreeWheel Lead Engineer 张夏写的一系列文章。总之，k8s中yaml文件的编写复杂程度直接决定了k8s的使用门槛。利用Kubernetes部署一个应用，须要Kubernetes原生资源文件如deployment、replicationcontroller、service或pod 等。而对于一个复杂的应用，会有不少相似上面的资源描述文件，若是有更新或回滚应用的需求，可能要修改和维护所涉及的大量资源文件，且因为缺乏对发布过的应用版本管理和控制，使Kubernetes上的应用维护和更新等面临诸多的挑战，helm主要是能解决这些问题。

而drone中提供了三个kube-helm插件，用来配合drone，实现k8s的cicd。这三个插件大同小异，我集中总结一下：

1. drone-kube
2. drone-kubernetes
3. helm

不过全部的插件都是只能用来更新应用，不能新建。

整体思路

1. 编写本身的.drone.yaml,放置到项目根目录下。主要就是引用各类pipeline插件，例如默认添加的git拉取代码的插件，项目编译环境的插件，此处针对不一样语言，能够定制不一样的镜像，例如咱们以前的项目会把common这种基础库也作到docker镜像里，能够提升构建速度。以及telegram，line，mail等通知插件。
2. 提交代码到github或是gogs等版本控制工具里，触发webhook钩子，通知drone执行整个设计的构建流程。该项目中，须要另外两个插件，一个是docker镜像，用于将编译好的程序作成镜像，并推到本身的docker registry中。因此须要在根目录下，编写本身的DockerFile文件。另一个是上面提到的helm插件。
3. docker hub因为墙的缘由，这边通常是使用harbor，vmware中国团队基于docker registry作出来的私有镜像仓库。
4. helm能够选用k8s官方的公共仓库，通常都会搭建一个本身私仓，结合起来使用。
5. 新的镜像推到harbor以后，helm插件就能够执行部署步骤了。
6. 最后通常都会引用通知插件，将构建结果通知部署人员。

总结

路漫漫其修远兮，其实整个helm插件只是能够知足通常的需求，整个部署过程常常会有必定的部署策略，蓝绿，金丝雀等。这一块须要不一样的paas平台，从新实现。另外以前提到的，helm插件只能用来更新，不能新建。因此这一块须要探索的路还很长。
说到部署策略，不得不说Spinnaker，实现的功能不少，可是足够的复杂，目前来看，国内只有小红书用起来了。实现的语言是groovy，也不够友好(固然主要是我不会).