通过之前的文章，相信大家已经熟悉了 Serving、Eventing 以及 Tekton。那么在实际使用中，我们往往会遇到一些复杂的场景，这时候就需要各个组件之间进行协作处理。例如我们提交源代码之后是否直接可以部署服务到 K8s 中？ 这个场景对于用户来说很有吸引力。那么现在就让我们来看一下，在 Knative 中如何实现从代码到服务？

场景介绍

现在的场景是这样的：代码构建->事件驱动->服务部署。那么对应到 Knative 中，需要 Eventing、Tekton 和 Serving 一起协作来实现这个场景。

准备

• 部署 Knative。参考在阿里云容器服务上部署 Knative；
• 部署 Tekton。通过阿里云容器服务控制台，应用目录选择 ack-tekton-pipelines 进行安装部署 Tekton；

• 部署 GitHub 事件源。阿里云容器服务控制台 Knative 组件管理中选择安装 GitHub 组件，如图所示：

从源代码到服务

• 修改分支代码，提交 merge request 合并到 master 分支；
• Eventing 监听到 merge 事件，发送给 GitHub Trigger 服务；
• GitHub Trigger 服务接收事件, 通过 Tekton 执行代码构建和并通过 deployer 执行服务部署。GitHub Trigger 的作用就是解析 GitHub 事件的详细信息，然后转换成 Tekton 资源并且提交到 Kubernetes 中执行 Pipeline。项目地址：https://github.com/knative-sample/tekton-serving。 这个项目中有两个部分： Trigger 和 Deployer，Trigger 的作用是解析 github 事件， 并提交 PipelineRun 定义。Deployer 的作用就是更新 Service 的镜像信息。github source pull_request body 的关键内容如下：

• action 表示当前的 pull request 事件细节。创建 pull request 时 action 是 opened ，关闭 pull request 时 action 就是 closed；
• merge_commit_sha 可以获得 merge commit 的 id；
• base.ref 可以获得 merge request 发生在哪个分支上。

本文涉及到的代码与资源文件地址：

• GitHubTrigger 和 Deployer：https://github.com/knative-sample/tekton-serving
• 部署示例文件：https://github.com/knative-sample/eventing-tekton-serving

接下来我们开始一步步搞起。

部署 Tekton 服务

我们看一下创建代码构建 Task 和 部署服务Task。

代码构建Task：

这里通过 deployer-deployer 执行服务部署，部署服务Task：

另外需要设置一下镜像仓库的 secret:

执行如下命令：

部署 Knative Serving 服务

先创建 deployer-github-trigger 服务，用于接收 GitHub 事件，并触发 Tekton Pipeline 构建任务。其中 service.yaml 如下：

这里通过 ConfigMap deployer-trigger-config， 设置 PipelineRun。deployer-github-trigger 能根据 github Event 信息获取代码仓库的最新信息但不能自动决定 PipelineRun 的定义，所以需要指定一个 PipelineRun 的模板。Trigger 通过 --trigger-config 参数指定 PipelineRun 的模板, 模板内容如下：

执行命令如下：

配置 Eventing 中 GitHub 事件源

代码 merge request 会触发对应的事件，通过 Knative Eventing 获取到事件之后直接将事件发送给 deployer-github-trigger 服务。

创建 GitHub Token

创建 Personal access tokens, 用于访问 GitHub API。另外你的代码将使用它验证来自 github 的传入 webhook（secret token）。token 的名称可以任意设置。Source 需要开启 repo:public_repo 和 admin:repo_hook , 以便通过公共仓库触发 Event 事件，并为这些公共仓库创建 webhooks 。

下面是设置一个 "GitHubSource Sample" token 的示例。

更新 githubsecret.yaml 内容。如果生成的是 personal_access_token_value token, 则需要设置 secretToken 如下：

执行命令使其生效：

创建 GitHub 事件源

为了接收 GitHub 产生的事件， 需要创建 GitHubSource 用于接收事件。

关键字段解释：

• 指定 github 仓库：ownerAndRepository: knative-sample/eventing-tekton-serving 表示监听 https://github.com/knative-sample/eventing-tekton-serving 仓库的事件；
• 事件类型：eventTypes 是一个数组，这个数组中可以配置 github 事件列表；
• 认证信息：accessToken 和 secretToken 是通过 secret 引用 github 仓库的认证信息；
• 目标 Service：sink 字段表示接收到的事件需要发送到哪个 Service , 这里是直接发送到前面定义的 deployer-github-trigger 服务。

执行 kubectl 命令：

如果集群中开启了 Istio 注入，需要开启 egress 访问：

deployer-github-sources 提交到 Kubernetes 之后，github source controller 会在 http://github.com/knative-sample/eventing-tekton-serving 下创建一个 webhook，回调地址就是我们的 github_receive_adapter 服务公网地址。

当 http://github.com/knative-sample/eventing-tekton-serving 有 pull request 发生时就会自动触发 deployer-github-trigger 的执行，deployer-github-trigger 首先编译镜像，然后更新 hello-sample service 镜像，从而完成自动化发布。

代码->镜像->服务

下面我们演示一下从代码到服务，自动化构建和部署过程：

服务访问体验地址：http://hello-sample.default.serverless.kuberun.com

结论

从代码到服务，通过上面的示例，Knative 是否给你带来了不一样的体验？希望通过 Knative 给你带来更轻松的代码构建和服务部署，让你更专注于业务本身。

----------------------------------

本文作者：一绿舟