新一代PaaS平台TanzuApplicationPlatform初探

VMware Tanzu 参考架构

TKGm 1.4 for vSphere 组件集成

VMware 现代化应用家族产品线是一个持续丰富和迭代的组合，随着 Tanzu Application Platform 的正式发布，使得 Tanzu 家族更加完善，通过 TAP 把Tanzu家族的产品进行整合、优化，推出新一代应用感知 PaaS 平台。

Tanzu Application Platform介绍

VMware Tanzu Application Platform ( 简称TAP ) 1.0 的在1月份正式GA，作为Tanzu 家族的新一代 PaaS 平台。TAP是一个模块化的应用感知平台，它提供了一组丰富的开发人员工具和一条预先配置好可装配的生产流水线，在任何认证公共云或本地的 Kubernetes 集群上更快速、更安全地构建和部署软件。

Kubernetes 作为容器编排技术标准平台，一直存在的问题是开发人员和运维人员之间泾渭分明的界限：即 Kubernetes 缺乏面向开发人员的应用平台。TAP 的出现弥补了这一鸿沟，TAP 实现了从提交代码到在 Kubernetes 生产中运行之间发生的所有事情。从 CI/CD 流水线到监控和扩展、生产部署都在 Kubernetes 上进行。这为平台带来了透明度、灵活性和模块化。

TAP完全基于成熟 Kubernetes 生态进行开发，以 Kubernetes 为核心，融合原有技术Spring Framework 及VMware 原有 PasS 平台 Tanzu Application Service 的应用感知能力，提供开发工具及流程，以加速开发应用及服务到公有云或本地部署经认证的 Kubernetes 集群上。

TAP 通过定义一个 workload 抽象与开发人员进行交互，开发人员只需要关注到 workload 这个层面，workload 之下交给 TAP 自动化完成，从而为在 Kubernetes 上构建和部署云原生应用程序的企业提供卓越的开发人员体验，是面向开发人员的应用平台，它使应用程序开发团队能够通过自动化流水线更快地投入生产，并且它清楚地定义了开发人员和、安全人员、运维人员的角色，以便他们可以协作工作。

借助TAP企业可以更快地将应用程序推向市场，因为开发人员可以将更多时间基于业务逻辑构建程序代码，而不是把精力放在开源组件拼装工作，同时TAP使企业能够构建更安全的业务程序代码，因为安全人员可以为供应链配置内置的安全性和合规性组件，使开发人员无需考虑这些因素，实现 DevSecOps 落地，从而实现应用程序从开发到生产的无缝切换。TAP 使这种切换变得无比流畅，因为它只需要开发人员提交他们的代码（例如，“git push”）。当开发人员提交代码时，安全的软件供应链流水线会自动触发，从而提供连续的生产路径。借助与环境相匹配的可扩展性和工具，TAP 得以帮助企业快速、持续地将业务代码投入生产。

TAP发布之前，VMware Tanzu 产品线的 PaaS 平台是 Tanzu Application Service（TAS），TAS 是基于久负盛名 Cloud Foundry 商业和产品实现。TAP 不是TAS的升级版本，但是 VMware 作为 Cloud Foundry 和Spring Boot开源者和社区主要贡献者，TAP 深受 Cloud Foundry 和 Spring Boot 构建应用程序平台、框架和工具的设计理念的影响，TAS 的 cf push 优秀体验也在 TAP 通过 git push完美的实现。

TAP 和 TAS 之间的主要区别在于目标环境：TAP 是为 Kubernetes 集群设计的，而TAS是为了运行虚拟机。虽然 TAS 也可以部署在 Kubernetes 上，但是VMware 将其定位为 VM 的 PaaS 层。另外，TAP使用Tanzu及kubectl指令行界面（CLI）工具，TAS 则使用 VMware Tanzu Operations Manager 及 Cloud Foundry CLI。针对计划迁移到 TAP 的 TAS 用户，VMware 也提供相应的迁移工具。

TAP核心组件介绍

