https://hangyan.github.io/tags/devops/Recent content in DevOps on 涯余的博客Hugozhhang.yan@hotmail.com (涯余)hang.yan@hotmail.com (涯余)Wed, 11 Sep 2019 16:44:26 +0000https://hangyan.github.io/post/2019-09-11-gitops/Wed, 11 Sep 2019 16:44:26 +0000hang.yan@hotmail.com (涯余)https://hangyan.github.io/post/2019-09-11-gitops/<p>Kubernetes 确定了统治地位之后，Service Mesh 和 GitOps 也渐渐火热起来。Service Mesh 领域内 , Istio 已经逐渐占了上风，但 GitOps 扔未有统治性的工具出现，尚处于早期阶段。</p> <p>相较而言, Service Mesh 本身技术性更强一些，而 GitOps 涉及的面比较广。对企业来说，会有很多额外因素需要考虑，一方面要考虑旧有系统的兼容性，另一方面要考虑所采用工具的可占有性(是否可以自己部署，维护，开发？)。所以即使现在社区有功能比较完善的 GitOps 工具，也很难被企业所采用。</p> <p>但就理念而言， GitOps 本身的前景非常广阔，最直观的改善就是对于研发人员效率的提升以及产品 Deploy 效率的提升。这些优点是以如下特性/流程为基础的:</p> <ul> <li>让工具去处理杂事</li> <li>研发人员使用熟悉的 Git ，专注于产品研发</li> <li>使用声明式语法描述环境目标状态，类似于 kubernetes</li> <li>使用 Pull Request 进行 Review</li> <li>流水线集成 lint /test, 进行较为基本的自动化 check</li> <li>PR 通过即可直接上线</li> <li>通过线上故障来总结反馈并修正自动化 check</li> </ul> <p>这个流程的效率非常高，事实上很多企业会在改善自身研发流程的过程中多多少少都实行了类似的模式，但问题就在于很多使用了 ad-hoc 或者 无法产品化的手段。如何解决社区标准化的产品与企业应用场景之间的鸿沟，是 GitOps 亟待解决的问题之一。</p> <p><img loading="lazy" src="https://miro.medium.com/max/2020/1*QNwZhE9HAJAWSi__0fnMhw.png"></p>