1. 介绍
  2. 应用创建流程
  3. 创建Git应用
  4. 创建应用表单说明
    1. 源码与开发信息
    2. 应用模板与高级配置
    3. Webhook 与仓库初始化
      1. 阿里云 Codeup
    4. 从 Git 导入应用 (/import)
  5. Pipelines as Code介绍
    1. 主要特点
  6. Pipelines-as-Code核心组件
  7. Pipelines-as-Code工作流程
  8. KDO自动创建的应用文件
  9. 应用管理
    1. 管理分支流水线
    2. 发布历史与回滚
    3. 管理流水线运行

介绍

应用是满足用户某些需求的程序代码的集合，可以是某个解耦的微服务或是某个单体应用，所有功能都会围绕应用服务进行。

在KDO平台里面，标准的应用是指基于Pipelines as Code方式创建的应用。 通过Pipelines as Code的方法，KDO对接 Git 代码仓库，直接从源代码仓库创建应用组件。 目前 KDO 支持和GitHub、GitLab、Gitee、Gitea、阿里云 Codeup 这五种 Git 仓库进行对接。

只需Git URL和用户的Git Token就可以自动生成支持多环境和多分支的流水线，流水线支持自动构建与自动部署，功能非常强大。 pipeline.png

Pipelines as Code详情

应用创建流程 

flowchart TD
    A[填写 Git 仓库地址与访问 Token] --> B[级联选择开发语言 版本与模板]
    B --> C[设置应用端口与命名空间]
    C --> D[配置分支与环境映射]
    D --> E[配置 Webhook 与流水线来源]
    E --> F[点击添加]
    F --> G[生成 devfile.yaml]
    G --> H[生成 docker/Dockerfile]
    H --> I[生成 kubernetes 部署清单]
    I --> J[按环境生成 .tekton 流水线定义]
    J --> K[挂载 Webhook 到代码仓库]
    K --> L[推送或 PR 触发 PipelineRun]
    L --> M[构建镜像并部署到目标环境]
    M --> N[状态回报到 Git 提供商]

创建Git应用

  • KDO支持多环境多分支的应用管理，在应用项目选择对应的项目，选择应用管理 -> 应用
  • KDO创建应用主要需要两个信息: 应用的Git地址、访问Git仓库的Token, 其他信息根据应用进行选择，包括： 开发语言、应用模板、应用端口等。
  • 应用基本参数设置好后，就可以开始设置自动分支流水线，不同环境选对应的分支，最后点击添加，这个支持多环境自动化流水线的应用就创建完成了。

创建应用

如何创建Java应用

如何创建Python应用

如何创建Golang应用

如何创建NodeJS应用

如何创建PHP应用

创建应用表单说明

在 应用管理 → 应用 点击 新建应用 打开创建表单，主要分区说明如下。

源码与开发信息

  • Git 提供商 / Git 仓库地址 / 访问 Token：用于对接 GitHub、GitLab、Gitee、Gitea、阿里云 Codeup 等代码仓库。
  • 开发信息（开发语言 / 开发版本 / 开发模板）：三个下拉级联选择。
    • 开发语言下拉只列出 kubedo 命名空间中已经可用的语言。
    • 选择语言后，开发版本只显示该语言可用的版本；开发模板只显示该语言+版本可用的框架模板。
    • 切换开发语言/版本/模板时会弹出确认框；确认并保存、重新初始化后，平台会自动重建生成的文件（devfile.yaml、docker/Dockerfile、kubernetes/deploy-*.yaml）。

应用模板与高级配置

  • 应用模板（Application Template）：默认自动选中第一个可用模板。
  • Secure Route：默认不勾选（默认创建非安全的路由）；如需通过 HTTPS 访问，请手动勾选。
  • Webhook 配置：默认折叠，展开后可查看并复制 Webhook URL 与 Webhook Secret；新建时会自动生成 Secret，也可以点击 Generate 重新生成。
  • Pipeline Source（流水线来源）：可选择 事件分支（event branch） 或 默认分支（default branch），对应仓库的 spec.settings.pipelinerun_provenance 设置；选择默认分支时，流水线定义文件的读写都走仓库的默认分支。

Webhook 与仓库初始化

  • Webhook 支持 GitHub、GitLab、Gitee、Bitbucket、阿里云 Codeup 等提供商，控制台会根据所选提供商展示对应的 Token 权限与触发事件说明。
  • 仓库初始化与 Webhook 挂载已经解耦：Webhook 创建/挂载失败不会阻断源码仓库的初始化，可以稍后再补齐 Webhook。

阿里云 Codeup

  • 无需单独选择提供商：填写 codeup.aliyun.com 的仓库地址后，控制台会自动识别为 Codeup。
  • 访问 Token 需要使用 Codeup 个人访问令牌，并具备仓库读写权限与 Webhook 管理权限；建议设置 30 天过期并定期轮换。
  • Codeup 不允许浏览器直接调用其 Webhook 接口，因此 Webhook 由 Console 后端代理由创建（/api/dev-console/webhooks/codeup），不需要在 Codeup 控制台手工配置。
  • 支持的事件包括推送、Tag 推送、合并请求与评论事件；表单中可直接查看事件说明。

