写点什么

Knative 实践:从源代码到服务的自动化部署

  • 2019-08-21
  • 本文字数:4815 字

    阅读完需:约 16 分钟

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 发生在哪个分支上。


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



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

部署 Tekton 服务

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


代码构建 Task:


apiVersion: tekton.dev/v1alpha1kind: Taskmetadata:  name: source-to-imagespec:  inputs:    resources:      - name: git-source        type: git    params:      - name: pathToContext        description: The path to the build context, used by Kaniko - within the workspace        default: .      - name: pathToDockerFile        description: The path to the dockerfile to build (relative to the context)        default: Dockerfile      - name: imageUrl        description: Url of image repository      - name: imageTag        description: Tag to apply to the built image        default: "latest"  steps:    - name: build-and-push      image: registry.cn-hangzhou.aliyuncs.com/knative-sample/kaniko-project-executor:v0.10.0      command:        - /kaniko/executor      args:        - --dockerfile=${inputs.params.pathToDockerFile}        - --destination=${inputs.params.imageUrl}:${inputs.params.imageTag}        - --context=/workspace/git-source/${inputs.params.pathToContext}      env:      - name: DOCKER_CONFIG        value: /builder/home/.docker
复制代码


这里通过 deployer-deployer 执行服务部署,部署服务 Task:


apiVersion: tekton.dev/v1alpha1kind: Taskmetadata:  name: image-to-deployspec:  inputs:    resources:      - name: git-source        type: git    params:      - name: pathToYamlFile        description: The path to the yaml file to deploy within the git source      - name: imageUrl        description: Url of image repository      - name: imageTag        description: Tag of the images to be used.        default: "latest"  steps:    - name: deploy      image: "registry.cn-hangzhou.aliyuncs.com/knative-sample/deployer-deployer:7620096e"      args:        - "--namespace=default"        - "--serivce-name=hello-sample"        - "--image=${inputs.params.imageUrl}:${inputs.params.imageTag}"
复制代码


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


apiVersion: v1kind: Secretmetadata:  name: ack-cr-push-secret  annotations:    tekton.dev/docker-0: https://registry.cn-hangzhou.aliyuncs.comtype: kubernetes.io/basic-authstringData:  username: <cleartext non-encoded>  password: <cleartext non-encoded>
复制代码


执行如下命令:


# Create Pipelinekubectl apply -f tekton/pipeline/build-and-deploy-pipeline.yaml
# Create PipelineResourcekubectl apply -f tekton/resources/picalc-git.yaml
# Create image secretkubectl apply -f tekton/image-secret.yaml
# Create task: soruce to imagekubectl apply -f tekton/tasks/source-to-image.yaml
# Create task: deploy the image to clusterkubectl apply -f tekton/tasks/image-to-deployer.yaml
复制代码

部署 Knative Serving 服务

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


apiVersion: serving.knative.dev/v1alpha1kind: Servicemetadata:  name: deployer-github-triggerspec:  template:    spec:      containers:      - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/deployer-trigger:tekton-v1_74647e3a-20190806093544        args:          - --trigger-config=/app/config/deployer-trigger.yaml        volumeMounts:        - name: config-volume           mountPath: /app/config      serviceAccountName: tekton      volumes:        - name: config-volume           configMap:            name: deployer-trigger-config            items:              - key: deployer-trigger.yaml                path: deployer-trigger.yaml
复制代码


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


apiVersion: v1kind: ConfigMapmetadata:  name: deployer-trigger-config  namespace: defaultdata:  "deployer-trigger.yaml": |-    apiVersion: tekton.dev/v1alpha1    kind: PipelineRun    metadata:      name: tekton-kn-sample    spec:      pipelineRef:        name: build-and-deploy-pipeline      resources:        - name: git-source          resourceRef:            name: eventing-tekton-serving-git      params:        - name: pathToContext          value: "src"        - name: pathToYamlFile          value: ""        - name: imageUrl          value: "registry.cn-hangzhou.aliyuncs.com/knative-sample/eventing-tekton-serving-helloworld"        - name: imageTag          value: "1.0"      trigger:        type: manual      serviceAccount: pipeline-account
复制代码


执行命令如下:


# Create clusterrolekubectl apply -f serving/clusterrole.yaml
# Create clusterrolebindingkubectl apply -f serving/clusterrolebinding.yaml
# Create serviceaccountkubectl apply -f serving/serviceaccount.yaml
# Create configmapkubectl apply -f serving/configmap.yaml
# Create servicekubectl apply -f serving/service.yaml
复制代码

