KubeVela篇08:一个组件的输出作为另一个组件的输入案例及传递原理

原创 吴就业 121 0 2023-07-23

本文为博主原创文章,未经博主允许不得转载。

本文链接:https://wujiuye.com/article/760bb54799cd47ba9d69bb7c5590f8a6

作者:吴就业
链接:https://wujiuye.com/article/760bb54799cd47ba9d69bb7c5590f8a6
来源:吴就业的网络日记
本文为博主原创文章,未经博主允许不得转载。

云原生企业级实战笔记专栏

kubevela安装一个Application的过程,就是执行工作流上的每个步骤的过程,并且当我们未配置工作流,kubevela会自动为组件的部署生成一个工作流步骤。

而当我们配置工作流后,组件的部署就需要我们编排,kubevela不会再为组件的部署生成任何工作流步骤。

工作流的编排可以指定步骤的依赖关系,哪个步骤依赖哪个步骤,被依赖的步骤先执行。

工作流可以插入人工卡点,也可以插入一个read-object的工作流步骤,来衔接前后两个工作流,实现数据的传递。

举例:假设把zookeeper当成云服务申请,由mycloud terraform provider插件提供mycloud-zookeeper组件。部署推送网关(内部自研网关)需要依赖zookeeper,那么可以这样编写application.yaml部署推送网关。

    apiVersion: core.oam.dev/v1beta1
    kind: Application
    metadata:
      name: push-gw-app
    spec:
      components:
        - name: xxx-zookeeper
          type: mycloud-zookeeper
          properties:
            business: xxx
            providerRef:
              name: mycloud-office-admin-provider
              namespace: default
            writeConnectionSecretToRef:
              name: push-gw-app-mycloud-zookeeper-output-secret  ## 尽可能唯一,避免覆盖其它app的zookeeper组件的输出
              namespace: default
        - name: push-gw
          type: helm
          properties: 
            repoType: helm
            url: https://charts.xxxx.com/middleware
            chart: push-gw-helm-chart
            version: "1.0.0"
            values:
              registry:
                address: ""
      workflow:
        steps:
          - name: zookeeper-deploy
            type: apply-component
            properties:
              component: xxx-zookeeper
          - name: read-zookeeper-output
            type: read-object
            dependsOn:
              - zookeeper-deploy
            outputs:
              - name: zkoutput
                valueFrom: output.value.data.address
            properties:
              apiVersion: v1
              kind: Secret
              name: push-gw-app-mycloud-zookeeper-output-secret
              cluster: local
          - name: push-gw-deploy # 部署中间件自身组件
            type: apply-component
            dependsOn:
              - read-zookeeper-output
            properties:
              component: push-gw
            inputs:
              - from: zkoutput
                parameterKey: values.registry.address

outputs[index]:

inputs[index]:

outputs很好理解,就是查询一个资源对象。

工作流步骤之间使用Context传递数据,利用工作流步骤提供的hook机制实现数据传递:

#云原生

声明:公众号、CSDN、掘金的曾用名:“Java艺术”,因此您可能看到一些早期的文章的图片有“Java艺术”的水印。

文章推荐

KubeVela篇11:可持续测试应用部署之Mock基础设施

我们基于KubeVela开发的云原生应用交付平台,提供如初始化基础设施导入、中间件部署共用基础设施等相关能力的测试,需要依赖基础设施。虽然terraform是面向公司内部的混合云平台,但是测试都要跨部门配置效率太低了,而且这种模式无法支持持续测试。

KubeVela篇10:KubeVela 私有云Terraform Provider Addon插件开发指南

如何Debug Terraform Controller;如何让Configuration可以指向私有仓库;为云资源编写ComponentDefinition;验证流程是否跑通。

KubeVela篇09:KubeVela工作流步骤CUE模版和Go代码是怎么关联的

terraformProvider、multiclusterProvider、oamProvider、configprovider、kube这些provider的Install方法注册了很多操作处理方法。这些方法就是提供给CUE中调用的方法。

KubeVela篇07:terraform controller实现原理

erraform-controller是一个专门负责terraform一类的组件"安装"的Operator,通过打包成helm,再封装成kubevela的Addon,由kubevela安装到管控集群,为其它terraform provider插件提供模块定义支持。

KubeVela篇06:Kubevela Addon插件安装原理

terraform插件的安装过程;terraform provider插件的安装过程。

KubeVela篇05:为kubevela开发terraform-mycloud Addon插件

通过前面的章节,我们已经学习了解terraform,并通过vpc资源例子,为私有云/混合云开发了terraform provider,这一节介绍如何将我们开发的mycloud terraform provider整合到kubevela控制平台上,以通过在application中声明一个kubevela组件的方式去申请基础设施资源。