Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to get started with CICD in Knative

2025-01-15 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

Shulou(Shulou.com)05/31 Report--

Today, I will show you how to get started with CICD in Knative. The content of the article is good. Now I would like to share it with you. Friends who feel in need can understand it. I hope it will be helpful to you. Let's read it along with the editor's ideas.

The Knative community has been talking about replacing Build modules with Tekton for a long time. Knative Build has officially stated that Knative Build is no longer recommended.

If you know what Knative Build is, it will be easy for you to understand Tekton.

Knative Build summed up his sentence as follows: a Kubernetes-native Build resource.

Tekton summed up his sentence as follows: a K8s-native Pipeline resource. Https://tekton.dev can see that the positioning of the two is very similar, but the design of Tekton is richer and more complete in terms of function, which is why the community finally adopted Tekton. Next let's take a look at the core concepts of Tekton.

Getting started with Tekton

Tekton mainly consists of the following five core concepts:

Task

TaskRun

Pipeline

PipelineRun

PipelineResource

Each of the above five concepts is provided in the form of CRD. Here is a brief description of the meaning of these five concepts.

Task

Task is a template for task execution. The reason why Task is a template is that the definition of Task can contain variables, and Task needs the specific value of a given variable when it is actually executed. Tekton's Task is very similar to the definition of a function. Task defines which input parameters are required through inputs.params, and each input parameter can also specify a default value. The steps field of the Task indicates which sub-steps the current Task consists of. Each step is the execution of an image, and the startup parameters of the image can be configured using template syntax through the input parameters of Task.

ApiVersion: tekton.dev/v1alpha1kind: Taskmetadata: name: task-with-parametersspec: inputs: params:-name: flags type: array-name: someURL type: string steps:-name: build image: registry.cn-hangzhou.aliyuncs.com/knative-sample/alpine:3.9 command: ["sh", "- c"] args: ["echo ${inputs.params.flags}; echo ${someURL}"] TaskRun

Task cannot be executed after it is defined, just like a function that needs to be called before it can be executed. So you need to define another TaskRun to execute Task. TaskRun is mainly responsible for setting the parameters required by Task and referencing the Task to be executed through the taskRef field.

ApiVersion: tekton.dev/v1alpha1kind: TaskRunmetadata: name: run-with-parametersspec: taskRef: name: task-with-parameters inputs: params:-name: flags value: "--set"-name: someURL value: "https://github.com/knative-sample"Pipeline

A TaskRun can only execute one Task, and Pipeline is needed when you need to orchestrate multiple Task. Pipeline is a template for orchestrating Task. The params of Pipeline declares the input parameters required for execution. Pipeline's spec.tasks defines the Task that needs to be choreographed. Tasks is an array in which the task is not executed in the order declared by the array, but through the runAfter to declare the order in which the task is executed. When parsing CRD, Tekton controller parses the order of Task, and then executes it according to the set order. Pipeline needs to pass in the necessary parameters to each Task when orchestrating the Task, and the values of these parameters can come from the params of the Pipeline itself.

ApiVersion: tekton.dev/v1alpha1kind: Pipelinemetadata: name: pipeline-with-parametersspec: params:-name: context type: string description: Path to context default: / some/where/or/other tasks:-name: task-1 taskRef: name: build params:-name: pathToDockerFile value: Dockerfile-name: pathToContext value: ${params.context}-name : task-2 taskRef: name: build-push runAfter:-source-to-image params:-name: pathToDockerFile value: Dockerfile-name: pathToContext value: "${params.context}" PipelineRun

Like Task, the definition of Pipeline cannot be executed directly after it is completed, and PipelineRun is required to execute Pipeline. The main function of PipelineRun is to set the necessary input parameters for Pipeline and execute Pipeline.

ApiVersion: tekton.dev/v1alpha1kind: PipelineRunmetadata: name: pipelinerun-with-parametersspec: pipelineRef: name: pipeline-with-parameters params:-name: "context" value: "/ workspace/examples/microservices/leeroy-web" PipelineResource

Four core concepts of Tekton have been introduced earlier. Now we know how to define task, execute task, and orchestrate task. But maybe you also want to share resources among Task, and that's what PipelineResource is for. For example, we can put git warehouse information in PipelineResource. So that all Task can share this data.

PiVersion: tekton.dev/v1alpha1kind: PipelineResourcemetadata: name: wizzbang-git namespace: defaultspec: type: git params:-name: url value: https://github.com/wizzbangcorp/wizzbang.git-name: revision value: master authentication information

Git repositories and image repositories all require authentication. Therefore, we also need a mechanism to set authentication information. Tekton itself is the native choreography system of Kubernetes. Therefore, you can directly use Kubernetes's ServiceAccount mechanism to achieve authentication. Examples are as follows:

Define a secret that stores the authentication information of the image repository

ApiVersion: v1kind: Secretmetadata: name: ack-cr-push-secret annotations: tekton.dev/docker-0: https://registry.cn-hangzhou.aliyuncs.comtype: kubernetes.io/basic-authstringData: username: password:

Define ServiceAccount and use the secret above

ApiVersion: v1kind: ServiceAccountmetadata: name: pipeline-accountsecrets:- name: ack-cr-push-secret

Reference ServiceAccount in PipelineRun

ApiVersion: tekton.dev/v1alpha1kind: PipelineRunmetadata: generateName: tekton-kn-sample-spec: pipelineRef: name: build-and-deploy-pipeline... ... ServiceAccount: pipeline-accountHello World

Https://github.com/knative-sample/tekton-knative this is a complete Tekton Hello World. Let's experience this Hello World together. Before you start the actual combat, you need to have a Kubernetes cluster, and you also need to install Knative and Tekton. The release-v0.5.2.yaml in tekton-knative is submitted directly to the Kubernetes cluster to complete the installation of Tekton. Let's start to experience the automated process of using Tekton from source code to build to deployment.

