什么是 GitOps

首先咱们来理解下 GitOps：

GitOps 最早是在2017年由 Weaveworks 创建提出，它是一种进行 Kubernetes 集群治理和应用程序交付的形式。 GitOps 应用 Git 作为申明性基础设施和应用程序的繁多事实起源。 GitOps 的核心思想是领有一个 Git repository，蕴含指标环境中以后所需基础设施的申明性形容，以及使指标环境与 Git repository 中形容的状态相匹配的自动化过程。借助 GitOps，能够针对 Git repository 与集群中运行的内容之间的任何差别收回警报，如果存在差别，Kubernetes reconcilers会依据状况自动更新或回滚集群。以 Git 作为 pipeline 的核心，开发人员能够应用本人相熟的工具收回PR，以减速和简化 Kubernetes 中应用程序部署和操作工作。

这使得 GitOps 在 Twitter 和 KubeCon 上引起了不小的轰动。

这里说一下Weaveworks 这家公司，这是一家为开发人员提供最高效的形式来连贯、察看和管制 Docker 容器的公司。在官网上，咱们能看到，GitOps 工作流的准则和模式，如何实现它们在生产中大规模运行 Kubernetes，以及GitOps 和基础设施即代码 (IAC) 配置管理工具之间的区别和最佳实际等等。https://www.weave.works/techn...

K8S的创始人之一：Kelsey Hightower 曾发推文评论过 GitOps是基于申明式基础设施的版本化 CI/CD，进行脚本化操作，开始（自动化）散发。

GitOps 是如何工作的呢？

把环境配置作为 Git repository

GitOps 以代码库为外围来组织部署。咱们须要至多有两个仓库：利用程序库和环境配置库。利用程序库蕴含应用程序的源代码和部署应用程序的 manifests。环境配置库蕴含部署环境以后所需基础架构的所有部署manifests。它形容了哪些应用程序和基础设施服务（音讯代理、服务网格、监控工具等）应该在部署环境中以何种配置和版本运行等内容。

基于 push 与基于 pull 的部署

两种部署类型之间的区别在于如何确保部署环境与所需的基础架构雷同。这里举荐，首选基于 pull 的办法，实现 GitOps 更平安、也有很多已有的最佳实际来借鉴。

基于 pull 的部署

传统的 CI/CD pipeline由内部事件触发，比方新代码被推送到利用程序库时，就触发了。

而基于 Pull 的部署办法，引入了operator。它通过一直将环境配置库中的冀望状态与部署环境中的理论状态进行比拟来接管pipeline的角色。当发现差别时，operator会更新部署环境中的状态以匹配环境配置库。此外，它还能够监控 image registry ，以查找要部署的新镜像版本。

基于 pull 模型的部署不仅能做到环境配置库更改时更新环境；

operator也能做到当理论环境与环境配置库中存在差别时进行还原。

这就确保了所有更改都能够在 Git 日志中进行跟踪，因为任何人都不容许对集群进行间接更改。

那么，这种形式的监控点就集中在 operator 及各个组件上了（比方，镜像仓库是否能失常拉取到镜像等等）。

为了防止基于 Push 场景中的上帝模式权限问题，operator 应该始终与要部署的应用程序在同一环境或集群中。（k8s RBAC受权：Kubernetes 从 1.6 开始反对基于角色的访问控制机制（Role-Based Access，RBAC），集群管理员能够对用户或 service account 的角色进行更准确的资源访问控制。在 RBAC 中，权限与角色相关联，用户通过成为适当角色的成员而失去这些角色的权限。）

基于 push 的部署

基于 Push 的部署策略能够利用风行的 CI/CD 工具来实现，例如 Jenkins、CircleCI 或 Travis CI。应用程序的源代码与部署的应用程序所需的 Kubernetes YAML 一起存在于利用程序库中。每当更新利用程序代码时，都会触发构建pipeline，构建容器镜像，最初应用新的部署manifest，更新环境配置库。

也能够将 YAML 的模板存储在利用程序库中。构建新版本时，能够应用模板在环境配置库中生成 YAML。

对环境配置库的更改会触发部署pipeline。pipeline负责将环境配置库中的所有manifests利用到基础设施。这就须要咱们更关注部署权限细分及管制。同时，这种形式无奈主动留神到环境及其所需状态的任何偏差。咱们须要额定的监控报警形式，来保障环境与环境存储库中形容的内容统一。

简单应用环境

对于大多数应用程序来说，只应用一个利用程序库和一个环境配置库是不事实的。GitOps 也能应答。能够设置多个构建 pipeline 来更新环境配置库。而后就像上两个形容过程一样，自动化 GitOps 工作流程开始并部署应用程序。

咱们须要在环境配置库中应用独立的分支，来治理多个环境。抉择设置 operator 或者构建pipeline，自动化 GitOps 工作流程开始并部署应用程序。

Tips：

1.不应用k8s的环境也能够思考应用 GitOps。（目前大多数基于 pull 的 GitOps 都是在Kubernetes 下实现的。）

2.明码。永远不要在 git 中以纯文本模式存储明码！在 K8s 生态系统中，有工具反对这种加密。(比方 Vault)

3.dev、qa、prod环境不能间接能用 GitOps 来解决，能够思考引入 CI/CD pipeline 来治理环境。

4.DevOps 与GitOps 不抵触。DevOps 是对于组织中的文化改革，能够使程序员及零碎维护者们更好地单干。而GitOps 是一种实现继续交付的技术。如果曾经在推动 DevOps 那么可能会更好接入 GitOps。

欢送订阅我的文章公众号【MoeLove】