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

时间 2019-11-19

原文原文链接

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

场景介绍

如今的场景是这样的：代码构建->事件驱动->服务部署。那么对应到 Knative 中，须要 Eventing、Tekton 和 Serving 一块儿协做来实现这个场景。git

准备

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

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

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

接下来咱们开始一步步搞起。
web

部署 Tekton 服务

咱们看一下建立代码构建 Task 和部署服务Task。docker

代码构建Task：api

apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
  name: source-to-image
spec:
  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/v1alpha1
kind: Task
metadata:
  name: image-to-deploy
spec:
  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:app

apiVersion: v1
kind: Secret
metadata:
  name: ack-cr-push-secret
  annotations:
    tekton.dev/docker-0: https://registry.cn-hangzhou.aliyuncs.com
type: kubernetes.io/basic-auth
stringData:
  username: <cleartext non-encoded>
  password: <cleartext non-encoded>

执行以下命令：less

# Create Pipeline
kubectl apply -f tekton/pipeline/build-and-deploy-pipeline.yaml

# Create PipelineResource
kubectl apply -f tekton/resources/picalc-git.yaml

# Create image secret
kubectl apply -f tekton/image-secret.yaml

# Create task: soruce to image
kubectl apply -f tekton/tasks/source-to-image.yaml

# Create task: deploy the image to cluster
kubectl apply -f tekton/tasks/image-to-deployer.yaml

部署 Knative Serving 服务

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

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: deployer-github-trigger
spec:
  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: v1
kind: ConfigMap
metadata:
  name: deployer-trigger-config
  namespace: default
data:
  "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 clusterrole
kubectl apply -f serving/clusterrole.yaml

# Create clusterrolebinding
kubectl apply -f serving/clusterrolebinding.yaml

# Create serviceaccount
kubectl apply -f serving/serviceaccount.yaml

# Create configmap
kubectl apply -f serving/configmap.yaml

# Create service
kubectl 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_repo 和 admin:repo_hook , 以便经过公共仓库触发 Event 事件，并为这些公共仓库建立 webhooks 。

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

更新 githubsecret.yaml 内容。若是生成的是 personal_access_token_value token, 则须要设置 secretToken 以下：

apiVersion: v1
kind: Secret
metadata:
  name: githubsecret
type: Opaque
stringData:
  accessToken: personal_access_token_value
  secretToken: asdfasfdsaf

执行命令使其生效：

kubectl  apply -f eventing/githubsecret.yaml

建立 GitHub 事件源

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

apiVersion: sources.eventing.knative.dev/v1alpha1
kind: GitHubSource
metadata:
  name: deployer-github-sources
spec:
  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 给你带来更轻松的代码构建和服务部署，让你更专一于业务自己。

本文做者：一绿舟

原文连接

本文为云栖社区原创内容，未经容许不得转载。