原文做者Jason Bloomberg是Intellyx的创始人兼总裁，他为SiliconANGLE撰写了这篇文章，就其数字化转型战略向商业领袖和技术供应商提供了建议。本文经D2iQ翻译并有所删改。原文地址：https://siliconangle.com/2020/09/11/meet-gitops-key-launching-effective-software-releases-cloud-native-era/git
导读数据库
GitOps是一种云原生运维模型，将软件开发领域面向Git的最佳实践扩展到了Ops，与云原生运维所需的基于配置的方法保持一致。GitOps具备充分的资格来抽象化大规模处理临时软件资产所需的环境、部署和配置之间的全部差别，有望在规模上甚至在机群级别上起做用。服务器
DevOps背后的自动化故事主要围绕CI/CD，即持续集成和部署，从而为生产作好工做代码的准备。微信
然而，部署并不是这一流程的终点。代码发布每每是被忽略的步骤——将新软件展现给客户和最终用户，同时确保知足业务的持续目标。网络
在传统的本地和云环境中，要实现这种以客户为中心的CI/CD快速部署很是困难。可是，当将其部署到Kubernetes驱动的云原生环境时，因为运维环境的超大规模和即时性，须要从新的端到端思考——如何将软件发布到生产环境中以及如何运维。架构
对云原生计算的空前需求app
虽然目前大多数企业都在加紧摸索Kubernetes部署，但部分行业，尤为是电信行业，已经开始展望空前的规模需求。框架
做为5G扩建的一部分，电信公司正在基站和存在点创建小型数据中心。可是“小型”是一个具备误导性的形容词，由于这些数据中心自己本质上就是云，每一个数据中心可能运行数十万甚至数百万个Kubernetes集群。运维
从电信业务的角度来看，产品经理但愿可以以复杂、动态的方式向客户推出新服务。他们可能但愿向一小部分客户推出新功能，而后随着时间的推移扩展其部署。他们可能会针对地理位置而推出特定的产品。或者，他们可能会经过合规性限制来划分不一样的服务类别。分布式
此外，电信公司身先士卒。许多行业，从银行业到汽车业，再到媒体业，也在寻求利用相似的功能来提升市场份额和客户价值。
此类企业可能但愿向其各自客户群的不一样细分市场尽量推出普遍多样的服务产品。一样，他们的技术基础设施及支持人员的规模也远远超出了几年前的需求。
一方面，这种针对短暂性和规模的业务需求的爆炸性增加正在推进Kubernetes生态系统异常迅速地走向成熟。
另外一方面，全部这些尖端技术都必须发挥切实的做用。而这正是云原生运维的用武之地。
云原生运维的基础
云原生计算采用既定的“基础设施即代码”原则，并将其扩展到模型驱动、基于配置的基础设施。云原生还利用了“shift left”、基础设施不变原则，偏重可扩展性而非定制性，这自己就是一种模型驱动的实践。
尽管要实现云原生计算的目标，须要模型驱动、基于配置的软件部署方法，可是这不足以应对在云原生环境中确保已部署软件的规模和短暂性的挑战。
软件团队必须将这种可配置性扩展到生产环境中，对生产中的持续变化做出预期和处理。为此，必须使用金丝雀部署、蓝/绿部署、自动回滚和其余技术来应对和利用生产环境中不断发生的、没法预测的变化。
跨不一样的生产环境中进行提取也是一个重要的挑战。不管是不一样的公共云、不一样的Kubernetes发行版，仍是将云和本地环境混合在一块儿的混合IT挑战（可能出于合规性缘由），云原生发布编排都必须抽象化此类差别，以便提供一致的、基于配置的方法，跨此类差别实现自动化部署。
依赖性管理也是必不可少的。不管是单个微服务之间的依赖关系，仍是对提供其余类型软件组件访问权限的 API 的依赖关系，重要的是，即便单个组件是临时的，意外的依赖关系也不得破坏部署。
最后，软件团队必须可以应对空前的规模。Kubernetes自己是按规模构建的，其架构可将微服务部署到容器中，将容器部署到pod中，将pod部署到集群中，可是光有集群还不够。
企业已经在研究复杂的多集群Kubernetes部署。软件团队还必须考虑集群组、集群组的“机群”。这样的机群一般会覆盖多个区域或数据中心，这给云原生部门带来了更大的挑战。
GitOps：云原生运维模型
一个有用的、极简的作法是，云原生社区将组织须要进行的全部工做简化，使Kubernetes可以在“3天”内全面投入生产。
Day 0是计划日。Day 1是部署Kubernetes和其余云原生生态系统的日子。Day 2则表明大规模全面运维的日子。
业内将如此复杂、相互关联的一系列任务划分为3个独立的日子，突显出了一个重要的事实：迄今为止，Day 2的任务一直未受到重视。为了充分关注Day 2的问题，社区创造了一个术语：GitOps。
GitOps是一种云原生运维模型，将本文迄今所讨论的全部概念都归入了考虑，包括在支持大规模动态生产环境的不可变基础设施上进行模型驱动的、基于配置的部署。
GitOps的名字来自广受欢迎的开源代码管理工具Git。然而，SCM主要关注软件生命周期的预发布部分，但GitOps比Git更关注Ops。
GitOps将软件开发领域面向Git的最佳实践扩展到了Ops，与云原生运维所需的基于配置的方法保持一致——直到如今，团队才使用Git来管理和部署配置以及源代码。
因为GitOps具备充分的资格来抽象化大规模处理临时软件资产所需的环境、部署和配置之间的全部差别，所以这种方法有望在规模上甚至在机群级别上起做用。
GitOps还承诺提供一种新的软件治理方法，以解决瓶颈问题。在传统的软件开发（包括Agile）中，质量控制或变动控制委员会的审查要求可能会使软件部署停滞不前。取而代之的是，GitOps对致使这种缓慢的政策进行了抽象化处理，使组织可以更好地利用自动化来快速交付适当的软件管理。
供应商和开源项目逐步升级到云原平生台
云原生计算的核心是开源软件，所以，开源项目在云原生运维中发挥先锋做用是合乎逻辑的。
例如，用于Kubernetes的Argo CD是声明性的、以GitOps为中心的CD工具。一样，Tekton是用于建立CI/CD系统的灵活开源框架，容许开发人员跨云提供商和本地系统进行构建、测试和部署。
可是，从许多方面来看，此类项目只是云原生运维难题中的冰山一角，将这些难题集中在一块儿的是供应商。首先，许多供应商推销基于模型驱动的配置方法。这里有几个例子。
例如，Digital.ai软件公司采用模型驱动的可扩展方法，使更改易于执行并能够传播到全部环境。借助Digital.ai，开发人员无需为每一个部署实例维护复杂的脚本或工做流。
Octopus Deploy公司采用相似的方法，使用模型驱动的Ops配置在异构环境（例如，本地和云）中提供简单的配置抽象。
借助Octopus，开发人员能够将这些脚本放入Octopus中并对其进行参数化处理，从而建立抽象的配置和展示形式，而没必要为每一个环境编写单独的脚本。与单独的CI/CD工具、ops工具和runbook自动化不一样，Octopus提供了一个跨全部工具、环境和平台的部署工具。
与Octopus相似，ShuttleOps公司将大量链接器、本身编码的应用程序和基础设施配置封装起来，并将它们做为管道工做流中的步骤进行参数化。而后将结果报告给所选的编排和管理工具。
CircleCI（Circle互联网服务公司）和Cloudbees公司是另外两个经过声明性配置文件表示完整部署的供应商。
许多供应商还解决了生产中微服务（以及其余组件）之间相互依赖性的问题。Cloud66公司使开发人员和架构师可以以抽象但肯定的方式定义服务依赖关系。这些依赖关系定义了运维必须管理的工做流。
接着，Cloud66能够告诉开发人员什么时候须要某个特定软件的新版原本解决这种依赖关系，而且告诉运维人员他们须要作什么来支持它。
Harness公司提供所谓的“连续交付抽象模型”，该模型使用模板消除依赖关系。CDAM经过自动回滚解决了上游和下游微服务依赖关系的影响。
运做中的GitOps
有多家供应商将云原生运维与GitOps产品整合在一块儿。
在WeaveWorks公司，GitOps具备环境感知能力，可生成表明其所需状态的整个系统模型。WeaveWorks支持多种变体，例如，本地自定义平台即服务——做为同一综合模型的一部分。WeaveWorks利用分布式数据库进行配置，这些配置可能支持数百万个集群，而且能够在高延迟和偶尔断开链接的环境中工做。
GitLab公司是另外一家提供显式GitOps支持的供应商。GitLab提供了一个单一的平台，它将基础设施做为代码方法，将配置和策略定义为“代码”，同时利用自动化将更改与Git合并请求一块儿应用。
GitLab中的这种自动化支持解决了许多治理问题，由于它能够减小审批瓶颈。GitLabs的GitOps策略全都涉及自动化，例如，自动回滚。GitLab还支持版本证据，它能够对每一个版本中包含的全部内容以及相关的元数据进行审计跟踪。
D2IQ公司推出了本身的GitOps产品，称之为GitNative，它结合了GitOps和Kubernetes原生CI/CD。目标是经过从DevOps到GitOps再到GitNative的全生命周期Git自动化，最大限度地提升速度、规模和质量。
D2IQ采用了基础设施不可变的方式——利用Kubernetes API和原语。D2IQ Kubernetes Platform既是无服务器又无状态的，也可在本地运行。D2IQ还同时利用了Argo CD和Tekton开源项目。
最后一个以GitOps为中心的供应商是Codefresh公司.，它使用Git做为事实的惟一来源，自动并保护拉取请求和部署。它处理源代码的来源并支持多个区域。
以机群的规模航行
“Day 2 Kubernetes部署“的关键在于它们可否处理数以百万计的大规模集群。
一些供应商在推销这种功能。WeaveWorks提供集群管理，它运行在客户选择的托管Kubernetes平台上，还能够进行应用程序管理，包括发布自动化和可扩展到机群的渐进式CD。
Vamp.io BV利用基于Kubernetes的环境为包含大量临时微服务的应用程序提供发布编排。该供应商为DevOps提供了版本编排，能够彻底自动化发布，包括A/B测试，细粒度分段和多租户发布。
D2IQ提供大规模GitOps，能够很好地处理大量异构节点，包括集群、集群组和机群。D2IQ还提供单一管理平面来治理Kubernetes集群的机群。
最后
对于"传统"企业中的任何人来讲，他们很容易看到云原生部署的大规模性和短暂性特征，并想知道他们的组织是否须要遵循这些模式的软件，这些软件与当今企业环境中他们熟悉的大多数软件有着天壤之别。
诚然，行业需求会有所不一样，各个公司将面临来自竞争对手的不一样挑战，但任何人都不该该所以认定本文提出的Day 2愿景对本身不适用。
请记住，若是一种技术能力可以提升某些组织推出知足客户需求的差别化产品和服务的能力，那么他们的竞争对手也必须利用相似的能力，不然就会面临失去竞争力的风险，最终没法生存。
换句话说，云原生计算已经到来。它已经为那些利用这些能力向各自市场提供差别化产品和服务的企业提供大规模性和短暂性。若是您的组织不尽快跟上这股潮流，您的将来就会问题重重。不要掉队！
*在原做者撰写本文时，Digital.ai和Dynatrace之前是Intellyx的客户。本文中提到的其余任何组织都不是其客户。
往期精彩文章
关于D2iQ
点击“阅读原文”，了解更多D2iQ Kubernetes Platform
本文分享自微信公众号 - D2iQ（d2iq_apac）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。