如何优雅的使用 GitOps 实现运维自动化

如何优雅的使用 GitOps 实现运维自动化

什么是 GitOps 呢？

1. GitOps 到底是个什么呢

GitOps = 基础设施即代码(IaC) + 合并请求(MR) + 持续集成/持续交付(CI/CD)

GitOps 是一种运维框架，它采用了 DevOps 在应用程序开发阶段的最佳实践(例如版本控制、协作、合规性和CI/CD工具)，并将其应用于基础设施自动化。

与 GitOps 相比，传统的 DevOps 尽管在软件开发生命周期已实现自动化，但基础架构大体上仍然是一个需要专业团队进行手动操作的过程。随着对基础架构需求的不断增长，实现基础设施自动化变得越来越重要。现代化的基础设施需要弹性机制(速度和规模)，以便能有效地管理持续部署所需的云资源。

GitOps体系学习和理解

GitOps 用于对基础设施置备的过程进行自动化，采用以 配置文件 存储为代码(基础设施即代码)，配置文件在每次部署时都会生成相同的基础设施环境，来保证环境的一致性，完成整个运维流程的自动化。

三叉戟 - 基础设施即代码(IaC) - Terraform  GitOps 使用 Git 仓库作为基础设施定义的单一可信来源，将所有基础设施以配置文件的方式存储起来，达到配置和管理应用服务的问题。 三叉戟 - 合并请求(MR)  GitOps 使用合并请求作为所有基础设施更新的变更机制，合并请求是团队通过评审和评论进行协作的地方，合并会被提交到您的主干分支并可作为审计日志。 三叉戟 - 持续集成/持续交付(CI/CD)   GitOps 使用具有持续集成和持续交付的 Git 工作流来自动化执行基础架构的更新，在新代码合并后，CI/CD 流水线将执行环境中的更改，从而避免手动配置的错误等问题。

对于任何需要协作的工作，改变都是很棘手的，GitOps 也不例外。GitOps 需要所有参与者遵守纪律，它是一种采用全新的方式来工作的承诺。对于团队来说，把所有的事情都记录下来至关重要。

2. GitOps 的核心在于协助

可以覆盖应用程序从构思到代码再到部署全流程的协作

从核心上来说，GitOps 指的是将 Git 存储库作为构建基础设施和部署应用程序所有代码的唯一可信数据源，然后将代码自动化部署到不同的云环境上面(可以借助Terraform完成资源编排)。

每个人都能够在同一个系统中工作，并了解事情的进展情况。无论你是在基础架构中还是在应用程序开发中，所有的更改都遵循同样的流程，即定义工作主体，将其分配给个人，团队协作，然后部署这些代码，并将 Git 存储库作为唯一可信数据源使用。

GitOps 与代码和协作都有紧密联系

使用版本控制系统可以确保一切都被记录且可见，审计跟踪使团队保持合规性。 针对于不同的项目和团队，新建 issue 来描述添加的目标和任务(多云平台)。 在 issue 中，记录列出的任务列表的执行程度和进展(通过ME合并请求)。

GitOps体系学习和理解

3. GitOps 的使用优秀实践

良好的运维体系拥有一个无缝链接且完美的体验，能够增进基础设施、运营和开发团队之间的协作，在提高软件环境的稳定性、可靠性和安全性的同时，实现更快速部署，这能够增强团队的信心。比如：

GitOps体系学习和理解

4. GitOps 的大致运行流程

伴随着 DevOps 在近些年的火爆，围绕 xOps 产生了很多概念，诸如 DevSecOps，AIOps，MLOps，ChatOps 等等，当然还有的主角 GitOps。而GitOps 这个词出现于 2017 年，是由 Weaveworks 公司根据多年云计算基础设施和应用程序管理经验而提出的一个概念。

GitOps体系学习和理解 - 乱七八糟的xOps造词运动

一般情况下，可以使用下面的持续交付系统(示意图)，来完成云原生应用程序的部署与交付。这种 从左到右走到底 的 Push 模式，虽然很容易实现一键式部署，但也存在一些问题。

GitOps体系学习和理解 - 完成云原生应用程序的部署与交付