TAP 包含多个现有的 Tanzu 功能，以及 VMware 的 Tanzu Labs 专业服务部门，为在此过程中需要一些咨询帮助的客户提供服务。下图为核心组件与服务架构图，接下来将分层介绍下TAP各个模块的功能。

从下往上进行介绍，最底层运行环境层，TAP需要一个Kubernetes运行环境，任何经过认证的公有云或者私有云Kubernetes；

运行环境层之上绿色部分是云原生运行时层，基于Cloud Native Runtimes实现的无服务器运行时，通过对底层基础架构运行环境的进行抽象，构成TAP的先进的无服务器运行时架构；

云原生运行时层之上紫色部分，是软件供应链层，实现代码从build到deploy全流程；

软件供应链层之上蓝色部分与灰色部分，开发者交互层，实现开发者与平台的交互，提供的一些开发组件，帮助提升开发者体验。灰色部分是API Portal，VMware Tanzu 的 API 门户使 API 使用者能够找到他们可以在自己的情况下使用的 API 应用程序，消费者可以查看详细的 API 文档并试用 API以查看它是否满足他们的需求。API 门户通过从源 URL 提取 OpenAPI 文档来组装其仪表板和详细的 API 文档视图。API 门户操作员可以添加任意数量的 OpenAPI 源 URL在单个实例中显示。

架构图左边黑色部分是服务工具包，可在TAP上轻松实现服务的上线、规划、消费和管理。

以上模块 TAP 基于成熟的 VMware 主力贡献开源产品以及开源生态构成，接下来详细介绍一下每层的功能以及组件构成，

第一部分，运行环境层

TAP是基于Kubernetes生态进行构建，所以TAP将支持任何标准的Kubernetes，当前经过验证的发型版本为：

- EKS （Elastic Kubernetes Service）

- AKS （Azure Kubernetes Service ）

- GKE （Google Kubernetes Engine）

- Minikube

Kubernetes 版本为v20, 21, 22 (N-2)

后续TKGm ，TKGs，TCE（VMware Tanzu Community Edition），TKGi，Kind，Openshift，Rancher都会进入支持列表。

备注：TKGm 1.5 即将发布，支持TAP。

第二部分，云原生运行时层

无服务器架构设计是TAP抽象基础架构的重要特点，所以会详细介绍。

云原生运行时层是基于VMware的基于Cloud Native Runtimes实现的Serverless（无服务器架构）运行时。

Serverless（无服务器架构）指的是由开发者实现的服务端逻辑运行在无状态的计算容器中它由事件触发，完全被第三方管理，其业务层面的状态则被开发者使用的数据库和存储资源所记录；

Serverless不代表不需要服务器，而是说开发者不用过多的考虑服务器问题，计算资源作为服务而非服务器的概念出现；

Serverless是一套构建和管理基于微服务架构的完整流程，允许开发者在服务级别而非服务器级别来管理应用部署，这会极大降低软件开发的复杂度，使得开发者可以快速迭代应用软件。

Serverless 是云原生技术发展的高级阶段，使开发者更聚焦在业务逻辑，而减少对基础架构的关注。

上图来自谷歌云平台官网，是对云计算的一个很好的分层概括，其中 serverless 就是构建在虚拟机和容器之上的一层，与应用本身的关系更加密切。

Serverless 包含 FaaS 和 BaaS 两种实现方式，FaaS（Functions as a Service）函数即服务，FaaS 是无服务器计算的一种实现形式，包含了一个标准化的运行时框架，用于构建和执行函数。BaaS 诸如云数据库、云缓存等。

当前各大云厂商和开源社区都推出自己的 Serverless 解决方案，但是由于缺乏统一标准，应用很难在不同 Serverless之间进行迁移，当前使用最广泛的 FaaS 是AWS的Lambada。Google Cloud Function、Aliyun Function Compute、VMware OpenFass 等。

厂商 Serverless 标准不统一，导致应用不能跨厂商迁移，客观造成厂商锁定，不符合云原生发展趋势。试图统一 Serverless 标准的 Knative 应运而生。Knative 开源于 2018 年 7 月 24 日，由 VMware/Pivotal、Google、IBM 等公司共同发起，从以 K 打头的名字上就可以看出来 Knative 是用以扩展 Kubernetes 的。