从 Git 导入应用 (/import)

在 开发者界面 → +添加 → 从 Git 导入（/import）页面：

  • 填写 Git 仓库地址后，会自动填充 Name、应用名、端口/Hostname 等信息：
    • Name 由仓库地址推导（去除末尾的 / 与 .git 后缀，兼容 HTTPS 与 SSH 形式）；组件 Name 与应用名保持一致（不再追加 -app 后缀）。
    • Hostname 按 <namespace>-<name>.<默认域名> 规则自动生成。
  • 自动填充只写入空字段或仍是上次自动填充值的字段，不会覆盖手动输入；编辑模式下不会自动填充。

Pipelines as Code介绍

Pipelines as Code 是一种实践方法，它将CI/CD（持续集成/持续部署）流水线的定义与源代码一同存储在版本控制系统中，如GitHub或GitLab。 这种方法使用Tekton PipelineRuns和Tasks来定义具体的CI/CD流程，并将其保存在一个文件里，该文件位于项目的源代码管理(SCM)系统中。

basic-devops.jpg

主要特点

  1. 集中化定义： 通过在一个文件中定义CI/CD流程，使得整个团队可以更容易地理解和修改这些流程。
  2. 版本控制： 因为流水线定义是作为代码存储的，所以它可以像其他任何代码一样被版本化、审查和协作处理。
  3. 自动化创建： 这个文件能够自动为Pull Request或者分支推送创建相应的CI/CD流水线。
  4. 状态查看与执行控制： 可以直接从SCM查看流水线的状态并控制其执行，而不需要切换到不同的系统进行操作。
  5. 增强协作： 开发人员可以在同一个平台上同时处理应用程序代码和流水线定义，提高了工作效率。
  6. 变更追踪： 每一次对流水线定义的更改都可以被记录下来，方便追踪和审核。

Pipelines-as-Code核心组件

KDO Pipelines-as-Code的架构主要由以下组件构成：

pipeline-as-code.png

  1. Tekton Pipelines： Tekton Pipelines 是 KDO Pipelines-as-Code 的核心引擎，负责执行流水线任务。

  2. Pipelines-as-Code Controller: 这是 KDO Pipelines-as-Code 的核心组件，负责将代码仓库中的流水线定义(如 .tekton/目录下的YAML文件)转换为Tekton资源。 它监听代码仓库的事件（如 Pull Request 或 Push），并根据事件触发流水线。

  3. Git Provider 集成： Pipelines-as-Code 支持与多种 Git 提供程序集成，例如 GitHub、GitLab、Bitbucket等。 它通过 Webhook 监听代码仓库的事件，并将事件传递给 Pipelines-as-Code Controller。

  4. Kubernetes 集成： Pipelines-as-Code 与 Kubernetes 深度集成，利用 Kubernetes 的 RBAC、命名空间、资源配额等特性。 流水线运行在 Kubernetes 的 Pod 中，使用 Kubernetes 的容器运行时和存储。

Pipelines-as-Code工作流程

以下是 KDO Pipelines-as-Code 的典型工作流程：

pipeline-architecture.png

  1. 代码推送(Push)或 Pull Request： 开发者向代码仓库推送更改(Push)或创建 Pull Request。 Git 提供程序（如 GitHub）通过 Webhook 将事件发送到 Pipelines-as-Code Controller。 当然也可以手动点击触发流水线。

  2. 流水线定义解析： Pipelines-as-Code Controller 从代码仓库中读取流水线定义文件(如 .tekton/pipeline.yaml、kubernetes/deployment.yaml、docker/Dockerfile 等)。 这些文件定义了流水线的分支、任务、步骤和参数，部署的集群和环境等信息。

  3. 流水线触发： Pipelines-as-Code Controller 将流水线定义转换为 Tekton 资源（如 PipelineRun 和 TaskRun）。Tekton Controller接收到这些资源后，开始在 Kubernetes 集群中调度和执行任务。

  4. 任务执行： Tekton 在 Kubernetes 集群中创建 容器组(Pod) 来执行流水线任务。 每个任务可以包含多个步骤，每个步骤运行在一个容器中。

  5. 结果反馈： 流水线执行完成后，Pipelines-as-Code将结果（如成功或失败）反馈到代码仓库。例如，在 GitHub 中，结果会显示在Pull Request的检查状态中。

以下是 KDO Pipelines-as-Code 的简化架构图：

