In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
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.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.