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

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

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

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

前言

前篇文章探讨了 Fleet 的基法用法与操作介面，而本文将要正式踏入到 Rancher Fleet GitOps 的世界中
为了使用 GitOps 来部署，必须要先准备一个 Git 的专案来放置要部署的资源，

本篇文章使用的范例都会放到我准备的一个公开 Git Repo Fleet Demo

Workspace

前述提到大部分 Rancher Fleet 的资源都是基於 Kubernetes CRD 去描述的，因此除了透过网页操作外也是可以准备一个相关的 YAML 档案，只要将该 YAML 给部署到 Kubernetes 内， Fleet Controller 就会根据该资源进行对应的操作与更新。

一开始先从简单的部分开始练习，尝试透过 GitOps 帮忙创建与管理 Workspace，预设的情况下丛集会有 fleet-default 与 fleet-local 这两个 workspace，所以目标是想要创造两个不同的 workspace，分别是 prod 以及 testing.

Workspace 的 YAML 非常简单，一个范例如下

apiVersion: management.cattle.io/v3
kind: FleetWorkspace
metadata:
  name: prod
  namespace: prod

创建一个 FleetWorkspace 的物件，并且针对 name/ns 给予相对应的资料即可，因此针对两个 workspace 准备两个档案，并且将这两个档案放到 git 专案下的 workspace 资料夹底下。示意图如下。

╰─$ tree .
.
└── workspace
    ├── production.yaml
    └── testing.yaml

将上述内容给推向远方 Git 专案中後，下一步就是要让 Fleet 知道请追踪这个 Git Repo 并且将相关的内容给部署到 Kubernetes 内。
切换到 Fleet 的介面，选择到 Fleet-Local 这个 workspace 并且於 GitRepo 的页面中点选创立，这时候可以看到如下的介面

该介面中我们需要设定几个资讯

1. GitRepo 物件的名称
2. Git 专案的 URL
3. Git 专案的 Branch
4. Git 专案是否需要透过权限去纯取。
5. 要从 Git 专案中的哪个位置去寻找相关 YAML 档案。

因为示范专案是公开的，所以(4)可以直接忽略。
第五点要特别设定成 workspace/，因为前述我们将两个 workspace 的 YAML 放到 workspace 资料夹底下。

创立完毕後就会看到系统上创建了一个名为 workspace 的 Git 物件，该物件的状态会从 GitUpdating 最後变成 Active。

由於 fleet-local 这个 workspace 中只有一个 cluster，也就是 local，因此刚刚创立的 GitRepo 只会将相关资源给安装到这个 local cluster 中，所以可以看到图中显示的 Clusters Ready 标示为 1。

点选 workspace 这个资源进去可以看到更多关於该 GitRepo 的资讯，譬如相关的资源有哪些。
范例中可以看到底下提供了两个属於 FleetWorkspace 的物件，分别为 prod 以及 testing，这两个物件都安装到对应的 namespace 中。

之前也有提过针对每个 GitRepo 所扫描出来的物件都会创造出一个最基本的 Bundle 物件，该物件会描述这个应用程序的所有内容。所以切换到 Bundle 介面去寻找 workspace，可以看到如下的范例。

该 bundle 会把所有要安装的资源都集中起来，同时因为这次的范例非常简单，没有要针对任何 Cluster 去客制化与过滤，所以 targets/targetRestrictions 都是空白的。
此时点选 workspace 的介面或是上方的选单，会发现先前描述的 testing 与 prod 这两个 workspace 已经被自动创立了，这意味者 Fleet 已经自动地从 Git 专案中学习到要部署什麽资源，并且把资源给成功的部署到 Kubernetes 内，最後的结果也如预期一样。

用 Fleet 管 GitRepo

下一个范例就是希望透过 Fleet 管理 GitRepo 物件，毕竟能够尽可能减少 UI 操作是追求自动化过程中不可避免的一环。

首先到 GitRepo 中将该 Workspace 的物件移除，移除後可以观察到 Bundle 中关於 prod/testing 的物件都不见，同时 workspace 中只剩下 fleet-local 以及 fleet-default.

为了让 Fleet 帮忙管理，我们需要准备一个描述 GitRepo 的 YAML 档案，将该档案放到专案中的 repos/local 底下。

kind: GitRepo
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: fleet-demo
  namespace: fleet-local
spec:
  repo: https://github.com/hwchiu/fleet_demo.git
  branch: master
  paths:
    - workspace/
  targets:
    - clusterSelector: {}

该 Yaml 描述的内容跟前述透过 UI 创建 GitRepo 是一致的，当系统中有愈来愈多应用程序要管理的时候，就修改该物件，让 Paths 指令更多路径即可。

准备好该物件後，接下来还是要到 Fleet UI 去创建一个 GitRepo 物件，该 GitRepo 物件是用来帮忙管理所有 GitRepo 物件的，因此必须要先手动创建一次，接下来就可以依赖 GitOps 的流程帮忙管理。

这边先创造一个新的 GitRepo 物件，该物件指向 repos/local。

所以整个流程就会变成