Clone code

Clone code to local.

Git clone https://github.com/knative-sample/tekton-knative

Create PipelineResource

The main content is in the resources/picalc-git.yaml file. The main thing shown below is to save the https://github.com/knative-sample/tekton-knative in resource for other resources to use.

ApiVersion: tekton.dev/v1alpha1kind: PipelineResourcemetadata: name: tekton-knative-gitspec: type: git params:-name: revision value: master-name: url value: https://github.com/knative-sample/tekton-knative create task

Create task. In this example, we create two task:source-to-image and deploy-using-kubectl

The main content of source-to-image is in the tasks/source-to-image.yaml file. The main function of this task is to compile the source code into a mirror. The main purpose is to use kaniko to realize the ability to compile Docker images in the container. The parameters of this Task are mainly to set some information about the compilation context, such as Dockerfile, ContextPath, and the target image tag.

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

The main content of deploy-using-kubectl is in the tasks/deploy-using-kubectl.yaml file. As shown below, the main function of this Task is to get the information of the target image through the parameters, and then execute a sed command to replace the _ _ IMAGE__ in the Knative Service yaml with the target image. And then publish it to Kubernetes through kubectl.

ApiVersion: tekton.dev/v1alpha1kind: Taskmetadata: name: deploy-using-kubectlspec: 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: update-yaml image: alpine command: ["sed"] args:-"- I"-"- e"-"s ownership of IMAGEN: ${inputs.params.imageUrl}: ${inputs.params.imageTag} G "-" / workspace/git-source/$ {inputs.params.pathToYamlFile} "- name: run-kubectl image: registry.cn-hangzhou.aliyuncs.com/knative-sample/kubectl:v0.5.0 command: [" kubectl "] args: -" apply "-"-f "-" / workspace/git-source/$ {inputs.params.pathToYamlFile} "defines Pipeline

We already have two Task, and now we will use a PIpeline to orchestrate the two Task:

ApiVersion: tekton.dev/v1alpha1kind: Pipelinemetadata: name: build-and-deploy-pipelinespec: resources:-name: git-source type: git params:-name: pathToContext description: The path to the build context Used by Kaniko-within the workspace default: src-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 to apply to the built image tasks:-name: source-to-image taskRef: name: source-to-image params:-name: pathToContext value: "${params.pathToContext}"-name: imageUrl Value: "${params.imageUrl}"-name: imageTag value: "${params.imageTag}" resources: inputs:-name: git-source resource: git-source-name: deploy-to-cluster taskRef: name: deploy-using-kubectl runAfter:-source-to-image params:-name: pathToYamlFile value: "${params.pathToYamlFile} "- name: imageUrl value:" ${params.imageUrl} "- name: imageTag value:" ${params.imageTag} "resources: inputs:-name: git-source resource: git-source authentication information

Define a Secret and ServiceAccount as shown below. And grant the ServiceAccount binding permission to execute Knative Service.

ApiVersion: v1kind: Secretmetadata: name: ack-cr-push-secret annotations: tekton.dev/docker-0: https://registry.cn-hangzhou.aliyuncs.comtype: kubernetes.io/basic-authstringData: username: password:-- apiVersion: v1kind: ServiceAccountmetadata: name: pipeline-accountsecrets:- name: ack-cr-push-secret---apiVersion: v1kind: Secretmetadata: name: kube-api-secret annotations: kubernetes.io/service-account.name: pipeline-accounttype: kubernetes. Io/service-account-token---kind: RoleapiVersion: rbac.authorization.k8s.io/v1metadata: name: pipeline-rolerules:- apiGroups: ["serving.knative.dev"] resources: ["services"] verbs: ["get" "create", "update", "patch"]-apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata: name: pipeline-role-bindingroleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: pipeline-rolesubjects:- kind: ServiceAccount name: pipeline-account definition PIpelineRun

The authentication information corresponding to ServiceAccount is performed by binding with PIpelineRun. See run/picalc-pipeline-run.yaml file

ApiVersion: tekton.dev/v1alpha1kind: PipelineRunmetadata: generateName: tekton-kn-sample-spec: pipelineRef: name: build-and-deploy-pipeline resources:-name: git-source resourceRef: name: tekton-knative-git params:-name: pathToContext value: "src"-name: pathToYamlFile value: "knative/helloworld-go.yaml"-name: imageUrl value: "registry.cn-hangzhou.aliyuncs.com/knative- Sample/tekton-knative-helloworld "- name: imageTag value:" 1.0 "trigger: type: manual serviceAccount: pipeline-account execute HelloWorldkubectl apply-f tasks/source-to-image.yaml-f tasks/deploy-using-kubectl.yaml-f resources/picalc-git.yaml-f image-secret.yaml-f pipeline-account.yaml-f pipeline/build-and-deploy-pipeline.yaml-f run/picalc-pipeline-run.yaml

Take a look at the pod information, which might look like this:

└─ # kubectl get podNAME READY STATUS RESTARTS AGEtekton-kn-sample-45d84-deploy-to-cluster-wfrzx-pod-f093ef 0 8htekton-kn-sample-45d84-source-to-image-7zpqn-pod-c2d20c 3 Completed 0 8htekton-kn-sample-45d84-source-to-image-7zpqn-pod-c2d20c 0 Completed 0 8 h or more is all about how to get started with CICD in Knative. For more information about how to get started with CICD in Knative, you can search the previous articles or browse the following articles to learn! I believe the editor will add more knowledge to you. I hope you can support it!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report