配置 Eventing 中 GitHub 事件源

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


创建 GitHub Token


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


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



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


apiVersion: v1kind: Secretmetadata:  name: githubsecrettype: OpaquestringData:  accessToken: personal_access_token_value  secretToken: asdfasfdsaf
复制代码


执行命令使其生效:


kubectl  apply -f eventing/githubsecret.yaml
复制代码


创建 GitHub 事件源


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


apiVersion: sources.eventing.knative.dev/v1alpha1kind: GitHubSourcemetadata:  name: deployer-github-sourcesspec:  eventTypes:  - pull_request  ownerAndRepository: knative-sample/eventing-tekton-serving  accessToken:    secretKeyRef:      name: githubsecret      key: accessToken  secretToken:    secretKeyRef:      name: githubsecret      key: secretToken  sink:    apiVersion: serving.knative.dev/v1alpha1    kind: Service    name: deployer-github-trigger
复制代码


关键字段解释:


  • 指定 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 命令:


kubectl  apply -f eventing/github-source.yaml
复制代码


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


kubectl  apply -f eventing/egress.yaml
复制代码


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 给你带来更轻松的代码构建和服务部署,让你更专注于业务本身。欢迎对 Knative 有兴趣的一起交流。


相关文章:


《初识 Knative:跨平台的 Serverless 编排框架》


《Knative 初体验:Serving Hello World》


《Knative 初体验:Eventing Hello World》


《Knative 初体验:Build Hello World》


《Knative 初体验:CI/CD 极速入门》


《Knative 基本功能深入剖析:Knative Serving 的流量灰度和版本管理》


《Knative 基本功能深入剖析:Knative Serving 自动扩缩容 Autoscaler》


《Knative 基本功能深入剖析:Knative Serving 之服务路由管理》


2019-08-21 09:279699
用户头像
阿里云容器平台 ACK,企业云原生转型最佳搭档

发布了 43 篇内容, 共 23.8 次阅读, 收获喜欢 81 次。

关注

评论

发布
暂无评论
发现更多内容

谈一谈webpack打包

林浩

Java 大前端 webpack

第九章作业

武鹏

你该知道的Docker-compose

北漂码农有话说

入门WebGL,看这一篇就够了

Geek_6y2vrc

大前端 WebGL

区块链行业发展月度新动态

CECBC

产业落地 政策扶持 差混高新技术 应用场景广泛

JVM垃圾回收

羽球

这一周,我肝了公司的聚合代扣支付网关!

诸葛小猿

微信 支付宝 周期扣款 委托代扣 协议扣款

编程经典案例之函数

顿晓

函数式编程

稳定匹配:幸福不靠等,脱单要主动

KAMI

生活 算法 方法论

创业公司技术体系建设-APM

星际行者

APM

第九周总结

晨光

Android |《看完不忘系列》之okhttp

哈利迪

android

基于 opentracing + Jaeger 实现全链路追踪 ----理论部分

是老郭啊

全链路监控 OpenTracing Jaeger Go 语言

ARTS Week10

时之虫

ARTS 打卡计划

N皇后问题的回溯法实现(C++)

老王同学

Docker 网络

北漂码农有话说

Docker

Python 多进程之间共享变量

AlwaysBeta

Python 进程

第九周学习总结

赵龙

JVM 垃圾回收原理

飞雪

架构师训练营第九周作业

qihuajun

架构师训练营第九周学习总结

qihuajun

用Queue实现Stack,Moya网络框架,Sublime列操作,网络通信协议 非阻塞网络I/O NIO 数据库架构原理 John 易筋 ARTS 打卡 Week 11

John(易筋)

ARTS 打卡计划 数据库架构原理 网络通信协议 Moya 非阻塞网络I/O

LeetCode题解:70. 爬楼梯,DP遍历数组,JavaScript,详细注释

Lee Chen

大前端 LeetCode

图解+代码|常见限流算法以及限流在单机分布式场景下的思考

yes

分布式限流 单体限流 限流算法

程序的机器级表示-算术与逻辑运算

引花眠

计算机基础

第九周作业

晨光

极客时间 - 架构师培训 - 9 期作业

Damon

复杂事件处理简介

星际行者

分布式 流计算 CEP 复杂事件处理

这是我迄今为止读过的最有价值的技术书,却一行代码都没有

废材姑娘

速览国内主要银行区块链技术应用现状

CECBC

应用落地 区块链+金融 信任 部署与维护

第九周作业

赵龙

Knative 实践:从源代码到服务的自动化部署_语言 & 开发_阿里云容器平台_InfoQ精选文章