一键创建/销毁环境

本章将介绍如何使用 KubeVela 在交付应用时对环境进行快速初始化和销毁。

环境指什么？

一个应用开发团队通常需要做一些初始化工作来满足应用部署时方方面面的需要，即“初始化环境”。 这里的环境是一个逻辑概念，既可以表示应用部署时依赖的公共资源，也可以表示应用运行必要的准备工作。

KubeVela 同样是 Application 对象做环境的初始化，可以初始化的资源类型包括但不限于下列类型：

  1. 一个或多个 Kubernetes 集群，不同的环境可能需要不同规模和不同版本的 Kubernetes 集群。同时环境初始化还可以将多个 Kubernetes 集群注册到一个中央集群进行统一的多集群管控。

  2. 任意类型的 Kubernetes 自定义资源（CRD）和系统插件，一个环境会拥有很多种不同的自定义资源来提供系统能力，比如不同的工作负载、不同的运维管理功能等等。初始化环境可以包含环境所依赖的一系列功能的初始化安装，比如各类中间件工作负载、流量管理、日志监控等各类运维系统。

  3. 各类共享资源和服务，一个微服务在不同环境中测试验证时，除了自身所开发的组件以外，往往还会包含一系列其他团队维护的组件和一些公共资源。环境初始化功能可以将其他组件和公共资源统一部署，在无需使用时销毁。这些共享资源可以是一个微服务组件、云数据库、缓存、负载均衡、API网关等等。

  4. 各类管理策略和流程，一个环境可能会配备不同的全局策略和流程，举例来说，环境策略可能会包括混沌测试、安全扫描、错误配置检测、SLO指标等等；而流程则可以是初始化一个数据库表、注册一个自动发现配置等。

不仅如此，KubeVela 的环境初始化能力还可以跟工作流、策略、依赖等功能相结合，做不同环境的差异化部署，依赖管理等。

若不同环境初始化存在依赖关系，可以初始化的公共资源分离出一个单独的 Application 作为依赖，这样可以形成可以被复用的初始化模块。 例如，测试环境和开发环境都依赖了一些相同的控制器，可以将这些控制器提取出来作为单独的环境初始化，在开发环境和测试环境中都指定依赖该环境初始化。

如何使用

直接使用应用部署计划完成环境初始化

请确保你的 KubeVela 版本在 v1.1.6 及以上。

如果我们希望在环境中使用一个自定义 CRD 控制器(如 OpenKruise)，那么，我们可以使用 Helm 组件初始化 kruise。

我们可以直接使用 KubeVela 的应用部署计划来初始化 kruise 的环境，该应用会帮你在集群中部署一个 OpenKruise 的控制器，给集群提供 kruise 的各种能力。

由于我们使用 Helm 组件完成 kruise 的部署，我们首先要在集群中使用 fluxcd 开启 helm 功能。 当环境初始化具备多个模块时，可以对初始化的内容进行拆分，同时使用工作流的 depends-on-app 步骤，描述不同初始化模块的依赖关系。 比如我们可以在这个例子里，使用 depends-on-app 表示环境初始化 kruise 依赖环境初始化 fluxcd 提供的能力。

depends-on-app 会根据 properties 中的 name 及 namespace，去查询集群中是否存在对应的应用。 如果应用存在，则当该应用的状态可用时，才会进行下一个步骤； 若该应用不存在，则会去查询同名的 configMap，从中读取出应用的配置并部署到集群中。 更详细的说明，请查看 depends-on-app。

部署如下文件：

  1. cat <<EOF | vela up -f -
  2. apiVersion: core.oam.dev/v1beta1
  3. kind: Application
  4. metadata:
  5.   name: kruise
  6.   namespace: vela-system
  7. spec:
  8.   components:
  9.   - name: kruise
  10.     type: helm
  11.     properties:
  12.       branch: master
  13.       chart: ./charts/kruise/v0.9.0
  14.       version: "*"
  15.       repoType: git
  16.       url: https://github.com/openkruise/kruise
  17.   workflow:
  18.     steps:
  19.     - name: check-flux
  20.       type: depends-on-app
  21.       properties:
  22.         name: fluxcd
  23.         namespace: vela-system
  24.     - name: apply-kruise
  25.       type: apply-component
  26.       properties:
  27.         component: kruise
  28. EOF

查看集群中应用的状态：

  1. $ vela ls -n vela-system
  2. APP                 COMPONENT       TYPE        TRAITS  PHASE   HEALTHY STATUS  CREATED-TIME
  3. kruise              ...             raw           running           healthy         2021-09-24 20:59:06 +0800 CST
  4. fluxcd              ...             raw           running           healthy         2021-09-24 20:59:06 +0800 CST

kruise 已经成功运行！之后，你可以在环境中使用 kruise 的能力。如果需要配置新的环境初始化，也只需要类似的定义一个部署计划。

在应用部署中加入初始化的工作流