[1] 很难保证   仓库里清单文件的内容是否和 k8s 集群的实际情况是否一致 [2] 不够灵活   镜像有更新时不能够自动同步至集群，除非每次从头到尾走一遍部署流程 [3] 安全合规   有可能需要操作人员通过 kubectl 命令做一些集群操作

这就需要使用的 Git 工具支持与 k8s 打交道的能力。 可以将 Git 工具与 Terraform 集成，来完成云基础设施的自动化管理。

# ------- 0.0 -------  # GitOps的仓库代码结构  # -------------------  # 多云环境  ➜ tree -a GitOps  GitOps  └── gitops      ├── .gitlab-ci.yaml             # CI/CD      └── environments          ├── aliyun          │   ├── kubeconfig.yaml     # k8s集群配置          │   ├── main.tf             # 基础设置配置          │   └── yaml          │       └── app.yaml        # 集群服务配置          └── k3s              └── yaml                  ├── app.yaml        # 集群服务配置                  └── kubeconfig.yaml # k8s集群配置

以 Git 为单一可信源，所有与软件开发相关流程中的代码(包括基础设施代码、应用程序源码、配置等)都会存储在 Git 仓库中。所有管理过程都是通过合并请求(MR)来完成的，当需要对基础设施作某些变更时，只需要修改代码，并提交 MR，在所有的修改都被审查和批准后，代码可以被合并到主分支上。一旦代码变化被合并，所有的变化将被部署到生产中。

GitOps 的优点  快速进行变更 - 更新和回滚 人员工作体验的提升 - 部署流程完美 安全性提高 - 仓库进行权限分配 合规审计容易做 - 所见即所得 GitOps 的缺点  协作文化的建立 - 逐步培养  Git Workflow的建立 - 混合云保证服务可用  敏感信息的处理 - 敏感信息(与Vault结合解决) - GitSecOps

5. GitOps 集成 ArgoCD 实践

ArgoCD 只是一个持续交付工具，但其实核心功能点！

ArgoCD 是一款开源且主要针对 Kubernetes 来做 GitOps 的持续交付工具。现在是 CNCF 的孵化项目。其整体架构图如下：

GitOps体系学习和理解 - 集成ArgoCD实践

ArgoCD 是以 Kubernetes Controller 的形式来实现的，它会对运行在 Kubernetes 集群上的应用程序进行监听，并将实际运行状态和期望状态（在部署清单文件中指定，且存储在版本控制系统中）进行对比，当两者状态不一致的时候，则提示 OutOfSync，此时可以通过自动或者手动的方式来完成同步操作，以让两者状态再次保持一致。存储在 Git 仓库中的任何变更都会被自动同步至集群侧。

这其实就是实现 GitOps 的核心原理。所有对于应用程序或者基础设施的变更仅仅需对 Git 仓库做一些 MR 或者 Push 操作即可实现，变更会自动部署。所以，虽然 GitOps 的核心不是 Git，但是却与 Git 息息相关。

Git 将作为存储部署清单文件的版本控制系统，与 ArgoCD 做集成，实现 GitOps workflow。整体示意图如下所示：

一个 Git 实例 一个 ArgoCD 运行实例

GitOps体系学习和理解 - 集成ArgoCD实践

[1] 安装和启动 ArgoCD 服务

[2] 介绍 sops 的使用

[3] 配置 ArgoCD 的服务

GitOps体系学习和理解 - 配置ArgoCD的服务

[4] 使用 ArgoCD 的服务

# 在ArgoCD的Project下面添加application来让GitOps飞起来  # 至此ArgoCD配置完成，且此ArgoCD实例已经在监听配置的Git的仓库  # 如果该仓库的配置文件发生了变化，则变化会被自动同步至Kubernetes集群侧  # 查看运行的应用程序  $ kubectl -n gitops-argocd get pods  NAME                      READY   STATUS    RESTARTS   AGE  deploy-766c4cbbfc-m8dz6   1/1     Running   0          53m  # 查看此应用程序的输出 - 映射端口出来  $ kubectl -n gitops-argocd port-forward pods/deploy-766c4cbbfc-m8dz6 9999:9999  $ curl localhost:9999/jihu  Hello JiHu GitLab,this is xiaomage,version is v6.1.0