最近项目在开始往helm来转变。鉴于历史上众多yaml，编写helm的chart并不是一件容易的事情。
我们目前的项目中有用到ansible，go等用于自动部署我们的企业级应用。选择它们以及要往helm上转的好处是：
- 坚持一切版本化，一切自动化的原则；
- Helm在声明式思维方面相对其它工具更友好；
- 方便配置与制品分离。
当然你要是说为了使用，谁又会拒绝一个好看的页面呢。（比如rancher，openshift，kubeSphere）
记得第一次接触helm，当时的版本还是v2，还要部署tiller。这个tiller用起来就很难过。还好v3的时候helm把它给移走了。v3社区的反应还是不错的，当然文档也相对健全了些。于是我们着手开始编写自己的chart。
自行版本化chart
maven、npm等构建工具的包会有一个唯一的官方源，但是，Helm的chart包似乎没有，你会遇到很多不同的源。这对chart的版本控制非常不利，因为你不知道哪天，远端的源就不见了。所以，最好的做法，使用helm pull命令将chart下载本地，然后指定一个版本上传制品库Nexus/artifactory的Helm仓库中。chart 一般不会特别大，所以不用像image那样过于担心他的体积，需要定时清理一些长久不使用不维护或者临时的制品以达到释放空间，资源的目的。但是chart需要一个好的维护管理标记，比如chart的目的功能，版本等。
使用upgrade —install子命令部署应用
刚开始学习Helm时，我们通常使用helm install来安装chart。但是，第二次执行helm install，就会报错，因为K8s中已经存在了该chart的release了。这个过程对流水线是不友好的，所以，在流水线，我们使用的是helm upgrade —install xx ./xx.tgz来部署。或者我们还可以通过namespace的方式，来达到资源的隔离。
尽早标准化应用，标准化chart
如果存在服务很多，我们是不是需要每个服务都需要创建chart呢？我觉得需要的。本着小步快走的目的，先行替换部分方式位chart，然后再逐渐改变剩下的。helm归根到底只是一个辅助工具。所以我们会优先改变那些比较容易实现的服务转为chart方式。（当然，还有个考量因素是deliver 给客户的制品。业务需要哪些服务需要一起给客户，那么它们之间就存在了业务上的耦合）我们会优先把公共的基础服务先期转为chart，比如：rabbitmq，redis，数据库等。然后转变相对独立的业务模块，比如身份认证等。在最后再转变核心的模块。有个好处就是，先期转变的服务模块，也在各种环境中得到了验证，确保这些服务是能正常work的，且没有引入新的regression。那么在转变核心块的时候我们是很有底气来判断是核心除了问题。与他关联的服务组件都没有嫌疑。当然在写的时候也是由易到难。制定标准写法，哪里需要暴露出来等最好先期定义一下。方便以后运用的时候能够很好的达成目的。所谓标准化，比如那些pod对外提供服务的端口号、优雅停机、设置环境变量的方法等等这些通用的领域的配置都应该是统一的。
尽量少使用if-else判断
以chart中，我们应该尽量少使用if-else判断。有时，宁愿多写几个YAML也不要在同一个文件嵌套if-else。因为要尽可能的让chart本身所见即所得。过于复杂的逻辑反而让chart显得过于臃肿。
待续。。。
