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

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
可观测可视化 Grafana 版,10个用户账号 1个月
简介: 通过之前的文章,相信大家已经熟悉了 Serving、Eventing 以及 Tekton。那么在实际使用中,我们往往会遇到一些复杂的场景,这时候就需要各个组件之间进行协作处理。例如我们提交源代码之后是否直接可以部署服务到 K8s 中? 这个场景对于用户来说很有吸引力。

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

场景介绍

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

c1


准备

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

      c2

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

c3

从源代码到服务

c4

  • 修改分支代码,提交 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/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:

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>

执行如下命令:

# 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 如下:

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_repoadmin:repo_hook , 以便通过公共仓库触发 Event 事件,并为这些公共仓库创建 webhooks 。

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

c5

更新 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 镜像,从而完成自动化发布。

代码->镜像->服务

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

c6

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

结论

从代码到服务,通过上面的示例,Knative 是否给你带来了不一样的体验?希望通过 Knative 给你带来更轻松的代码构建和服务部署,让你更专注于业务本身。欢迎对 Knative 有兴趣的一起交流。

欢迎加入 Knative 交流群

c7

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务&nbsp;ACK 容器服务&nbsp;Kubernetes&nbsp;版(简称&nbsp;ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情:&nbsp;https://www.aliyun.com/product/kubernetes
相关文章
|
1月前
|
运维 监控 持续交付
构建高效自动化运维体系:策略与实践
在数字化时代,企业IT基础设施的管理和维护变得日益复杂。为了提高效率、降低错误率并快速响应市场变化,构建一个高效的自动化运维体系至关重要。本文将探讨自动化运维的核心策略,并通过实际案例分析展示如何将这些策略应用于日常管理中,以实现IT运维的优化。
17 0
|
1天前
|
运维 监控 安全
构建高效自动化运维体系:策略与实践
【4月更文挑战第25天】在数字化转型的浪潮中,企业IT基础设施日趋复杂多变,传统的手动运维模式已难以满足快速响应和高效管理的需求。本文探讨了构建一个高效自动化运维体系的关键环节,并结合实际案例分析,提出了一系列切实可行的策略与实践方法。文章着重分析了自动化工具选择、流程设计优化以及持续监控的重要性,并讨论了如何通过这些手段降低运维成本,提升系统稳定性和安全性。
|
10天前
|
敏捷开发 监控 前端开发
深入理解自动化测试框架Selenium的架构与实践
【4月更文挑战第16天】 在现代软件开发过程中,自动化测试已成为确保产品质量和加快迭代速度的关键手段。Selenium作为一种广泛使用的自动化测试工具,其开源、跨平台的特性使得它成为业界的首选之一。本文旨在剖析Selenium的核心架构,并结合实际案例探讨其在复杂Web应用测试中的高效实践方法。通过详细解读Selenium组件间的交互机制以及如何优化测试脚本,我们希望为读者提供深入理解Selenium并有效运用于日常测试工作的参考。
15 1
|
11天前
|
自然语言处理 测试技术 API
深入理解自动化测试框架Selenium的设计理念与实践
【4月更文挑战第15天】 在现代软件开发过程中,自动化测试已成为确保产品质量和加速迭代的关键手段。Selenium作为一种广泛使用的自动化测试框架,提供了对多种浏览器和平台的支持,极大地促进了Web应用的功能测试。本文旨在剖析Selenium的核心设计理念,探讨其在实际项目中的应用,并指出常见的误区及最佳实践,以期帮助测试工程师更高效地利用Selenium进行测试工作。
|
11天前
|
运维 Kubernetes Devops
构建高效自动化运维体系:DevOps与容器技术融合实践
【4月更文挑战第15天】 在当今快速发展的信息技术时代,传统的IT运维模式已难以满足业务敏捷性的需求。本文旨在探讨如何通过整合DevOps理念和容器技术来构建一个高效的自动化运维体系。文章将详细阐述DevOps的核心原则、容器技术的基础知识,以及两者结合的优势。此外,文中还将分享一系列实践经验,包括持续集成/持续部署(CI/CD)流程的搭建、微服务架构的应用,以及监控和日志管理策略的优化,以期帮助企业实现快速、可靠且安全的软件交付过程。
|
11天前
|
测试技术 持续交付 Docker
Django中的自动化部署与持续集成实践
【4月更文挑战第15天】本文介绍了Django项目中自动化部署与持续集成的实践方法。自动化部署通过选择Ansible、Fabric或Docker等工具,编写部署脚本,配置持续集成工具(如Jenkins、GitLab CI),确保服务器环境一致,实现快速应用上线。持续集成则涉及配置版本控制系统,设置自动化构建和测试,编写全面的测试用例,集成代码质量检查工具,并配置通知机制,以提升代码质量和开发效率。这两者结合能有效提升项目的迭代速度和可靠性。
|
13天前
|
人工智能 运维 监控
构建高效自动化运维体系的实践与思考
【4月更文挑战第14天】在数字化转型的浪潮中,自动化运维作为提升系统稳定性和效率的关键手段,受到了企业的广泛关注。本文将深入探讨如何构建一个高效的自动化运维体系,涵盖从基础设施的搭建到流程的优化等多个方面。通过分析当前自动化运维的挑战及解决方案,文章旨在为读者提供一套实用的策略框架,帮助企业实现运维工作的高效化、标准化和智能化。
|
18天前
|
运维 监控 Kubernetes
构建高效自动化运维体系的实践与思考
【4月更文挑战第8天】在数字化时代,IT基础设施的复杂性日益增加,传统的手工运维模式已经难以满足快速响应和高效率的需求。本文将探讨如何通过自动化工具和策略构建一个高效的自动化运维体系,旨在提高系统的稳定性、减少人为错误以及优化资源分配。文章首先分析了自动化运维的必要性,接着介绍了实现自动化的关键技术和工具,并通过案例分析展示自动化运维体系的实际效果。最后,对自动化运维的未来发展趋势进行了展望。
|
1月前
|
敏捷开发 测试技术 持续交付
深入探索软件测试自动化:框架与实践
在快速演进的软件行业中,测试自动化已成为确保产品质量和加快上市速度的关键因素。本文将深入分析测试自动化框架的构建要点,探讨其在实际应用中的效益,以及实施过程中可能面临的挑战。通过对比手动测试与自动化测试的优势与局限,本文旨在为读者提供一套系统化的测试自动化实践指南,以支持更高效、可靠的软件开发周期。
12 0
|
1月前
|
运维 Prometheus 监控
构建高效稳定的云基础设施:自动化运维策略与实践
在动态的云计算环境中,自动化运维(AIOps)已成为确保服务稳定性和效率的关键。本文将深入探讨构建高效稳定云基础设施的策略,重点关注自动化工具的选择、配置管理的最佳实践、持续集成与持续部署(CI/CD)流程的优化,以及监控和日志分析的重要性。通过这些策略的实施,企业能够减少人为错误,提高响应速度,并最终实现运维效率的显著提升。