写点什么

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

2019 年 8 月 21 日

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 年 8 月 21 日 09:278376
用户头像
阿里云容器平台 ACK,企业云原生转型最佳搭档

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

关注

评论

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

架構師訓練營第 1 期 - 第 01 周作業

Panda

第一周命题作业

崔方剑

极客大学架构师训练营

第一周学习总节

兵长

LeetCode题解:94. 二叉树的中序遍历,递归,JavaScript,详细注释

Lee Chen

LeetCode 前端进阶训练营

极客时间架构师培训1期-第1周作业

Kaven

第一周作业一:食堂就餐卡系统设计

登顶计划

极客大学架构师训练营

Spring Cloud 微服务实践 (3) - 服务间的调用

xiaoboey

Spring Cloud 熔断 服务调用 Feign

架构师训练营第 1 期-第一周周总结

郑凯元

极客大学架构师训练营

架构师训练营第一期第一周命题作业

朱磊

极客大学架构师训练营

第1周 架构方法 浮皮潦草之总结

Pyr0man1ac

极客时间架构师培训1期-第1周总结

Kaven

目标:创业团队组织搭建的内在逻辑

boshi

创业 团队组织

中国法定数字货币发展新机遇

CECBC区块链专委会

数字货币 数字经济

架构师训练营第一周作业 (就餐卡UML图)

springH₂O

食堂就餐卡系统设计

钟杰

极客大学架构师训练营

食堂就餐卡系统设计

fmouse

训练营第一周作业1

仲夏

训练营第一周作业 2

仲夏

你附近的人都有谁,这个功能是怎么实现的?

老胡爱分享

redis geo

架构师训练营第 1 期 命题作业

张建亮

「架构师训练营第 1 期」-食堂卡管理系统

睡不着摇一摇

极客大学架构师训练营

架构师训练营第 1 期 - 作业提交

Todd-Lee

极客大学架构师训练营

架构师训练营第 1 期-第一周学习总结

Todd-Lee

极客大学架构师训练营

第一周总结

fmouse

极客大学架构师训练营

RxSwift和RxCocoa入门

teoking

ios swift

week1-UML图

张兵

极客大学架构师训练营

用简单而又专业的角度为大家揭秘区块链和比特币

CECBC区块链专委会

比特币 区块链 数字货币

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

朱磊

极客大学架构师训练营

第一周学习总结

崔方剑

极客大学架构师训练营

项目滞后,如何让自己的技术快速成长

郎哲158

个人成长 舒适区 熟练工

区块链将掀开人类的伟大时代

CECBC区块链专委会

区块链 智能合约 价值物联网

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

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