10.2 进一步理解 GitOps

进一步解释 GitOps 实施理念:

  • 一切皆代码:因为 GitOps 要将一切(不仅包含应用程序,也涵盖基础设施)代码化,然后用 Git 进行版本控制,应用程序或者基础设施的变更也都是通过 Git 进行。所以,有时候 GitOps 被解释为 IaC(Infrastructure as Code,基础设施即代码) + Git+ CI/CD。
  • Git 为单一可信源:所有的变更都要从 Git 仓库侧发起(例如 GitLab、GitHub),使用版本化控制,方便代码的安全和审计。
  • 声明式系统为基座:以声明式系统(包括基础设施和应用程序)为基座(典型如 Kubernetes)。

通过图 10-3 感受 GitOps 下的 CI/CD 实践过程。

  1. 首先,团队成员 fork 仓库进行业务逻辑开发,然后提交 Pull Request。
  2. 接下来运行 CI 流水线,例如校验配置文件、执行自动化测试、构建镜像、推送到镜像仓库等。
  3. CI 流水线执行完成后,拥有合并代码权限的人将 Pull Request 合并到主分支。
  4. 合并的动作触发 CD 流水线,结合 CD 工具(譬如 Argo CD)将变更自动应用到目标集群中。


图 10-3 GitOps 实践流程

基于 Git 仓库编排文件作为集群状态的唯一真实来源,再加上类似 Argo CD 这种自动同步的系统,那么就能:

  • 回滚更快速:Argo CD 会定期拉取最新配置并应用到集群中,一旦新提交的配置导致应用出现故障,则可以用过 Git 历史将应用状态快速恢复到上一个可用状态。
  • 集群灾备更简单:譬如某个可用区的 Kubernetes 集群出现故障,且短期内不可恢复,这个时候可以直接创建一个新集群,然后将 Argo CD 连接到 Git 仓库,新的集群将自动同步仓库内所有应用的配置声明,期间完全不需要人工干预。
  • 合规及安全:使用 Git 实现访问控制(开发人员 Pull Request、管理人员 Merge Request),除了集群管理员和少数人员外,其他人不再直接访问 Kubernetes 集群。而且 Argo CD 已经部署在 Kubernetes 集群中,必须的访问权限已经配置妥当,这样就不要给集群外配置额外的证书、权限等,从而给 Kubernetes 集群提供更为安全的保证。
总字数:631
Last Updated:
Contributors: isno