项目地址：https://github.com/knative

官方给 Knative 的定位是：基于 Kubernetes 的平台，用来构建、部署和管理现代 Serverless 工作负载。通过 Knative 可将云原生应用开发在三个领域的最佳实践结合起来——服务构建部署的自动化、服务编排的弹性化以及事件驱动基础设施的标准化。

VMware Cloud Native Runtimes 是开源方案 Knative 的商业化和产品化实现。

VMware 全力支持与参与Knative社区，在Knative 社区有强大领导力：

VMware是Knative的主要创始成员之一，并一直是主要的贡献者；

VMware 研发团队有专门的全职员工支持Knative；

Knative steering committee 的5名成员中的2位来自VMware ；

Knative technical oversight committee 的5名成员中的2位来自VMware；

Knative 2020 年度贡献报告如下：

Knative 架构包含以下两大组件：

Eventing：提供用来使用和生成符合 CloudEvents 规范的事件的构建块。它包括对来自事件源的信息流的抽象，以及通过由可插拔发布/订阅代理服务提供支持的消息传递通道实现交付解耦。

Serving：可缩放至零、请求驱动的计算运行环境，Serving 的目标是为 Kubernetes 提供扩展功能，用于部署和运行 Serverless 工作负载

Knative建立在Kubernetes生态基础之上，整合了Kubernetes 和 Istio 的能力，从云原生开源社区生态获益，Knative 作为一个云原生的 Serverless 框架，可以运行任何无状态的容器应用，意味着 Knative 可以通过容器整合各类 Faas 平台的运行时框架，实现兼容各类 Faas 平台已有的程序。VMware基于 Knative 的 Cloud Native Runtimes 成为TAP抽象、稳定、标准化运行时的基石。

第三部分，软件供应链层

软件供应链层的核心是通过Cartographer把各个功能组件进行编排实现开箱即用的软件供应链。

通过软件供应链层开发人员只需要通过抽象的workload，不需要写其他的yaml文件，就可以按照预定义流水线模版完成build和deploy全流程。

支持灵活的软件供应链编排，既可以开箱即用，并可以灵活定制和替换。TAP提供了三个开箱即用（Out of The Box ）OOTB 供应链来与 TAP组件一起使用，1.0 版本默认包括：

OOTB Basic (default)

OOTB Testing

OOTB Testing+Scanning

软件供应层详细的功能组件介绍如下：

供应链编排-Cartographer

TAP 采用Cartographer作为软件供应链的编排，实现开箱即用的软件供应链。

项目地址 https://github.com/vmware-tanzu/cartographer

Cartographer 是 VMware开源的Kubernetes 的供应链编排师。它允许应用平台通过将 Kubernetes 资源与其现有工具链（例如 Jenkins、Tekton）的元素集成来创建预先批准的生产路径。

每个预先批准的供应链都为生产铺平了道路；协调供应链资源 - 测试、构建、扫描和部署 - 让开发人员能够专注于为用户提供价值，同时也让应用平台高枕无忧，因为生产中的所有代码都已通过所有步骤批准的工作流程。

Cartographer 允许用户定义应用程序创建映像和 Kubernetes 配置必须经过的所有步骤。用户通过供应链抽象来实现这一点。供应链由通过模板指定的资源组成。每个模板都充当现有 Kubernetes 资源的包装器，并允许它们与 Cartographer 一起使用。目前有四种不同类型的模板可用于 Cartographer 供应链：源模板镜像模板配置模板通用模板

与市场上已经存在的许多其他Kubernetes原生工作流工具相反，Cartographer 本身并不“运行”任何对象。相反，在给定资源完成执行并更新其状态后，它会监控每个资源的执行并模板化供应链中的以下资源。

通过使用 Runnable CRD（它是 Cartographer 的一部分），还可以扩展供应链以包括与现有 CI/CD pipeline 的集成。Runnable CRD 充当不可变 CRD 的包装器（这意味着将创建一个新对象而不是更新对象）。有许多 CI/CD CRD 遵循这种模式，包括 Tekton。Runnable CRD 为在 Cartographer 中运行的管道提供了一种声明方式。

