10.2 GitOps 的实施要素和流程
实施 GitOps 由以下三个要素:
- 一切皆代码:GitOps 的设计理念是将一切(基础设施、应用程序、服务状态等)代码化,然后使用 Git 对代码版本控制,有任何变更则通过 Git Push/Pull 处理。所以,GitOps 也被称为 IaC(Infrastructure as Code,基础设施即代码)+ Git + CI/CD。
- Git 为单一可信源:所有的变更都要从 Git 仓库侧发起,这样方便代码的安全和审计。
- 声明式系统为基座:以声明式系统(包括基础设施和应用程序)为基座(典型如 Kubernetes)。
GitOps 三要素下的 CI/CD 流程可以概括为图 10-3。
- 首先,团队成员 fork 仓库进行业务逻辑开发,然后提交 Pull Request。
- 接下来运行 CI 流水线,例如校验配置文件、执行自动化测试、构建镜像、推送到镜像仓库等。
- CI 流水线执行完成后,拥有合并代码权限的人将 Pull Request 合并到主分支。
- 合并的事件触发 CD 流水线,结合 CD 系统(例如 Argo CD)将变更自动应用到目标集群中。
图 10-3 GitOps 下的 CI/CD 流程
基于 Git 仓库作为集群状态的唯一真实来源,再加上 Argo CD 这种自动同步的系统,那么就能:
- 回滚更快速:Argo CD 会定期拉取最新配置并应用到集群中,一旦新提交的配置导致应用出现故障,可通过 Git 历史将应用状态快速恢复到上一个可用状态。
- 集群灾备更简单:假如某个可用区的 Kubernetes 集群出现故障,且短期内不可恢复。这个时候可以直接创建一个新集群,然后将 Argo CD 关联到 Git 仓库,新的集群将自动同步仓库内所有应用的配置声明,期间完全不需要人工干预。
- 合规及安全:基于 Git 实现访问控制,开发人员 Pull Request,管理人员 Merge Request,没有额外的权限系统。且 Argo CD 已经部署在 Kubernetes 集群中,必须的访问权限已经配置妥当。除了集群管理员和少数人员外,其他人不再直接访问 Kubernetes 集群,这样就不再提供额外的证书、权限等,从而为 Kubernetes 集群提供更安全的保证。
总字数:610字