1. Fleet 去读取 Git 专案底下 repos/local 内的物件
2. repos/local 内的物件被套用到 Kubernetes 後就会产生另外一个名为 fleet-demo 的 GitRepo 物件
3. fleet-demo 物件会再次的去把专案内的 workspace/ 给抓进来进行後续安装。

一切准备完毕後，会观察到 GitRepo 列表呈现的如下图，会有两个 GitRepo

这时候如果点进去 fleet-demo 这个 GitRepo，可以看到该 GitRepo 会部署两个 workspace，同时最上方还有一个额外的 label，该 label 是由 helm 产生的。
前述提过 Fleet 会将所有资源都动态的转换为 Helm 格式。

转移 Cluster

创立好两个不同的 workspace 後，可以尝试将三个预先创立的 k8s cluster 给搬移过去，举例来说将
rke-qa 以及 ithome-dev 这两套丛集搬移到 testing workspace，而 rke-it 则搬移到 prod workspace。

下一步就是真正实务上的需求，部署应用程序。为了让 Fleet 安装应用程序，所以也需要帮忙准备一个 GitRepo 的物件。针对 testing 以及 prod 各准备一个，并且依序放到 repos/testing, repos/prod 底下。

╰─$ cat prod/app-basic.yaml
kind: GitRepo
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: prod-app
  namespace: prod
spec:
  repo: https://github.com/hwchiu/fleet_demo.git
  branch: master
  paths:
    - app/basic
  targets:
    - clusterSelector: {}
╰─$ cat testing/app-basic.yaml
kind: GitRepo
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: testing-app
  namespace: testing
spec:
  repo: https://github.com/hwchiu/fleet_demo.git
  branch: master
  paths:
    - app/basic
  targets:
    - clusterSelector: {}

目前系统上还没有 app/basic 资料夹，可以先不用管它。

上述两个 GitRepo 的差异处有两个

1. 名称不同
2. 安装的 namespace 不同，注意这边的 namespace 要跟 workspace 的名称一致。

接者我们要让最原始的 repos 一起帮忙处理这两个 GitRepo，将 repos/local 底下的档案修改为

╰─$ cat local/repos.yaml
kind: GitRepo
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: fleet-demo
  namespace: fleet-local
spec:
  repo: https://github.com/hwchiu/fleet_demo.git
  branch: master
  paths:
    - workspace/
    - repos/testing
    - repos/prod
  targets:
    - clusterSelector: {}

这时候整个专案呈现如下

╰─$ tree -l
.
├── repos
│   ├── local
│   │   └── repos.yaml
│   ├── prod
│   │   └── app-basic.yaml
│   └── testing
│       └── app-basic.yaml
└── workspace
    ├── production.yaml
    └── testing.yaml

当这些修改都推到远方 Git 专案後就会观察到 fleet-local 下的两个 GitRepo 物件都变成 NotReady 的状态，如下

以 Fleet 的角度来解释就是

1. fleet-demo 这个 GitRepo 本身会希望安装三个路径底下的物件，分别是 workspace/ repos/testing, repos/prod, 只要其中有一个没有顺利部署完成，身为老爸的 fleet-demo 也就自然不能说自己完成
2. fleet-demo 这个物件是由 repos 这个 GitRepo 去动态产生的，因此 fleet-demo 本身没有顺利完成的话，repos 物件也没有办法说自己顺利完成。

接者点进去 fleet-demo 看一下到底是什麽物件没有顺利完成，可以看到刚刚创立的 prod-app 以及 testing-app 这两个物件也都没有完成，所以跟 workspace 无关。

这时候切换到 testing 的 workspace，可以观察到系统上的 testing-app GitRepo 是呈现红色的字眼，叫做 Git Updating。
同时最上方有显示相关错误讯息，告知使用者为什麽该专案目前不能正常运作。
其讯息告知 Fleet 没有办法从 专案底下的 app/basic 路径找到可以用的 Kubernetes 物件，因此没有办法顺利安装资源，所以标示为错误。

为了解决这个问题，我从官方范例中复制了一个简单的 Deployment 物件，将该物件给放到 apps/basic 底下。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  selector:
    matchLabels:
      app: guestbook
      tier: frontend
  replicas: 3
  template:
    metadata:
      labels:
        app: guestbook
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google-samples/gb-frontend:v4
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        ports:
        - containerPort: 80

将这个物件推向远方的 Git 专案後就可以观察到 testing-app 成功顺利的安装物件到丛集中，由於 testing 的 workspace 底下有两个不同的 cluster， ithome-dev 以及 rke-qa。
所以这个物件就会自动的安装到这两个丛集中。

这时候如果去 cluster explorer 的介面可以看到 deployment 中有一个名为 frontend 的 deployment 物件被创建出来。

本篇文章到这边为止，我们尝试透过 Fleet GitOps 的方式来管理 Fleet 本身并且部署了第一个应用程序，下一篇文章将来探讨如何针对不同的 Cluster 给予不同的客制化，譬如 ithome-dev 跟 rke-qa 可以使用不同的参数或是档案来部署。