导语编程
过去十年的编程经历了一系列革命性的转变。其中之一来自于围绕devop的一组实践，这些实践使开发和运营团队在一个共享的工做流程以及持续集成和分发（CI / CD）中保持一致，在这些实践中devop团队能够提供不断增量更新代码库。从单片代码库过渡到由编排平台（如Kubernetes）管理的容器上运行的基于云的微服务，这一转变带来了另外一种转变。安全
正文服务器
在集群或云系统上运行的基于容器的应用程序可能很复杂，而且即便使用像Kubernetes这样的平台来编排事物，也很难对其进行配置和管理。GitOps是一组新兴实践，旨在经过应用devops和CI / CD 领域的技术来简化此管理任务。微信
GitOps的关键是将基础架构视为代码的想法，它采用与devop用来供应应用程序相同的基础设施供应方法。所以，不只文件中描述了应用程序，并且底层主机和网络都在文件中进行了描述，这些文件能够像版本控制系统中的任何其余代码同样被处理，并具备自动过程，可使实际应用程序收敛。与那些文件中所述的那个。网络
在GitOps语言中，版本控制系统中的代码是有关应用程序在生产中应该是什么样的惟一真实来源。架构
GitOps定义编程语言
Weaveworks是为推广GitOps概念所作的最大努力的公司。稍后咱们将详细介绍Weaveworks角色，但首先让咱们看一下GitOps的定义，该定义分为两部分：分布式
Kubernetes和其余云原生技术的运营模型，提供了一套最佳实践，能够统一集群，容器化应用程序的部署，管理和监视。svg
在应用程序管理中得到开发人员体验的途径，将端到端 CI / CD通道和Git工做流应用于操做和开发。微服务
换句话说，GitOps是一组专门用于管理Kubernetes和相似平台的实践，随着愈来愈多的dev商店采用devop实践并将代码迁移到云中，GitOps也适合更普遍的应用程序。可是，要了解GitOps的秘诀及其解决的问题，咱们必须谈论其组件。
Git的定义
GitOps中的Git是指Linus Torvalds在2005年开发的流行的分布式版本控制系统。Git是一种工具，它容许开发人员团队在应用程序代码库中一块儿工做，存储他们先前修改的各类代码分支。将它们合并到生产代码中。Git中的一个关键概念是拉取请求，在该请求中，开发人员正式要求将他一直在从事的某些代码集成到代码库中的另外一个分支中。
Git拉取请求为团队成员提供了机会，在就是否应将新代码添加到应用程序达成共识以前进行协做和讨论。Git还存储了旧版本的代码，若是出现问题，能够轻松地返回到最新的良好版本，并容许您快速查看两次修订之间的更改。Git可能更被称为GitHub（云托管版本控制系统）的基础，可是Git自己是开源软件，能够部署在从内部公司服务器到PC的任何地方。
请记住，尽管咱们一般将Git视为一种计算机编程工具，但实际上它与您所使用的内容无关。Git将很高兴将任何文本文件集视为其“ 代码库 ”，例如，但愿跟踪协做工做编辑的做者可使用Git 。这很重要，由于GitOps核心中的许多代码库都由声明性配置文件而不是可执行代码组成。
在进一步介绍以前要说的最后一件事：即便以“ Git”为名，GitOps实际上并不须要使用Git。已经投资了其余版本控制软件（例如Subversion）的商店也能够实现GitOps。可是，Git在开发人员世界中普遍用于实现CI / CD，所以大多数GitOps项目最终都将使用Git。
CI / CD流程是什么？
对CI / CD的完整介绍不在本文的讨论范围以内，可是咱们须要说几句话，由于它与理解GitOps的工做方式有关。经过诸如Git之类的版本控制存储库，能够实现持续的CI / CD集成：开发人员能够对其代码库进行不断的细微改进，而没必要每隔几个月或几年推出巨大的总体式版本。经过称为“ 管道 ” 的自动化系统，能够在生产环境中构建，测试和部署新代码，从而实现连续部署。
再说一次，咱们仍在谈论代码，一般会将以C，Java或JavaScript之类的编程语言编写的可执行代码的愿景聚集在一块儿。可是在GitOps中，咱们处理的“代码”主要由配置文件组成。这不只是一个小细节，并且是GitOps的核心。正如咱们已经说过的，这些配置文件是“惟一的真理源”，描述了咱们的系统应如何。它们是声明性的，而不是指导性的。这意味着配置文件不会说“启动十台服务器”，而只会说“该系统包括十台服务器”。
GitOps公式的CI一半使开发人员能够快速对这些配置文件进行调整和加强。当自动化软件代理尽最大努力确保应用程序的实时版本可以反映配置文件中的描述时，就会产生一半的CD（使用GitOps语言与声明性模型相融合）。
GitOps和Kubernetes
如前所述，GitOps概念最初是围绕Kubernetes应用程序的管理而开发的。有了咱们如今所知道的，让咱们回到这里的Weaveworks GitOps讨论，看看它们如何描述如何根据GitOps原理对托管Kubernetes进行更新。总结以下：
开发人员向Git请求新功能。
该代码通过审核和批准，而后合并到主代码库中。
合并激活CI / CD通道，该通道将自动测试和重建新代码并将其显示在注册表中。
软件代理会注意到更新，从注册表中提取新代码，并更新配置库中的配置文件（以YAML编写）。
Kubernetes集群中的软件代理会根据配置文件检测到它已过期，删除更改并实施新功能。
Weaveworks和GitOps
步骤4和5显然是在作不少繁重的工做。使Git存储库中的“真相源”与实际的Kubernetes应用程序神奇地同步的软件代理，使GitOps成为可能。如前所述，就GitOps而言，使活动系统更像配置文件中描述的理想系统的过程称为收敛。（当实时系统与理想系统不一样步时，称为发散。）理想状况下，将经过自动化过程实现融合，可是自动化能够作什么存在局限性，有时须要人工干预。
咱们已经用通用术语描述了该过程，可是若是您真的要看到Weaveworks页面，则咱们提到的“软件代理”是公司Weave Cloud平台的一部分。“ GitOps ”一词是由Weaveworks首席执行官Alexis Richardson创造的，它的部分做用是使Weaveworks平台对已经沉迷于devop和CI / CD世界的开发人员具备吸引力。
可是Weaveworks从未声称过GitOps的垄断，这不是特定产品，而是更多的哲学和最佳实践。正如提供CI / CD解决方案的公司CloudBees的博客所指出的那样，GitOps 表明了一种开放的，与供应商无关的模型，该模型是对Amazon等大型云提供商部署的Kubernetes专有托管解决方案的一种反应。，Google和Microsoft。CloudBees提供了本身的GitOps解决方案，这一领域的众多参与者也是如此。
GitOps和devops
Atlassian是一家开发了几种敏捷开发人员工具的公司，在其博客文章中值得一读，其中谈到了GitOps的历史和目的，他们认为GitOps表明了这一思想的逻辑延伸。加入了devops。具体来讲，GitOps是对基础架构概念（即代码）的详细阐述，该概念源于devops环境。正如Atlassian所见，GitOps桥接了devop技术现有解决方案，这些解决方案已发展为解决系统管理问题以及分布式云托管应用程序的特定需求。各类云提供商所提供的自动融合使GitOps独树一帜。
尽管GitOps继续专一于Kubernetes，但咱们但愿咱们已经阐明了它如何适用于更普遍的分布式和基于云的应用程序世界。一个博客帖子由开源安全提供WhiteSource总结GitOps的好处：
可观察性：GitOps系统在复杂的应用程序中提供监视，日志记录，跟踪和可视化，所以开发人员能够看到发生了什么以及在哪里发生了什么。
版本控制和变动管理：显然，这是使用版本控制系统（如Git）的主要好处。有缺陷的更新能够轻松删除/撤消。
易于采用：GitOps创建在许多开发人员已经具有的 devops技能的基础上。
生产率：GitOps提供了devop和CI / CD在其余方面的生产率提升。
审核：借助Git，能够将每一个操做追溯到特定的承诺，从而能够更轻松地跟踪错误缘由。
即便您不使用Kubernetes，早晚极可能GitOps也将成为您工做流程的一部分。
渠道激活专题文章推荐：
进入2020年，新冠状病毒疫情突发，云计算市场渠道招募和拓展工做也受到了一些影响，甚至在业界，已经不多人再谈及渠道一词了。但，毫不会永远这样。
从开源云计算厂商此前进行的渠道拓展来看：首先，整个渠道拓展体系从不是随意创建，而是须要根据不一样区域市场状况，以及渠道伙伴拥有的不一样技术能力来进行内容宣导。其次，渠道内容的设计和组织也不是自由的，要根据行业客户实际场景需求来作相应输出。
开源云计算厂商一般会构建大量的产品线和复杂的解决方案体系，这就须要借助渠道伙伴的力量面向最终用户输出，以此保障最佳客户体验和售后支持。所以，渠道伙伴在开源云计算市场拓展方面的能力强弱，关系到厂商总体的市场战略实施效果。
在近几年，不少开源云计算厂商携手渠道伙伴共同应对云化时代的变化与挑战，加速行业云计算转型。实际上，这一调整意味着开源云计算厂商将更加剧视与伙伴的生态合做，并鼓励合做伙伴发挥各自优点，协同为客户传递价值。但开源村也发现，也还有不少开源云计算厂商没有成功创建起本身的渠道体系。
云化时代到来之际，行业客户业务场景会根据云化转型的节奏进行调整。开源云计算服务提供商在此时的做用是帮助渠道伙伴学会借助平台之力，知足行业客户的真实需求。这是相比友商而言，更具竞争优点之处。优质的平台，会助力渠道伙伴得到更多行业用户的信任。
对于开源云计算厂商而言，若是但愿在抢滩新基建上构建差别化竞争优点，具有高超的售前技能、售后体验，并拥有创新的技术服务能力与解决方案构建能力是实有必要的。巧了，这些都与渠道构建息息相关。
私有云凉了么？固然没有！连当事人都出来辟谣了！私有云需不须要渠道？固然须要！没有渠道，开源云厂商怎么为私有云产品、营销和销售提供售前支持？没有渠道，开源云厂商怎么可以既少花钱，又能实现高效、便捷、快速的售后服务？
开源云计算市场竞争激烈、用户需求多变，对于怎样带货，怎样推进市场增加，也成为让不少厂商头疼的事。开源村以为，开源云计算渠道虽不比网红，但此时应当敢于站出，全面激发和表现出自身的“带货”实力。
有报道称，一名开发者用两年的业余时间开发并维护了一个开源项目由于微软的剽窃而被迫停止。有网友评论说，这也是不少大公司的通用策略，好比组织技术人员与之交流，而后套取有用信息，而后发展本身的产品，这在中国叫作“偷艺”。事实上，设想一下，若是这个项目可以早日产品化，而且建构好了一套成熟的市场分发渠道，或许形势就会彻底不一样。
本文分享自微信公众号 - 开源村OSV（osvosvosv）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。