GitOps将Git的力量带入Ops

到目前为止，您可能已经听说过GitOps，如果这样，您可能仍想知道它的含义。如果我告诉您GitOps不一定涉及Git（真的，不是），它也不需要，也不需要Kubernetes（与之定期配对的编排引擎）。 感到困惑？好吧，尝试一下：GitOps是一种以开发人员为中心的体验来管理应用程序的方法，正如创造了“ GitOps”一词的公司Weaveworks可能会说。更好地控制他们的工作。可以将其视为类固醇上的DevOps或自然得出结论的DevOps。 这个结论？使开发人员能够在其应用程序的操作中扮演更大的角色，同时也使操作人员的生活大大改善。
Linus Torvalds可能是最著名的Linux创建者，但是Git（他的发明的分布式版本控制系统）可以说是更为重要。托瓦尔兹曾说过：“ Git证明了我不仅可以成为一个不可思议的奇迹，”但这在极端情况下还是轻描淡写了。虽然Git之前有版本控制系统（例如Subversion），但自2005年推出以来，Git改变了开发人员构建软件的方式。 根据分析师Lawrence Hecht进行的研究，如今Git已成为软件开发的“近乎通用”的组成部分。
如何“近乎通用”？好吧，Stack Overflow调查显示它在2018年的使用率为87％，而JetBrains的数据将其采用率从79％（2017）跃升至90％（2019）。由于有这么多代码位于公共Git存储库和（甚至更多）私人Git存储库中，因此我们处于将Git打包操作的绝佳位置。 引用Weaveworks首席执行官Alexis Richardson的话说：“ Git是强大的选择，[并且]如果可能的话，我们总是会推荐它，但是说GitOps需要Git方面的专业知识是错误的。
使用Git作为UI并非如此需要。 Git是真理的来源，而不是UI。”例如，银行在Subversion或Mercurial中有旧的存储库。
它们可以用这些存储库进行GitOps吗？是。实际上，GitOps的某些元素早在2000年代就开始出现。 但是对于大多数公司而言，在很多时候，对Git的依赖使GitOps在DevOps上取得了如此引人入胜的进步，并带来了巨大的近期机遇。
哦，还有Kubernetes。为什么选择Kubernetes？尽管可以使用不同的容器编排引擎，但Kubernetes是行业默认设置。根据Weaveworks的说法，GitOps有两件事： 也许您并不需要全部使用Kubernetes，但是许多组织正在将它视为他们部署软件的重要方面。
然而，仍然有太多公司对Kubernetes集群视而不见。为何如此？根据Weaveworks的首席技术官Cornelia Davis的说法，尽管IT拥有各种工具（例如
，配置管理，发现等）来尝试跟踪系统内部和系统之间正在发生的事情，但在很大程度上这是浪费的。未知，这就是为什么补丁管理如此困难的原因。 戴维斯说：“迁移到Kubernetes并没有使IT失去魔力。
“他们将已经存在的问题带入了Kubernetes。” 或如Richardson所说：“您如何知道是否更新Kubernetes处于正确状态？您是否被告知状态错误？答案是不。 [开发人员]不知道。
他们瞎了。”因此，Kubernetes用户被“冻结”，因为他们被困在害怕更新的集群上。 GitOps模型可以解决此类Kubernetes瘫痪问题，而无需开发人员成为Kubernetes大师。理查森： 如果集群中的所有内容都通过模型进行了更新怎么办？如果您在集群中安装了一些查看当前状态的代理并将其与模型进行比较，则可以进行更改以强制其与模型保持一致。您不是直接更新它们-您是在更新模型。一路走来，您将获得持续集成，逐步交付等。
Weaveworks对此进行了更详细的描述，但我也喜欢Redmonk分析师James Governor的摘要： 对于开发人员及其可能服务的应用程序团队而言，这种方法听起来很棒。但是，平台工程团队，我们经常称为“ ops”的人员又对安全性，合规性，成本管理等负有特殊责任的人呢？ 对于运维人员，GitOps通过可重复性推动了巨大的价值。是否需要备份可用区？平台工程团队知道，由于所有模型都是模型化的，因​​此他们只需运行协调器即可使事情恢复与模型一致。
加上Git的还原/回滚和fork功能，ops团队可以获得稳定且可复制的回滚，更不用说Git的安全优势和更多。 简而言之，GitOps可能就是DevOps长期以来的志向：即使平台工程（ops）能够更好地担当他们的角色，对于开发人员来说，这也是一种为应用承担更多操作负担的好方法。 br>