您或许已经听说过 DevOps （开发与运维），它用于自动化应用的部署流程。如果您是数据领域的专业人士，您很可能也熟悉 MLOps （机器学习运维），它用于简化模型部署。那么 GitOps 又是什么呢？
在这篇博客中，我们将探讨 GitOps、它为何重要、不同的 GitOps 模式，以及最后如何将 GitOps 集成到大型语言模型项目中。
图片由作者提供
您也可以通过我们的两门优质短课学习 DevOps 和 MLOps 背后的理论： DevOps Concepts 和 MLOps Concepts 。
什么是 GitOps？
GitOps 是一种将 DevOps 原则扩展到基础设施自动化的运营框架。它强调 DevOps 的关键经验，如版本控制、协作、合规性、 CI/CD 和可观测性，并将其应用于基础设施的配置与管理，尤其是在现代云环境中。
GitOps 的核心是将配置视为代码（通常称为基础设施即代码，IaC），从而实现基础设施管理自动化。正如开发团队使用源代码一致地构建应用二进制文件，运维团队也使用存储在 Git 仓库中的配置文件，确保每次部署的基础设施环境保持一致。这种方法保证了一致性、可靠性和可重复性。
GitOps 工作流的关键组成部分：
Git 仓库 ：同时存储应用源代码和基础设施配置文件。 持续交付（CD）流水线： 自动化构建、测试和部署应用与基础设施变更。 应用部署工具： 基于 Git 仓库中的配置，确保应用被正确、高效地部署。 监控系统： 跟踪应用性能与健康状况，保障系统可靠性。
GitOps vs DevOps vs MLOps
Aspect DevOps GitOps MLOps Definition A set of practices that combines software development (Dev) and IT operations (Ops) to shorten the development lifecycle. An operational framework that applies DevOps principles to infrastructure management using Git as the source of truth. A set of practices that apply DevOps principles to machine learning (ML) model development and deployment. Primary Focus Automating and improving software development, testing, and deployment. Automating infrastructure and application deployment through Git-based workflows. Automating ML model development, deployment, and lifecycle management. Key Principles Collaboration, Continuous Integration/Continuous Deployment (CI/CD), Infrastructure as Code (IaC). Infrastructure as Code (IaC), Declarative Configurations, Continuous Reconciliation, Version Control. Model Versioning, Model Monitoring, Reproducibility, Continuous Training & Deployment. Tools & Technologies Jenkins, GitHub Actions, Terraform, Ansible, Docker, Kubernetes. Argo CD, Flux, Kubernetes, Helm, Terraform, GitHub Actions. MLflow, Kubeflow, TensorFlow Extended (TFX), SageMaker, Airflow. Use Cases Software development, application deployment, cloud-native applications. Managing cloud infrastructure, Kubernetes deployments, automating configuration updates. ML model training, deployment, monitoring, and retraining pipelines. Automation Scope Automates application builds, testing, and deployment to production. Automates infrastructure provisioning, configuration management, and application deployment. Automates ML model training, validation, deployment, and monitoring. Version Control Version-controlled codebase for software development and application configurations. Git is the single source of truth for infrastructure state and configurations. Version control applies to ML models, datasets, and training pipelines. CI/CD Integration Core principle with automated testing, build, and deployment pipelines. Highly integrated with CI/CD pipelines to automate infrastructure updates. Integrates with CI/CD but requires specialized ML pipelines for continuous training and validation. Infrastructure Management Supports infrastructure as code (IaC) but focuses more on application deployment. Manages infrastructure through version-controlled configurations. Supports ML infrastructure but also manages model experimentation and drift. Monitoring & Observability Observability through logging, monitoring, and tracing tools like Prometheus and Grafana. Continuous monitoring and self-healing via GitOps controllers like Argo CD. Focuses on model performance monitoring, data drift detection, and retraining triggers. Challenges Cultural shift, requires collaboration between dev and ops teams, complexity in toolchain integration. Requires a shift to declarative infrastructure, complexity in scaling large environments. High infrastructure complexity, data management challenges, integration with DevOps pipelines.
为何使用 GitOps？
传统的基础设施管理多为手工操作，但现代云环境要求通过自动化来应对云原生应用的速度与规模。借助 GitOps，基础设施变得弹性且可靠，使团队能够快速且一致地部署变更。它消除手工错误、提升效率，并确保基础设施与应用始终保持同步，满足现代开发工作流的高速需求。
GitOps 的主要优势：
版本控制： 对基础设施与应用的所有变更在 Git 中进行版本控制，便于回滚并提供完整的审计追踪。 更好的协作： 团队可利用熟悉的 Git 工作流（如 Pull Request）更高效地协作。 更高的可靠性： 声明式配置确保在发生故障时可自动恢复到期望的系统状态。 自动化： 将手工干预降至最低，从而降低人为错误风险。 安全性： Git 的提交历史提供不可变记录，增强安全性与可追溯性。
基于拉取与基于推送的 GitOps 模型
在 GitOps 方法中，部署和管理基础设施与应用配置主要有两种模型： 基于拉取（pull-based） 与 基于推送（push-based） 。二者在处理配置变更并将其应用到目标环境的方式上有所不同。
基于拉取的模型（典型 GitOps）
基于拉取的方法依赖将系统的期望状态存储在 Git 仓库中。GitOps 运维器（如 Flux 或 Argo CD）会持续监控该仓库的变更。一旦检测到更新，运维器会自动拉取更新后的配置并将其应用到目标环境。
基于拉取的模型还提供漂移检测与自愈能力，因为集群会持续从 Git “拉取”期望状态。这确保了对环境中任何非预期变更或配置漂移的自动纠正，从而保持一致性与稳定性。
基于推送的模型（使用 CI/CD 工具）
基于推送的方法依赖 GitHub Actions 或其他 CI/CD 服务，在提交变更时将更新推送到集群。与基于拉取的模型不同，基于推送的方法缺乏持续对账，也就是说没有内置的漂移检测或自动回滚，对环境中的非预期变更抗扰度较弱。不过，基于推送的模型通常更易实施，并能对部署提供更细粒度的控制。
将 GitOps 集成到 LLM 项目中
我们将聚焦于使用 GitHub Actions 的基于推送 GitOps 方法，因为它更易上手且对先验知识要求较低。尽管基于推送的系统可能无法提供所有基于拉取方法的优势，但它仍具备 GitOps 的关键特性，如版本化配置、自动化部署与简化的回滚。
本节将把 GitOps 原则应用于教程 How to Deploy LLM Applications Using Docker: A Step-by-Step Guide 中的项目。该项目包含一个 Gradio 应用的代码、Dockerfile 和 requirements.txt，展示了如何使用 Docker 将 AI 应用部署到云端。
来源：How to Deploy LLM Applications Using Docker: A Step-by-Step Guide
通过参加课程 Developing Machine Learning Models for Production with an MLOps Mindset ，以 MLOps 思维有效地训练、记录、维护并扩展您的机器学习模型。
项目结构
该 GitOps 项目旨在使用 Docker、Kubernetes 和 GitHub Actions 部署大型语言模型（LLM）应用。项目将所有 LLM 项目文件组织在 app 文件夹下，在 infra 文件夹中创建 Kubernetes 配置，并使用 .github/workflows/ 配合 GitHub Actions 实现 CI/CD 自动化。
Docker 将应用及其所有依赖进行打包，确保跨环境一致运行。 Kubernetes 自动化应用的部署、扩缩与管理。 GitHub Actions 自动化测试、构建与部署。
参加 Introduction to Kubernetes 课程，学习 Kubernetes 基础知识，并通过 Manifests 与 kubectl 指令来部署和编排容器。
这种结构确保了遵循现代 GitOps 原则的自动化、可扩展且面向特定环境的 LLM 应用部署。
Deploying-LLM-Applications-with-Docker/
├── app/
│ ├── requirements.txt <-- Python dependencies for your LLM app
│ ├── main.py <-- Your LLM application code
│ └── Dockerfile <-- Docker instructions for building the app
├── infra/
│ ├── dev/ <-- Dev environment configs (YAML or Helm)
│ ├── staging/ <-- Staging environment configs
│ └── production/ <-- Production environment configs
└── .github/
└── workflows/
├── ci.yaml <-- GitHub Actions workflow for continuous integration
└── cd.yaml <-- GitHub Actions workflow for continuous deployment技术支持 下面是简要说明：
app/ ：包含应用代码（main.py）、依赖（requirements.txt）以及用于将应用构建为容器的 Dockerfile。 infra/ ：存放针对不同环境的 Kubernetes 配置：
dev/、staging/ 与 production/ 文件夹分别用于环境特定设置。
.github/workflows/ ：使用 GitHub Actions 自动化 CI/CD：
ci.yaml：构建应用与 Docker 镜像。 cd.yaml：通过推送 Docker 镜像并应用 Kubernetes 配置来部署应用。
阅读 Kubernetes vs Docker 教程，了解二者的区别。
GitHub Actions 工作流概览
GitHub Actions 工作流中的流程如下：
Developer commits code + config to GitHub
|
v
GitHub Actions CI (ci.yaml)
- Builds Docker image
- (Optional) pushes Docker image
|
v
GitHub Actions CD (cd.yaml)
- Deploys updated app/config
- kubectl apply or helm upgrade
|
v
Kubernetes Cluster Updated技术支持
开发者提交变更： 将代码与配置更新推送到 GitHub。 CI 流水线（ci.yaml）：
构建 Docker 镜像。 可选地将镜像推送至容器镜像仓库。 运行测试以验证应用。
CD 流水线（cd.yaml）：
部署更新后的应用或配置。 执行 kubectl apply 或 helm upgrade 更新 Kubernetes 清单。
Kubernetes 集群更新完成： 集群运行应用的新版本。
通过阅读教程 A Beginner's Guide to CI/CD for Machine Learning ，学习如何使用 GitHub Actions 自动化模型训练、评估、版本管理与部署，并创建相关文件。
采用基于推送 GitOps 方法的关键优势与权衡
如果您有 GitHub Actions 的使用经验，那么采用基于推送的方法来搭建 GitOps 方法论会相对直观。您只需添加基础设施配置文件、设置 CI/CD 流水线即可开始。不过，尽管这种方法简单易行，但也需要考虑若干重要的权衡点。
优势
简单： 只需使用 GitHub Actions 即可实现，无需额外的 GitOps 运维器（如 Argo CD 或 Flux）。 一站式： GitHub Actions 提供构建、测试、部署于一体的平台，简化全流程。
权衡
并非真正的基于拉取： 与 Argo CD 等拉取式 GitOps 工具不同，此方法缺少“持续对账”。也就是说，集群状态不会被自动监控并与 Git 中的期望状态对齐。 无漂移检测： 若有人在集群中手动修改资源，这些改动不会被自动回退以匹配 Git 仓库，时间一长可能导致配置漂移。 安全性： 为使 GitHub Actions 能部署到您的集群，您必须在 GitHub secrets 中存储集群凭据或使用基于 OIDC 的认证方式。这两种方式都需要谨慎处理以避免安全风险。
过渡到基于拉取的模型
随着项目扩大或需求提升，迁移到基于拉取的 GitOps 模型会带来显著优势。如果您的团队需要自愈、持续对账或可视化看板等功能，那么采用 Argo CD 或 Flux 等拉取式工具可能是下一个合乎逻辑的步骤。
自愈： 若发生漂移，自动恢复集群状态。 持续对账： 7×24 监控 Git 仓库中的配置变更。 可视化看板： 便于查看应用状态与日志。
您可以切换到 Argo CD 或 Flux 等拉取式工具。它们会持续监控您的仓库，确保集群始终与 Git 中的内容保持一致——在初次提交之后，无需手动“推送”步骤。
结论
若要高效实施 GitOps，最好从小处着手，逐步采用相关技术。先使用一个简单的 Dockerfile 将应用容器化并部署到云端；随后引入 Kubernetes，通过自动化部署与管理来实现可扩展性与可靠性。
在此基础上，使用 GitHub Actions 等工具采用基于推送的 GitOps 方法，自动化云基础设施与应用部署。最后，随着项目成熟并需要生产级稳定性，可迁移至 Argo CD 或 Flux 等基于拉取的模型，以实现持续对账、漂移检测与自愈能力。
这种循序渐进的路径能够确保平滑的学习曲线，同时充分发挥 GitOps 在现代云原生应用中的潜力。
在本文中，我们探讨了 GitOps、其重要性、各种 GitOps 模式，以及如何将 GitOps 集成到一个 AI 项目中。若您刚接触 AI，我们强烈建议学习 AI Fundamentals 技能路径，它涵盖 AI 基础，深入探讨如 GPT-4o 等模型，并揭示生成式 AI 的要点，帮助您把握不断演进的 AI 版图。
%22%3E%3Cpath%20d%3D%22m-369%200h408v79h-408z%22%20fill%3D%22%237933ff%22%2F%3E%3Cpath%20d%3D%22m-148%200h306v45h-306z%22%20fill%3D%22%23974dff%22%2F%3E%3C%2Fg%3E%3C%2Fsvg%3E)
%22%2F%3E%3C%2FclipPath%3E%3Cg%20clip-path%3D%22url(%23a)%22%3E%3Cpath%20d%3D%22m76%200h484v36h-484z%22%20fill%3D%22%23974dff%22%2F%3E%3Cpath%20d%3D%22m0%200h384v24h-384z%22%20fill%3D%22%2306bdfc%22%20transform%3D%22matrix(1%200%200%20-1%200%2060)%22%2F%3E%3C%2Fg%3E%3C%2Fsvg%3E)
您或许已经听说过DevOps（开发与运维），它用于自动化应用的部署流程。如果您是数据领域的专业人士，您很可能也熟悉MLOps（机器学习运维），它用于简化模型部署。那么GitOps又是什么呢？
在这篇博客中，我们将探讨 GitOps、它为何重要、不同的 GitOps 模式，以及最后如何将 GitOps 集成到大型语言模型项目中。
图片由作者提供
您也可以通过我们的两门优质短课学习 DevOps 和 MLOps 背后的理论：DevOps Concepts 和 MLOps Concepts。
什么是 GitOps？
GitOps 是一种将 DevOps 原则扩展到基础设施自动化的运营框架。它强调 DevOps 的关键经验，如版本控制、协作、合规性、CI/CD 和可观测性，并将其应用于基础设施的配置与管理，尤其是在现代云环境中。
GitOps 的核心是将配置视为代码（通常称为基础设施即代码，IaC），从而实现基础设施管理自动化。正如开发团队使用源代码一致地构建应用二进制文件，运维团队也使用存储在 Git 仓库中的配置文件，确保每次部署的基础设施环境保持一致。这种方法保证了一致性、可靠性和可重复性。
GitOps 工作流的关键组成部分：
GitOps vs DevOps vs MLOps
为何使用 GitOps？
传统的基础设施管理多为手工操作，但现代云环境要求通过自动化来应对云原生应用的速度与规模。借助 GitOps，基础设施变得弹性且可靠，使团队能够快速且一致地部署变更。它消除手工错误、提升效率，并确保基础设施与应用始终保持同步，满足现代开发工作流的高速需求。
GitOps 的主要优势：
基于拉取与基于推送的 GitOps 模型
在 GitOps 方法中，部署和管理基础设施与应用配置主要有两种模型：基于拉取（pull-based）与基于推送（push-based）。二者在处理配置变更并将其应用到目标环境的方式上有所不同。
基于拉取的模型（典型 GitOps）
基于拉取的方法依赖将系统的期望状态存储在 Git 仓库中。GitOps 运维器（如 Flux 或 Argo CD）会持续监控该仓库的变更。一旦检测到更新，运维器会自动拉取更新后的配置并将其应用到目标环境。
基于拉取的模型还提供漂移检测与自愈能力，因为集群会持续从 Git “拉取”期望状态。这确保了对环境中任何非预期变更或配置漂移的自动纠正，从而保持一致性与稳定性。
基于推送的模型（使用 CI/CD 工具）
基于推送的方法依赖 GitHub Actions 或其他 CI/CD 服务，在提交变更时将更新推送到集群。与基于拉取的模型不同，基于推送的方法缺乏持续对账，也就是说没有内置的漂移检测或自动回滚，对环境中的非预期变更抗扰度较弱。不过，基于推送的模型通常更易实施，并能对部署提供更细粒度的控制。
将 GitOps 集成到 LLM 项目中
我们将聚焦于使用GitHub Actions 的基于推送 GitOps 方法，因为它更易上手且对先验知识要求较低。尽管基于推送的系统可能无法提供所有基于拉取方法的优势，但它仍具备 GitOps 的关键特性，如版本化配置、自动化部署与简化的回滚。
本节将把 GitOps 原则应用于教程How to Deploy LLM Applications Using Docker: A Step-by-Step Guide 中的项目。该项目包含一个 Gradio 应用的代码、Dockerfile 和
requirements.txt，展示了如何使用 Docker 将 AI 应用部署到云端。来源：How to Deploy LLM Applications Using Docker: A Step-by-Step Guide
通过参加课程Developing Machine Learning Models for Production with an MLOps Mindset，以 MLOps 思维有效地训练、记录、维护并扩展您的机器学习模型。
项目结构
该 GitOps 项目旨在使用 Docker、Kubernetes 和 GitHub Actions 部署大型语言模型（LLM）应用。项目将所有 LLM 项目文件组织在
app文件夹下，在infra文件夹中创建 Kubernetes 配置，并使用.github/workflows/配合 GitHub Actions 实现 CI/CD 自动化。参加Introduction to Kubernetes 课程，学习 Kubernetes 基础知识，并通过 Manifests 与 kubectl 指令来部署和编排容器。
这种结构确保了遵循现代 GitOps 原则的自动化、可扩展且面向特定环境的 LLM 应用部署。
下面是简要说明：
阅读Kubernetes vs Docker 教程，了解二者的区别。
GitHub Actions 工作流概览
GitHub Actions 工作流中的流程如下：
kubectl apply或helm upgrade更新 Kubernetes 清单。通过阅读教程A Beginner's Guide to CI/CD for Machine Learning，学习如何使用 GitHub Actions 自动化模型训练、评估、版本管理与部署，并创建相关文件。
采用基于推送 GitOps 方法的关键优势与权衡
如果您有 GitHub Actions 的使用经验，那么采用基于推送的方法来搭建 GitOps 方法论会相对直观。您只需添加基础设施配置文件、设置 CI/CD 流水线即可开始。不过，尽管这种方法简单易行，但也需要考虑若干重要的权衡点。
优势
权衡
过渡到基于拉取的模型
随着项目扩大或需求提升，迁移到基于拉取的 GitOps 模型会带来显著优势。如果您的团队需要自愈、持续对账或可视化看板等功能，那么采用 Argo CD 或 Flux 等拉取式工具可能是下一个合乎逻辑的步骤。
您可以切换到 Argo CD 或 Flux 等拉取式工具。它们会持续监控您的仓库，确保集群始终与 Git 中的内容保持一致——在初次提交之后，无需手动“推送”步骤。
结论
若要高效实施 GitOps，最好从小处着手，逐步采用相关技术。先使用一个简单的 Dockerfile 将应用容器化并部署到云端；随后引入 Kubernetes，通过自动化部署与管理来实现可扩展性与可靠性。
在此基础上，使用 GitHub Actions 等工具采用基于推送的 GitOps 方法，自动化云基础设施与应用部署。最后，随着项目成熟并需要生产级稳定性，可迁移至 Argo CD 或 Flux 等基于拉取的模型，以实现持续对账、漂移检测与自愈能力。
这种循序渐进的路径能够确保平滑的学习曲线，同时充分发挥 GitOps 在现代云原生应用中的潜力。
在本文中，我们探讨了 GitOps、其重要性、各种 GitOps 模式，以及如何将 GitOps 集成到一个 AI 项目中。若您刚接触 AI，我们强烈建议学习AI Fundamentals 技能路径，它涵盖 AI 基础，深入探讨如 GPT-4o 等模型，并揭示生成式 AI 的要点，帮助您把握不断演进的 AI 版图。