前言

对于DevOps是不是大家均已经很熟悉，每论你的公司大与小也许你都已经存在了一个devops平台或是工具链，用来辅助环境配置、应用发布、监控等方面。

也许你可能遇到会这样的情形，jenkins或内部发布系统挂了，应用无法更新发布？怎么办？只能等着系统修复或是人肉来搞。。。

但是如果我们的代码、配置均存储至Git, 让 Git 成为我们唯一可以信赖的源，是不是可以缓存些上面的尴尬呢，比如发布系统挂了，但所有的配置均在 Git里，我们直接可以通过 kubectl (针对k8s集群内的应用)等命令将应用部署成功。

What is GitOps

我们上说所提到的，代码及配置均保存至 Git, 而且通过 git push或是git pull来触发相应的 action.

GitOps一种针对云原生应用持续部署的方式, 它通过使用开发人员已经熟悉的工具(包括Git和持续部署工具),并且在运营基础设施时注重以开发人员为中心的体验。

GitOps的核心思想是拥有一个Git仓库，它总是包含生产环境中当前所需的基础架构的声明性描述，并有一个自动化流程使生产环境与仓库中的描述状态相匹配。如果你想部署一个新的应用程序或更新一个现有的应用程序，你只需要更新仓库,而其他的均由自动化流程处理。

Why need GitOps

不想把GitOps的优点说的很魔幻，我感觉主要是两点

1. Deploy Faster More Often 更快、更频率地部署，

的确，因为你需求提交代码，不需求再打开 jenkins 或是其他的构建/部署系统，但是如果你的部署流程中包含审批之类的流程，并不能真正地改善（因为虽然你可以快速触发，但是你还需要等待审批）。

2. Easy and Fast Error Recovery 更容易、更快的回滚

因为代码、配置均在仓库中，你可以很轻松地使用git revert来回滚操作。

3. 其他优点（觉得并不能作为优点）

  • Easier Credential Management,
  • Self-documenting Deployments
  • Shared Knowledge in Teams 注: 上面的这三个点对于你们目前没有一个较好的构建/发布流程的话，会是一个优点，但是如果你们已经有一个较好的构建部署平台，那么这几点则就显得没有什么意义。

How does GitOps work

环境部署作为Git仓库

GitOps将代码库作为中心元素来组织部署过程, 至少包含两个仓库：一个应用的仓库（应用的源代码，应用的 deployment manifests）和一个环境的配置仓库（当前部署环境所期望基础设施所有的 deployment manifests）。

Push-based Deployments

image

注意: You can also just store templates of the YAMLs in the application repository. When a new version is built, the template can be used to generate the YAML in the environment configuration repository.

Pull-based Deployments

image

Woarking with Multiple Applications and Environments

The Pull-based deployment strategy uses the same concepts as the push-based variant but differs in how the deployment pipeline works. Traditional CI/CD pipelines are triggered by an external event, for example when new code is pushed to an application repository. With the pull-based deployment approach, the operator is introduced. It takes over the role of the pipeline by continuously comparing the desired state in the environment repository with the actual state in the deployed infrastructure. Whenever differences are noticed, the operator updates the infrastructure to match the environment repository. Additionally the image registry can be monitored to find new versions of images to deploy.

image

注意: Managing multiple environments with GitOps can be done by just using separate branches in the environment repository. You can set up the operator or the deployment pipeline to react to changes on one branch by deploying to the production environment and another to deploy to staging.

最佳实践

image

不同的角色有不同的职责

This way of segregating the concerns is heavily influenced by the Open Application Model, which attempts to provide a framework for cloud-native application development.

Open Application Model OAM describes a model where

  • Developers are responsible for defining application components.
  • Application operators are responsible for creating instances of those components and assigning them application configurations.
  • Infrastructure operators are responsible for declaring, installing, and maintaining the underlying services that are available on the platform. By applying the OAM framework, the below table attempts to segregate the YAML contribution responsibilities. This is may change based on how your organization is structured and the type of Kubernetes cluster you choose.

image

结论

GitOps很符合现在 IaC 的思想，但是请一定要根据你们当前的基础设施决定是否启用 GitOps；

  1. 如果当前你们的团队比较少，且没有特定的运维角色人员，且你们使用的云服务商的k8s，使用 GitOps是一个不错的体验。
  2. 如果当前你们的团队有特定的角色分工，且一次发布/部署过程链路需要开发者、应用操作者、集群操作者配合的话，除非你们当前已经可以很好的支持Fully Declarative Continuous Deployment Pipeline, 否则直接启用 GitOps 也不会是一个令你满意的体验。
    • 比如，开发者变更了环境仓库的配置，会触发同步，但此应用需要运维人员/集群操作者提交其他配置的更改才可以正常启动，显然开发者这次变更将会是一次失败的部署。
  3. 如果当前团队有较稳定的构建/部署流程，可以先将 GitOps 的思想带入（一切的操作可审计、追溯），将应用、环境的配置仓库均基于代码仓库，但是实际的触发部署流程，慎重评估后再决定是否引入。
  4. 当前团队内未完整启用 GitOps, 如有说的不对，欢迎交流~

推荐阅读

  1. A Year With Gitops in Production
  2. What you need to know Guide to GitOps
  3. 5 Gitops Best Pratices
  4. GitOps: How to Ops Your Git the Right Way

参考

  1. Weaveworks GitOps
  2. Continuous GitOps, the way to do DevOps in kubernets