虽然供应链是面向运维人员的，但 Cartographer 还为开发人员提供了一种称为工作负载的抽象。工作负载允许开发人员创建应用程序规范，例如其存储库的位置、环境变量和服务声明。

根据设计，供应链可以被许多workload重用。这允许操作员一次性指定生产路径中的步骤，并且开发人员可以独立指定他们的应用程序，但每个应用程序都使用相同的生产路径。其目的是让开发人员能够专注于为用户提供价值，并且可以快速轻松地投入生产，同时让应用程序运营商高枕无忧，确保每个应用程序都通过了他们的生产路径的步骤。已经定义。

Cartographer基于微服务的理念，使用 Kubernetes API 本身来互连现有的 K8s-native CI/CD 工具，而不是依赖事件触发器和外部编排。为了解决规模问题，Cartographer 反转了传统 CI/CD 编排工具的控制流程。使用 Cartographer，开发人员可以将可移植的应用程序配置和测试定义带到一个平台，该平台决定需要应用哪些工具和策略。Cartographer 不是像 Jenkins 这样的多功能 CI/CD 工具，也不是像 Cloud Foundry 这样自以为是的应用程序平台，而是一种允许操作员设计自己的灵活应用程序平台的工具，该平台不仅可以扩展 Kubernetes，而且还包含其声明性模型。

Kubernetes生态系统中有许多组件是专门为解决特定问题而构建的。Cartographer 旨在将这些单独的系统连接在一起，为您的所有工作负载创建生产路径。

GitOps-Flux

TAP 通过fluxcd监控github的变化，触发GitOps流水线

项目地址：https://github.com/fluxcd

Flux 是一组可支持实现 GitOps 的工具，用于使 Kubernetes 集群与配置源（如 Git 仓库）保持同步，并在有代码更新后自动同步配置，面向 Kuber netes 的持续渐进式交付解决方案。

流水线-Tekton

TAP 在 OOTB Testing 、OOTB Testing+Scanning 软件供应链中使用 Tekton Pipelines 进行测试和安全扫描，创建新镜像，应用预定义的 converntions，应用程序部署到集群

Tekton 是一款功能非常强大而灵活的 CI/CD 开源的云原生框架。Tekton 的前身是 Knative 项目的 build-pipeline 项目，这个项目是为了给 build 模块增加 pipeline 的功能，但是随着不同的功能加入到 Knative build 模块中，build 模块越来越变得像一个通用的 CI/CD 系统，于是，索性将 build-pipeline 剥离出 Knative，就变成了现在的 Tekton，而 Tekton 也从此致力于提供全功能、标准化的云原生 CI/CD 解决方案。

Tekton Pipelines 是 Tekton 的基础，它定义了一组 Kubernetes CRD 作为构建块，我们可以使用这些对象来组装 CI/CD 流水线。

项目地址：

安全扫描-Anchore Grype

TAP软件供应链安全工具 (SCST)：这是 TAP 安全工具插件的名称，包括签名、扫描和存储组件。SCST 是首字母缩写词。

SCST --Sign：这是一个 TAP 组件，允许客户创建一个策略来防止未签名的镜像部署在集群上。我们也将其称为签名验证 webhook。

SCST --Scan：这是一个 TAP 组件，允许客户使用 Kubernetes 控制器和 Anchore Grype 的扫描仪扫描源代码和镜像以查找 Tanzu 供应链中的漏洞。用户也可以使用此组件定义通过-失败扫描策略。

SCST --Store：这是一个TAP组件，用于存储来自SCST --Scan组件的物料清单元数据和CVE扫描结果，用户可以使用[Beta]insight CLI查询数据之间的关系，我们也称它为元数据存储.

Source Scanning 和 Image Scanning使用的是Anchore gyepe。

项目地址：https://github.com/anchore/grype

