大家好，我是张晋涛。
接下来会为大家带来一个 GitOps 的应用实践系列文章，这是第一篇。
什么是 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/technologies/gitops/
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 ，以查找要部署的新镜像版本。
img
基于 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。
img
对环境配置库的更改会触发部署pipeline。pipeline负责将环境配置库中的所有manifests应用到基础设施。这就需要我们更关注部署权限细分及控制。同时，这种方式无法自动注意到环境及其所需状态的任何偏差。我们需要额外的监控报警方式，来保障环境与环境存储库中描述的内容一致。
复杂应用环境
对于大多数应用程序来说，只使用一个应用程序库和一个环境配置库是不现实的。GitOps 也能应对。可以设置多个构建 pipeline 来更新环境配置库。然后就像上两个描述过程一样，自动化 GitOps 工作流程开始并部署应用程序。
img
我们需要在环境配置库中使用独立的分支，来管理多个环境。选择设置 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。
