GitOps实践：配置即代码的运维新范式

从 ClickOps 到 GitOps

传统运维中，配置变更往往通过 Web 控制台或 SSH 手动操作完成，这种方式被称为"ClickOps"。它有几个致命缺陷：操作不可追溯、变更无法回滚、环境配置漂移（Drift）难以发现。

GitOps 的核心原则：Git 是系统期望状态（Desired State）的唯一真实来源（Single Source of Truth）。任何对基础设施的变更，都必须通过 Git 提交完成。

GitOps 工作流模型

Push 模型（CI 驱动）

CI 流水线在构建完成后，直接将新版本推送到目标环境：

# GitHub Actions 示例
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to K8s
        run: |
          kubectl apply -f k8s/deployment.yaml
          kubectl set image deployment/app app=${{ steps.build.outputs.image }}

优点：简单直接。缺点：CI 系统需要集群访问凭证，安全风险高。

Pull 模型（Agent 驱动）

集群内部署 Agent（如 Argo CD），持续拉取 Git 仓库并与集群实际状态对比，自动同步差异：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  project: default
  source:
    repoURL: https://github.com/team/infra
    path: apps/my-app
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Pull 模型是 GitOps 的推荐实践：集群凭证不出 CI，自动修复配置漂移。

工具生态选型

落地四步法

1. 基础设施代码化：将所有 K8s YAML、Helm Chart、Terraform 配置纳入 Git 管理。
2. 部署 Argo CD / Flux：在集群中安装 GitOps Agent，配置仓库连接。
3. 建立 PR 评审流程：所有变更通过 Pull Request 提交，经同行评审后合入。
4. 启用自动同步：配置 selfHeal，自动修复手动修改导致的配置漂移。

总结

GitOps 不仅仅是工具升级，更是运维文化的变革——从"我能做什么"到"Git 里写了什么"。对于正在建设 DevOps 体系的团队，GitOps 是迈向可观测、可审计、可回滚运维的最佳路径。