文档会一直更新，所以使用Notion进行撰写，需要科学访问
DevOps Practice: GitOps

本实践采用云原生理念，全程声明式，实现代码一次推送，全程流水线持续集成与部署。

本实践借助以下系统或工具实现GitOps，有些工具或系统需要有一定的了解：

• Terraform
• Ansible
• Kubernetes
• Docker
• Harbor
• Gitlab
• Tekton Pipelines
• Tekton Triggers
• Kaniko
• Sonarqube
• Argo CD
• Argo CD Notification
• Kustomize

还有一些是为实现更为复杂的部署能力，如自动化测试、蓝绿部署、渐进式金丝雀发布等，需要以下工具提供更多的能力，将会在未来支持：

• Argo CD Workflow （未来版本）
• Argo CD Event （未来版本）
• Vault （未来版本）
• Helm（未来版本）
• Flagger （未来版本）
• Istio （未来版本）

首先介绍此实践的理念

1.理念与工具集

然后开始持续集成

2.Tekton

最后开始持续部署

3.ArgoCD

DevOps

理念

DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

工具集

DevOps是一套理论，一般会采用这样的一套工具集来实现DevOps：

• 持续集成/CI：Jenkins/Gitlab CI/Drone
• 代码检查：Sonarqube
• 持续部署/CD：Jenkins/Ansible
• 持续部署/CD 配套工具：Helm

云原生

信息

Pivotal 是Cloud Native/云原生应用的提出者，并推出了Pivotal Cloud Foundry和Spring系列开发框架，是云原生的先驱者和探路者。

定义

2018年6月，CNCF正式对外公布了更新之后的云原生的定义1.0:

• 容器
• 微服务
• 不可变基础设施
• 声明式API
• 服务网格

挑战

用云原生理念来思考DevOps，可能遇到的问题：

• 我们没有完全容器化，还有二进制部署
• 我们服务耦合很强，没有对功能进行微服务拆分
• 我们新增加服务器还需要对服务器进行一番定制化的配置
• 我们还在使用Jenkins这类命令式的工具
• 我们还没有使用Kubernetes
• 我们还没有使用服务网格
• 我们很难支持Serverless、FaaS

GitOps

定义

GitOps是DevOps的一种实现方式，类似的还有AIOps、ChatOps，简单来说都是做流水线的，只是侧重点不同，来看看GitOps的定义：

GitOps是一种持续交付的方式。它的核心思想是将应用系统的声明性基础架构和应用程序存放在Git版本库中。将Git作为交付流水线的核心，每个开发人员都可以提交拉取请求（Pull Request）并使用Git来加速和简化Kubernetes的应用程序部署和运维任务。通过使用像Git这样的简单工具，开发人员可以更高效地将注意力集中在创建新功能而不是运维相关任务上（例如，应用系统安装、配置、迁移等）。

总结来说相比较基于命令式流水线，有以下几样东西：

• 声明式API，所有的操作都来自于声明
• 不可变基础设施，尽量不要关注宿主机信息
• 任何声明都存储在Git中
• 保证不使用kubectl
• Pull流水线，都是在Kubernetes内的Pod根据Webhook信号主动Pull代码，对集群内部的操作的权限留存在集群内
• Kubernetes，Kubernetes是云原生基础

工具集

可以用以下工具实现GitOps：

• 环境：Terraform/Ansible
• 持续集成/CI：Tekton/Jenkinsx
• 持续集成/CI 配套工具：Kaniko/Buildkit
• 静态代码检查：Sonarqube
• 持续部署/CD：ArgoCD
• 持续部署/CD 配套工具：Helm/Kustomize/Flagger/Istio