Update nexus: fix conflicts and sync local changes
This commit is contained in:
@@ -1,44 +1,44 @@
|
||||
---
|
||||
title: "GitOps"
|
||||
type: concept
|
||||
tags:
|
||||
- DevOps
|
||||
- CI/CD
|
||||
- Kubernetes
|
||||
- Infrastructure as Code
|
||||
---
|
||||
|
||||
## Definition
|
||||
GitOps 是一种将软件开发的版本控制与协作原则应用于云原生基础设施和应用部署的方法论。核心思想:**使用 Git 作为单一事实来源(Single Source of Truth)声明系统的期望状态,由自动化代理(GitOps Controller)持续协调实际状态向期望状态收敛。**
|
||||
|
||||
## Four Principles
|
||||
1. **声明式配置(Declarative Configuration)**:所有基础设施和应用配置必须以声明式代码描述,而非命令式脚本
|
||||
2. **版本控制(Version Control)**:所有配置存储在 Git 仓库中,享受完整的变更历史、代码审查和回滚能力
|
||||
3. **CD 流程分离(CD Process Separation)**:CI 专注构建和分析代码,CD 专注部署,两者解耦增强安全性
|
||||
4. **自修复协调器(Automated Reconciliation)**:GitOps Controller 持续监控实际状态与 Git 声明状态,自动调和偏差
|
||||
|
||||
## Key Benefits
|
||||
- 开发者只需掌握 Git 即可完成安全部署
|
||||
- 分钟级代码变更上线
|
||||
- 零停机回滚(Git 历史即回滚计划)
|
||||
- Git 提交日志天然构成合规审计追踪
|
||||
- 提高开发者生产力(使用熟悉的工具)
|
||||
|
||||
## Pull Model vs Push Model
|
||||
|
||||
| | Pull Model(推荐) | Push Model |
|
||||
|---|---|---|
|
||||
| 机制 | 部署代理主动监控 Git 和目标系统 | CI/CD 管道主动推送变更到目标 |
|
||||
| 安全性 | 更高——系统状态不暴露给外部 | 较低——需外部访问目标系统 |
|
||||
| 代表工具 | ArgoCD, Flux | Jenkins CI/CD, Terraform Cloud |
|
||||
| 适用场景 | GitOps 核心模式 | 传统 CI/CD 扩展 |
|
||||
|
||||
## Relationship with IaC
|
||||
GitOps 是 [[Infrastructure as Code]] 的部署编排层:
|
||||
- **IaC**:定义"基础设施应该是什么样的"(Terraform/Pulumi/HCL)
|
||||
- **GitOps**:定义"如何确保基础设施始终符合声明"(ArgoCD/Flux/Atlantis)
|
||||
|
||||
## Sources
|
||||
- [[ctp-topic-33-an-introduction-to-gitops]] — GitOps 方法论入门,Victor Etkin 主讲
|
||||
- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] — Atlantis 作为 GitOps 工具实践
|
||||
- [[ctp-topic-9-ci-cd-with-gruntwork]] — Gruntwork CI/CD 与 GitOps 的关联
|
||||
---
|
||||
title: "GitOps"
|
||||
type: concept
|
||||
tags:
|
||||
- DevOps
|
||||
- CI/CD
|
||||
- Kubernetes
|
||||
- Infrastructure as Code
|
||||
---
|
||||
|
||||
## Definition
|
||||
GitOps 是一种将软件开发的版本控制与协作原则应用于云原生基础设施和应用部署的方法论。核心思想:**使用 Git 作为单一事实来源(Single Source of Truth)声明系统的期望状态,由自动化代理(GitOps Controller)持续协调实际状态向期望状态收敛。**
|
||||
|
||||
## Four Principles
|
||||
1. **声明式配置(Declarative Configuration)**:所有基础设施和应用配置必须以声明式代码描述,而非命令式脚本
|
||||
2. **版本控制(Version Control)**:所有配置存储在 Git 仓库中,享受完整的变更历史、代码审查和回滚能力
|
||||
3. **CD 流程分离(CD Process Separation)**:CI 专注构建和分析代码,CD 专注部署,两者解耦增强安全性
|
||||
4. **自修复协调器(Automated Reconciliation)**:GitOps Controller 持续监控实际状态与 Git 声明状态,自动调和偏差
|
||||
|
||||
## Key Benefits
|
||||
- 开发者只需掌握 Git 即可完成安全部署
|
||||
- 分钟级代码变更上线
|
||||
- 零停机回滚(Git 历史即回滚计划)
|
||||
- Git 提交日志天然构成合规审计追踪
|
||||
- 提高开发者生产力(使用熟悉的工具)
|
||||
|
||||
## Pull Model vs Push Model
|
||||
|
||||
| | Pull Model(推荐) | Push Model |
|
||||
|---|---|---|
|
||||
| 机制 | 部署代理主动监控 Git 和目标系统 | CI/CD 管道主动推送变更到目标 |
|
||||
| 安全性 | 更高——系统状态不暴露给外部 | 较低——需外部访问目标系统 |
|
||||
| 代表工具 | ArgoCD, Flux | Jenkins CI/CD, Terraform Cloud |
|
||||
| 适用场景 | GitOps 核心模式 | 传统 CI/CD 扩展 |
|
||||
|
||||
## Relationship with IaC
|
||||
GitOps 是 [[Infrastructure as Code]] 的部署编排层:
|
||||
- **IaC**:定义"基础设施应该是什么样的"(Terraform/Pulumi/HCL)
|
||||
- **GitOps**:定义"如何确保基础设施始终符合声明"(ArgoCD/Flux/Atlantis)
|
||||
|
||||
## Sources
|
||||
- [[ctp-topic-33-an-introduction-to-gitops]] — GitOps 方法论入门,Victor Etkin 主讲
|
||||
- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] — Atlantis 作为 GitOps 工具实践
|
||||
- [[ctp-topic-9-ci-cd-with-gruntwork]] — Gruntwork CI/CD 与 GitOps 的关联
|
||||
|
||||
Reference in New Issue
Block a user