您现在的位置是:主页 > 数据库技术 > 数据库技术

从源代码到服务的自动化部署Knative实践如何理解

IDCBT2022-01-11服务器技术人已围观

简介本篇文章为大家展示了从源代码到服务的自动化部署Knative实践如何理解,内容简明扼要并且容易理解,绝对能使你眼前一亮,通过这篇文章的详细介绍希望你能有所收获。 通过之前的文

本篇文章为大家展示了从源代码到服务的自动化部署Knative实践如何理解,内容简明扼要并且容易理解,绝对能使你眼前一亮,通过这篇文章的详细介绍希望你能有所收获。

通过之前的文章,相信大家已经熟悉了 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": "closed",
        	... ...
        	"merge_commit_sha": "f37cb28b1777a28cd34ea1f8df1b7ebcc6c16397",
        	... ...
        	"base": {
        	  "ref": "master",
        	  ... ...
        	  },
        	... ...
        }

          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。

            标签:

            很赞哦! ()

本栏推荐