Gitops 的一些实践经验

之前看过多很多讲 Gitops 概念的文章，今天终于看到一篇讲实践的（原文见 这里 ），我觉得这篇文章很有参考价值，介绍了一些 gitops 实在会遇到的问题和工具，和大家分享一下。

1.只用一个 git 仓库

建议所有跟基础设施有关的内容都放到一个仓库，包括有的团队、所有的项目。比如 kubernetes 的 template， infra as code 的平台，比如 terraform，比如 ansible playbooks，监控设施比如 grafana dashboards, alerts, 等等。

这样有哪些好处呢？

1. single source of truth。线上的真实环境，实际在生效的配置，都可以在这一个仓库找到，就避免了去各个平台看现在生效的是什么配置的问题；
2. 可以将在 CI 中设置 lint、准入检查等。虽然如果分多个仓库，也可以分别设置 CI，但是那样毕竟容易乱。用 CI 我们可以自动的检查某些变更是否符合标准，一开始可能是全部要人工检查(去 Review Merge Request)，但是逐渐自动化起来难度也不大；
3. 灾难恢复更简单。都放在一个仓库里面，可操作性就很强了，不然你要处理多个仓库的先后顺序问题，相互依赖的问题等等。
4. 加强了管控能力和审计。这个很好理解，毕竟只有一个仓库嘛。但是 git log 一定要写好，审计才方便。

作者推荐了一个目录结构：

/ terraform -> This will be scanned by your terraform operator (Atlantis)
— / modules -> can be extracted globally if required in multiple teams
— / workspace -> the actual folder where terraform is applied from
/ k8s -> this will be scanned by your kubernetes deploy operator (Flux)
 — / prod -> your production k8s templates
 — / int -> your integration k8s templates
/ templates -> this could contain your customize overlays (triggered at each push to generate stuff in the k8s folder)
/ docs
/ runbooks
/ monitoring
 — / alerts
 — / dashboards
…

思考：

只用一个仓库所带来的透明性，收益是很高的，审批可能都是 merge requests 了。我们也不必各种问”最近有什么变更”了，每个人都可以去看 git log。如果操作都能设计成声明式的，那么回滚也很方便，revert log 就可以了。

恢复整站，或者再搭建一套环境速度也大大提高，waveworks 经历过所有机器都被抹掉的情况，得益于 gitops， 集群的重新 provision 只用了 45min .

2.自动化

Automation is key because it speeds you up immense.

作者在这里举了一个例子，如果用 Prometheus 的话，可以将 HTTP 服务的大盘监控抽象成一种通用的模板，新加一种 HTTP 服务的话大盘可以自动生成。(监控规则同理)

思考：

在Web平台上点点点，是比较难自动化和复用的，但是如果是 Code 就不一样了。你可以用你最喜欢的Vim编辑器快速处理大量的配置文本，也可以用脚本批处理，可定制化很高。但是这依赖于 Infra as Code,监控代码化，configuration-as-code、database-as-code、infrastructure-as-code 等。

配监控太痛苦了！我觉得比较理想的监控是：中间件层收集一些通用的 metric，开发同学在代码中(用注释或者继承类的方式？)暴露关键的业务指标，大盘可以根据template自动生成。(要是真这样就好了)

3.能用Operators就用Operators

简而言之，可以减轻手动 Apply 的负担。(既然都 gitops 了，鼠标能少点几次就少点几次吧。)

举几个例子：

• Atlantis: 基于 PR 的 Terraform 流程，看 这里一张图 就明白了。
• flux: waveworks的作品，确保 git 仓库的配置和 k8s 集群中的状态一致。(消除 diff 应用变更，readme 里面也有 一张图 展示的很明白)

思考：

XX as code, 声明式，diff merge 应该是 gitops 的核心吧？

4.Secrets 能够被自动获取

Secrets are still just parts of the deployment, that is why they are required for full disaster recovery for example.

推荐将 Secrets 存在仓库中(当然了，加密存储)，或者在部署后能以某种形式自动地获取。这里的关键和难点是保持 Secrets 以加密的形式存储，严禁明文存入 repo。

Problem: “I can manage all my K8s config in git, except Secrets.”
Solution: Encrypt your Secret into a SealedSecret, which is safe to store – even to a public repository. The SealedSecret can be decrypted only by the controller running in the target cluster and nobody else (not even the original author) is able to obtain the original Secret from the SealedSecret.
— sealed-secrets

推荐的几种形式有：

• 用类似 sealed-secrests 的 Operator，已加密形式将 Secrets 存到仓库，Secrets 到达集群的时候进行解密。(同类产品还有 Mozilla 的 SOPS)
• 使用 Hashicorp Vault 类似的集中式 Secrets 管理工具
• 云服务商提供的同类产品
• 使用 git-crypt 或 git-secret 进行手动加密

以上，水平有限，如果有疑问可以看下原文确认，如有理解错误欢迎指出。如果原文有错误欢迎讨论。