在环境中，一些通用的 ConfigMap / PVC 等资源是十分常用的。 如果你希望在部署应用前内置一些通用资源，可以在应用部署中加入初始化的工作流来完成。

KubeVela 提供了一个内置的工作流步骤 apply-object，可以直接在组件的 properties 字段中填写创建到环境中的原生 Kubernetes 资源。 这种在 Application 中直接填写 Kubernetes 原生资源的方式，可以避免编写多余的组件定义（ComponentDefinition）。

部署如下应用，初始化一个带有 ConfigMap / PVC 的环境。同时，部署两个组件，第一个组件会不断向 PVC 中写入数据，第二个组件会读取 PVC 中的数据：

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4.   name: server-with-pvc-and-cm
  5.   namespace: default
  6. spec:
  7.   components:
  8.   - name: log-gen-worker
  9.     type: worker
  10.     properties:
  11.       image: busybox
  12.       cmd:
  13.         - /bin/sh
  14.         - -c
  15.         - >
  16.           i=0;
  17.           while true;
  18.           do
  19.             echo "$i: $(date)" >> /test-pvc/date.log;
  20.             i=$((i+1));
  21.             sleep 1;
  22.           done
  23.       volumes:
  24.         - name: "my-pvc"
  25.           type: "pvc"
  26.           mountPath: "/test-pvc"
  27.           claimName: "my-claim"
  28.         - name: "my-configmap"
  29.           type: "configMap"
  30.           mountPath: "/test-cm"
  31.           cmName: "my-cm"
  32.           items:
  33.             - key: test-key
  34.               path: test-key
  35.   - name: log-read-worker
  36.     type: worker
  37.     properties:
  38.       name: count-log
  39.       image: busybox
  40.       cmd: 
  41.         - /bin/sh
  42.         - -c
  43.         - 'tail -n+1 -f /test-pvc/date.log'
  44.       volumes:
  45.         - name: "my-pvc"
  46.           type: "pvc"
  47.           mountPath: "/test-pvc"
  48.           claimName: "my-claim"
  49.         - name: "my-configmap"
  50.           type: "configMap"
  51.           mountPath: "/test-cm"
  52.           cmName: "my-cm"
  53.           items:
  54.             - key: test-key
  55.               path: test-key
  57.   workflow:
  58.     steps:
  59.       - name: apply-pvc
  60.         type: apply-object
  61.         properties:
  62.           apiVersion: v1
  63.           kind: PersistentVolumeClaim
  64.           metadata:
  65.             name: my-claim
  66.             namespace: default
  67.           spec:
  68.             accessModes:
  69.             - ReadWriteOnce
  70.             resources:
  71.               requests:
  72.                 storage: 8Gi
  73.             storageClassName: standard
  74.       - name: apply-cm
  75.         type: apply-object
  76.         properties:
  77.           apiVersion: v1
  78.           kind: ConfigMap
  79.           metadata:
  80.             name: my-cm
  81.             namespace: default
  82.           data:
  83.             test-key: test-value
  84.       - name: apply-remaining
  85.         type: apply-remaining

查看集群中的 PVC 以及 ConfigMap：

  1. $ kubectl get pvc
  2. NAME       STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
  3. my-claim   Bound    pvc-2621d7d7-453c-41df-87fb-58e6b3a8e136   8Gi        RWO            standard       2m53s
  5. $ kubectl get cm
  6. NAME                                      DATA   AGE
  7. my-cm                                     1      3m8s

查看集群中应用的状态：

  1. $ vela ls
  2. APP                     COMPONENT       TYPE    TRAITS  PHASE   HEALTHY STATUS  CREATED-TIME
  3. server-with-pvc-and-cm  log-gen-worker  worker          running healthy         2021-10-11 20:42:38 +0800 CST
  4. └─                      log-read-worker worker          running                 2021-10-11 20:42:38 +0800 CST

检查第二个组件的日志输出：

  1. $ kubectl logs -f log-read-worker-774b58f565-ch8ch
  2. 0: Mon Oct 11 12:43:01 UTC 2021
  3. 1: Mon Oct 11 12:43:02 UTC 2021
  4. 2: Mon Oct 11 12:43:03 UTC 2021
  5. 3: Mon Oct 11 12:43:04 UTC 2021
  6. 4: Mon Oct 11 12:43:05 UTC 2021
  7. 5: Mon Oct 11 12:43:06 UTC 2021
  8. 6: Mon Oct 11 12:43:07 UTC 2021
  9. 7: Mon Oct 11 12:43:08 UTC 2021

可以看到，应用中的两个组件均已正常运行。同时，这两个组件共享同一个 PVC，并使用相同的 ConfigMap 进行配置。

如何销毁环境

因为我们已经通过应用（Application）这个统一的模型做了环境初始化，所以销毁环境变得非常简单，只需要删除这个应用即可。

  1. vela delete server-with-pvc-and-cm

KubeVela 控制器会自动将资源删除。