Grype是一款针对容器镜像和文件系统的漏洞扫描器。在该工具的帮助下，广大研究人员可以轻松完成针对容器镜像和文件系统的漏洞扫描和安全审计任务。

功能特性

扫描一个容器镜像或文件系统中的内容，尝试寻找其中存在的已知的安全漏洞；

支持对主流操作系统包进行安全漏洞扫描：

AlpineBusyBoxCentOS / Red HatDebianUbuntu

支持对特定语言的软件包进行漏洞扫描：

Ruby (Bundler)Java (JARs等)JavaScript (NPM/Yarn)Python (Egg/Wheel)Python pip/requirements.txt/setup.py支持Docker和OCI镜像格式

源代码构建-Tanzu Build Service

TAP使用Tanzu Build Service使用云原生构建包直接从源代码自动创建容器镜像。Tanzu Build Service 是Cloud Native Buildpacks (CNB)的企业版。

Cloud Native Buildpacks(简称, CNB) , 是2018年VMware/Pivotal 和 Heroku 发起了一个项目，并在同年十月份加入 CNCF。这个项目的目标就是实现一个统一的应用打包生态系统。

项目地址：https://buildpacks.io/

Cloud Native Buildpack功能：

快速可重复的构建，实现代码到镜像的打包镜像格式符合OCI标准高度模块化的插件式设计可以基于本地环境运行以方便排错非特权模式的容器基于CNCF社区的开源项目

Tanzu Build Service增强功能：

镜像交付 – 无需重新构建

比传统方式更加智能的镜像交付方式

开发人员可以使用BuildService实现跨PCF Foundation的镜像交付

镜像自动更新

配置简单

始终保持全环境一致的镜像更新维护

运维效率提升

可控的Buildpack访问和服务获取

可以按照不同用户实现不同的BuildService配置

惯例服务-Convention Service

TAP使用Convention Service 为运维人员提供了一种方法来体现最佳实践惯例，即应用程序应如何在 Kubernetes 上运行作为惯例。Convention Service 将这些意见应用于部署到平台上的大量开发人员工作负载，从而节省了运维人员和开发者时间。

该服务由两个组件组成：

Convention Service 控制器：Convention Service 控制器向 Convention 服务器提供元数据，并根据约定服务器的请求执行更新 Pod 模板规范。

Convention Service 服务器：Convention Service服务器接收和评估与工作负载关联的元数据，并请求更新与该工作负载关联的 Pod 模板规范。您可以为单个Convention控制器实例拥有一个或多个约定服务器。约定服务当前支持定义和应用 Pod 的约定。

Convention Controller 作为 TAP的一部分安装。当部署到 TAP 的工作负载通过供应链进行时调用 Convention Service，该供应链包括 Convention Service 作为其步骤之一（例如 OOTB 供应链）。

应用部署-CARVEL

TAP在应用交付使用的是CARVEL套件中kapp-controller来完成。

项目地址：https://carvel.dev/

Carvel 项目是由 VMware 开源的一套云原生开发工具集，提供了一套遵循 Unix 哲学的工具来帮助开发者将应用构建和部署到 Kubernetes 集群。每个工具只做一件事情，可自由组合，这些工具包括：

ytt：通过YAML结构而不是文本文档为Kubernetes配置生成模板和覆盖

kapp：将多个Kubernetes资源当做一个“应用”一样进行管理，比如安装、升级和删除等操作

kbld：以不可变的方式在 Kubernetes 配置中构建或引用容器镜像

imgpkg：通过 Docker 镜像仓库来打包和迁移应用程序的容器镜像及其配置文件

vendir：声明性地说明目录中应该包含哪些文件

Kapp-controller 是 Carvel OSS 工具包的一部分，它通过 Kubernetes 集群用户可用的一小部分 CR 提供包管理和持续部署能力。符合 GitOps 理念的包管理器，实现 K8s 应用程序与包的持续交付

App CR – 提供一种统一的方式来定义要获取、模板化和部署到集群的内容，由 kapp 部署 CLI 功能提供支持，提供一种混合和匹配各种工具的方法，如 git、imgpkg、ytt、helm 模板、kapp、kbld。

