本文将於赛後同步刊登於笔者部落格

有兴趣学习更多 Kubernetes/DevOps/Linux 相关的资源的读者，欢迎前往阅读

更多相关科技的技术分享，欢迎追踪 矽谷牛的耕田笔记

对於 Kubernetes 与 Linux Network 有兴趣的可以参阅笔者的线上课程

前言

前述文章探讨了应用程序部署的基本思路，从 Rancher 管理的丛集出发有至少三种不同的部署方式，分别为

1. 直接取得 Kubeconfig 获得对 Kubernetes 丛集操作的权限
2. 使用 Rancher 内的应用程序机制(Catalog or App & Marketplace) 来安，并可透过 Terraform 来达到 Infrastructure as Code 的状态。
3. 使用 GitOps 的方式来管理 Kubernetes 应用程序

本篇文章开始将探讨何谓 GitOps 以及 GitOps 能够带来的好处，并且最後将基於 Rancher FLeet 去进行一系列 GitOps 解决方案的
示范。

GitOps

就如同 DevOps 是由 DEV + OPS 两种概念结合而成， GitOps 的原意来自於 Git 以及 OPS，目的是希望以 Git 上的资料为基底去驱动 Ops 相关的操作。

该词源自於 2017 年由 Weave Works 所提出，GitOps 本身并没有一个非常标准的定义与实作方式，就如同 DevOps 的文化一样， 不同人使用 GitOps 的方式都不同，但是基本上都会遵循一个大致上的文化。

GitOps 的精神就是以 Git 作为唯一的资料来源，所有的应用程序部署都只能依赖这份 Git 上内容去变化。
基於这种精神，下列行为都希望尽量减少甚至避免。

1. 直接透过 KUBECONNFIG 对丛集直接使用 Helm/Kubectl 去进行操作
2. 透过其他机制(Rancher Catalog/App) 去对丛集进行应用程序的管理

当 Git 作为一个唯一的资料来源时，整个部署可以带来下列的好处

1. Git 本身的管理控制提供了应用程序的稽核机制，透过 Git 机制可以知道谁於什麽时间点什麽时间点带来了什麽样的改变。
2. 需要退版的时候，可以使用 Git Revert 的方式来退版 Git 内容，因此应用程序也会退版
3. 可以透过 Git 的方式(Branch, tag) 等本身机制来管理不同环境的应用程序
4. 由於 Git 本身都会使用 Pull Request/Git Review 等机制来管理程序码管理，因此该机制可以套用到应用程序管理上。

这边要注意的是， GitOps 本身的并没有特别限制只能使用於 Kubernetes 环境之中，只是当初 Weave work 讲出这名词时是基於 Kubernetes 的环境来探讨，因此後续比较多的解决方案也都是跟 Kubernetes 有关，但是这并不代表 GitOps 只能使用於 Kubernetes 内，任何的使用环境只要有基於 Git/Ops 的理念，基本上都可以想办法实作 GitOps.

但是 GitOps 到底要如何实作? 要如何将 Git 的更动给同步到应用程序的部署则没有任何规范与标准，目前主要有两种主流，以下都是一种示范介绍，实务上实作时可以有更多不同的变化。

1. 专属 CI/CD 流水线
2. 独立 Controller

接下来以 Kubernetes 为背景来探讨一下可能的解法。

专属 CI/CD 流水线

这种架构下会创立一个专属的 CI/CD Pipeline, 该 Pipeline 的触发条件就是 Git 专案发生变化之时。
所以 Pipeline 中会去抓取触发当下的 Git 内容，接者从该内容中判别当前有哪些档案被修改，从这些被修改的档案去判别是哪些应用程序有修改，接者针对被影响的应用程序去进行更新。

以 Kubernetes 来说，通常就是指 CI/CD Pipeline 中要先获得 KUBECONFIG 的权限，如果使用的是 Rancher，则可以使用 Rancher API Token。
当系统要更新应用程序时，就可以透过这些权限将 Kubernetes 内的应用程序进行更新。

这种架构基本上跟传统大家熟悉的 CD 流程自动化看起来没有什麽不同，不过 GitOps 会更加强调以 Git 为本，所以会希望只有该 CI/CD Pipeline 能够有机会去更新应用程序，这也意味任何使用者直接透过 KUBECONFIG 对 Kubernetes 操作这件事情是不被允许的。

所以 GitOps 不单单是一个工具与解决方案，也是一个文化。

独立 Controller

第二个解决方式是目前 Kubernetes 生态中的常见作法，该作法必须要於 Kubernetes 内部署一个 Controller，该 Controller 本身基於一种状态检查的无限回圈去运行，一个简单的运作逻辑如下。

1. 检查目标 Git 专案内的档案状态
2. 检查当前 Kubernetes 丛集内的应用程序状态
3. 如果(2)的状态与(1)不同，就更新丛集内的状态让其与(1)相同

一句话来说的话，该 Controller 就是用来确保 Git 专案所描述的状态与目标环境的现行状态一致。

为了完成上述流程，该 Controller 需要有一些相关权限

1. 能够读取 Git 专案的权限
2. 能够读取 Kubernetes 内部状态的权限
3. 能够更新 Kubernetes 应用程序的权限

由於该 Controller 会部署到 Kubernetes 内部，所以(2+3)的权限问题不会太困难，可以透过 RBAC 下的 Service Account 来处理。
(1)的部分如果是公开 Git 专案则没有太多问题，私人的话就要有存取的 Credential 资讯。

以下是一个基於 Controller 架构的部署示范

1. 先行部署 Controller 到 Kubernetes 丛集内
2. 设定目标 Git 专案与目标 k8s 丛集/namespace 等资讯。
3. 开发者针对 Git 专案进行修改。
4. Controller 侦测到 Git 专案有变动
5. 获取目前 Git 状态
6. 获取目前 丛集内的应用程序状态
7. 如果(5),(6)不一样，则将(5)的内容更新到丛集中
8. 反覆执行 (4~7) 步骤。

到这边为止探讨了关於 GitOps 的基本概念，接下来就会数个知名的开源专案去进行探讨