+-------------------+       +-------------------+       +-------------------+
|                   |       |                   |       |                   |
|   Git Provider    |       | Kubernetes Cluster|       | Pipelines-as-Code |
|  (GitHub/GitLab   |<----->|   (Tekton Engine) |<----->|     Controller    |
|   Gitee/Gitea)    |       |                   |       |                   |
+-------------------+       +-------------------+       +-------------------+
|                           |                           |
| Webhook Events            | Pipeline Runs             | Pipeline Definitions
v                           v                           v
+-------------------+       +-------------------+       +-------------------+
| Code Repository   |       |                   |       |                   |
| (.tekton/*.yaml   |       |   Task Pods       |       |   Tekton CRDs     |
| kubernetes/*.yaml  |       | (Kubernetes Pods) |       |  (PipelineRun,    |
| docker/Dockerfile)|       |                   |       |   Task, etc.)     | 
+-------------------+       +-------------------+       +-------------------+

KDO自动创建的应用文件

KDO Pipelines-as-Code相关的文件都是存储在应用的代码仓库，其中包括应用定义文件、流水线定义文件、应用镜像配置文件、部署配置文件等。这些文件都通过KDO Controller根据模板自动创建的。

  1. 应用定义文件： 在应用Git仓库主分支(比如master/main)的根目录下，有一个应用定义文件devfile.yaml。它定义了应用名、开发语言等信息，以及其他应用参数。

  2. 流水线定义文件： 在应用Git仓库主分支(比如master/main)的.tekton/目录下，是流水线定义的核心文件，它定义了流水线的分支、任务、步骤和参数。 每个环境分支的流水线对应一个yaml文件，命名是应用名-部署环境-部署分支，比如：spring-boot-scheduler-dev-develop.yaml表示应用名为spring-boot-scheduler，部署环境为dev，部署分支为develop。 里面的内容就是一个嵌入流水线。关于嵌入流水线，可以参考嵌入流水线

  3. 应用镜像配置文件： 在应用Git仓库分支(比如develop/release)的docker/目录下，它定义了应用的镜像的参数，一般就是Dockerfile，可以根据需要进行修改

  4. 部署配置文件： 在应用Git仓库分支(比如develop/release)的kubernetes/目录下。 它定义了部署参数，一般就是无状态(Deployment)、有状态(StatefulSet)、 服务(Service)等这些资源对象。

应用管理

应用创建完成以后，如果需要对应用进行管理，选择应用管理 -> 应用，点击对应的应用，有四个菜单。

在 应用管理 → 应用 列表中，每一行还提供一个 Open in Che（访问云开发环境）图标入口，点击可直接在 Eclipse Che 中以该仓库地址打开云开发环境。

菜单 说明
详情 应用详情页面提供了全面的信息概览，包括应用的URL、开发语言、端口号等关键细节。
分支流水线 管理分支流水线功能允许您对应用在不同环境中的流水线进行精细化管理。
流水线运行 查看和管理流水线运行，包括运行过的流水线，可以选对应的进行流水线的回滚。
YAML 这个应用的YAML定义文件，一些不能在图形化编辑的功能，可以在这里编辑。

应用信息

管理分支流水线

在分支流水线菜单，我们可以对对应分支的流水线进行管理，包括新增分支流水线、编辑流水线、手动运行流水线(必须先禁用自动触发)等。 无论是开发、测试还是生产环境，您都可以针对各个分支配置和调整相应的流水线，以满足特定环境下的需求。 流水线的编辑支持图形化和YAML文件方式，请参考嵌入流水线。

管理分支流水线

发布历史与回滚

在 分支流水线 页面打开某个分支/环境的 发布历史（Release history） 抽屉，可以查看该环境下所有已部署的镜像版本，并回滚到任意历史版本。

抽屉标题格式为 Release history: <分支> → <环境>，包含两个标签页：

标签页 说明
构建历史 按清单提交展示历史版本，含镜像 Tag、提交信息、时间、构建/部署状态
手动指定 手动输入要回滚的 Image tag

构建历史的每一行包含：

  • Image tag：部署使用的镜像版本；
  • Commit：触发本次构建的源码提交标题，副行显示源码提交与写回提交的短 SHA；
  • Time：构建/部署时间；
  • Status：构建或部署状态；
  • Current：当前正在使用的版本会带 Current 标记；
  • 构建成功/失败、部署成功/失败等状态标签。

回滚步骤：

  1. 在构建历史中选择目标版本，或切换到 手动指定 输入 Image tag；
  2. 点击回滚，确认弹窗显示 Roll back to <tag>?；
  3. 确认后，平台会提交清单变更并自动触发部署流水线；
  4. 页面提示 Rollback committed and the deploy pipeline was triggered.。
  • 发布历史通过清单提交记录版本，因此可以看到源码提交与写回提交的对应关系（Kubedo-Source-Commit / Kubedo-Source-Title trailer）。
  • 如果当前 Git 提供商不支持回滚所需的写回能力，页面会给出提示，此时可以手动更新镜像 Tag 或 YAML。
  • 回滚只会改变目标环境的镜像版本，不会修改其他环境。

管理流水线运行

在流水线运行菜单中，您可以查看所有已执行的流水线详情，包括每个流水线的耗时、日志记录以及所使用的参数等信息。 您可以按需查看和筛选流水线运行记录，以便更好地了解流水线的执行情况，并进行相应的操作，如回滚、重新运行等。

管理流水线运行