Package / PackageMetadata / PackageInstall / PackageRepository CR

又名包管理 API，提供元数据 API 来描述正在分发的软件，按名称 + 版本定义单个软件（例如 tap.tanzu.vmware.com 0.3.0），提供安装 API 以指示应在集群上安装某些软件PackageInstall CR – 定义集群上应该存在的特定软件

‍

第四部分，开发者交互层

开发者交互层是开发者通过API、GUI、CLI、IDE 实现开发者与平台的交互，帮助提升开发者体验。

App Accelerator

开发人员进行项目开发时，需要先创建项目。通常，可以通过手动、或者IDEA、Eclipse等开发工具创建项目。如果采用 maven 来构建项目，则需要自己手动去创建目录结构（当然，IDEA、Eclipse工具也可以完成），也需要自己去编写 pom 文件。Spring Boot 项目需要添加一些依赖，这些依赖开发人员并不知道，总的说来比较麻烦。Spring Boot 提供了 Spring Initializr 工具，可以让开发快速创建项目。

Spring Initializr从本质上来说就是一个Web应用程序，它能为你生成Spring Boot项目结构。虽然不能生成应用程序代码，但它能为你提供一个基本的项目结构，以及一个用于构建代码的Maven或Gradle构建说明文件。开发人员只需要写应用程序的代码就好了。

App Accelerator 设计思想来源于Spring Initializr ，App Accelerator 是TAP一个组件，它基于通过开发人员提供的选项值定制的加速器模板项目（在 Git中提供）生成最终用户项目（以 zip 形式），这些交互可以通过 TAP GUI Backstage 插件或 Tanzu CLI 扩展来完成。App Accelerator比Spring Initializr更多支持更多的开发语言，不仅支持java，也支持nodejs、C#等。

企业可以按照自己的技术标准定制/扩展App Accelerator，架构师定义代码和配置框架、标准、类等、流水线等；开发人员直接选择定制好的App Accelerator，创建项目，开发业务代码。

项目地址 https://github.com/sample-accelerators

API Portal

API 门户基本上用作 API 生产者（API 创建者）和 API 使用者（通常是开发人员社区）之间的桥梁。API 门户允许 API 消费者注册使用您的 API，并在其整个生命周期中获取有关这些 API 的所有必需信息，包括指导开发人员如何集成 API、围绕 API 进行教育、授予或提供用户访问权限、生成客户端密钥以及其他。成功的 API 门户将授予开发人员访问加载生产数据的沙箱环境的权限，以便开发人员可以轻松地测试API。由于大多数开发人员更喜欢测试 API，因此良好的API 门户将提供该服务并使其易于访问。

API 门户拥有开发人员可能需要的有关 API 的所有信息，包括文档、规格、安全性、API 设计的完整透明度。它可以包括有关实施 API 的业务优势的更多信息，甚至可能是成功使用 API 的一些示例。事实上，我们鼓励这些措施以增加开发人员使用该 API 的可能性。API 门户还应包括任何已知问题、解决问题的时间以及如何寻求帮助。

TAP API 门户使 API 使用者能够找到他们可以在自己的应用程序中使用的 API。

API使用者可以查看详细的 API 文档并使用 API 以查看它是否满足他们的需求。API 门户通过从源 URL 提取 OpenAPI 文档来组装其仪表板和详细的 API 文档视图。API 门户操作员可以添加任意数量的 OpenAPI 源 URL在单个实例中显示。

API 门户有助于发现、管理和发布 API。

Workload Visibility

‍

Workload visibility 又名Runtime Resources Visibility 可观测性向开发人员显示其组件的 Kubernetes 资源的详细信息和状态，以了解其结构和调试问题。

App Live View

Application Live View 是一个轻量级洞察和故障排除工具，可帮助应用开发人员和运维人员查看内部运行的应用状态。

Application LiveView 以 Spring BootActuator 概念为基础。

其基本含义是，应用通过端点（在本例中是 HTTP 端点）从正在运行的进程内部提供信息。Spring Boot Observer使用这些端点从应用内部获取数据并与应用交互。

