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

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

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

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

前言

前篇文章介绍了 Rancher(v2.0 ~ v2.4) 中主打的应用程序管理系统， Catalog，所有的 Catalog 都必须要於 Cluster Manager 的介面中去管理。

而 Rancher v2.5 开始主打 Cluster Explorer 的介面，该介面中又推行了另外一套应用程序管理系统，称为 App & Marketplace。

事实上前述的章节就已经有透过这个新的系统来安装 Monitoring 的相关资源，因此现在 Rancher 都已经使用这个新的机制来提供各种整合服务，因此後续的新功能与维护也都会基於这个新的机制。

使用上我认为两者还是有些差异，因此对於一个 Rancher 的使用者来说最好两者都有碰过，稍微理解一下其之间的差异，这样使用上会更有能力去判断到底要使用哪一种。

Rancher App

新版的应用程序架构基本上跟前述的没有不同，不过名词上整个大改，相关名词变得与 Helm 生态系更佳贴近，譬如旧版使用 Catalog 来描述去哪边抓取 Helm 相关的应用程序，新版本则是直接贴切的称为 Helm Repo。

Cluster Explorer 的状态下，左上方点选到 Apps & Marketplace 就可以进入到新版的系统架构，

该架构中左方有三个类别，其中第二个 Charts Repositories 就是新版的 Catalog，画面如下。

预设系统上有两个 Chart Repo，其中之前安装的 Monitoring 就是来自於这边。
接者点选右上方的 Create 就会看到新版的创立画面

新版本的创建画面更加简洁与简单，首先可以透过 target 来选择到底要使用 Git 还是 HTTP 来存取，针对 Private Helm Repo 这次则提供了两种验证方式，譬如 SSH Key 与 HTTP Basic 两种方式。

创造完毕後就可以於系统上看到新建立的 Helm Repo，系统预设的两个 Helm Repo 都是基於 Git 去处理，而本篇文章新创立的则是 HTTP。

有了 Helm Repo 後，下一步就是要创造应用程序，切换到 Charts 的介面就可以看到如下的画面。

画面中上方显示了目前拥有的 Helm Repo 有哪些，这边可以透过勾选的方式来过滤想要显示的 Helm Repo
只有单纯勾选 dashboard 後就可以看到 kubernetes-dashboard 这个 Helm Chart。

点选该 kubernetes-dashboard 後进入到新版的安装设定介面，该画面中相对於旧版的 Catalog 来说画面更为简洁有力。
画面中，最上方包含了 App 的名称，该使用的 Helm Chart 版本，范例使用了 4.5.0。

接者下方则是安装的 namespace ，这些选择都与旧版的介面差不多。
最下方则列出不同的类别，包含

1. Values
2. Helm README
3. Helm Deploy Options

Rancher 新版 App 舍弃了旧版 Answer 的叫法，同时也完全使用 YAML 的格式来设定 values，而不是透过 UI 一行一行慢慢设定。

注: 事实上旧版的 UI 的设定方式其实有满多问题，某些情况还真的不能设定，透过档案还是相对简单与方便。

下面的 Helm Deploy Options 有不同的部署选项，譬如

1. 要不要执行 Helm Hooks
2. 部署 Helm 时要不要设定 Timeout，多久的时间没有成功部署就会判定失败

一切设定完毕後就可以开始安装，安装画面跟 Monitoring 的经验类似，都会弹出一个 Terminal 画面来显示安装过程。
画面最下方则是显示了到底系统是使用什麽指令来安装 Helm Chart，安装完毕可以用左上的按钮离开画面。

接者移动到 Installed Charts 可以找到前述安装的 App，外面提供的 Active 资源数量则是代表所有 Kubernetes 的资源，不单单只是旧版所显示的 Pod 而已。

新版跟旧版的 App 最大的差异我认为就是 Endpoint 的显示，旧版的 Catalog 会很好心地将 Endpoint 呈现出来让使用者可以轻松存取这些服务，但是新版却不会。
要注意的是这些存取实际上是透过 Kubernetes API 去转发的，所以其实这项功能并不需要 Rancher 特别帮你的应用程序处理什麽，因此如果知道相关的规则，还是可以透过自行撰写 URL 来存取相关服务网页，如下。

透过 UI 观察新版应用程序後，接下来就示范如何透过 Terraform 来管理这种新版本的 Application。

Rancher 於 Terraform 中的实作是将 Catalog 与 App 的概念分开，新的概念都会补上 _v2 於相关的资源类型後面，譬如
catalog_v2, app_v2。

这个范例中的作法跟前述一样

1. 取得 project 的 ID(此处省略)
2. 透过 catalog_v2 创造 Helm Repo
3. 创造要使用的 namespace
4. 接者使用 app_v2 创造 App

Terraform 的程序码非常简单，如下

resource "rancher2_catalog_v2" "dashboard-global-app" {
  name = "dashboard-terraform"
  cluster_id = "c-z8j6q"
  url = "https://kubernetes.github.io/dashboard/"
}
resource "rancher2_namespace" "dashboard-app" {
  name = "dashboard-terraform-app"
  project_id = data.rancher2_project.system.id
}
resource "rancher2_app_v2" "dashboard-app" {
  cluster_id = "c-z8j6q"
  name = "k8s-dashboard-app-terraform"
  namespace = rancher2_namespace.dashboard-app.id
  repo_name = "dashboard-terraform"
  chart_name = "kubernetes-dashboard"
  chart_version = "4.5.0"
  depends_on       = [rancher2_namespace.dashboard-app, rancher2_catalog_v2.dashboard-global-app]
}

其实透过观察 v2 版本的 API 就可以观察出来 v2 的改动很多，譬如

1. catalog_v2 (Helm Repo) 移除了关於 Scope 的选项，现在所有的 Helm Repo 都是以 Cluster 为单位，不再细分 Global, Cluster, Project.
2. app_v2 (App) 安装部分差异最多，特别是 Key 的部分跟贴近 Helm Chart 使用的名词，使用上会更容易理解每个名词的使用。
   譬如使用 chart_name, chart_version 取代过往的 template, template_version，同时使用 repo_name 取代 catalog_name。
   不过如果都要使用 repo_name 了，其实直接舍弃 catalog_v2 直接创造一个新的物件 helm_repo 我认为会更佳直觉一些。

另外 App 移除了对於 Project 的使用，反而是跟 Cluster 有关，变成 App 都是以 Cluster 为基本单位。

当 Terraform 顺利执行後，就可以於 App 页面观察到前述描述的应用程序被顺利的部署起来了，如下图。

到这边可能会感觉到有点混淆，似乎使用 Cluster Explorer 就再也没有 Project 的概念了，因此我认为 Rancher v2.6 後续还有很多东西要等，短时间内 Cluster Explorer 没有办法完全取代 Cluster Manager 的介面操作，但是部分功能 (Monitoring) 又已经完全转移到 Cluster Explorer，这会造就管理者可能会两个功能 (Cluster Explorer/Manager) 都会各自使用一部分的功能。

期许 Rancher 能够将这些概念都同步过去才有办法真正的移除 Cluster Manager，或是更可以直接的说过往的某些概念於新版後都不再需要。