向运行在Kubernetes 集群上的 Application Live View 注册应用时有两种部署模式：

Connector：负责发现运行在 k8s 集群上的多个应用的组件

Sidecar：与运行在 k8s 集群上的单个应用（在同一个 Pod 中）一起启动的代理组件

IDE Plugins& Dev Tooling

Visual Studio Code（简称VS Code）是一款由微软开发且跨平台的免费源代码编辑器。该软件支持语法高亮、代码自动补全（又称IntelliSense）、代码重构功能，并且内置了命令行工具和Git 版本控制系统。

Tanzu DeveloperTools for Visual Studio Code 是 VSCode 的官方 VMware Tanzu IDE 扩展，可帮助使用 Tanzu 应用程序平台开发代码。VSCode 扩展支持在集群上运行时实时更新应用程序，并允许直接在集群上调试应用程序集群。

Kubernetes 用于生产，Tilt 用于开发。现代应用程序由太多的服务组成。它们无处不在，并且在不断的交流中。

Tilt 支持微服务开发并确保它们正常运行！运行tilt up 以在为您的团队配置的完整开发环境中工作。Tilt 自动化了从代码更改到新流程的所有步骤：查看文件、构建容器映像以及使您的环境保持最新。可以用来实现App Live update应用程序实时更新，快速开发

https://github.com/tilt-dev/tilt

Tanzu CLI Plugins

此 Tanzu CLI 插件能够在安装了 Tanzu 应用程序平台组件的任何 Kubernetes 集群上创建、查看、更新和删除应用程序工作负载。

TAP GUI

TAP GUI 让开发人员可以查看组织正在运行的应用程序和服务。它提供了一个用于查看依赖关系、关系、技术文档甚至服务状态的中心位置。TAP GUI 是从云原生计算基金会的项目 Backstage 构建的。

项目地址：https://github.com/backstage/backstage

Backstage 是一个用于构建开发人员门户的开放平台。由集中式软件目录提供支持，Backstage可以恢复微服务和基础设施的秩序，并使您的产品团队能够快速交付高质量的代码 - 而不会影响自主权。

Backstage 统一了您的所有基础架构工具、服务和文档，以创建端到端的简化开发环境。开箱即用，Backstage包括：

用于管理所有软件（微服务、库、数据管道、网站、ML 模型等）的后台软件目录；

后台软件模板，用于快速启动新项目并使用组织的最佳实践标准化您的工具；

后台 TechDocs，使用“类似代码的文档”方法，可以轻松创建、维护、查找和使用技术文档。

此外，不断发展的开源插件生态系统进一步扩展了 Backstage 的可定制性和功能。

Backstage由 Spotify 创建，但现在由云原生计算基金会 (CNCF) 作为沙盒级项目托管。

服务工具包

Services Toolkit可在TAP上轻松启动、管理、消费和管理服务，可以与 VMware Appliacation Catalog by Bitnami 结合构建服务市场。

Services Toolkit 提供了CRD（自定义资源定义），客户可以将其应用于Kubernetes群集来管理随时可用的服务。

项目地址 https://github.com/servicebinding/spec

Service BindingSpecification for Kubernetes旨在标准化应用程序如何访问服务的 OSS 规范由 VMware / IBM / Redhat 提供兼容的 VMware 服务，将包含服务凭证的 Secret 挂载到应用程序的容器中通过 Spring Cloud Binding 在应用程序中启用库的自动配置。

在Tanzu应用程序平台的上下文中，最重要的用例之一是将应用程序工作负载绑定到支持服务，如PostgreSQL数据库或RabbitMQ队列。这确保了在开发生命周期中使用支持服务的最佳用户体验。

TAP DevSecOps实现

TAP把以上的核心组件的精心设计与编排，通过面向开发人员的内循环与面向运维、安全人员的外循环，实现DevSecOps的真正落地与实践。

要想了解云原生、机器学习和区块链等技术原理，请立即长按以下二维码，关注本亨利笔记（ henglibiji )，以免错过更新。